For anyone managing IoT deployments, the recently introduced SGP.32 from GSMA is a first because it offers a made-for-IoT specification for the first time. SGP.32 significantly simplifies remote SIM provisioning (RSP) and offers greater flexibility and ease of use for IoT organizations. A core concept within SGP.32 is how the device downloads a SIM profile to enable connection to a network.
SGP.32 encompasses two choices – direct and indirect profile download. Choosing the best option for your deployment is important because each has advantages and disadvantages to consider. The fundamental difference between the two is in the communication path the device uses to get its profile from the subscription manager data preparation (SM-DP+), the server that stores and delivers profiles.
A direct download talks directly to the SM-DP+ server while an indirect download talks only to the eSIM IoT remote manager (eIM) which then acts as an intermediary to the SM-DP+.
Direct or indirect?
Direct download advantages include a simpler architecture, potentially lower latency, a reduced bandwidth burden on the eIM and a clear troubleshooting path. Disadvantages include high device network requirements which can be problematic behind firewalls, sometimes complex security credential management, and less control and visibility during download. Direct download aims for the lowest real-time latency when the device is online but sacrifices the success rate.
Indirect download in contrast offers extremely flexible network requirements, centralized security and policy management, enhanced control and visibility for the eIM, and scalability for bulk operations. However, indirect download has a more complex system architecture, there is a higher capacity eIM requirement and there can be slightly higher latency because of the extra hop involved with the intermediary. Indirect download sacrifices immediacy by introducing asynchronous mechanisms but this is achieved in exchange for extremely high reliability.
The single most important decision point could be whether the download option supports the protocol the device uses. For example, HTTPS is supported for direct download while protocols, including LwM2M, CoAP and MQTT, are supported for indirect download. Put simply, if your protocol isn’t supported, you can’t use that profil download method.
Use case scenarios
Direct download should therefore be selected for simple application scenarios where devices operate independently on public networks and there is no need for centralized lifecycle management. Shared bicycles connected via public 4G or 5G and personal consumer electronic devices are good examples of use cases where direct download is optimal.
Indirect download is best suited for managing large scale IoT deployments that require configuration, monitoring and control of all devices. This method is therefore most appropriate for the vast majority of enterprise and industrial applications. Typical use cases where indirect download is the best option include smart meters, fleet management and industrial sensor networks.
Decision time
Device capabilities should also influence your decision. Devices with sufficient processing capability, memory and power supply such as gateways, routers or data transfer units (DTUs) should choose direct download while resource constrained endpoints, such as battery-powered sensors, water or gas meters, should choose indirect download so they can optimize power consumption and network resources.
The network environment should also be assessed. When devices are located on the public internet, they can establish connections with external SM-DP+ servers directly while those behind firewalls, VPNs or networks that employ IPSec policies should take the indirect approach and access the eIM to handle all communication with external SM-DP+ servers.
To explore the best choice for your deployment book a free consultation with Acceleronix [here].
