<html><head></head><body>There’s a lot of excitement around the latest Remote SIM Provisioning standard, named after its specification published by the GSMA mid 2024: SGP.32. This article walks you through the standard and provides an update on its market adoption.This article builds on our previous article on&nbsp;<a href="https://monogoto.io/2023/09/25/is-your-iot-product-ready-for-the-sgp-32-esim-specification/" target="_blank" rel="noopener" data-wpel-link="internal">SGP.32</a>&nbsp;from 2023, let’s explore the latest developments.<h2>Can you remind me again about SGP.32?</h2>It all starts with embedded SIMs, or eSIMs, which are soldered directly onto IoT devices. eSIMs are becoming increasingly popular due to their compact size, enhanced security and improved efficiency as they can be integrated into the manufacturer’s production line. However, the most significant advantage is the freedom to switch providers. Replacing plastic SIMs across a deployed fleet of devices is highly impractical. While traditional SIM cards do not create vendor lock-in, the threshold to migrate devices to a different provider usually results in companies sticking to one vendor, forever. Although an eSIM itself cannot be swapped, its profile or identity on this eSIM can be remotely updated. This process for remote SIM provisioning of IoT devices is standardized under the SGP.32 specifications.<h2>It already works on my phone, what’s the big deal?</h2>Phones use a similar process to update the profiles of eSIMs (as defined in GSMA’s SGP.22 specification). eSIMs on phones are managed one at a time, with user-friendly interfaces (like QR codes or SMS verification). IoT devices usually don’t have such luxury. They are often deployed in remote locations, with minimal bandwidth, memory, and power.&nbsp;To address these challenges, industry experts developed an updated process designed for resource-constrained devices. This process requires minimal data throughput, no physical interactions with the devices, and enables management of multiple devices simultaneously.<h2>How does it work, really?</h2>The SGP.32 specification revolves around three key components that enable efficient and secure profile management, the IPA, eIM and SM-DP+.<img src="https://s3-us-west-1.amazonaws.com/wevolver-project-images/froala%2F1742289531375-SGP32+update.jpg" style="width: 100%px;" class="fr-fic fr-dib"><figure id="isPasted"><figcaption>Remote SIM Provisioning architecture</figcaption></figure>IPA (IoT Profile Assistant)The IPA is a piece of software that operates on the IoT devices to manage their profiles. When embedded directly into the SIM, it is known as IPAe (embedded IPA). When installed on the device, typically within the cellular module, it is called IPAd (device-based IPA). Acting as a local agent, the IPA interacts with one or more eIM instances to facilitate profile management.eIM (eSIM IoT Remote Manager)The eIM is a cloud-based solution that communicates with IPAs to manage SIM profile management. It connects with backend systems that handle SIM provisioning (SM-DP+) and can direct the IPA to enable, disable, delete, or download profiles.SM-DP+&nbsp;(Subscription Manager Data Preparation Plus)The SM-DP+ is a cloud-based service which stores, encrypts, and delivers SIM profiles. Once requested by the eIM, the IPA downloads a new SIM profile from the SM-DP+ and provisions it to the eUICC.<h2>Let’s be honest, does everything work?</h2>As of early 2025, the technology is still in its infancy. The specifications have only recently been solidified and the market is only starting to implement them. Initial testing environments have been established, allowing experimentation and early-stage validation.Currently, several industry players are working on integrating SGP.32. SIM vendors like <a href="https://kigen.com/" target="_blank" rel="noopener external noreferrer" data-wpel-link="external">Kigen</a> and <a href="https://www.gi-de.com/en/" target="_blank" rel="noopener external noreferrer" data-wpel-link="external">G+D</a> have initial versions of the IPAe running on their SIMs, and provide corresponding eIM solutions. As of early February 2025, module makers have yet to release modules containing the IPAd. Connectivity providers like Monogoto are collaborating with both module manufacturers and SIM vendors to integrate the SGP.32 process into their connectivity cloud platforms.Is it ready for large-scale production? Not yet. However, the market is gearing up to test and refine the process, offering developers an opportunity to explore its potential.&nbsp;To learn about the current state of SGP.32 and to get an understanding of the full SIM provisioning process, watch the demo video below. The demo uses the Kigen SIM and Kigen eIM, together with the Monogoto Cloud.<iframe width="640" height="360" src="https://www.youtube.com/embed/3meVG9Xd9lo?&amp;wmode=opaque&amp;enablejsapi=1&amp;origin=https://www.wevolver.com" frameborder="0" allowfullscreen="" class="fr-draggable" data-lf-form-tracking-inspected-kn9eq4roawkarlvp="true" data-lf-yt-playback-inspected-kn9eq4roawkarlvp="true" data-lf-vimeo-playback-inspected-kn9eq4roawkarlvp="true"></iframe> <div data-id="be109c3" data-element_type="widget" data-widget_type="theme-post-content.default" id="isPasted"><h3>Conclusion</h3>While the potential is enormous, widespread adoption will take time. The industry needs to prepare eSIMs for certification and module makes need to release new firmware which embeds the IPA.&nbsp;Despite these challenges, now is the perfect time to get started. Early adopters can gain a competitive edge by exploring the technology and preparing for future market demands.Don’t let these challenges hold you back! Monogoto now offers an SGP.32 evaluation kit, enabling developers to gain hands-on experience and get a grasp of the true potential of Remote SIM Provisioning for IoT. <a href="https://monogoto.io/labs/sgp-32-ready-kit/" target="_blank" rel="noopener" data-wpel-link="internal">Learn more about the SGP.32 Ready Kit</a>.</div><div data-id="1fd13d7" data-element_type="widget" data-widget_type="author-box.default"> </div></body></html>

This article walks you through the standard and provides an update on its market adoption.

SGP.32: The Future of Remote SIM Provisioning for IoT Devices

<h2 id="isPasted">The days of monolithic binaries are over</h2>As the IoT market is slowly maturing, IoT systems are becoming increasingly complex and versatile. As a result, embedded devices are composed of distinct firmware components made by different parties working together, often running on multiple MCUs simultaneously.This multi-party involvement has implications for how firmware is developed and updated. Rather than creating single binaries which are built and flashed to devices at once, firmware is constructed from multiple components. Each of these components can be managed and updated separately, just like cloud applications, allowing you to do what you do best. Whether it’s developing modem firmware, application code, bootloader software, drivers for sensors, or interfaces with hardware secure modules.Let’s explore the opportunities of remotely managing multi-component firmware in IoT devices by using the LwM2M standard.This article is the part of a series about OTA software updates for IoT devices. Read the first article <a href="https://www.avsystem.com/blog/remote-firmware-updates-for-iot-devices/" rel="noopener" target="_blank">here</a>.<h2>Problems with full-firmware updates</h2>When dealing with IoT devices which are highly constrained due to their limited available bandwidth, power and memory size, the process for device firmware updates (DFU) has to be carefully crafted. Updating the firmware can be resource-intensive, certainly when the network connection is unstable, leading to a lengthy update process which requires the radio to be on and drains the device’s battery.As IoT devices become more complex, so do their firmware, leading to increasingly large update files. This not only increases the necessary time and required energy to perform an update, it also makes the update more prone to errors as the devices require a stable connection for a longer period of time.In contrast to single-binary firmware which are to be updated fully (as described in our <a href="https://www.avsystem.com/blog/remote-firmware-updates-for-iot-devices/" rel="noopener" target="_blank">latest article</a>), embedded firmware can be composed of separated code blocks which can be configured and updated independently. A component-based update process can significantly reduce the required resources for updating the device’s firmware.<h2 id="isPasted">Deconstructing embedded device firmware</h2>Firmware is usually stored in the device’s flash memory; non-volatile memory which persists after a reboot and can be electronically rewritten. To virtually isolate different firmware components, flash memory is split into multiple partitions. Different firmware components – such as the bootloader, application firmware or the tinyML model – reside in dedicated flash partitions. Consequently, one partition can be safely updated while the others remain untouchedEmbedded devices usually don’t contain just one MCU. Instead they often contain multiple processors each being responsible for a dedicated task. Next to the main MCU, the device may include one or multiple radio modems for cellular or Bluetooth communication. It may include smart sensors which include local processing to add more intelligence. For example, cameras which detect the number of cars, bikes or people passing by, or microphones which only detect specific sound events. All of these MCUs may contain flash partitions which can become updatable.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NDgxMzg4LWJsb2dwb3N0LWZsYXNoLW11bHRpLTEuanBnIiwiZWRpdHMiOnsicmVzaXplIjp7IndpZHRoIjo5NTAsImZpdCI6ImNvdmVyIn19fQ==" style="width: 302px;" class="fr-fic fr-dib">A multi-MCU IoT device with partitioned flash memoryMaking flash partitions updatableIn order to make a firmware component updatable, a dedicated partition – called the update partition – needs to be created for each component. In essence, this means that each component consists of two partitions; one that runs the actual firmware, and one which is reserved to store new firmware images during firmware updates. In case flash size is restricted, update partitions can be created in external flash memory.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NDk5MTc1LWJsb2dwb3N0LWZsYXNoLW11bHRpLXVwZGF0ZS1tY3UtMi5qcGciLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 302px;" class="fr-fic fr-dib">A multi-MCU IoT device with partitioned flash memory containing update partitions<h2 id="isPasted">Multi-Component Firmware Updates</h2>Let’s explore what really happens deep down in the device’s flash memory when a firmware component is being updated.The process starts when new firmware is released and uploaded to the repository. Once uploaded, the LwM2M Server informs the device about the availability of new firmware, enabling the device to download the firmware image.DownloadingOnce the firmware update is initiated for a specific component, the device starts downloading the new firmware image into the dedicated update partition. After the download has completed, the application initiates a reboot. At boot, the bootloader validates the authenticity and integrity of the new firmware, once validated it initiates the swapping process.Swapping firmwareIn contrast to Linux-based systems which support “position-independent code”, microcontrollers usually can’t boot firmware directly from the update partition. As a result, the firmware residing in the update partition needs to be swapped with the original firmware. When using the open source MCUboot bootloader, the two images are swapped using the flash partition known as the scratch partition. The scratch partition acts as a buffer, allowing the bootloader to switch the new and existing firmware images between their respective partitions. Throughout the swapping process, the device goes offline and becomes unresponsive to server commands.In the swap process, the bootloader first copies a chunk of the new firmware from the update partition to the scratch partition. It then moves the existing firmware to the update partition. Finally, it moves the new firmware chunk from the scratch partition to the original partition. This process repeats until the entire new firmware image has been moved into the original partition, completing the swap.Running new firmwareAfter the swap has been completed, the bootloader initiates the new firmware from the newly flashed image. If initialized successfully, the device starts running the new firmware. The new firmware is expected to write a flag in the flash memory to indicate that the update was successful, which is done after performing several self-checks, e.g. initializing the hardware.RollbackIf no successful update flag is added to the flash memory, the bootloader assumes something went wrong and performs a rollback during the next boot. The rollback triggers the swap procedure to revert the initial firmware. Once the swap is complete, the bootloader initiates the old firmware, ensuring the device remains operational.<img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NTYxNzk2LXJvbGxiYWNrLndlYnAiLCJlZGl0cyI6eyJyZXNpemUiOnsid2lkdGgiOjk1MCwiZml0IjoiY292ZXIifX19" style="width: 302px;" class="fr-fic fr-dib">DFU process for a distinct firmware component<h2 id="isPasted">Presenting the LwM2M Advanced Firmware Update Object</h2>In the <a href="https://www.avsystem.com/blog/remote-firmware-updates-for-iot-devices/" rel="noopener" target="_blank">previous article</a>, we’ve discussed the Firmware Update Object (/5) as defined in the <a href="https://technical.openmobilealliance.org/OMNA/LwM2M/LwM2MRegistry.html" rel="noopener" target="_blank">LwM2M Object and Resource Registry</a>. The creation of updatable firmware components can be accomplished through implementing the Advanced Firmware Updates Object (/33629). Object 33629 extends the functionality of the Firmware Update Object (/5) by enabling multiple Object Instances to represent the different components of device's firmware. The specific purpose of these components are not standardized and can vary depending on the implementation.Similar to Object 5, the Advanced Firmware Updates process comprises 4 States (idle, downloading, downloaded, updating) and no less than 13 Update Results which contain all the likely outcomes of the firmware update process; providing developers with information about the update status and results.Currently, developers are using Object 33629 as a custom LwM2M Object implementation, until it’s officially adopted into the <a href="https://technical.openmobilealliance.org/OMNA/LwM2M/LwM2MRegistry.html" rel="noopener" target="_blank">LwM2M Object and Resource Registry</a>. <img src="https://images.wevolver.com/eyJidWNrZXQiOiJ3ZXZvbHZlci1wcm9qZWN0LWltYWdlcyIsImtleSI6ImZyb2FsYS8xNjk4MDc1NTg4MTYzLTExLmpwZyIsImVkaXRzIjp7InJlc2l6ZSI6eyJ3aWR0aCI6OTUwLCJmaXQiOiJjb3ZlciJ9fX0=" style="width: 302px;" class="fr-fic fr-dib">View of the Firmware Update feature within&nbsp;<a href="https://www.avsystem.com/coiote-iot-device-management-platform/" rel="noopener" target="_blank" id="isPasted">Coiote IoT Device Management Platform</a><h2 id="isPasted">Conclusion</h2>The shift from monolithic firmware to a multi-component structure in embedded devices presents an opportunity to streamline and enhance the OTA device firmware update process. This approach offers flexibility in updating specific components independently, reduces resource usage, and provides a more efficient update process.As IoT devices become increasingly complex, moving towards multi-component FOTA updates is a logical and beneficial step. It facilitates the concurrent development of different firmware components by various parties which ensures the overall quality and functionality of IoT systems over time. As the IoT market continues to mature, this practice is likely to become the norm, making firmware updates more efficient, reliable, and user-friendly.

As the IoT market is slowly maturing, IoT systems are becoming increasingly complex and versatile. As a result, embedded devices are composed of distinct firmware components made by different parties working together, often running on multiple MCUs simultaneously.

firmware update

Latest Posts

SGP.32: The Future of Remote SIM Provisioning for IoT Devices

Long live multi-component FOTA updates