In the previous two parts of this series I’ve taken a look at how the eSIM and downloading virtual SIM cards into devices compares to using physical SIM cards today. Now that the general concept is clear, let’s name some of the components involved which will help a lot when reading the standards documents GSMA SGP.21 and SGP.22.
eUICC
So far I’ve always referred to the embedded security chip in cellular devices that replace the SIM card as embedded-SIM or eSIM. This term is used by a lot of people but actually not quite correct. The correct term, also used in the specifications is the “embedded Universal Integrated Circuit Card” or eUICC for short.
Profile
As already mention in the previous posts, the virtual SIM card that is downloaded from the network into the eUICC is referred to as a ‘profile’. A profile is not a template for many virtual SIM card but one profile is exactly one virtual SIM card that can be downloaded. This is important to realize as otherwise the standards text that uses the word ‘profile’ is quite confusing.
LPA
As the download of a profile requires user interaction (see part 2 of this series), an app on the device is required that lets the user manage his virtual SIM cards (profiles). Management operations are downloading new profiles, activating and deactivating them and also deleting them from the eUICC. The app that interacts with the user and communicates with the eUICC and the server in the network is referred to as the ‘Local Profile Assistant’ (LPA). In theory the LPA can also reside in the eUICC but in this series I only deal with scenarios where the LPA is an app in a cellular device that interacts with the user.
SM-DP+
When the user signs a contract or picks up a prepaid subscription, the profile (the virtual SIM card) attached to this contract is downloaded from a server on the network. The server is referred to as ‘Subscription Manager – Data Preparation’ or SM-DP+ for short. The SM-DP+ is contacted by the LPA app to start a profile download. Later in the process the SM-DP+ is directly contacted by the eUICC with the help of the LPA through an encrypted data channel) to download a new profile.
The SM-DP+ also communicates with the provisioning system of the network operator, e.g. in the following scenario: The user buys a prepaid subscription (online or in a store). The network operator then links the contract to a profile (a virtual SIM card) that the network operator knows that it already exists on the SM-DP+. The network operator then gives a MachingID to profile and informs the SM-DP+ that a perticular MatchingID has been assign to a particular profile. The MatchingID is then also given to the user as part of the 2D barcode which is scanned with the LPA app. The MachingID is then sent by the LPA to the SM-DP+ when the user wants to download the profile so the SM-DP+ can find the profile which the network operator’s provisioning system has assigned to the user.
So as you can see, the SM-DP+ is the central node of the Remote Service Provisioning (RSP) system!
ES9+ Interface
As pointed out above the eUICC, LPA on the device and the SM-DP+ server in the network communicated with each other. As these components come from different companies standardized protocols (interfaces) are required so that any device with any eUICC can be used in combination with any SM-DP+ server and any mobile network operator. No easy task… The first interface I want to mention in this post is the ES9+ interface, an encrypted connection the LPA establishes to the SM-DP+, e.g. when the user wants to download a new profile (virtual SIM).
ES8+ Interface
At some point during the Profile download process, the eUICC wants to establish an end-to-end encrypted tunnel to the SM-DP+. This tunnel (interface) is referred to as the ES8+ interface. The LPA is used to connect the eUICC to the SM-DP+ over the Internet (e.g. via Wifi).
ES 10 (a,b,c) Interface
The LPA app on the device does not only interact with the SM-DP+ server in the network and the user via the GUI but also with the SIM card. This is the ES10 interface and different operations use the ES10a, ES10b and ES10c parts of the interface.
ES2+ Interface to the network operator
And the final interface I will mention today is the ES2+ interface which connects the SM-DP+ with the network operator. Standardization of this interface is required because the SM-DP+ server can be operated by different entities. For example, a network operator could buy and operate his own SM-DP+ server, or he could outsource SM-DP+ operation and the creation of profiles to an external entity.
Summary
In SGP.21 and SGP.22 there are lots of other abbreviations and terms used. However, the ones above are the most important ones. In the next part of this series I’ll have a close look of how this model ensures that any eSIM device can be used with any network operator.