Inside the SGP.32 Standard: What Sets IPA and LPA Apart for Next-Gen IoT eSIMs

The hearth of SGP.32 is an innovative approach to perform remote management of the subscriptions in an IoT device by using the IoT Remote Manager, or eIM, together with the IoT Profile Assistant, or IPA. This enables profile downloads from the Operator’s SM-DP+, and the rest of operations to manage the connectivity of the IoT Device.

The following diagram illustrates the SGP.32 architecture in two different flavors depending on where the IPA resides and highlights the key components and how they interact to streamline IoT profile management.

The IPA (IoT Profile Assistant) builds on the concept of the LPA (Local Profile Assistant), originally created for consumer devices and defined under SGP.22. Unlike the LPA, which was defined to allow the user to control the subscriptions directly in the device, the IPA is specifically designed for IoT and lacks a graphical user interface (GUI). This GUI-free design allows for lower power consumption and broader device compatibility, as many IoT devices operate without user interfaces. Instead, profile management is handled by the eIM component, which allows users to control eSIM subscriptions remotely.

IPA comes in two versions, each adapted to different device capabilities and control requirements:

• IPAe (Embedded IPA): IPAe is hosted directly on the eUICC, making it a true plug-and-play solution that’s compatible with a wide range of devices. Its design keeps the IPA independent of the device itself, simplifying deployment across a range of devices and easing the integration across various platforms. For OEMs seeking a seamless integration path without requiring modifications to the device’s operating system, IPAe is an ideal choice. Additionally, because IPAe resides within the eUICC, it benefits from the eUICC’s robust security features, providing a secure environment for managing profiles.
• IPAd (Device IPA): IPAd, on the other hand, is hosted on the application layer of the device’s operating system (OS). This setup requires adaptation to specific OS environments, such as Android or Linux, allowing for closer integration with the device’s internal systems. IPAd offers greater flexibility for certain applications and the customization or addition of additional functionalities to include further Value-Added Services by the Device Manufacturer. In opposition to the IPAe, it’s  best suited for cases where OEMs have control over the OS and can customize the device environment.

The choice between IPAd and IPAe should be based on the specific requirements of the IoT deployment, considering factors such as security needs, resource availability, deployment complexity, and cost considerations.

• Our team of experts is ready to support you in the assessment to select which IPA option suits the best for your use case so can you are confident when taking the decision.

Valid supports IoT OEMs by providing flexible, standards-compliant solutions that include eSIM, eIM, and both versions of IPA (IPAe and IPAd). OEMs can choose the best IPA solution for their needs, with IPAd available for Android and Linux devices and IPAe suited for a broad range of implementations with minimal device adaptation requirements.

Check our recent post about SGP.32 eSIM engineering samples availability and IoT Connectivity White Paper to dive deeper into the SGP.32 ecosystem and see how our solutions benefit OEMs and MNOs.