Remote management of embedded UICC (eUICC) or embedded SIM (eSIM) being distinguished from detachable UICC or SIM allows a mobile network operator (MNO) to respond to requests to change subscription from one MNO to another MNO without having physical access to the eUICC in a user equipment or terminal. Generally, eUICCs handle multiple profiles from multiple MNOs, wherein only one profile can be enabled at any time in operation. In this regard, mechanisms for over-the-air remote provisioning and management of eUICCs entail downloading new profiles, updating subscription addresses, and enabling, disabling, or deleting profiles as defined in the GMSA Remote Provisioning Architecture for eUICC Technical Specification. However, remote provisioning and management of eUICC pose several problems.
For instance, end users or consumers are unable to modify their eSIM settings and profiles from their phones or mobile devices locally when switching devices or network providers or mobile carriers. In this regard, many MNOs typically prefer to pre-install their profile for use as a default SM-DP+ (i.e., a single entry stored in the eUICC) at the time of manufacturing that is outside the scope of a downloadable profile. Generally, providing default SM-DP+ provides a better out-of-the box experience for end users because the users are able to download their profile onto their phone and connect to a mobile network.
Alternatively, end users can download their eUICC profile via GMSA root discovery server or an alternate discovery server (SM-DS). Discovery servers allow MNOs to register where devices can query and retrieve the corresponding SM-DP+ address associated with the profile from MNOs. Discovery servers, however, can be disadvantageous in that they incur operational expenses for MNOs and other users. Although GSMA is the sole entity that is to manage the root SM-DS that is to be provided by a single or multiple vendors, it has not yet provided the business model and the cost structure to its consumers (i.e., MNOs).
While default SM-DP+ does not introduce an additional direct cost to MNOs, default SM-DP+ is currently an optional single entry stored in the eUICC. In order to diversify, the MNOs may decide to multisource (profiles and eUICC identifiers) from more than one eUICC manufacturer (EUM) and may connect with multiple subscription managers and vice versa, wherein some MNOs may not directly connect with subscription managers (i.e., profile/eUICC identifier (EID)) ordering might not directly or indirectly include MNOs in the path). Thus, when MNOs wish to diversify their subscription managers, it would have more than one SM-DP+ from different vendors. With the single optional entry model, the implementation of diversifying subscription managers can be very complex. More specifically, it would be complex to determine how to select which SM-DP+ to choose for each subscriber, end user, and/or device, and how each end user device reaches the correct SM-DP+. Thus, the MNO has to decide how they allocate these addresses in multiple devices. The selection becomes very complex, as there are no clear criteria to be chosen ahead of any contracts (e.g., per type of device, per geographic location, etc.).
In various scenarios, therefore, with the addition or replacement of MNOs, servers, user equipment, and eUICC profiles, a fully meshed connectivity are not practical and very difficult to manage.
The detailed description is described with reference to the accompanying figures, in which the leftmost digit(s) of a reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical items.
This disclosure is directed to a local profile assistant (LPA) that is a client hosted application and an application programming interface (API) for enabling local management of eSIM and eUICC profiles by interacting with an MNO and an API server in a network environment. The MNOs maintain, without limitation, SM-DP or SM-DP+, eUICC profiles, activation codes, and/or other attributes. Upon introduction of a newly added SM-DP+ or a replacement SM-DP+, the MNO is configured to update the server to store an SM-DP+ address that correlates to a new or replaced SM-DP+. Therefore, the server maintains the most up-to-date list of all of the MNO's SM-DP+ addresses in a highly secured environment. It is noted that the same security measures enforced by the GSMA can be implemented to maintain, convey, and store additional SM-DP+ addresses on the server or in a data store. This includes node-to-node as well as end-to-end security (including over the air (OTA)).
Node-to-node security guarantees that data is secure while being transferred from one node to another within a communication system. Data security can encompass multiple aspects. Two common aspects of data security are integrity and privacy considerations. Integrity security employs a technology, such as digital signatures, to prevent data from being tampered with or forged by an unauthorized party. By using a digital signature, a receiver or destination node may be able to verify the sender's identity and know if the data has been altered or forged. Privacy security employs a technology, such as encryption, to restrict access to sensitive data and, thereby, prevent disclosure to or collection by an unauthorized party. One, both, or neither of these security technologies may be employed for the transmission of data. The end-to-end security includes secure data in transit from the platform to external clouds, secure access for users, secure encryption keys, secure logs for auditing, secure instances from breaches, secure data in storage, and the like.
The server updates user equipment with the new or replaced SM-DP+ address. The means by which this information is queried by the device and relayed to the device is part of implementation details (e.g., means similar to OTA, or part of device upgrade, or other means). The protocol used as well as its storage on the user equipment must remain highly secured (e.g., similar to trusted execution environment).
In terms of ownership and maintenance of the server, the server can be owned and maintained by the MNO, jointly owned/maintained by the MNO and original equipment manufacturer (OEM), solely owned and maintained by the OEM, or by any other arrangements that are agreeable to the involved parties. For example, the operational size and geographical span of an MNO can determine its server allocation to provide an optimal coverage for the user equipment.
In various embodiments, default SM-DP+ can take on multiple values within the eUICC of the user equipment. Alternatively, the user equipment can locally store additional SM-DP+ addresses or a default list of SM-DP+ addresses. Adding and/or maintaining additional entries in the eUICC to hold additional SM-DP+ addresses is advantageous in that an eUICC is a tangible element where its requirement and behavior shall comply with the GSMA specifications. In contrast, proposal, discussions, agreements by MNOs, OEMs, and/or EUMs can be extremely time-consuming. In various embodiments, the user equipment can use a default SM-DP+ address as appears in the eUICC in order to request a new profile. If using the default SM-DP+ address results in a successful download of a profile, then the procedure for downloading a profile is completed. Otherwise, the additional optional default SM-DP+ addresses stored in the user equipment can be used to download a profile. More specifically, if using the first default SM-DP+ does not result in a successful download of a profile, the next default SM-DP+ on a queue is used to download a profile, and so on until there is a successful profile download.
In various embodiments, the LPA is configured to manage additions, deletions, or replacements of SM-DP+ as well as MNOs, servers, user equipment, and eUICC profiles using business logics that are implemented by a rules engine. For example, the LPA, via the business logic can automatically route different user equipment to specific profiles using predefined parameters. In this way, the LPA simplifies the complexities of managing multiple profiles by reducing or eliminating changes needed on the part of the MNOs.
Additionally, in order to report a profile status update event to the MNO, either an extension to an existing ES2+ API can be implemented, or a new API can be used to relay the update event to the MNO. API for monitoring and managing profile status updates can take either single value (e.g., single ICCID) and/or take on multiple values or range of values to accommodate bulk profile status updates. Additional considerations may include avoiding a possibility of cloning so that if a profile deletion notification has not been received by an SM-DP+ from a user equipment, SM-DP+ does not allow profile state transposing.
The techniques described herein may be implemented in a number of ways. Example implementations are provided below with reference to the following figures.
It is noted that there are no limitations on deployment options. For example, one MNO can be connected to a single server that is connected to multiple user equipment. In another example, one MNO can be connected to a plurality of servers, wherein each server is connected to a user equipment by device type. Additionally, the architecture 100 can include an SM-DS 116 that can receive a query for an SM-DP+ address.
The API server 114 can include general-purpose computers, such as desktop computers, tablet computers, laptop computers, servers (e.g., on-premise servers), or other electronic devices that are capable of receive inputs, process the inputs, and generate output data. In various the embodiments, the server 114 may be operated by a wireless communication carrier, MNO, a third-party entity that is working with the wireless communication carrier such as an OEM, or any combination thereof. The server 114 may store data in a distributed storage system, in which data may be stored for long periods of time and replicated to guarantee reliability. Accordingly, the server 114 may provide data and processing redundancy, in which data processing and data storage may be scaled in response to demand.
Further, in a networked deployment, new servers 114 may be added on the fly without affecting the operational integrity of the LPA 102 described herein. In this regard, the servers 114 can include a plurality of physical machines that may be grouped together and presented as a single computing system. Each physical machine of the plurality of physical machines may comprise a node in a cluster. For example, the cluster comprises a failover cluster that provides failover operation during a cluster-wide outage. However, in other embodiments, the servers 114 may be in the form of virtual machines, such as virtual engines (VE) and virtual private servers (VPS).
In some embodiments, the server 114 is operatively connected to a data store 118. The data store 118 can comprise a home subscriber server (HSS) of a telecommunications network or a home location register (HLR) of the telecommunications network. The data store 118 may store profiles, SM-DP+ addresses, and/or mapping data that is generated from routing a user equipment 108 to an SM-DP+ 110A-110N and vice versa. The data store 118 can also store other information relating to MNOs 112, user equipment 108, and/or so forth. Moreover, the data store 118 can store a tree having a root node for security and that is configured to implement a protocol to coordinate with a third-party entity.
The MNO 112 is connected to a plurality of SM-DP+ 110A-110N, wherein each SM-DP+ is configured to securely package profiles to be provisioned on the eUICC 104 of the user equipment 108. The SM-DP+ 110A-110N manages the installation of these profiles on the eUICC. Consumer profiles can be loaded from EUMs to the corresponding SM-DP+ 110A-110N. Note that for machine to machine (M2M) scenarios, M2M user equipment do not have LPAs. SM-DP+ can provide feed to the MNO to inform the MNO about the loaded profiles upon completion of loading based on agreements between the MNO and the SM-DP+. After receiving feeds, the MNO can update the server properly. The profile enabling procedure between the MNO 112 and the SM-DP+ 110A-110N is used to enable a profile previously downloaded or installed (e.g., default eUICC) on the eUICC 104. The MNO 112 owning the profile to be enabled initiates the profile downloading procedure.
In some embodiments, the profiles can comprise a provisioning profile, an operational profile, and/or a user profile. The provisioning profile includes information for needed to establish a connection to an MNO. The operational profile includes MNO network access information for receiving service therefrom. If there is no provisioning profile, the operational profile can act as the provisioning file, depending upon embodiments. The user profile includes user information, including a short message service (SMS), multimedia messaging service (MMS), user account information, user equipment information, and a phone book. The user profile may be included in an operational profile, depending upon embodiments.
Additionally, each profile can include information related to a corresponding subscription manager and information for establishing a connection or for allowing communication with the subscription manager, and an authentication credential and key information for performing an authentication (e.g., key exchanges). In some embodiments, the authentication credential comprises an Authentication and Key Agreement (AKA) scheme, public key infrastructure (PKI), and/or other authentication protocol such as multifactor authentication and SAS certification.
The profiles enable the subscription managers to communicate with respective user equipment 108 or terminals that comprise eUICCs having matching or corresponding profiles, wherein the eUICCs can be identified by their EID and ICCID. In this regard, a user equipment 108 can access a subscription manager by using a profile selected from one of the profiles stored in the MNO 112 and/or the API server 114. In this way, the user equipment 108 can communicate with an MNO using the subscription manager. The eUICC can automatically perform a user authentication with respect to a mobile communication network, to which a user has subscribed, by using the information stored in the eUICC, so that the user may conveniently receive mobile communication services through the user equipment 108.
The user equipment 108 may include smart phones, game consoles, personal digital assistants (PDAs) or other electronic devices having a wireless communication function that are capable of receive inputs, process the inputs, and generate output data. However, in other embodiments, the user equipment 108 comprises general-purpose computers, such as desktop computers, tablet computers, laptop computers, servers, and so forth. In various embodiments, the user equipment or terminal may include an a consumer terminal. In various the embodiments, the user equipment 108 may be operated by a wireless communication carrier or a third-party entity that is working with the wireless communication carrier.
In various embodiments, the LPA 102 can work in conjunction with an onboarding entity that can provide client privilege responsibility. For example, the onboarding entity can verify if profiles have been loaded and available in the SM-DP+ 110A-110N before a user equipment makes a request for ordering profiles. More specifically, SM-DP+ 110A-110N can provide a feed to the onboarding entity upon loading profiles.
An SM-DP+ 110A-110N receives and processes requests for profiles from a user equipment 108, wherein the user equipment 108 can reach the appropriate SM-DP+ using an SM-DP+ address stored thereon corresponding to the SM-DP+. The SM-DP+ 110A-110N retrieves a profile, and responsive to the request serves at least one of the retrieved eUICCs. The request includes credentials in accordance with PKI-based authentication protocol and/or utilizes multi-factor authentication. The request can also include one or more SAS certificates. In various embodiments, the request utilizes an identifier correlating with an account that is associated with a plurality of user equipment and a plurality of users (e.g., a user identification associated with a wireless service provider, a wireless carrier, a cellular company, a mobile network carrier, etc.).
Profile orders with an SM-DP+ address or other associated information are provided from the user equipment 108 to the MNO 112. In various embodiments, an MNO 112 can use an extension in ES2+ commands to relay the associated metadata attributes related to the order and the SM-DP+ 110A-110N can use the content of the extension to prepare a profile with the requested metadata from the MNO 112. The mapping of this attribute (i.e., part of the extension to ES2+) to metadata attributes (DP+) can be based on an agreement between the MNO 112 and SM-DP+ 110A-110N.
It should be noted that the storage and/or maintenance of SM-DP+ addresses requires secure location on the user equipment 108. The SM-DP+ addresses can be stored as part of LPA 102, device secure execution environment, and/or so forth. The method by which the SM-DP+ addresses get updated is implementation details. For example, the updates could be tied into device operating system upgrade, via OTA, and/or via any other security mechanism.
In various embodiments, SM-DP+ receives a notification indicating a profile was deleted from a user equipment and upon receiving profile delete notification from the user equipment; the profile state may be moved to a newly defined state or state transition. For example, the profile state can be moved as temporarily deleted. Additional considerations may include avoiding a possibility of cloning. If delete notification has not been received by SM-DP+ from the user equipment; SM-DP+ shall not allow this profile state transposing. SM-DP+ can report to an MNO of the profile delete notification. To relay this information, either an extension to an existing ES2+ API can be implemented, or a new API can be used to relay the event to the MNO. Profile status change API can also be a new API to be defined between the MNO and the SM-DP+. The API can take either single value (such as single ICCID) and/or take on multiple values or range of values to accommodate bulk updates.
There can be instances where notifications may not have been properly received by the MNO. In this regard, the MNO determines whether it received the profile delete notification from the SM-DP+. If the MNO does not receive the notification, the MNO transmits a query on the profile status to the SM-DP+ or requests for the state transition. If the profile status in SM-DP+ does not indicate that the profile state was moved as temporarily deleted, then the MNO may not proceed with status change request as there is a high probability that the profile may not have been deleted or not properly deleted from the user equipment. If the notification has been received by the MNO, the MNO can check the billing status associated with the deleted profile. The MNO determines whether the profile is active in the billing system (e.g., the profile was not deleted by accident). If the profile is active in the billing system, the profile can be reused only by the same EID. If the profile is not active in the billing system, the profile can be reused by any. The SM-DP+ receives requests for profile state transition from the MNO based at least partially on the MNO's business logic.
The memory 208 may be implemented using computer-readable media, such as computer storage media. Computer-readable media includes, at least, two types of computer-readable media, namely computer storage media and communications media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD), high-definition multimedia/data storage disks, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanisms. The memory 208 may also include a firewall. In some embodiments, the firewall may be implemented as a hardware 206 in the computing device 114.
The processors 204 and the memory 208 of the computing device 114 may implement an operating system 210, the local profile assistant 102, SM-DP+ address book 106, application programming interface 222, and data store 118. The operating system 210 may include components that enable the computing device 114 to receive and transmit data via various interfaces (e.g., user controls, communication interface, and/or memory input/output devices), as well as process data using the processors 204 to generate output. The operating system 210 may include a presentation component that presents the output (e.g., display the data on an electronic display, store the data in memory, transmit the data to another electronic device, etc.). Additionally, the operating system 210 may include other components that perform various additional functions generally associated with an operating system.
The local profile assistant 102 includes a rules engine 214, a mapping module 216, a business logic 218, and an application interface 220. The modules may include routines, program instructions, objects, and/or data structures that perform particular tasks or implement particular abstract data types.
The mapping module 216 is configured to enable a user equipment to reach a correct SM-DP+ and vice versa. In one example, the mapping module 216 is configured to access the SM-DP+ addresses book 212 in order to retrieve an SM-DP+ address and retrieve a profile from an SM-DP+ having a corresponding SM-DP+ address. The mapping module 216 can communicate with the rules engine 214 that can implement business logic 218 to route user equipment to a dedicated SM-DP+ via affinity pairing or affinity routing. For example, the operating system can guarantee that a particular core on a CPU will handle a request, or a load balancer can guarantee that a particular web server will handle a particular HTTP request. In various embodiments, the strength of the relationship between the user equipment and the SM-DP+ can be quantified via an affinity coefficient, wherein if the affinity coefficient exceeds a specified threshold, the user equipment can be paired with the SM-DP+. Said another way, the rules engine 214 can implement business logic 218 to guarantee that a request for profile is handled by a particular SM-DP+. Additionally, an SM-DP+ can be decommissioned in a convenient manner as the affinity coefficient decreases below the specified threshold or based on affinity routing arrangements. In various embodiments, the rules engine 214 is configured to pair user equipment with only a specific group or a known subset of SM-DP+ or to a failover cluster of SM-DP+.
In various embodiments, the rules engine 214 is configured to implement business logic 218 to route user equipment to specific SM-DP+ in various scenarios such as additions, deletions, disablements, or replacements of profiles. For example, the business logic 218 is configured to initially internally map the user equipment to a first SM-DP+, and then to automatically to a second SM-DP+ when a profile is deleted. Without limitation, the business logic can be based on network partition, round robin, queue, and/or other predefined parameters. For example, the rules engine 214, based on the business logic 218, can make an initial determination as to the particular sequence in which an SM-DP+ may be selected from a plurality of SM-DP+. The determination may be made based on data inputs received from a network engineer, depending upon embodiments.
In various embodiments, the mapping module 216 can verify whether the correct profile is available. For example, the mapping module 216 can communicate with an onboarding entity that receives feeds from one or more SM-DP+. Additionally, the mapping module 216 can receive authentication parameters for remote provisioning from the SM-DP+ and receive security credentials therefrom upon verification of authentication parameters. In some embodiments, the mapping module 216 is configured to perform key exchanges and/or generate a secure digital identifier based on the security credentials.
The application interface 220 may enable the local profile assistant 102 to communicate with one or more components of the present system and to receive inputs and route outputs to various applications. For example, the application interface 220 may enable a user (e.g., a network engineer, an administrator, an administrative entity, etc.) to manually select a specific SM-DP+ or ranges of SM-DP+. The application interface 220 may also display information relating to one or more servers, MNOs, user equipment, SM-DP+, and/or so forth via a user interface display. For example, the application interface 220 can display mapping information, profile information, identifiers, and/or so forth.
The data store 118 can include a data collection module 224, a data processing module 226, a data storage module 228, and a data access module 230. The data collection module 224 may use data adaptors to retrieve data from the structured or unstructured data sources such as MNOs, user equipment, and/or so forth. In this regard, the data collection module 224 may use data-agnostic data adaptors to access the data sources without taking into consideration the underlying content of the data. Further, changes to the data content in each data source the do not affect the functionality of the corresponding data-agnostic data adaptors. On the other hand, the data collection module 224 may use database-specific data adaptors to access structured databases.
The data collection module 224 may include a workflow scheduler that periodically checks for and retrieves newly available data from the multiple data sources. The workflow scheduler may handle the extraction and the handling of the data based on configurable policies. For example, a configurable policy may specify the source data location, frequency of data retrieval, handling procedures for late arrival data, data retention period, and data disposal following an expiration of the data retention period. The handling procedures for the late arrival data may specify a predetermined cutoff period during which any data arriving late may be incorporated with data that is retrieved on time for processing. Accordingly, the data collection module 224 may retrieve data with different generation latencies (e.g., one minute, fifteen minutes, one hour, one day etc.), as well as data with different spatial aggregation (e.g., network cell data, network node data, radio network controller data, etc.) such that real time or non-real time data analysis may be performed.
In various embodiments, the data processing module 226 may implement adaptor-specific logics to decode the format of various data from data sources. Accordingly, collected data may be fed into other modules for analysis and storage. In some embodiments, the data processing module 226 may aggregate data from multiple data sources for a particular time period into an aggregated data file of data sets according to one or more grouping parameters. The grouping parameters may include specific time periods (e.g., hourly, daily, etc.), network components, user device vendor, user device models, and/or so forth. In other embodiments, the grouping parameters may be used to aggregate the data into multiple datasets that correspond to different levels of a network hierarchy. For example, the data may be aggregated into datasets that correspond to a subscriber level, a device level, a service area level, and a geographical market level. The geographical market level may further include a zip code sublevel, a municipality sublevel, or another location-based sublevel that may correspond to datasets for aggregation. Nevertheless, the aggregated data from the multiple data sources may be stored in the data sets according to their own storage schemas. In other embodiments, the data processing module 226 may converge the data from multiple data sources for a particular time period into a converged data file of data sets, in which the data are stored in the data sets according to a unitary storage schema.
The data storage module 228 may store data across multiple virtual data storage clusters with redundancy, so that the data may be optimized for quick access. The stored data may include the performance data from data sources, the aggregated and covered data files, data that are generated by the local profile assistant 102, and/or so forth. The data access module 230 may provide a data access API for accessing the data stored in the multiple virtual storage clusters. Accordingly, the API may be used by the local profile assistant 102 as well as other third-party application to access the data that received and stored by the data store 118.
At decision block 410, the user equipment determines whether the new profile was successfully downloaded. If the new profile was not successfully downloaded (“no” response from decision block 410), the mapping module searches and selects another SM-DP+ address from the default list stored in the user equipment as indicated in block 412. At block 414, the MNO receives a new request comprising the newly selected SM-DP+ address from the user equipment to download the new profile. At block 416, the MNO retrieves the new profile from the SM-DP+ corresponding to the newly selected SM-DP+address. Thereafter, the process returns to the decision block 410 to determine whether the new profile was successfully downloaded. This process is repeated until the new profile is successfully downloaded onto the user equipment. Thus, the local profile assistant determines whether a profile has been downloaded each time the mapping module queries down the list of addresses in order to ensure that a profile has been downloaded. In various embodiments, the API server ensures that the user equipment comprises valid SM-DP+ addresses are stored in the eUICC of the user equipment such that the user equipment can reach proper SM-DP+. More specifically, the server, via the MNO, determines whether one or more SM-DP+ has been disabled or decommissioned. If an SM-DP+ has been disabled or decommissioned, the MNO updates the server to remove the SM-DP+ address associated with the disabled or decommissioned SM-DP+. In this way, the user equipment is prevented from reaching a disabled SM-DP+ to download a profile. Similarly, if an SM-DP+ has been added, the MNO updates the server to add the SM-DP+ address associated with the newly added SM-DP+.
The techniques herein describe a local profile assistant for employing local eSIM profile management functionality. By storing multiple SM-DP+ addresses within a user equipment, the user equipment can increase the likelihood of successfully retrieving a profile from an SM-DP+ having at least one of the stored SM-DP+ address to provide an end user with a better out-of-the box experience. In this way, the local profile assistant can adapt to various operating scenarios as described in the embodiments in order to reduce the burden on the end users who would otherwise be unable to modify their eSIM settings and profiles locally and to operate in a more simplistic manner than operating via a discovery server or using a single default SM-DP+ address. As the interconnectivities among user equipment, servers, and MNOs become more densified and complex over time, the ability to manage eSIM profile locally may lead to improved remote provisioning and management of the eUICC.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.