The third article in our SGP.32 series, if you haven’t read the previous article you can go to our website https://simplexwireless.com/site/news and catch-up. In this article we are jumping into the client side of Device or SIM card implementations. As we mentioned in the previous article the Local Profile Assistant (LPA) that was introduced in the Consumer eSIM (SGP.22) specification is now being renamed to IoT Profile Assistant (IPA) in the IoT eSIM specification SGP.32. There are two variations of the client application on the spec of the IPA; IPA.d and IPA.e. The IPA.d resides on the Device and the IPA.e resides on the eUICC and runs at the OS level of the SIM card.

Why is it that when we were already settled on a device-based client with the LPA there is a new eUICC based client introduced in the latest specifications, why couldn’t the industry just agree on one over the other?

The device-based IPA.d has the opportunity of utilizing a rich environment of an operating system. There is plenty of processing power to put together a sophisticated application that can do more than just download an eSIM from the SM-DP+. With a device-based client you can implement business logic for failover scenarios. For example, when “Profile A” does not have service, it will try to switch to “Profile B” after a certain period time. A Device client can use well established client-server protocols such as MQTT or LwM2M that already have tried and true server solutions in place and are designed towards low bandwidth / small power usage IoT type communication. This is ideal choose as a communication channel for your eSIM IoT Manager (eIM) to manage a fleet of devices.

The challenge with a device-based IPA.d is jungle of operating system environments, meaning that there is a significant amount of variations of what Operating Systems do IoT devices use. To mention a few: Linux, FreeRTOS, RIOT, TinyOS and even Windows 10 IoT. Just under the Linux umbrella there are many variants from Ubuntu, Yocto, Rasperry Pi OS and OpenWRT. They all have different software libraries and extension capabilities. In addition to this when developing the software, you have to take into account if its Intel CPI or ARM32 or ARM64 as well. This shows the point that even if Linux is the dominant IoT OS out there many cases will require a new version of the IPA.d client depending on the device – and they all need to be maintained over time.

But luckily, we have eUICC based IPA.e right? An IPA client that resides in the operating system of the eUICC and hence is not affected by the device’s operating environment complexity. The IPA.e can be shipped alongside the SIM card upon personalization and will work out of the box in any IoT device, almost. There are some device requirements that are needed for this to work. The eUICC has to be able to open a TCP/IP channel using Bearer Independent Protocol (BIP) and the device has to support that. This is not a showstopper by any means, but it is not as sophisticated as an MQTT client would be without having a constant keep-alive communication to the server. To perform an update operation such as downloading an eSIM you have to either wakeup the client with an SMS, using periodical polling or by subscribing to an event such as a power cycle.  

So now we have covered both IPA.d and IPA.e and their pros and cons, but which one is the winner? We believe that it depends which role you play in the ecosystem. If you are a Device Maker and you want to make your device attractive in today’s market, you want to have eSIM support included therefore your choice is likely IPA.d. You control the environment, and you can ship the device with the IPA.d tried and tested in your environment. If you are a Connectivity Services Provider such as Simplex Wireless we do not control the device. Our customers can range from simple tracking solutions to advanced smart city platforms to CPE routers. Our customers’ IoT device Operating Systems vary widely, and it is difficult for us to have multiple IPA.d variants available. Therefore, for us the best is to go with an IPA.e implementation that will work “out of the box” in our customers device. On the server-side backend, we will offer our eIM server (named SPX Anywhere) with the ability to handle both IPA.e and IPA.d. Ultimately we believe both variants will be prevalent in the market.

Let us know your thoughts on this and reach out to us from our website https://simplexwireless.com

This was written by Jan Lattunen, Chief Commercial Officer at Simplex Wireless