In the not too distant future, small sensors will monitor the microclimate in cities, help agriculture to optimize irrigation and fertilization, and help track our goods when they pass through global logistics chains, to mention a few examples.
These small Internet of Things (IoT) devices need connectivity, while being installed in various remote locations – and cannot depend on recharging or rely on a local hotspot for connectivity. They also need to be secure – meaning they must be resilient to cyber attacks, and cannot become compromised or part of botnets (those networks of malware-infected devices controlled remotely by attackers).
Cellular networks, in particular 5G and NB-IoT, provide the energy-efficient connectivity and trustworthiness needed to allow small IoT devices to reliably and securely connect and communicate with other entities. Secure identities play a fundamental role for this much needed reliability and security, and are utilized at every layer for secure communication between devices, network nodes, applications, and humans – as discussed in Technology Trends 2020 by our CTO.
By secure identities, we mean digital identities that are securely anchored to physical entities, such as devices and network nodes using root-of-trust mechanisms. Examples of such mechanisms are secure storage and trusted environments, which can be found on a SIM card, for example. A digital identity is an identifier associated with credentials.
In this post we focus on secure identities for devices to authenticate and gain cellular network access. Traditionally Subscriber Identity Module (SIM) cards are used to store and operate on such identities. However, for IoT, the embedded SIM (eSIM) technology – for provisioning devices with secure identities for network access authentication – has many advantages, an and is explained further in the next section.
Today there are two different eSIM standards: one for machine-to-machine (M2M) devices, and one for consumer devices. Neither is perfectly suited for constrained low-power IoT devices, but the consumer device standard is fairly close to – and can be the basis for – a new eSIM solution for the industry. Here, we’ll elaborate on this conclusion and suggest the way forward.
The increasingly popular eSIM technology by GSMA, the association of mobile operators and mobile ecosystem players, allows the remote download and management of cellular network subscription data on eSIM-enabled devices. Non-removable SIM cards, known as embedded Universal Integrated Circuit Cards (eUICC), are used to securely store the subscription data, so called subscription profiles containing secure identities for network access authentication.
For IoT, eSIM technology offers several advantages:
- Logistical simplicity and cost advantages due to not having to ship and install physical SIM cards.
- Allows the device to be hermetically sealed and its size to be smaller since there’s no need for card readers.
- Simplifying the switch of the profile for IoT devices in hard-to-reach places.
Yet the current eSIM standards pose certain challenges for low-power IoT devices that connect via low-power wide area (LPWA) networks, such as NB-IoT. We’ll discuss this below, but let’s first briefly look how eSIM works.
The remote provisioning of subscription profiles works as follows.
- The device owner (enterprise or IoT service provider, for example) or end user orders one or more profiles for their devices from a Communications Service Provider (CSP). The profiles are then prepared at a provisioning server.
- Each device is triggered to securely download a profile. Both the eUICC and the provisioning server are equipped with credentials for mutual authentication and for protection of the profile during download.
- The profile is transferred between provisioning server and eUICC with end-to-end protection. Some form of connectivity is required for the profile download, either based on an existing or earlier provisioned cellular subscription profile in the eUICC or via other radio interface, possibly via another device.
- Once the profile is downloaded it can be installed and activated.
eSIM use cases and key challenges for low-power IoT
One of the dominating eSIM use cases for IoT is to provide connectivity for globally distributed products in a very cost efficient manner. The blog post esim-makes-global-iot-easy provides information for understanding this use case and IoT healthcare is also a concrete example. This use case and other eSIM use cases are valid both for high-end IoT devices like cars and low-power and constrained IoT devices such as connected labels, water pumps, environment monitoring panels, and utility meters.
However, adopting eSIM has some challenges for enterprises when offering connected products involving low-power and constrained devices.
The first challenge is the limited battery power during the long lifespan of the device. Due to limitations in the physical environment of the device, the device does not have an external power supply, and needs to rely on power provided by a small battery for several years. In order to save power, the device is in sleep mode most of the time and is not able to communicate with any server. A wake-up timer or externally triggered events wakes up the device. How device wake-up is done depends on the use case and affects the remote provisioning server. Triggering any remote eSIM provisioning needs to adapt to the specifics of the device and the use case.
The second challenge is device cost. A small device usually has strict cost constraints and cannot afford to have extra hardware units in its Bill of Material (BOM). The use of an integrated eSIM (also called “iSIM”, where “i” stands for integrated) may save BOM costs. In addition, the possibilities for the device to remotely load new firmware, OS, and software applications are limited. Normal “heavyweight” internet protocols like HTTPS may require more memory and are less power efficient than a low-power IoT device can afford. This affects how the device can communicate with the remote eSIM provisioning server.
The third challenge is connectivity and remote provisioning cost during the device lifecycle. Connected devices are typically shipped all over the world, and must be able to connect at every location at first start-up. The connectivity provider for low-power IoT devices needs to secure NB-IoT based worldwide roaming coverage with low cost and global service quality. And then when the devices need to be localized with local mobile network operators, a cost-efficient eSIM provisioning solution is needed to download and enable local mobile network operator profiles.
The fourth challenge is the scale and interoperability. The IoT device market is still very fragmented, and there are many different types of device standards and designs. A solution that works for one type of device may not work well for another type of device. Such fragmentation typically results in poor interoperability and poor service quality, which leads to slow market adoption and high deployment and operational costs. The eSIM provisioning solution must be easy to adopt and provide interoperability between solution providers.
Existing eSIM standards: no perfect match for low-power IoT
As mentioned, GSMA has specified two different eSIM standards: one for M2M devices and the other for consumer devices, neither of which is perfectly suited for constrained low-power IoT devices.
In the M2M standard, the subscription profiles in the eUICC are managed by a remote entity called Subscription Manager Secure Routing (SM-SR). , Before it is assembled to the device, the eUICC must be equipped with a binding to an SM-SR, and must have a subscription profile, a so-called provisioning profile, which is installed by the eUICC manufacturer during the production/personalization of the eUICC. This provisioning profile must provide connectivity in the geographic region where the device is deployed. The IoT service providers and enterprises need to decide which CSP to use for the provisioning profiles of their devices and order eUICCs configured with such provisioning profiles for assembly at device manufacturing. The SM-SR bound to the eUICCs needs to be integrated to every CSP that will provide the operational profile later on.
For the device owners, enterprises, or IoT service providers to manage (enable, disable, or delete) profiles on their IoT devices, they may contact the CSP, which then sends commands via SM-SR to the device. Alternatively, they may spend efforts integrating with the SM-SR, allowing them to send management commands directly to their devices. However, if the IoT device moves a lot, for example between countries, and a change of subscription is required during the lifetime of the device, even further integration may be needed as an SM-SR is typically integrated with a set of CSPs.
If the IoT service providers would like to switch to a CSP outside of this group, they either need to switch to and integrate with a new SM-SR or the new CSP needs to integrate with the existing SM-SR. When switching from one SM-SR to another, the eUICC must be programmed with the new SM-SR credentials, which requires some level of integration between the two SM-SRs.
The SM-SR is the central entity that must be integrated with CSPs and provisioning servers, so called Subscription Managers Data Preparation (SM-DPs), and potentially also with IoT service providers and other SM-SRs. Such integration is both costly and complex, which provides a lock-in effect and limits the use of the technology for low-power and low cost IoT devices.
The M2M standard relies on SMS, which means a cellular connection must be established and used to download a new profile. For low-power IoT devices connecting over NB-IoT networks, the requirement to support SMS is an issue, since not all NB-IoT networks and NB-IoT modules have SMS support.
The GSMA consumer eSIM standard gives the end user full control to manage the subscription profiles. The end user can perform profile management operations (for example, enable, disable, or delete profile) and trigger the download of new profiles via the user interface of the device. A Local Profile Assistant (LPA) running inside the device handles interaction with the provisioning server, SM-DP+, and ensures user consent for all management operations. The consumer standard allows the remote download of profiles over non-cellular interfaces, such as Bluetooth or Wi-Fi, and does not, in this case, require a pre-installed provisioning profile. There are no integration efforts required like in the M2M standard. End users may order a profile from any CSP and instruct their devices to connect to the SM-DP+ used by that CSP for the profile download without any further actions required. HTTPS-based communication between the LPA and SM-DP+ is used.
Certain types of consumer devices have a limited user interface and for this reason the consumer standard allows the user interface of another locally connected device to be used. This is the so-called companion device scenario, which is frequently used between a smart watch and a mobile handset of the same brand, for example.
Since the consumer specification requires a local user interface, or a companion device in proximity, as well as user consent for all profile operations, applicability for an IoT use case is limited. Low-power IoT devices are often managed from remote and automated handling for a batch of hundreds or thousands of (identical) devices is desirable. Request for user consent, handled locally, or from a remote or individual device, is not acceptable.
Besides the user interface, another issue with the consumer standard is the need for support of HTTPS in the device. HTTPS is not a suitable protocol for battery-driven low-power IoT devices, where UDP is supported rather than TCP. A protocol stack suitable for low-power IoT is required for the interaction with such a device. If in addition, the IoT device is also memory constrained, the same protocol stack, as used for device and data management, must also be used for profile download and management.
eSIM for low-power IoT
We conclude that neither of the two current GSMA eSIM standards is really suitable for constrained low-power IoT devices and a new solution is required. At the same time, there is a strong push from enterprises and IoT service providers to have a solution available as soon as possible. To save time when developing the new solution, it is desirable to build upon one of the existing specifications. We believe the M2M standard should be disqualified due to the drawbacks in terms of complexity, cost, and lock-in effect. The consumer standard on the other hand, is relatively close to what is needed in the market and has a robust architecture and existing ecosystem to build on.
The new solution should allow the IoT service providers or enterprises to control profiles for their eSIM devices without involvement or integration of third parties, such as the CSPs or any provisioning server. The IoT service providers or enterprises should be able to buy a batch of subscriptions from any CSP they prefer and instruct their devices to download those profiles.
The consumer standard provides a good base for the new solution, but will require some changes. For example, the IoT services provider or enterprise must be allowed to manage profiles from a remote entity rather than via a local user interface and user consent cannot be required for each action and device. Automated handling for a batch of devices must be possible. IoT service providers or enterprises should be able to program a remote managing entity to download and switch profiles for their devices without having to provide user consent individually for each device. Each device then needs to have capabilities to ensure that only authorized entities are allowed to trigger profile downloads and manage profiles.
The new solution must be flexible in the choice of remote managing entity and the protocol stack used for communication between devices and the managing entity. The solution must be usable with different device management frameworks used in different ecosystems, leveraging device management entities and device management protocols tailored for the low-power and constrained devices, and amending them with capabilities to also manage eSIM. For IoT today, not only is there one protocol stack for device and data management, but a plethora of protocols and protocol stacks being used, such as LwM2M and DLMS/COSEM. The existing triggering and wake-up mechanisms used for the device should also be re-used for eSIM remote provisioning and management. The new solution should not create bindings to SM-SR like third party entities like in the M2M solution, but the device owner must be able to manage all aspects of its devices directly, including eSIM.
Security of IoT devices is of a high concern due to various factors. There is a multitude of initiatives by governments, standardization bodies and other entities to ensure IoT devices are secure, and new regulations and guidelines are being published. Whether the IoT device has a modem and corresponding authentication module (eUICC) does not change the need for secure IoT device management. Leveraging the device management protocol stack for eSIM also means leveraging the security protocol being used for mutual authentication between the device and the managing entity, ciphering and integrity protection of exchanged data, and ensuring only authorized entities can control the device. The new solution should define minimum security requirements for the device management protocol stack to be leveraged for profile management, but should not aim at stipulating the generic IoT device requirements, which are set by the industries and regulators.
The consumer standard uses HTTPS for the interaction with the provisioning server SM-DP+ to download a profile. Battery-driven low-power IoT devices benefit from remotely assisted profile download so that the protocol stacks and battery usage of the device can be optimized. The same protocol stack and security binding as is used for the profile management should be leveraged. The remote managing entity may, for example, relay the profile download related messages between the SM-DP+ and the profile assistant of the device such that the remote managing entity is handling the HTTPS interaction with the SM-DP+. The new solution must ensure maintained end-to-end security between the eUICC and the SM-DP+, as supported in the consumer standard.
The industry needs a new eSIM solution that addresses the limitations of low-power IoT devices. This solution should enable IoT service providers and enterprises to control profiles for their eSIM devices without involvement or integration of third parties. Such control should be possible via existing communication channels and protocol stacks suitable for low-power IoT.
Read our blog post: Benefits of eSIM for service providers: 6 use cases.
Read more about eSIM: Driving global connectivity in the automotive industry.