7.2.1 Development

Upon purchasing a new mobile device, the user needs to establish a customer relationship with his/her preferred MNO. There are various ways to do this. A typical procedure is to establish the relationship at the same time as the actual contract is signed in the retail store or at the operator’s own customer service point. There are two contract types: post‐paid and pre‐paid. In either case, the subscriber information needs to be established both in the network side and in the respective SIM/UICC. Also, in either case, the customer can typically select the device from the MNO’s pre‐selected (subvention) set, or use his/her own device (often referred to as ‘Bring Your Own Device’) by inserting the SIM/UICC into any general device.

The activation of the subscription at the POS happens in such a way that the customer selects the subscription type as well as the parameters for the supported functionalities (e.g., data quantity and rate, value‐added services such as voice mail box), from different options and price ranges. When entering the customer’s personal data like name and address, the sales personnel typically need to ensure the identity of the customer. As the national regulations tend to be increasingly stricter for pre‐paid customer ID registering, the sales service may require a proof of identity and address. This step aims to prevent the activation of fraudulent subscription. The false user information would provide means to use the pre‐paid or post‐paid line anonymously (e.g., for criminal purposes) or overlook the generated bills.

After ensuring the correct identification of the customer, the customer service dedicates an MSISDN which the network (HLR/HSS) will associate to the subscribed services. The customer may also choose the preferred MSISDN from a certain set of available numbers. The line is then activated, that is, provisioned [16]. The procedure includes steps summarized in the following paragraphs by generalizing a commercial example of an OTA On‐Demand Activation (ODA) as described in [17]. The OTA activation process allows the mobile operator to dynamically activate and provision the subscription and SIM/UICC as the subscriber goes active ‘on the air’ for the first time. Figure 7.1 presents the principle of ODM.

In the operational environment, prior to the provisioning of the new user services, the registered subscriptions that have not yet been activated cause license fees and other expenses for MNOs because of the reserved resources. This challenge is especially relevant for pre‐paid SIMs that are physically stored in different POS locations to be purchased by new clients. With a large variety of offered SIM card types, the related logistics and storing costs of MNOs can be quite considerable.

There are solutions developed for these challenges such as the SmartTrust ODA of Giesecke & Devrient (G&D) which supports the activation, personalization and provisioning of the mobile subscription and the SIM card that is already distributed physically but not yet sold, and when the subscriber is about to activate the new subscription with new MSISDN information, or replace an old or lost SIM card with the same MSISDN. This solution is based on a single, generic card profile which is used for initialization and activation of the actual subscription, thus removing the need for reserving the subscription in the HLR/HSS and other platforms in advance when the physical card is not yet purchased. The benefit is the optimization of the respective capacity and licensing costs as they are only triggered upon the actual activation of the subscription including the customer‐specific parameters, files, service set personalization, International Mobile Subscriber Identity (IMSI), MSISDN, priority lists for roaming, SIM‐based value‐added services, customer care entry in SIM‐based phonebook and service provider name [17]. Furthermore, the end‐users may be able to make selections via SIM‐based menus for such items as the language and the phone number or subscription type during the activation process.

This service is an example of the solutions that integrate with the existing MNO infrastructure (such as HLR/HSS) so that the handling of sensitive information like the subscription’s authentication keys is maintained safely within the same network. The service can also rely on the mobile network’s signalling to trigger the activation, so there is no need for special adjustments in the respective interfaces as the existing network can be completely reused. Also, the solution may be integrated with the BSS of the MNO. Activation is possible from any compatible network in any country as the system is able to determine the country and network from where the activation takes place in order to select the proper operator profile within a cooperating operator group.

This type of SIM management platform product provides a complete solution for the SIM lifecycle OTA management by relying on the Remote File Management (RFM) and Remote Applet Management (RAM) as defined by ETSI specifications for Java Card based SIMs and by adopting vendor‐specific OTA protocols from the participating SIM card suppliers.

7.2.2 Benefits and Challenges of Subscription Management

The subscription management can be done remotely via OTA methods, or in the simplest form, locally. Modern subscription management happens by relying on OTA methods due to the cost‐efficiency while local subscription management (i.e., fixed line connectivity) can be assumed to be only relevant for devices that cannot be updated due to physical and economic reasons.

The subscription type selection is one of the essential tasks of the end‐user. Depending on the need, the user may want to have only a basic subscription including voice, messaging and light packet data services, whereas more advanced users might need the highest available data rate. The task of the MNO is to optimize the available network resources by balancing the expected utilization of the capacity and charged fees. In some cases, the MNO may want to offer an unlimited data plan while others may control the utilization by setting capacity or data rate limitations on a monthly basis. Finding a good balance is not an easy task as it depends on competitive dynamics, so too unattractive subscriptions may increase the churn. The optimization of the churn is one of the priorities of the MNO, as well as the minimization of the customer care calls, as both are expensive to the MNO’s operations.

As for the subscription lifecycle management, one of the most critical instances is the initial activation of the subscription. If something fails in this phase, it increases customer complaints and may lead to increased churn. The interpretation of the end‐user (and POS personnel) may be that the service quality of the network is low, or that the mobile device or SIM card is of low quality. If the initialization fails when the customer is trying to activate the subscription remotely at home, it generates a customer care call which again is an added MNO expense and may result in churn if not solved promptly.

What then are the basic reasons for the failing activation, and what can be done to minimize these events? Some of the issues may be due to the incompatibility or failure of a component in the chain of the mobile device (OEM), SIM/UICC card (SIM vendor), service (provider), or network (MNO). The issue may also be due to the different interpretations of the standards or errors in the design. The aim of early testing is to capture these potential issues before the device enters market, including the problems that may lead to security holes.

When the issues are minimized and eliminated successfully, the HW then has a certain expected lifetime. It depends on the components of the device, such as the internal memory and any external memory surfaces – including the one found within the SIM/UICC card. The wearing of the memory happens gradually until part of it results in errors when writing to and reading from it. This type of HW behaviour can be assumed to be irrelevant fromr the security point of view as the ADPUs of the requests and responses between the SIM/UICC and the reader should prevent any problems – although the opening of a security hole may not be discarded completely due to the unpredicted responses in such a situation. To prevent incidents due to wearing, there are application‐level solutions which monitor the memory such as the SIM Lifetime Monitor app as described in Ref. [20].

7.3.1 General

The user’s subscription provisioning and management can be handled fluently by OTA methods during the lifetime of the active subscription. An alternative for the initialization and maintenance of the subscription is to connect the device via fixed wire with the operator’s management server at the customer service, but this represents a special case which is not practical in the modern commercial environment. The SIM OTA refers thus to the management of the SIM/UICC lifecycle remotely via a cellular radio interface. After the first provisioning that initializes the new subscription, managing the SIM card is of utmost importance to the MNO in order to ensure a fluid experience while accessing and updating mobile services. The management is handled via the OTA platform.

The SIM OTA provides an adequate remote communications method for the management of the contents of the SIM/UICC card over the radio interface. The benefit of the SIM OTA for the MNO is the possibility to deploy easily new SIM services without requiring the customer to bring the device or SIM to a physical customer care location. It also provides the means to modify the contents of the SIM/UICC cards efficiently and economically.

Although the OTA procedure was initially related to the consumer space, management of the M2M environment is now becoming more important as a result of the current growth of IoT. For the respective OTA Device Management (DM), there are various commercial solutions available on the market. As an example, the SmartTrust Delivery Platform provides a base for G&D’s OTA products. The SmartTrust AirOn enables remote management for the lifecycle of M2M SIM, related devices and value‐added services such as activation, subscription management and deactivation. As another example, SmartAct is a SIM management solution compatible with other vendor cards. SmartAct provides MNOs the option to deploy NFC‐based services for authentication, digital signatures and transactions. As a third example, the SmartTrust SmartàLaCarte functions as an enabler for mobile value‐added services and operator‐specific services for basic and feature phones. Since the solution includes the dynamic SIM Toolkit platform, it provides the end‐users with a service menu on the device’s display that allows users to call up applications that have been saved directly onto the SIM card via the OTA installation. Although the legacy and basic mobile device models are supported in such offerings, it is expected that smartphones will gradually become the universal service engine. Also, the smartphone architecture would become the default for multiple services and the coexistence of the SIM/UICC and eSE.

7.3.2 Provisioning Procedure

The initial phase of subscriber provisioning includes adding a new customer with new mobile equipment onto the system. The procedure contains the following steps for the activation of the new customer services in generic mobile communications networks: (1) The new subscriber purchases the mobile equipment at the POS of an authorized sales location of the MNO, and the sales personnel issues the respective new SIM/UICC. (2) The subscriber gets a new personal account, and the new mobile equipment and the UICC are linked to it via the POS terminal. (3) The UICC is inserted into the mobile equipment, and it is powered on. Upon the network access initialization procedures of the equipment, the real‐time activation with respective information download is started from the OTA platform as depicted in Figure 7.2.

Another option for provisioning (i.e., activation) of the UICC is to perform it physically at the POS by relying on a card reader as depicted in Figure 7.3.

The OTA Provisioning Manager (OPM) provides services such as activation, deactivation, SIM swap, MSISDN change, feature change, push file, manage application, get subscriber information and roaming awareness. The OPM is integrated into the MNO’s Billing System (BSS) interface. The OPM manages the administrative operations that are initiated in the BSS, such as the activation, SIM swap and subscription update.

7.3.3 SMS‐based SIM OTA

The SIM OTA is based on the server and client architecture. The SIM/UICC represents the client while the MNO’s back‐end system – together with many other roles such as Business Support System (BSS) and customer care – contains the SIM OTA server. Typically, this back‐end system communicates with an OTA gateway by delivering service requests as presented in Figure 7.4. The gateway interfaces with the Short Message Service Centre (SMSC) by converting these service requests into Short Messages (SMs). Furthermore, the SMSC delivers these SMs to the SIM/UICC of a single device, or a set of SIM/UICCs of a respective larger group of devices.

The idea of the SIM OTA is to update and modify data which is stored in the SIM/UICC without the need to reissue it. Thus it is possible to download and use new services remotely instead of physically visiting an MNO’s customer service or retail store.

In order to function, the SIM OTA needs access to the MNO’s back‐end system to create the requests, the SIM OTA gateway to convert the requests into SIM/UICC‐specific format, the SMSC to forward the requests via the mobile communications network, the bearer (such as SMS) for request transport, the user device for receiving the request via the radio interface and for delivering it to the SIM/UICC card and, finally, the actual SIM/UICC for the execution of the request.

The SIM OTA back‐end system may include a variety of entities like billing system, customer care and end‐user’s subscription self‐management web interface. The service request may be related, e.g., to the activation, deactivation, loading, updating or modifying the contents. The request message also includes identification of the subscription and data for executing the service. The SIM OTA back‐end then sends the request to the OTA gateway via a gateway API that indicates the respective SIM/UICC, which is identified with the help of a database that contains information about the cards, e.g., ICC Identification Number (ICCID), IMSI and MSISDN (Mobile Subscriber’s ISDN number). Furthermore, the OTA gatewa contains information about the vendor‐specific format which is needed in order to form the message to comply with the way each vendor’s cards handle the requests.

The SIM OTA gateway forwards this vendor‐specific formatted message to the SMSC by relying on the parameter set according to the ETSI specification GSM TS 03.48, issuing a sufficiently large set of short messages in order to complete the request. It is valuable to note that the SIM OTA gateway needs to manage the messages and ensure the integrity and security of their delivery. The SMSC then forwards the messages to the user device(s) via the SMS bearer within the mobile communications network according to the standardized SMS procedure.

As defined originally in the ETSI SMS service descriptions, each individual message can consist of a maximum of 160 alphanumeric characters, so the complete request may (and typically does) consist of several short messages that are compiled in the device side. If the device is not reachable upon the delivery of the messages, they are stored in the SMSC until the device activates the network next time, or until the maximum expiration time is reached. In order to support the SIM OTA functionality, the user equipment needs to comply at a minimum with ETSI phase 2+ GSM standards, and it specifically needs to support the SIM Toolkit functions. Finally, the SIM/UICC communicates with the user equipment via the standardized, secure interface, to deliver the vendor‐specific contents to it.

7.3.4 HTTPS‐based SIM OTA

The benefit of the SMS‐based SIM OTA is that it is robust and straightforward to set up in any environment supporting short messaging. The drawback is the slow speed of the delivery of the commands due to the limitations in the interface between the mobile device and SIM card. An OTA update of the SIM profile may take several tens of kB with a multitude of separate messages which, in turn, might last about 10 minutes. Furthermore, not all the networks support 3GPP SMS format by default, as is the case for the CDMA 1xRTT.

The solution for this low transmission speed is to transfer the commands and contents via a packet data bearer which can be based on, e.g., GPRS or LTE data service while the protocol used on top can be the secured HTTPS. This solution may reduce the time for the update down to some tens of seconds instead of the minutes that the SMS method typically takes.

7.3.4.2 Bearer Independent Protocol

The OTA access to SIM/UICC cards has been based on the low‐bandwidth SMS bearer for a long time. As a result of the updated standards, BIP provides considerably faster data transfer between the card, terminal equipment that supports BIP, and external world for accessing the card’s contents.

An integral part of the modern HTTPS SIM OTA is in fact the BIP. It functions regardless of the underlying techniques in order to provide secured access OTA to the device and respective SIM/UICC, and it works as an alternative to the SMS‐based accessing to the card. BIP is defined in ETSI TS 102 223 [21]. It allows the UICC’s CAT application to establish a data channel with the terminal, and further through the terminal either to a remote network server or to a remote device in the PAN. BIP inherits the properties of the respective bearer and the network protocols and may be used on top of unreliable transport protocols such as UDP [18,19].

As described in ETSI TS 102 124, BIP provides the UICC a standardized manner to use Terminal Equipment (TE) bearers to communicate with remote entities in a WAN or PAN. The base for BIP is to exchange data first between the UICC and TE, and then between the TE and external server. Figure 7.5 depicts the principle.

Without CAT_TP, the CAT application is unable to know if the remote entity has received the data sent. Moreover, without CAT_TP, the remote entity may receivs data without transport information such as the emitter identity, packet numbering or transmission status. CAT_TP aims to provide the possibly missing transport functionalities.

More details about BIP, CAT and CAT_TP can be found in ETSI TS 102 124 [18].

7.3.5 Commercial Examples of SIM OTA Solutions

There are various commercial SIM/UICC vendors in global markets as well as respective SIM OTA management platforms. The basic functionality of the commercial solutions is similar for the lifecycle management, while the support of the more advanced set of features varies. Some of the globally recognized SIM/UICC vendors are Giesecke & Devrient (G&D), Gemalto, Oberthur, Schlumberger, DeLaRue and ST Microelectronics (STM).

As an example of the portfolio of G&D SmartTrust OTA products, they provide a platform for secure and reliable SIM card management by any vendor throughout the SIM lifecycle, from defining card specifications through pre‐personalization to deactivation. The portfolio has been designed to support a variety of environments like NFC and secure mobile payment that are being deployed at a global level. The portfolio also includes device‐aware products, integrated for SIM and mobile device management. Some examples of the portfolio are SmartTrust Delivery Platform, which is an OTA platform supporting advanced management of SIM cards and mobile devices, and SmartTrust AirOn, which is platform for secure OTA management of connected M2M SIMs, devices and their applications. More detailed solution descriptions can be found in [15]. The following sections generalize some of the commercially available solutions for presenting an overview of the possibilities of advanced OTA device management.

The OTA provisioning is typically capable of automatically downloading multiple types of settings to a variety of handset models. It may also support various download protocols such as OMA‐CP and OMA‐DM, as well as vendor‐specific protocols of the device manufacturers. The solution may include operations for device and SIM personalization, configuration and reconfiguration, diagnostics and firmware management as well as device locking and erasing the contents in case the device is lost. In other words, the device management is designed to manage the whole lifecycle of the device.

The solution may also support event triggers for automated and manual operations, such as actions from the customer care and campaigns. Open API interfaces may be supported for the integration of third‐party systems which may be based on, e.g., HTTP/SOAP. The solution can use a client installed on the device, and an IP‐push mechanism to enable server‐initiated device management actions over cellular networks and Wi‐Fi hotspots. Furthermore, the solutions may include automated device detection functionality to ease the device management, which can be based on a Java applet installed on the SIM supporting Java Card and which makes the device detection independently from the network provider.

In general, along with numerous models on the market, the devices are provisioned according to the OS and provisioning protocol stack. The OTA provisioning system should ideally support all or near all of these devices and protocols in such a way that the provisioning with the respective settings happens automatically based on network and SIM triggers. The procedure can also be manual, based on customers’ self‐care provisioning for setting up the device, e.g., via a web user interface, short messaging or SIM‐based menu of the device. The provisioning settings are typically related to GPRS, MMS, SIP, Wi‐Fi, streaming and email settings. Logically, the device‐dependent settings require respective terminal capability repository for storing the settings ad supported protocols per device, and for identifying the device in question, which means constant updating of the information by the provisioning system provider.

The following sections discuss the functionalities that may be included into the typical OTA provisioning system.

7.4.1 GlobalPlatform

The card specifications of the GlobalPlatform can be found in Ref. [27], and the systems requirements in Refs. [28,29] summarize the new model for the customer‐centric ecosystem for managing subscriptions.

7.4.2 SIMalliance

Ref. [30] outlines the role of SIMalliance in the development of new subscription management methods especially for the M2M environment, but the SIMalliance is ultimately useful for consumer space along with the development of wearables. The new specification allows MNOs to remotely load and manage subscriptions across deployed M2M and consumer devices in a standardized way. The respective eUICC Profile Package defines the interoperable format via technical specification v1.0.1 by describing a common coding process for subscription data to be built, remotely loaded and installed into any embedded UICC by any SIM vendor on behalf of any MNO.

Ref. [30] emphasizes the importance of standardized remote subscription management across eUICCs as it provides time and development efficiencies for MNOs and the wider remote provisioning ecosystem. Service providers can thus provision fleet or an installed base of devices fast and efficiently in a unified way across diverse terminals, MNO customer management systems and eUICCs. The benefit of the solution is simple application provisioning and lifecycle management combined with scalability and flexibility within the remote provisioning ecosystem.

As for the cross‐functionality, the SIMalliance’s specification is referenced in the GSMA Embedded SIM Specification within the latest Remote Provisioning Architecture for Embedded UICC Technical Specification v3.0, which defines a technical solution for the remote provisioning and management of the eUICC in M2M devices.

7.4.3 OMA

The OMA Device Management (DM) Working Group (WG) specifies protocols and mechanisms to define management of mobile devices, services access and software on connected devices. The OMA DM WG has operated since 2002 which has resulted in a suite of specifications to provide simple, reliable and cost‐effective ways to deploy new applications and services. The OMA also cooperates with other standardization bodies to avoid fragmentation and duplication of specifications.

The OMA DM technologies have been designed to manage converged and multi‐mode devices on different networks, including devices that do not have a SIM card, as well as resource‐constrained devices. The benefit of the OMA DM specification suite is thus the extensibility which is especially suitable for M2M communications. The OMA DM specifications define the protocols and the mechanisms allowing an OMA DM server to deliver configuration parameters to an OMA DM client by using a set of DM commands for a set of management procedures. These commands are executed within a defined and secure environment, referred to as the DM session.

The OMA DM client has been designed in such a way that it exposes the device data to the OMA DM server via the so‐called DM tree, in the form of a hierarchical structure, as presented in Figure 7.6. It contains management objects, or sub‐trees, which provide the functionality for the device management. The philosophy of the OMA DM is thus to manage device features via the DM tree which in turn virtualizes the device features and functionalities.

The management authority can remotely set parameters, perform terminal functionality troubleshooting, as well as install and upgrade SW via the OMA DM.

The device’s applications are able to access the DM tree and interact with the management objects and the DM server via the interfaces specified by the OMA DM client framework API for receiving configurations and report data. According to the OMA DM smartcard specification, the DM server may be executed on the smartcard that is inserted in the device which optimizes network bandwidth and capacity.

OMA DM specification release 2.0 includes advances for reducing complexity and for providing better interoperability. The OMA DM specifications include management objects that implement various management functions such as Firmware Update Management Object (FUMO), Software Management (OMA DM SCOMO), Diagnostics and Monitoring (OMA DM DiagMon MO), Connectivity (OMA DM ConnMO), Device Capabilities (OMA DM DCMO), Lock and Wipe (OMA DM LAWMO), Browser (OMA DM BMO), Virtualization (OMA DM VirMO), Management Policy (OMA DM Management Policy MO) and Gateway functionality (OMA DM GwMO v1.0).

The OMA has designed remote management especially for the M2M environment via the OMA Lightweight M2M protocol, which focuses on constrained cellular and sensor network M2M devices. The OMA Lightweight M2M provides simple management interfaces based on feasible and available standards such as IETF (CoAP, DTLS; UDP and SMS binding). Figure 7.7 presents the principle.

7.4.4 GSMA

The GSMA is one of the entities establishing interoperable procedures for remote SIM provisioning for the M2M environment. The concept is integrally based on the embedded SIM/UICC, and the respective definitions are included in the GSMA Embedded SIM specification. It provides a single, de facto standard mechanism for the remote provisioning and management of M2M connections via OTA provisioning of an initial operator subscription, as well as the subsequent change of subscription between MNOs.

The M2M environment is one of the drivers for the development of interoperable subscription management because the respective SIM/UICC may be challenging to replace and change due to the restrictions of the physical access to the device, or if the element is permanently installed in the form of an eSE. The logical way to manage these devices is based on OTA methods for the provisioning of the SIM/UICC. Combined with the secure OTA channels, the method provides the same level of security as the removable SIM/UICC are capable of in the consumer market [26]. The GSMA Embedded SIM specification can be used for both removable and embedded SIM/UICC environments, which supports the development of the ever‐growing markets of the IoT/M2M devices and the remote provisioning of operator credentials [1]. As an example, the automotive industry has spearheaded the introduction of remotely provisioned SIM/UICC elements in managing MNO subscriptions and to support the evolving services for cars [3]. Other examples of remote provisioning where GSMA is of use include utility and basically any other IoT device.

7.4.4.1 Embedded UICC

The remote provisioning architecture of GSMA for embedded UICC that focuses on the M2M environment is described in the GSMA documents in Refs. [2,6,8] and the test specification is in Ref. [7]. The definitions are based on current telecommunications standards like Global Platform (GP), which emphasizes the separation of roles and isolation of data. Nevertheless, there are also items in the GP that are not covered by GSMA, like the Issuer Security Domain (ISD).

The following section summarizes the GSMA remote provisioning architecture. More detailed information about the embedded SIM/UICC as seen by GSMA can be found in Refs [25,31]. The GSMA remote provisioning architecture of embedded UICC is shown in Figure 7.8 as interpreted from the version 2.1.

As can be seen in Figure 7.8, there are various roles and interfaces in the remote provisioning. EUM refers to the eUICC manufacturer which produces the physical SE. The MNO executes the profile order by communicating with the SM‐DP (Subscription Manager, Data Preparer) and SM‐SR (Subscription Manager, Secure Routing). SM‐DP, SM‐SR and MNO have a communication link to the secure element, eUICC. Furthermore, the integrity of the data is taken care of by the CI (Certificate Issuer).

The high level contents of the actual eUICC is shown in Figure 7.9 as interpreted from Ref. [31]. The respective contents are referred to as Security Domains (SDs) that provision platform and profile management use. In the GSMA remote eUICC provisioning architecture, each entity has a dedicated SD that consists of different privileges and settings.

Figure 7.10 shows further the structure of a single profile as interpreted from Ref. [31].

The mapping of the communication between the system and eUICC is presented in Figure 7.11.

Following the terminology of Figure 7.9 and Figure 7.11, the EUM installs and personalizes first the ISD‐R (Issuer Security Domain Root) as an initial phase of the eUICC manufacturing. Technically, the ISD‐R is associated with itself. ISD‐P (Issuer Security Domain Profile) is a component that hosts a unique profile. In the GSMA solution, only one ISD‐P is enabled on an eUICC [6]. The EID refers to the eUICC identifier related to the remote provisioning and remote management of the eUICC. It is comparable to the ICCID, but not equivalent. Thus, in systems that relate the ICCID and other identifications, such as IMEI, there is a need for mapping the new EID. It should be noted that there is no global database for this information so operators need to rely on their own solutions. The (eUICC Controlling Authority Secure Domain (ECASD) is installed and personalized by the EUM during the eUICC manufacturing, assisted by the CI associated with the ISD‐R. As soon as the eUICC is manufactured, the ECASD is set to lifecycle state ‘personalized’ as defined in the GlobalPlatform Card specification.

The lifecycle states of the eUICC are presented in Figure 7.12. The lifecycle contains states called ‘Selectable’, ‘Personalized’, ‘Disabled’ and ‘Enabled’ in such a way that once the element is personalized, the transition can be switched between disabled and enabled for each ISD‐P.

The further development of remote provisioning of the GSMA include V3 and V4 (GSMA+), of which the latter includes consumer use cases in addition to the M2M environment as presented in Figure 7.13. In fact, after the initial subscription management solutions, the importance of consumer use cases has been identified as highly relevant. This is due to the fact that wearables and other small devises are becoming more popular, and the respective changing of subscription information between the devices needs to be much more dynamic. The further evolution of GSMA subscription management is called Remote SIM Provisioning (RSP), and the respective SGP.21 architecture specification and SGP.22 technical specification set are divided into phases from which the phase 1 and 2 specifications have been available since the second half of 2016 for companion device and consumer use cases. They define further the architecture and add, e.g., Local Profile Assistant (LPA) into the eUICC. Figure 7.14 summarizes the RSP V1 [33]. As the RSP architecture develops along with phases 2 and 3, the latest documentation of can be found in Ref. [32].

There have been several initiations related to this environment from which the GSMA has been one of the most active parties during 2015.