Freeeway AG ads

🚗 Not every digital service inside a vehicle is consumed in the same way. 📊 Connectivity may be measured in GB, conferencing in minutes or sessions, and gaming through individual purchases or events. Future services may introduce entirely new ways of measuring usage. 💡 This means monetization needs to go beyond managing subscriptions. The commercial infrastructure must understand how each service is consumed, apply the appropriate rating rules, and translate that usage into the right allowance, subscription, or charge. ⚙️ The goal is not to build a new billing model every time a new service is introduced, but to create a flexible infrastructure that can monetize different forms of digital usage as the in-car service portfolio expands. Because services will evolve. The commercial infrastructure shouldn't have to start from scratch. #ConnectedCars #ConnectedCommerce #SoftwareDefinedVehicle #DigitalMonetization #UsageBasedBilling

🚗 Connected cars are becoming more than just connected machines. As vehicles evolve into software-defined platforms, they can offer an expanding range of digital services to drivers and passengers, from infotainment and conferencing to applications and AI-powered experiences. 🤖 💡 This creates a new commercial opportunity for automotive manufacturers: extending customer relationships beyond the initial vehicle sale and generating recurring revenue throughout the vehicle lifecycle. But connectivity is only the beginning. 💳 Monetizing these services requires managing payments, subscriptions, taxation, telecom regulations, and different models for measuring and charging for usage. 🔄 This is where connected cars become connected commerce. 💬 How is your organization approaching the commercial layer of the software-defined vehicle? #ConnectedCars #SoftwareDefinedVehicle #ConnectedCommerce #AutomotiveInnovation #DigitalMonetization

🚗 A single in-car service can trigger much more than a simple payment. To commercialize digital services across Europe, automotive manufacturers need to manage three interconnected layers: 💳 Payment and taxation: Payment processing, currencies, local payment methods, and VAT. 📡 Telecommunications and regulatory compliance: Service classification, national regulatory requirements, customer identification, and data protection. ⚙️ Usage monetization: Subscriptions, allowances, bundles, metering, rating, and service provisioning. Each layer affects the others. 💡 For example, a customer purchasing additional infotainment data may need to be identified, charged in the correct currency, taxed appropriately, and have the new data allowance provisioned to the correct vehicle. This is why connected-car commerce quickly becomes more complex than simply adding a payment button. The challenge is not solving each layer separately. It is making them work together. #ConnectedCarCommerce #SoftwareDefinedVehicle #DigitalMonetization #TelecomCompliance #SubscriptionManagement

36 TB of data per month. Just 60 SIM cards. Some might look at these numbers and say: Thats not IoT. Thats something else. I disagree. At Freeeway, we handle WiFi connectivity on trains, where passengers generate massive amounts of data through a relatively small number of SIM cards. And this is precisely where the conventional understanding of IoT connectivity reaches its limits. Because managing 60 SIM cards is easy. Managing 36 TB of monthly traffic reliably across a moving fleet is a completely different challenge. The SIM card is only one small part of the equation. Behind this level of connectivity, you need a core network designed for high data volumes, sufficient capacity on leased lines, and a management layer that can handle the operational complexity. Without that infrastructure, offering large data packages is simply a commercial promise. Delivering those volumes consistently requires much more. Thats why we built Freeeways infrastructure to manage genuinely massive data traffic in IoT environments, rather than treating connectivity as a question of how many SIM cards are deployed. For me, the real measure of an IoT connectivity provider is not the number of connected devices. Its whether the infrastructure behind those connections can actually support the use case. Would you agree that 36 TB across 60 SIM cards is a different connectivity challenge than managing thousands of low-data IoT devices?

I dont think enterprises should have to operate their own eSIM infrastructure to control their connectivity. But I do think they should control the decisions behind it. That distinction is important when we think about where the eIM should sit in an SGP.32 architecture. The enterprise should decide which operators can be used, when profiles should change, where local connectivity is required and which suppliers it wants to work with. But operating the infrastructure that executes those decisions is a different job. This is where I see the role of an independent connectivity orchestrator such as Freeeway. The eUICC vendor provides the secure hardware layer. MNOs and MVNOs provide network services. Freeeway operates the eSIM orchestration layer, while the enterprise retains governance over its connectivity policy. But there is a consequence to that position which I think is important to say explicitly: Freeeway must be replaceable, too. Otherwise, we could remove one form of lock-in only to introduce another at the eIM layer. For us, the stronger SGP.32 model is therefore enterprise-controlled connectivity policy, independent orchestration, multiple network suppliers — and a tested exit path. A good platform should be able to demonstrate how customers migrate onto it. A genuinely independent one should also be able to demonstrate how they migrate away. Would “freedom to leave” make you more comfortable choosing a connectivity partner for the next 10 or 15 years? This concludes my four-post series on independence in SGP.32. My conclusion: enterprise governance, independent orchestration and a tested exit path.

There is one question I would ask any SGP.32 provider before discussing a long-term IoT deployment: “How may I leave you?” That is not pessimistic procurement. For devices expected to operate for 10 or 15 years, it is architecture. Because an exit strategy in SGP.32 means more than proving that an Operator profile can be replaced by a another Operator profile, or vice versa. That demonstrates operator portability. But it does not necessarily demonstrate control-plane portability. The more interesting test starts with an eUICC managed by the existing eIM. A second eIM is added and verified. That new eIM needs to manage the eUICC, download and activate profiles independently, before the original eIM can ultimately be removed without interrupting normal operation. Only then have you tested whether the enterprise can replace the party controlling its ability to change networks. And I think that distinction will become increasingly important as SGP.32 moves from specifications and early implementations into long-lived enterprise deployments. Supporting the standard is one thing. Demonstrating the exit path is another. Therefore, “Do you support SGP.32?” may eventually be the wrong procurement question.“Have you tested how I migrate away from you?” tells you considerably more. Would you include a tested eIM switching scenario in an SGP.32 procurement process? Part 3 of my four-post series on independence in SGP.32. In the final post, I’ll explain where I believe the eIM should sit — and who should ultimately control it.