1oT

See how smoothly an IoT eSIM profile switch happens in 1oT Terminal. This demo takes you through the whole process, from selecting a new profile and starting the switch to confirming the device reconnects. You’ll also see how our systems coordinate each step behind the scenes. Planning your own deployment? Request your 1oT testing kit.

~70% of our recent inbound enquiries at 1oT have been about SGP.32. Yet a few companies have still chosen SGP.22, and I understand where they’re coming from. If you are planning to deploy 100,000 devices, you want to make sure interoperability is there and that all pieces of the architecture have been validated and tested. At 1oT, we have tested with all the main DP+ providers using our IPAe cards, and we've completed platform integrations. But maturity is not the only thing I would look at. There are two practical questions to consider. 𝟭. 𝗪𝗵𝗶𝗰𝗵 𝘀𝘁𝗮𝗻𝗱𝗮𝗿𝗱 𝗯𝗲𝘁𝘁𝗲𝗿 𝗳𝗶𝘁𝘀 𝘁𝗵𝗲 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁? SGP.22 was tailored for consumer devices such as phones and tablets, where someone is usually available to scan a QR code, connect to Wi-Fi, and manage the whole process. IoT is different. The devices often have no human interface and nobody around to touch them. That’s the environment SGP.32 was built for. SGP.22 can still be used for IoT, but it will need a dedicated firmware to run on the device. This firmware is called LPA (Local Profile Assistant) and controls how the device behaves when receiving a profile from the DP+. Although it’s not rocket science, it does require engineering expertise and resources. However, once you have the SIM cards and your own LPA in place, you are less reliant on another software provider. With our SGP.32 eSIM, the profile assistant is already on the card as an IPAe (IoT Profile Assistant on the eUICC). The R&D team doesn't need to build that part of the code, which helps you get to market faster. Profiles can then be managed remotely through the eIM software using an API or user interface. The first connection is also something to consider. Your devices need a way to get online before they can download a new profile. With SGP.22, you need to make sure that initial connectivity is available through Wi-Fi, Ethernet, or an existing cellular profile. Our SGP.32 cards include a bootstrap profile and connect globally out of the box, so connectivity isn’t something you need to worry about. 𝟮. 𝗜𝘀 𝘁𝗵𝗲 𝗽𝗿𝗼𝘃𝗶𝗱𝗲𝗿 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗿𝗲𝗮𝗱𝘆 𝘁𝗼 𝘀𝘂𝗽𝗽𝗼𝗿𝘁 𝗶𝘁? I’ve seen providers claim they support SGP.32, but when a customer asks for a sample card, they can’t provide one and start coming up with excuses why. That will naturally make companies question whether the technology is actually ready. With 1oT, you can get a sample card and an account to run a proof of concept using your own hardware. If you’re weighing up your options, I strongly advise testing it on your own hardware and in the field before committing to a large deployment. That gives you something concrete to base the decision on, rather than just comparing spreadsheets. Feel free to message me if you’d like to chat through your setup and where to start!

Your IoT device might connect perfectly during office testing. But what happens when it crosses a border, switches networks or goes through a factory producing thousands of units? We’ve seen devices pass testing in Europe, then fail to connect when they reached a deployment market in Africa. These issues reach our tech support team after the devices have already been shipped. We can usually isolate the problem quickly: i.e the hardware uses NB-IoT, but there’s no NB-IoT coverage at the destination, or a regional module deployed out of the area of supported bands. That’s why I recommend testing the actual device and SIM/eSIM together in the markets where they’ll operate, starting with the basic checks: - Does the device connect and send data through to your backend? - Does an SMS go through and does profile provisioning work? - Does the device handover cells during border crossings? Then put a small set of devices into the field. For moving devices, test the routes they’ll take, including changes between cell towers, roaming between networks and border crossings. Even with automatic network selection configured, those conditions are difficult to reproduce in the office. In the field, you can also see the detailed session breakdown in our connectivity management platform, including which network each device joined and which technology it used. Before a larger rollout, I’d also recommend a small production run. That might be 50 or 100 units, depending on the volume you’re comfortable with. The point is to play the whole production process through and see whether your factory, connectivity platform and other vendors can handle it together: factory provisioning, IMEI pairing, low-cost RF checks and the API calls you’ll use to manage connections at scale. I’ve worked through these small production runs with multiple R&D companies, and I’d say there’s no better way to test the process. At 1oT, we can help you work through what to test and support the eSIM profile provisioning side, including how profiles are changed and who controls the process. If you’re planning a rollout, let’s talk through your setup before you move into larger-scale production.

Your IoT device can switch eSIM profiles successfully and still fail to connect. The eSIM transaction happens on the card, but the subscription behind the new profile also needs to be activated on the telecom’s core network and configured correctly. Getting both right can mean coordinating between two or three different companies. If you're handling the switch yourself, you'll need to: - Trigger the profile download on your current telecom's platform - Log into the new telecom's platform and click activate - Suspend the old subscription so you're not paying to keep it alive (You could activate the new subscription in advance, but you'd be paying for it before using it.) There isn't much incentive for telecoms to work together. At 1oT , we focus on what the customer is trying to achieve. Our integrations with 12 telecoms let us handle those steps automatically through Terminal, our connectivity management platform. Customers choose the profile they want enabled on their devices and start the download through Terminal. We activate the subscriptions behind the new profiles, so connectivity is there when the devices switch. We also suspend the old subscriptions so there aren't any leftover costs for keeping those SIMs live.

The average IoT fleet today is roughly 70% domestic and 30% international, BUT in the next ~5 years, companies expect it to be closer to 50/50. That is a significant change! The numbers come from Pelion’s latest research and confirm that right now it’s still much easier to do business in your home market, and relatively tricky to scale outside it. This indicates that managing connectivity across borders will become a much bigger part of day-to-day operations for IoT companies. More networks, commercial terms and coverage issues for the team to handle. When you are managing devices in 12 or 50 different countries, you might have multiple mobile operators with different pricing models and commercial terms. Different APNs and network configurations. Different coverage problems. And it gets much harder to have a good overview of what’s going on with your whole fleet. SGP.32 will solve a lot of this in the future. But the other big topic is the platform, and how to bring all of that information together in one place. I believe if we want to see more IoT cases booming, we need to make it easy for companies to scale from their home market to international. With 1oT Terminal, customers can choose from multiple telecoms and manage their connectivity in one place. It makes it so much easier to have a broad overview of what’s going on. You really don’t want to be patching together all these systems yourself!

Super excited to see that ~95% of our IoT eSIM transactions are succeeding, especially when that figure is just 13% with M2M eSIM! It’s still a small sample from the last two months, but we’re seeing what that means for customers during testing. When you're testing an IoT device, you don't always know every connectivity requirement upfront. A setup looks suitable, then another requirement appears. You need to find out whether a different setup will work. We recently had a customer test where that meant trying three profiles. We knew the first wouldn't meet their needs. The second didn't support everything they needed for their VPN and fixed IP configuration. The third was exactly what they needed. With separate physical SIMs, trying those alternatives would involve shipping cards and waiting for delivery. With profile downloads, the customer could keep working with the hardware already in front of them. Remote profile changes were possible with M2M eSIM too. What we're examining now is how reliably those changes complete with IoT eSIM in our deployments. For a manufacturer, the value is being able to act on what they learn. Discover a requirement, try another profile, and continue testing. That's what we care about: how much easier we make it for the customer to get their device working the way it needs to.