How Devices Manage eSIM Profile Management & Power Management
This documentation applies to the following products:
OmniSIM
For all other products, please review their respective documentation
Overview
The KORE OmniSIM product family revolutionizes mobile connectivity by allowing electronic SIM profile downloads and activations directly on mobile devices. This technology showcases the seamless integration of eSIM capabilities, largely operating independently from the mobile device's host CPU. Despite this autonomy, there are scenarios where the host CPU is intricately involved in the activation process. Moreover, leveraging the host CPU more significantly can enhance this functionality. This document delves into the specifics of the host CPU’s involvement and its potential for a more substantial role in eSIM management.
eSIM Overview
An ESIM, or eUICC, is a smart-card device backwards-compatible to the classic cell phone SIM. In fact, eUICCs and traditional SIMS can be used interchangeable in most most devices. However, eUICCs do bring new benefits to the table, including the ability to download and enable new profiles via Remote SIM Provisioning (RSP). This capability allows an eUICC to become an entirely new SIM without touching or changing any hardware.
Two basic models exist for RSP, the M2M model, and the Consumer model. In the largest context, the M2M model is a centralized push architecture, while the Consumer model is a decentralized pull architecture. Each model has its relative strengths and the best fit for any application depends on many details. This document focuses on the M2M model, as described by the GSMA in SGP.01 and SGP.02.
In the M2M model, a central RSP server performs operations directly on eUICCs, using the modem for access. Each operation begins with a special binary SMS message sent by the server to the modem and eUICC. The SMS is followed by a corresponding data session between the SIM and RSP server. By and large, this process bypasses the host CPU entirely, and no special code or AT commands are required. The end user typically makes RSP requests via web UI or API to the RSP server, which then performs the appropriate operation. For large deployments, this architecture scales well up to thousands or millions of devices.
Conceptually, RSP supports five top-level operations:
Download Profile - Downloads a profile into the eUICC.
Delete Profile - Removes a profile from the eUICC.
Enable Profile - Enables a profile in the eUICC. The profile must be previously downloaded, and only one profile may be enabled at a time. The enabled profile is, in effect, the “SIM” in a traditional sense. If desired, the host CPU may also enable profiles locally using AT commands (see, KORE Local Profile Management Applet).
Disable Profile - Disables the eUICC’s currently active profile, and correspondingly enables a designated “fall-back” profile.
Audit - Verifies that the profiles downloaded into the eUICC match the server’s record of what should be downloaded into the eUICC.
For the most part, these transactions are simple, each involving one binary SMS message and a few hundred bytes of data. The Download Profile operation is the exception to this rule, involving 30K-50K bytes of data total. While these operations happen largely transparently to the host CPU, the Enable Profile operation will look like a SIM change, involving a new IP address and a potential new APN configuration. Additionally, mobile devices using PSM or eDRX will need to disable (or reduce) power savings before RSP operations start.
Host CPU Implementation
Upon activating a new profile, the host CPU undergoes a process akin to a live SIM swap. This includes updates to its IP address, IMSI, MSISDN, and APN configurations. For Cat-M devices, this procedure can be more intricate due to the potential need to adjust Power Saving Mode (PSM) and extended Discontinuous Reception (eDRX) timers before initiating Remote SIM Provisioning (RSP) operations.
Devices Operating from Continuous Power
Devices running on continuous power primarily need to adapt to changes in the operational profile. This process involves detecting changes in the profile and adjusting the device's configuration accordingly. The adaptation process can be efficiently represented as a state machine workflow. Here, the host CPU transitions from a configuration state to an operational state. Whenever there's a change in the profile, the system automatically revisits the configuration state to adjust its settings in response to the new requirements. This ensures the device remains optimally configured for its current operational environment.
During the configure state, the host CPU configures its modem, when then attaches to the mobile network. Once configuration is complete the device transitions into the operate state for normal operations. Upon detecting a profile change, the device transitions back into the configure state to accommodate the new profile, then returns to normal operations.
Devices Operating from Battery Power
Battery-powered devices are integral in today's wireless communication ecosystem, with Remote SIM Provisioning (RSP) being a pivotal feature for seamless network connectivity. However, the inherent nature of these devices to conserve energy by disconnecting from the network creates significant challenges for executing RSP operations effectively. This section outlines the complexities associated with energy conservation in battery-powered devices during RSP tasks and proposes a more sophisticated state machine approach to mitigate these challenges.
Challenges in RSP Operations Due to Energy Conservation
Extended T3412 Timer Issues: The T3412 timer controls the interval at which a device periodically reports its presence to the network. Setting this timer too long can lead to RSP tasks, such as profile updates, timing out before they even begin. This disconnect between operational timing and network expectations can render RSP processes ineffective.
Short T3324 Timer Complications: On the other hand, a short T3324 timer, which dictates the duration a device waits in idle mode before disconnecting from the network, may not provide ample time for crucial RSP operations, such as Download Profile, to complete successfully. This results in incomplete tasks and potential disruption to the user's network service.
Mobile Device State Machine for Profile Management
This section outlines the state machine required for a mobile device to effectively manage both its normal operational modes and concurrent profile management operations. These operations ensure the device can interact with servers for profile updates efficiently without unnecessary power consumption, and then revert to energy-saving modes post-operation.
States Overview
Operate: The regular operational mode where the device performs its standard functions with power-saving strategies activated.
Configure: The state where the device adjusts its settings or updates its profile as per server requests without initiating power-saving measures.
PM-Operate (Profile Management Operate): A dedicated operational mode where the device maintains connectivity and functionality with reduced or disabled power-saving measures to facilitate profile management.
PM-Configure (Profile Management Configure): This state involves preparing the device for profile management by disabling or reducing battery savings timers, ensuring a smooth and uninterrupted profile update process.
State Transitions
Prepare Request: Upon receiving a server instruction for profile management, the device transitions to PM-Configure.
In this state, the device temporarily disables or reduces its battery savings timers to remain responsive and ensure uninterrupted profile management operations.
PM-Operate: Following PM-Configure, the device enters PM-Operate.
Power-saving strategies are disabled or reduced, allowing the device to manage the profile update effectively.
Configure: Once the Remote SIM Provisioning (RSP) operations are complete, the device moves to the Configure state.
The modem is reconfigured for operation with the new profile, preparing the device for a return to its normal operation mode.
Operate: Finally, the device resumes its Operate state.
It returns to its regular operational mode with appropriate power savings modes reactivated, ensuring efficient power consumption post-profile update.
This state machine allows for seamless transitions between power-efficient operations and the necessary conditions for successful profile management, ensuring minimal disruption to the user experience and device performance.
Profile Change Detection
After an Enable Profile, the new profile is roughly analogous to a new SIM, which includes a new IMSI, MSISDN, IP address, and ICCID. The host CPU needs to detect this profile change and configure itself accordingly. There are several ways to do this.
ICCID Query
The host can query the ICCID periodically, or prior to opening a PDP session, to explicitly detect a profile change.
Unsolicited Response Code (URC)
Modems will often transmit a URC or multiple URCs to the host CPU after a new profile is enabled, as the PDP context closes and the device becomes unregistered. The host CPU can use this to detect the profile change. In some cases, the URC may indicate a possible profile change, such as +CEREG. In this case, the modem will need to query the ICCID after the URC to confirm that the profile has changed.
Device driver
Modems react to profile changes in different ways, depending on their make, model, and configuration. Some modems perform a soft reset when this happens. Others report a network configuration change to connected applications, and other remain completely silent. Depending on the specific modem and driver, the host CPU or OS may be able to detect the profile change through the modem driver.
Device Configuration After a Profile Change
Cellular networks use Access Point Names (APNs) to route IP packets between mobile devices and endpoints outside the cellular network. An APN is a URL-type text string identifying the specific VPN and packet gateway (P-GW) used by the mobile device. The APN determines the mobile device’s authorization, IP address pool, and various other parameters. Cellular modems support multiple APNs, described by their name and numeric class. Most networks use the class 1 APN for the module’s operational connectivity, although the Verizon network uses the class 3 APN for this purpose in most cases. Carriers use other APNs are for other purposes such as IMS, RSP, or over-the-air configuration.
All OmniSIM profiles use one common APN value, data.apn.name, which must be written into modem configuration as the class 1 (non-Verizon) or class 3 (Verizon) APN. Once an APN is configured, the modem can attach and open a Packet Data Protocol Context (“PDP context” or “packet context”) to send and receive IP data.
After a profile change, the modem will need to re-attach and open a new PDP context. For applications that do not include the Verizon profile, the host CPU may be able to simply configure the modem once with the data.apn.name APN and disable autoconfiguration-type features of the modem, which will leave the APN settings unchanged after a profile change. However, when using Verizon, this approach will not work because the class of the custom APN changes from 1 to 3 when moving to a Verizon profile. Often, when explicit APN configuration is required, best practice will involve disabling the transceiver (AT+CFUN=4) immediately after detecting a profile change, then configuring the modem appropriately, then restoring the modem to full functionality (AT+CFUN=1).
KORE Local Profile Specifics
AT&T Profile (890117)
AT&T profile requires that the class 1 APN be set to the OmniSIM custom value data.apn.name.
Verizon Profile (891480)
Verizon profile requires that the class 3 APN be set to the OmniSIM custom value data.apn.name.
Verizon profiles come in two basic variants, Cat-1+ and Cat-M, identified by their IMSI.
Cat-1+
The Verizon Cat-1+ profile uses SMS over IMS, which requires the class 1 APN to be set to IMS. The class 3 APN must be set to the OmniSIM value data.apn.name, which must be used to establish the PDP context.
Cat-M
The Verizon Cat-M profile uses SMS over NAS, which requires the class 1 APN to be blank. The class 3 APN must be set to the OmniSIM value data.apn.name, which must be used to establish the PDP context.
Quectel Modems
Certain Quectel Cat-M modems are Verizon-certified via waiver, and they require a different configuration. In these cases, the class 1 APN must be set to the OmniSIM value data.apn.name, and the class 3 APN must be set to the Verizon default value VZWINTERNET. The class 1 APN must be used to establish the PDP context. Please contact KORE for specific details on how these modems should be configured.
KORE OmniSIM Profiles (891039)
The KORE OmniSIM profiles require that the class 1 APN be set to the OmniSIM custom value data.apn.name.
KORE Local Profile Management Applet
OmniSIM includes an optional local profile management applet, which permits the host CPU to enable pre-downloaded profiles locally without using RSP. Using AT commands, the host CPU may retrieve a list of profiles available in the eUICC and enable them as needed. It also enables the host CPU to read the eUICC EID value, which can be useful in setting the correct APN value. The KORE LPM Applet obviously requires more host CPU involvement than RSP; however, it facilitates a much more powerful profile management system. Using the KORE LPM Applet, devices can select and enable a new profile according to GPS location, relative signal quality, network speed, network latency, user interface, or loss of connectivity. Please see the Local Profile Management Guide for more details.
Conclusion
OmniSIM enables mobile devices to change SIMs electronically using remote or local control. This powerful capability requires some degree of involvement by the host CPU, but the benefits are more than worth the development investment for many applications.
Last updated
