Method for providing communication function in user equipment

Abstract

The present disclosure relates to a method for providing a communication function in a user equipment, the method comprising: at a management server, receiving (110) a first request to implement a communication profile of a user in a user equipment (UE); at a mobile network operator (MNO), receiving (120) from the management server a second request to activate the communication profile based on the first request; and at the UE, receiving (130) an activation message enabling the communication profile to be implemented in the UE; the method further comprising: at the UE, receiving an initiation message from the user, the first request being based on the initiation message, the initiation message comprising an MNO selection.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to a method for providing communication functionality in a user device, a computer-readable storage medium, a management server, and a server of a mobile network operator. Embodiments of the present disclosure relate specifically to implementing a communication profile (e.g., an eSIM profile) in a user device, particularly a vehicle. Background Art

[0002] The use of wireless communication systems is growing rapidly. In particular, users may have various devices that should be equipped with communication capabilities. Such devices may be smartphones, tablets, smart watches, and vehicles. Due to certain restrictions imposed by mobile network operators, it may be difficult or even impossible to provide communication capabilities to all user devices.

[0003] In view of the above, a new method of providing communication functionality in a user equipment, a computer-readable storage medium, a management server, and a server of a mobile network operator that overcomes at least some of the problems in the art would be beneficial. Summary of the invention

[0004] According to the above, a method for providing a communication function in a user equipment, a computer-readable storage medium, a management server, and a server of a mobile network operator are provided.

[0005] The purpose of the present disclosure is to enable communication functions of user equipment. In particular, the purpose of the present disclosure is to enable communication functions of user equipment with reduced resources and / or energy consumption.

[0006] The object is achieved by a method according to the invention for providing a communication function in a user equipment, a computer-readable storage medium according to the invention and a management server according to the invention.

[0007] According to an independent aspect of the present disclosure, a method for providing a communication function in a user equipment is provided. The method comprises: receiving, at a management server, a first request for implementing a communication profile of a user in a user equipment UE.

[0008] According to an independent aspect of the present disclosure, a method for providing a communication function in a user equipment is provided. The method comprises: receiving, at a management server, a first request for implementing a communication profile of a user in a user equipment UE; receiving, at a mobile network operator MNO, a second request from the management server requesting activation of the communication profile based on the first request; and receiving, at the UE, an activation message enabling implementation of the communication profile in the UE; the method further comprises: receiving, at the UE, an initiation message from the user, the first request being based on the initiation message, the initiation message comprising an MNO selection.

[0009] According to some embodiments, which can be combined with other embodiments described herein, the method further comprises receiving, at the UE, an initiation message from a user, wherein the first request is based on the initiation message.

[0010] According to some embodiments, which can be combined with other embodiments described herein, the initiation message comprises at least one of an MNO selection and / or a user's phone number.

[0011] According to some embodiments, which can be combined with other embodiments described herein, the method further comprises: sending a third request from the management server to the MNO requesting a token from the MNO; and receiving, at the management server, the token from the MNO.

[0012] According to some embodiments, which can be combined with other embodiments described herein, the method further comprises receiving, at the management server, an activation code from the MNO.

[0013] According to some embodiments, which can be combined with other embodiments described herein, the method further comprises generating a SIM profile or a CSMI profile for the user at the MNO.

[0014] According to some embodiments, which can be combined with other embodiments described herein, the communication profile is an eSIM profile of a user.

[0015] eSIM (Embedded Subscriber Identity Module) is a standardized process for securely embedding subscriber information in a module of a telecommunication device. For communication via eSIM, security or data confidentiality is critical. For this purpose, the module contains a standardized digital certificate. There are a large number of different certificates around the world, where a certain type of eSIM only works with a certain type of certificate.

[0016] The term "user equipment" includes a mobile computer device (e.g., a vehicle) and / or a portable computer device (e.g., a smart phone), and the computer device is configured for wireless communication. Examples of UE devices include mobile phones or smart phones, portable gaming devices, laptops, wearable devices (e.g., smart watches, smart glasses, smart shoes), PDAs (personal digital assistants), portable Internet devices, music players, data storage devices or other handheld devices, etc. In general, the term "UE" or "UE device" can be broadly defined to include any electronic device, computing device, and / or telecommunication device (or combination of devices) capable of wireless communication.

[0017] The term "vehicle" includes passenger cars, trucks, buses, campers, motorcycles, etc. used to transport people, goods, etc. In particular, the term includes motor vehicles used to transport people.

[0018] The term "mobile terminal" particularly includes smartphones, but also other mobile or cellular phones, personal digital assistants (PDAs), tablets, smart watches, smart glasses, and all current and future electronic devices equipped with communication technology.

[0019] According to another independent aspect of the present disclosure, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes instructions, and when executed on one or more processors, the instructions cause the one or more processors to implement the method for active call switching of the present disclosure.

[0020] The term "computer-readable storage medium" includes various types of non-transitory memory devices or storage devices. The term "storage medium" is intended to include: computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory, such as flash memory, magnetic media (such as hard disk drives or optical storage); registers; or other similar types of memory elements, etc. The storage medium may also include other types of non-transitory memory or combinations thereof.

[0021] According to another independent aspect of the present disclosure, a management server includes one or more processors, which are configured to: receive a first request to implement a communication profile of a user in a user equipment UE; send a second request to a mobile network operator MNO to activate the communication profile based on the first request; and send an activation message enabling the communication profile to be implemented in the UE to the UE; wherein the first request is based on an initiation message received from the user at the UE, and the initiation message includes an MNO selection.

[0022] Other aspects, advantages and features of the present disclosure emerge from the description and the accompanying drawings.

[0023] Each embodiment is also directed to an apparatus for implementing the disclosed method, and includes an apparatus portion for implementing each described method aspect. These method aspects can be implemented by hardware components, computers programmed with appropriate software, any combination of the two, or in any other manner. In addition, embodiments according to the present invention are also directed to methods for running the described servers and user devices. It includes method aspects for implementing each function of the server and user device. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to understand the above-described features of the present disclosure in detail, the above briefly summarized disclosure can be described in more detail with reference to the embodiments. The accompanying drawings relate to embodiments of the present disclosure, in which:

[0025] Figure 1 A flow chart illustrating providing communication functionality in a user equipment according to the embodiments described herein;

[0026] Figure 2 A schematic diagram showing a vehicle and a management server according to embodiments described herein;

[0027] Figure 3 shows a message transmission flow for providing communication functionality in a user equipment according to the embodiments described herein;

[0028] Figure 4 shows a message transmission flow for providing communication functionality in a user equipment according to a further embodiment described herein;

[0029] Figure 5 Logic implemented at a management server according to further embodiments described herein is shown. DETAILED DESCRIPTION

[0030] Various embodiments of the present disclosure will now be discussed in detail, one or more examples of which are shown in the accompanying drawings. In the following description of the drawings, the same reference numerals refer to the same components. In general, only the differences with respect to the various embodiments are described. Each example is provided to illustrate the present disclosure and is not intended to limit the present disclosure. In addition, features shown or described as part of one embodiment may be used on other embodiments or used in combination with other embodiments to obtain other embodiments. The specification is intended to include such modifications and variations.

[0031] Although embodiments of the present disclosure are described with reference to a vehicle, it is to be understood that the present disclosure is not limited thereto and that the embodiments described herein may be implemented in and / or used with a variety of different types of UE devices, including but not limited to any of cellular telephones, tablet computers, wearable computing devices, portable media players, vehicles, and various other computing devices.

[0032] Figure 1 A flow chart of a method 100 for providing communication functionality in a user equipment according to the embodiments described herein is shown.

[0033] The method 100 includes: in box 110, at a management server, receiving a first request to implement a communication profile of a user in a user equipment UE; in box 120, at a mobile network operator MNO, receiving a second request from the management server requesting activation of the communication profile based on the first request; and in box 130, at the UE, receiving an activation message enabling implementation of the communication profile in the UE.

[0034] An MNO may also be referred to as a wireless service provider, wireless operator, cellular company, or mobile network operator, and is a wireless communications service provider that owns or controls all elements necessary to sell and deliver services to users. In particular, an MNO owns or controls elements of the network infrastructure necessary to provide services to subscribers (users) over a licensed spectrum.

[0035] UE and MNO communicate via a transmission medium (see Figure 2 The communication may be performed by a mobile network (e.g., a mobile network managed by an MNO) or a network (e.g., a reference numeral "1" in the figure). In a preferred embodiment, the network is a mobile network managed by an MNO. The transmission medium may use any of various wireless communication technologies or telecommunication standards (e.g., GSM, UMTS, LTE, LTE-Advanced (LTE-A), 5G, HSPA, etc.). Communication via future telecommunication standards is feasible.

[0036] Figure 2 A schematic diagram showing a vehicle 20 and a management server 300 according to the embodiment described herein is shown.

[0037] exist Figure 2 In the example shown in , the UE is the vehicle 20 or the communication module 200 of the vehicle 20. However, the present disclosure is not limited thereto, and the embodiments may be implemented in and / or used with a variety of different types of UE devices, including but not limited to any of a cellular phone, a tablet computer, a wearable computing device, a portable media player, and various other computing devices.

[0038] Figure 3 A message transmission flow for providing communication functionality in a user equipment according to the embodiments described herein is shown.

[0039] In some implementations, method 100 further includes receiving an initiation message from a user at the UE, wherein the first request is based on the initiation message. For example, the user may initiate the process by logging into an account (e.g., in the UE, which may be a vehicle). The user may select a particular MNO and / or enter his / her phone number during the login. Based on this, the UE may generate a first request, which is then sent to the management server. The first request may include the selected MNO and / or the phone number entered by the user.

[0040] In some embodiments, the method 100 further includes: sending a third request from the management server to the MNO requesting a token; and receiving, at the management server, a token message from the MNO.

[0041] The third request may include an anonymous account ID and phone number. Thus, there is no need to expose the user's identity (e.g., to a management server) because the identity is mapped to an anonymous profile. Only the MNO knows the user's identity.

[0042] The token message sent from the MNO to the management server may include the MNO token and / or the anonymous account ID. Furthermore, the second request sent from the management server requesting activation of the communication profile may include the MNO token.

[0043] According to some embodiments, which can be combined with other embodiments described herein, the method 100 further comprises generating a SIM profile or a CSMI profile for the user at the MNO.

[0044] Finally, the MNO sends an activation message to the UE that enables the communication profile to be implemented in the UE. The activation message may include an activation code and may optionally include a profile type (e.g., personal, etc.) based on a SIM profile or CSMI profile for the user.

[0045] In some implementations, the communication profile is an eSIM profile of the user. eSIM (Embedded Subscriber Identity Module) is a standardized process for securely embedding subscriber information in a module of a telecommunications device. For communication via eSIM, security or data confidentiality is critical. For this purpose, the module contains a standardized digital certificate. There are a large number of different certificates around the world, where a certain type of eSIM only works with a certain type of certificate.

[0046] As explained above, the method 100 includes sending a third request from the management server to the MNO for a token. The third request may be constructed as follows:

[0047]

[0048] HTTP Header:

[0049]

[0050] Request body:

[0051]

[0052]

[0053]

[0054] The response (token message) can be configured as follows:

[0055]

[0056] HTTP Status Codes:

[0057] HTTP Codes describe 200 Success. The MNO token is included in the response body. 201 The federated_id has been created and assigned to the appropriate user. 401 Not authorized 403 The client does not have the necessary permission to add the MNO token to the user. 404 The user identified by account_id could not be found. 408 Service failed. Invalid phone number. 422 The federated_id format is incorrect, or the id is a duplicate, or the account_id is invalid. 500 Internal Server Error

[0058] Response body (optional):

[0059]

[0060]

[0061] When the management server uses "Request MNO token", the MNO has two options on how to respond:

[0062] 1. Synchronous response mode:

[0063] Successful response (MNO token generated / MNO token available):

[0064] o The MNO uses status code 200 in the "Request MNO token" response and includes the MNO token in the response body as described above.

[0065] Unsuccessful response (unable to generate MNO token):

[0066] o The MNO uses a 4xx status code and includes the error description in the response body.

[0067] o Synchronous response mode is only allowed if the MNO token is already available at the MNO's system and can be returned within 3 seconds. This means in particular that no user interaction is required. If any user interaction is required, the asynchronous response mode must be used.

[0068] 2. Asynchronous response mode:

[0069] Successful response:

[0070] oMNO uses status code 201, which indicates that the request of the management server will be processed. When the MNO token is available, the MNO uses the server's API "Send MNO token" to deliver the MNO token to the management server.

[0071] Unsuccessful response:

[0072] oMNO uses status code 201, which indicates that the request of the management server will be processed. If an error occurs during processing, the MNO uses the management server's API "Send MNO token" to deliver the error description to the management server.

[0073] Figure 4 A message transmission flow for providing communication functionality in a user equipment according to further embodiments described herein is shown.

[0074] Figure 3 The above use case of "Quality New User Onboarding Flow" can be modified for three reasons:

[0075] In the previous version, there were customer notifications via email / SMS / etc involved. These notifications were considered unreliable and there was a high risk of losing customers during this notification step. The new flow does not include this notification process.

[0076] In the previous version, the customer needed to enter his / her phone number, for example on the HMI. There was a risk that the customer entered the wrong phone number (typographical error) and the process would fail. In the new process, the customer does not need to enter a phone number.

[0077] In the previous version, there was a risk that if user A logged in at the vehicle and user B entered his / her phone number, the MNO token was assigned to the wrong user by mistake. In the current version this is avoided because no phone number needs to be entered on the vehicle HMI.

[0078] Overview of the adaptive vehicle onboarding process:

[0079] While in the vehicle, the customer decides to start the onboarding process.

[0080] The HMI directs the customer to a management server touchpoint, for example, by presenting a QR code that opens a management server app or a management server web portal.

[0081] From this step on, the flow is the same as for the use case “Quality onboarding of new users via touchpoints (e.g., app)”.

[0082] Interface with MNO

[0083] The REST interface provided by the MNO is defined below.

[0084] Request activation code

[0085] POST / activation-code-requests / {federated_id}

[0086] The management server calls this interface to make an activation code request on behalf of the user, or calls this interface to request a default configuration file for a car-sharing vehicle.

[0087] ask

[0088] HTTP Header:

[0089]

[0090] Path parameters:

[0091]

[0092]

[0093] Request body:

[0094]

[0095]

[0096]

[0097] HTTP Status Codes:

[0098] HTTP Codes describe 200 Success. The activation code is included in the response body. 201 The request has been stored and will be processed. 401 Not authorized 404 The user identified by federated_id or request could not be found 422 No activation code can be created. 500 Internal Server Error

[0099] Response body (optional):

[0100]

[0101]

[0102]

[0103] When the management server uses "Request activation code", the MNO has two options on how to respond:

[0104] 1. Synchronous response mode:

[0105] Successful response (Activation code generated / Activation code available):

[0106] o The MNO uses status code 200 in the "Request activation code" response and includes the activation code and profile type in the response body as described above.

[0107] Unsuccessful response (unable to generate activation code):

[0108] o The MNO uses a 4xx status code and includes an error description in the response body (as described in Error Handling).

[0109] o Synchronous response mode is only allowed if the activation code is already available at the MNO's system and can be returned within 3 seconds. This means in particular that no user interaction is required. If any user interaction is required, the asynchronous response mode must be used.

[0110] 2. Asynchronous response mode:

[0111] Successful response:

[0112] oMNO uses status code 201, which indicates that the request of the management server will be processed. When the activation code is available, the MNO uses the management server's API "Send activation code" to deliver the activation code to the management server.

[0113] Unsuccessful response:

[0114] oMNO uses status code 201, which indicates that the request of the management server will be processed. If an error occurs during processing, the MNO uses the management server's API "Send activation code" to deliver the error description to the management server.

[0115] Send MNO token

[0116] POST / cesim / mno / v1 / users / {account_id}

[0117] This interface is called by the MNO to submit the MNO token to the management server. After having received the user's certificate together with some value (which the management server can use to identify the user as a management server client), the MNO first checks whether the certificate is correct. If the certificate is correct, the MNO generates a UUID ("MNO token") that should be used as a joint identity between the MNO and the management server.

[0118] ask

[0119] HTTP Header:

[0120]

[0121] Path parameters

[0122]

[0123]

[0124] Request body:

[0125]

[0126]

[0127]

[0128] :

[0129] HTTP Status Codes:

[0130] HTTP Codes describe 201 The federated_id has been created and assigned to the appropriate user. 401 Not authorized 403 The client does not have the necessary permission to add the MNO token to the user. 404 The user identified by account_id could not be found 422 The format of Federated_id is incorrect or the id is a duplicate. 500 Internal Server Error

[0131] "phoneNumber" and "subscriptionType" will be used to display information to the customer, so the customer can distinguish between multiple subscriptions if the customer has joined multiple subscriptions, such as a personal contract and an enterprise contract. When "phoneNumber" and "subscriptionType" change, "Send MNO token" can be sent again with "isUpdate" set to "true". Only "phoneNumber" and "subscriptionType" can be updated, "federated_id" cannot be updated.

[0132] Send activation code

[0133] POST / cesim / mno / v1 / activation-codes / {federated_id}

[0134] This interface is called by the MNO to submit the activation code to the management server. After the MNO has received the request for the activation code and generated the activation code, the MNO submits the activation code to the management server backend for further processing (ie, storage and forwarding to the vehicle).

[0135]

[0136] HTTP Header:

[0137]

[0138]

[0139] Path parameters:

[0140]

[0141] Request body:

[0142]

[0143]

[0144]

[0145] :

[0146] HTTP Status Codes:

[0147]

[0148] Another example of an embodiment of the present disclosure is described in detail below. The following embodiments may be combined with other embodiments described herein.

[0149] 1. Interface documentation

[0150]

[0151]

[0152] 1.1CESIM MNO API V1

[0153] These functions are called by the MNO during various processes that require data exchange with the management server backend.

[0154] Send MNO token

[0155] POST / cesim / mno / v1 / users / {account_id}

[0156] This interface is called by the MNO to submit the MNO token to the management server. In addition, this interface can be used to update some user information (phone number, subscription type or customer group) in the customer's information. The MNO token itself cannot be updated.

[0157]

[0158] HTTP Header:

[0159]

[0160]

[0161] Path parameters:

[0162]

[0163] Response body:

[0164]

[0165]

[0166]

[0167] Phone number encryption:

[0168] For security reasons, the phoneNumber must not be sent as plain text in "phoneNumber", but must be encrypted. This is in addition to the TLS encryption of the message itself, which means that the message must be encrypted using TLS and additionally the phone number must be encrypted in the field "phoneNumber".

[0169] Encrypted details:

[0170] The phoneNumber will be encrypted in the MNO backend. Details on the encryption type and algorithm will be included in the interface contract. Note: The encryption mechanism / algorithm will be different from the activation code encryption.

[0171] Reason: The activation code encryption will be end-to-end between the MNO and the vehicle. However, the phone number can be decrypted in the management server backend, e.g. for support use cases.

[0172] :

[0173] HTTP Status Codes:

[0174] HTTP Codes describe 201 The federated_id has been created and assigned to the appropriate user. 401 Not authorized 403 The client does not have the necessary permission to add the MNO token to the user. 404 The user identified by account_id could not be found 422 The format of federated_id is incorrect, or the id is a duplicate, or the account_id is invalid. 500 Internal Server Error

[0175] "phoneNumber" and "subscriptionType" will be used to display information to the customer, so the customer can distinguish between multiple subscriptions if the customer has joined multiple subscriptions, such as a personal contract and an enterprise contract. When "phoneNumber" and "subscriptionType" or "customerGroup" changes, "Send MNO token" can be sent again with "isUpdate" set to "true". Only "phoneNumber" and "subscriptionType" and "customerGroup" can be updated, "federated_id" cannot be updated.

[0176] When a new MNO token is sent from the MNO to the management server (isUpdate=false), the management server will check if the account_id is valid. The management server will accept the MNO token only if the account_id is valid. Otherwise, the management server will return HTTP status 422 and reject the token.

[0177] To send an update (isUpdate=true) of "phoneNumber", "subscriptionType", or "customerGroup", account_id can be used even if account_id is expired.

[0178] Send activation code

[0179] POST / cesim / mno / v1 / activation-codes / {federated_id}

[0180] This interface is called by the MNO to submit the activation code to the management server. After the MNO has received the request for the activation code and generated the activation code, the MNO submits the activation code to the management server backend for further processing (ie, storage and forwarding to the vehicle).

[0181] ask

[0182] HTTP Header:

[0183]

[0184]

[0185] Path parameters:

[0186]

[0187] Request body:

[0188]

[0189] Activation code encryption:

[0190] For security reasons, the activation code must not be sent as plain text in the field "activationCode", but must be encrypted. This is in addition to the TLS encryption of the message itself, which means that the message must be encrypted using TLS and, in addition, the activation code must be encrypted in the field "activationCode".

[0191] Details about encryption:

[0192] The activation code should be encrypted end-to-end between the MNO and the vehicle to protect the user. The activation code will be encrypted in the MNO backend and decrypted in the vehicle. Details on the encryption type and algorithm will be included in the interface contract.

[0193] General example:

[0194] The activation code I$CV-1000-MY-ESIM.COM$DEF40A57E6CEFD34FA64B4A38D9681A5 after encryption and Base64 encoding is:

[0195] K+gntTX9lB40o88Km+fraIYJHoPXK9yOAtJWebk+VGq+ShFHBEx-BUeWC2CzWPoxba8O6OF1kNZvTcaylhYORA==

[0196] This encrypted activation code must then be sent in the field "activationCode".

[0197] :

[0198] HTTP Status Codes:

[0199]

[0200] Notify MNO token invalid

[0201] This interface is called by the MNO to notify the management server that the user's subscription has ended or the user has chosen to delete the link between the management server account and the MNO account. The MNO token can no longer be used to request any new activation codes, so all profiles of the user will be deleted.

[0202]

[0203] HTTP Header:

[0204]

[0205] Path parameters:

[0206]

[0207]

[0208] Request body:

[0209]

[0210] :

[0211] HTTP Status Codes:

[0212] HTTP Codes describe 204 federated_id has expired 401 Not authorized 404 The user identified by federated_id or request could not be found 500 Internal Server Error

[0213] Send profile information POST / cesim / mno / v1 / users / {federated_id} / profiles

[0214] This interface is called by the MNO to send information related to a specific profile or a list of specific profiles, all belonging to the same customer and the same subscription (MNO token).

[0215]

[0216] HTTP Header:

[0217]

[0218] Path parameters:

[0219]

[0220] Request body:

[0221]

[0222]

[0223] :

[0224] HTTP Status Codes:

[0225]

[0226] Information about the use of "Send profile information":

[0227] This API should be used when information about a specific profile or a list of profiles needs to be sent from the MNO to the management server. For example, if a profile does not work due to a defect, the MNO can notify the management server to delete this specific profile. If the MNO needs to send information for multiple profiles, for example if two profiles have to be deleted, the MNO can specify multiple ICCIDs in the array, however, all the specified profiles must belong to the same user (same MNO token). The request "Send profile information" should not be sent together with "NotifyMNO token invalid", because in this case the management server automatically considers that all profiles linked to this MNO token are invalid and the management server will delete these profiles.

[0228] When the MNO sends the activation code to the management server with profileReplaced=true, the request "Send profile information" should not be sent either, because in this case the management server automatically considers that the profile specified in replaceIccid in the management server's request is invalid, and the management server will delete the profile.

[0229] Configuration file status information:

[0230]

[0231] The profile status "invalid" should only be sent from the MNO to the management server when the profile is in a state where the customer cannot use telephony / data, and the profile status will never return to a state where the customer can use telephony / data again via that profile. When the management server receives the "invalid" status, the management server will delete the profile from the vehicle. Examples of when a profile "invalid" may be sent from the MNO to the management server are:

[0232] The configuration file has a technical defect and needs to be replaced with a new configuration file

[0233] The profile is removed from the user's subscription and the user will never be able to use the profile in the future.

[0234] The profile states "suspended" and "valid" do not trigger direct actions on the management server side, e.g. no profile deletion will take place, but the information will be logged for supported cases, e.g. when a customer calls the management server's customer service. The profile states "suspended" and "valid" shall not be sent during normal profile usage, e.g. when a profile is enabled or disabled. These profile states shall only be sent when the MNO blocks the usage of the profile for a limited time. Blocking usage means that the user will not be able to use telephony / data after logging in at the vehicle, because the MNO has set the profile to a state that prohibits telephony / data services. Example use cases are:

[0235] The customer has not paid the MNO’s bill, so the MNO decides to block the customer’s phone calls / data usage until the bill is paid.

[0236] • The customer loses the primary phone and calls the MNO's customer service, the MNO blocks telephony / data usage for all profiles associated with the customer's contract for security reasons until the customer calls the MNO to release the usage block.

[0237] The Management Server will use the profile states "suspended" and "valid" in the following example support scenario: A customer calls the Management Server's customer service stating that a service in the vehicle using the Consumer eSIM is not working. The Management Server will then check if the profile state "suspended" has been sent to the Management Server from the MNO. If so, the Management Server can explain to the customer that the service is not working because the profile is currently in a state where telephony / data cannot be used.

[0238] Error handling

[0239] Error code provided by the management server:

[0240] In case of an error (status code other than 2xx), when the MNO uses one of the following APIs:

[0241] Send MNO token

[0242] Send activation code

[0243] Notify MNO token invalid

[0244] Send profile information

[0245] The management server will use one of the HTTP status error codes described on the response of each API (e.g., 401, 404, etc.). Additionally, in the case of an error, the HTTP response body will contain the following fields:

[0246]

[0247] The following error codes and descriptions may appear:

[0248]

[0249]

[0250] Error code provided by MNO:

[0251] The following errors can be provided by the MNO to the management server in "Send MNO token" and "Send activation code" (if the specific error is applicable to the MNO). The "error" field in these requests shall contain the defined error code followed by ":" and then the error description.

[0252] Example: "20: Federated_id not found"

[0253]

[0254]

[0255] 1.2MNO Interface

[0256] The remaining interfaces that the MNO must provide are defined below.

[0257] Request activation code

[0258] POST / activation-code-requests / {federated_id}

[0259] The management server calls this interface to make activation code requests on behalf of users.

[0260]

[0261] HTTP Header:

[0262]

[0263]

[0264] Path parameters:

[0265]

[0266] Request body:

[0267]

[0268]

[0269] :

[0270] HTTP Status Codes:

[0271]

[0272]

[0273] Response body (optional):

[0274]

[0275]

[0276] Activation code encryption:

[0277] For security reasons, the activation code must not be sent as plain text in the field "activationCode", but must be encrypted. This is in addition to the TLS encryption of the message itself, which means that the message must be encrypted using TLS and, in addition, the activation code must be encrypted in the field "activationCode".

[0278] Details about encryption:

[0279] The activation code should be encrypted end-to-end between the MNO and the vehicle to protect the user. The activation code will be encrypted in the MNO backend and decrypted in the vehicle. Details on the encryption type and algorithm will be included in the interface contract.

[0280] General example:

[0281] The activation code I$CV-1000-MY-ESIM.COM$DEF40A57E6CEFD34FA64B4A38D9681A5 after encryption and Base64 encoding is:

[0282] K+gntTX9lB40o88Km+fraIYJHoPXK9yOAtJWebk+VGq+ShFHBEx-BUeWC2CzWPoxba8O6OF1kNZvTcaylhYORA==

[0283] This encrypted activation code must then be sent in the field "activationCode".

[0284] When the management server uses "Request activation code", the MNO has two options on how to respond:

[0285] · Synchronous response mode:

[0286] Successful response (Activation code generated / Activation code available):

[0287] The MNO uses status code 200 in the "Request MNO token" response and includes the activation code and profile type in the response body as described above.

[0288] Unsuccessful response (unable to generate activation code):

[0289] The MNO uses a 4xx status code and includes an error description in the response body (as described in Error Handling).

[0290] The synchronous response mode is only allowed if the activation code is already available at the MNO's system and can be returned within 3 seconds. This means in particular that no user interaction is required. If any user interaction is required, the asynchronous response mode must be used.

[0291] · Asynchronous response mode:

[0292] Successful response:

[0293] The MNO uses status code 201, which indicates that the request of the management server will be processed. When the activation code is available, the MNO uses the management server's API "Send activation code" to deliver the activation code to the management server.

[0294] Unsuccessful Response:

[0295] The MNO uses status code 201, which indicates that the request of the management server will be processed. If an error occurs during the processing, the MNO uses the management server's API "Send activation code" to deliver the error description to the management server.

[0296] Send CSIM status

[0297] POST / statuses / {federated_id}

[0298] This interface is called by the management server to notify the MNO of eSIM profile status updates.In addition to the notifications set in the GSMA standard, backend-to-backend profile notifications are also sent to the MNO.

[0299]

[0300] HTTP Header:

[0301]

[0302]

[0303] Path parameters:

[0304]

[0305] Request body:

[0306] A list containing one or more of the following objects:

[0307]

[0308]

[0309] :

[0310] HTTP Status Codes:

[0311] HTTP Codes describe 201 The request has been stored and will be processed. 401 Not authorized 404 The user identified by federated_id or request could not be found 422 The request cannot be processed. 500 Internal Server Error

[0312] Status Subscription Options

[0313] In the table above, in "status", "mode" a list of possible status values ​​is described. The MNO can decide which of the possible CSIM states should be sent from the management server to the MNO or should not be sent. For example, the MNO can decide that the management server should not send the "enabled" and "installed" states but should send, for example, "deleted". The MNO has to inform the management server which state should be sent and the decision of the MNO will be documented in the interface contract after the management server agrees. If the MNO does not make any specification, the management server will only send the "deleted" state to the MNO and all other status updates will not be sent to the MNO.

[0314] The delete message can be used by the MNO to release the eSIM location for the customer upon receiving this information from the management server. All other status information (including "enabled" and "disabled") are intended only for supported cases and cannot be used to trigger any provisioning or change the customer's connection configuration.

[0315] The "enable" and "disable" states are sent only once for the first time a profile is enabled or disabled. All subsequent enables and disables are not sent.

[0316] Figure 5 The logic implemented at the management server is shown in FIG.

[0317] Request invalidate MNO token

[0318] DELETE / users / {federated_id}

[0319] This interface is called by the management server to request the invalidation of the federated_id (referred to herein as the MNO token). This call occurs after the user chooses to cancel the link between the management server account and the MNO account. The MNO token can no longer be used to request any new activation codes, so all profiles of the user will be deleted.

[0320]

[0321] HTTP Header:

[0322]

[0323] Path parameters:

[0324]

[0325]

[0326]

[0327] HTTP Status Codes:

[0328] HTTP Codes describe 204 The MNO token has been successfully invalidated. 401 Not authorized 404 Unable to find user 422 The request cannot be processed. 500 Internal Server Error

[0329] Service health check

[0330] GET / healthcheck

[0331] This interface is called by the management server to obtain the status of the MNO's service. The MNO's server processes the management server's request and sends the request to the management server. Status code 200 will be interpreted as "service is operating normally". All other status codes will be interpreted as service abnormal operation. The health check endpoint should have the same authentication and authorization requirements as all other APIs provided by the MNO (for example, firewall rules, client and server certificates for manual authentication, API keys or basic authentication).

[0332]

[0333] HTTP Header:

[0334]

[0335] :

[0336] HTTP Status Codes:

[0337] HTTP Codes describe 200 Service is running normally 401 Not authorized 403 Banned 422 The request cannot be processed. 500 Internal Server Error

[0338] Error handling

[0339] In the event that an error occurs during a call to one of these APIs (status code other than 2xx)

[0340] Request activation code

[0341] Send CSIM status

[0342] ·Request invalidate MNO token

[0343] The MNO MUST add the following fields to the HTTP response body:

[0344]

[0345]

[0346] Predefined values ​​and descriptions for the error codes can be found in chapter 4.1 Management Server CESIM MNO API V1, section "Error Handling", subsection "Error codes provided by the MNO". This also includes the possibility for the MNO to provide additional error codes and descriptions as described in the referenced subsections. All additional error codes must be specified and agreed upon before use. For supported cases (e.g. customer contacting customer service), the Management Server will log these errors / descriptions and mark the request as failed.

[0347] For the following APIs, special rules apply:

[0348] Request activation code

[0349] The management server uses this API to request the activation code. As described in Chapter 4.1, Management Server CESIM MNO APIV1, there are two corresponding APIs provided from the management server, which the MNO uses to send the token or activation code to the management server (see APIs "Send activation code" and "Send MNOtoken" in Chapter 4.1). The APIs "Send activation code" and "Send MNO token" also contain the following field, in which error messages can be transmitted to the management server.

[0350] Therefore, for "Request activation code", the following error handling strategies are allowed:

[0351] If an error occurs during the management server's request "Request activation code", the MNO may respond to the request with a 4xx or 5xx error code (see HTTP status codes in the section on these APIs) and an error response body (see above). The management server will then know that the request failed.

[0352] The MNO may respond to the request "Request activation code" with HTTP status code 201 (see HTTP status codes in the section of these APIs). The management server will then know that the request is currently being processed at the MNO. If an error occurs later during processing (e.g., the customer does not successfully complete the new user onboarding flow at the MNO touchpoint), the MNO may use the "Send activation code" and "Send MNO token" APIs and include the error information in these APIs (see the description of these APIs). If these APIs are used with the error code and description, the management server will know that the initial request failed.

[0353] 1.3 General API Requirements

[0354] The following requirements apply to the CESIM MNO API V1 and MNO Interface sections.

[0355] Ensuring the highest security and data privacy for the Service is the top priority for the Management Server. If the Management Server or the MNO becomes aware of any issues related to security or data privacy, the parties agree to notify each other immediately of those issues and both parties agree to work to resolve the issues with the highest priority.

[0356] The following content types must be used for the API: application / json

[0357] · API key shall be used for each request of "Management Server CESIM MNO API V1". For "Management Server CESIM MNO API V1", the Management Server provides the API key to the MNO. For "MNO interface", the MNO provides the username and password to the Management Server for basic authentication, or the MNO provides the API key. The MNO must specify whether the API key or basic authentication shall be used for "MNO interface". The MNO provides the username and password or the API key to the Management Server.

[0358] Mutual TLS (two-way authentication) should be used for every request.

[0359] For the Management Server CESIM MNO API V1 (the MNO calls the API provided at the Management Server), the following process will be used:

[0360] o The management server provides a server certificate, which must be trusted by the MNO

[0361] The MNO provides the client certificate to the management server, so that the management server can add the MNO's client certificate to the management server's trusted client list.

[0362] For the MNO interface (the management server calls the API provided at the MNO), the following process will be used:

[0363] oMNO provides the server certificate, which must be trusted by the management server

[0364] o The management server provides the client certificate to the MNO so that the MNO can add the management server's client certificate to the MNO's trusted client list

[0365] The certificates provided by the Management Server and the MNO shall apply the following guidelines, unless otherwise stated in the interface contract:

[0366] οCryptographic protocol: TLS v1.2

[0367] οKey strength: 2048bit

[0368] οCertificate expiration: 1 year

[0369] ο All certificates (server and client certificates) must be signed from a public certificate authority. Self-signed certificates are allowed only if agreed upon in the interface contract. If not otherwise agreed upon in the interface contract, the certificate chain consists of a root certificate, an intermediate certificate, and a leaf certificate.

[0370] o Changes to root and intermediate certificates must be announced at least six weeks before the actual change date by the MNO or management server (depending on which party changes the certificates).

[0371] All communications between the management server backend and the MNO backend, all communications between the touchpoint and the backend (e.g., from the MNO touchpoint to the MNO backend), and all other communications related to the management server consumer eSIM services must be encrypted. The use of unencrypted communications is strictly prohibited.

[0372] The MNO ensures that all data in the MNO's system related to managing the server consumer eSIM services is always encrypted both in transit and at rest (eg in a database).

[0373] - The MNO and Management Server will provide the IP addresses for outgoing calls (from the MNO to the Management Server or from the Management Server to the MNO) so that these IP addresses can be added to the firewall whitelist.

[0374] Management Server and the MNO will provide a pre-production environment and a production environment for the service. The pre-production environment must always be available and the pre-production environment must have the same functionality and behavior as the production environment. Access to the management server production environment can only be granted after successful testing on pre-production. This applies to the initial establishment of the service and any subsequent updates.

[0375] The Management Server and the MNO will provide the service endpoint URLs for the pre-production and production environments. Subsequent changes to the pre-production or production URLs must be announced at least six weeks before the planned date of the change.

[0376] For the UUIDs (Universally Unique Identifiers) used in the described interfaces, unless otherwise stated, the following applies: There are no special requirements on how to generate the UUID, as long as the UUID is random and unique. The following example shows a valid format for a UUID to be used:

[0377] 62d198e4-36ea-46c5-aaed-06727a272c72

[0378] da62eb89-6255-486c-85c9-d5a7369060b0

[0379] 0297e8f3-e2fd-404d-9dc9-e76f6c8cld52

[0380] For security reasons, the user's account ID and the MNO token cannot be the same value.

[0381] MNO tokens that are no longer valid must be invalidated using a token invalidation request as described in the interface description. If the user or the management server invalidates the token on the management server side, the management server will notify the MNO that the token is invalid. If the user or the MNO invalidates the token on the MNO side, the MNO will notify the management server that the token is invalid.

[0382] Information about how to use the request ID and correlation ID:

[0383]

[0384]

[0385] Example:

[0386]

[0387]

[0388] The following table shows the maximum length of the values ​​sent from the Management Server to the MNO or from the MNO to the Management Server via the described interface. This ensures that the Management Server and the MNO use the appropriate field length in their databases for each of the following values:

[0389]

[0390]

[0391] Note 1: This corresponds to the maximum length that the management server can store for this value. If the MNO uses a shorter length in the MNO's system, this is acceptable because the management server only uses the value provided by the MNO.

[0392] Note 2: As defined in SGP.22eSIM technical specification SGP.22V2.2.1.

[0393] For security reasons, the account_id (anonymous account ID) generated by the management server before redirection from the management server to the MNO has a limited temporary validity. If an MNO token is sent from the MNO to the management server with an expired account_id, the mno token will be rejected by the management server. The validity time of the account_id is specified in the interface contract between the management server and the MNO.

[0394] A signed interface contract is mandatory for accessing the Consumer eSIM Services API of the management server.

[0395] The interface must operate 24 / 7 based on the agreed SLA, including incident management and problem management.

[0396] If not stated otherwise in the interface contract, English communications, including those in event management, are used.

[0397] All processes for operations and support (including incident management, problem management, change management, contractors, and communication channels) must be clarified before granting access to the production environment.

[0398] Planned downtime for maintenance services must be performed during non-business hours and must be announced at least 48 hours in advance (except for emergency changes).

[0399] The management server and the MNO are responsible for the testing and quality assurance of their own systems. Before the initial service launch, the management server and the MNO must perform adequate testing of their own systems, and every change or new feature after the initial service launch must also be adequately tested to ensure high quality of the service. Joint testing, such as integration testing, will be performed after testing the own systems. In order to allow continuous testing before and after the service launch, the pre-production environment of the service must always be available with the same SLA and behavior as the production environment.

[0400] In case of security issues or in case of cumulative or repeated customer problems, the Management Server may restrict the use of the Consumer eSIM API in order to avoid said issues or avoid customer problems.

[0401] In the event of a problem with the service (which may be discovered before or after the service is launched), the management server and the MNO agree to work jointly to resolve the problem.

[0402] MNO custom header option

[0403] o The MNO may optionally specify a customer header (header name and header value) that the management server will include in every request sent by the management server to the MNO (e.g., in Request activation code, Send CSIM status, etc.). The header name and header value must be static and the same for all requests. Furthermore, such custom headers cannot be used to include any additional customer-specific or vehicle-specific information.

[0404] o An intended use case for this custom header is for example that the management server sends the client ID defined by the MNO to the MNO in each request, example: header name: "client_id", header value: "bmw123", so the MNO can recognize that the request comes from the management server.

[0405] o Custom headers will not be sent by default. If the MNO requires a custom header, the MNO must notify the management server, which will then check whether the requested custom header name and header value are feasible, and then if the management server agrees, the custom header name and header value will be recorded in the interface contract.

[0406] 2. Edge Case Considerations

[0407] Vehicle User Login

[0408] Normal use case: The customer must perform a personalized login at the vehicle to be able to use the Consumer eSIM profile. The customer can only be physically in one vehicle, which means that only one of the Consumer eSIM profiles is enabled.

[0409] Edge case: A customer can start two vehicles, have both running and be logged in in both vehicles or share his / her management server login credentials with another person. This means that the customer is then logged in to both vehicles and both eSIM profiles are enabled.

[0410] Desired behavior: In this edge case, the MNO should allow two Consumer eSIM profiles to be enabled simultaneously.

Claims

1. A method (100) for providing a communication function in a user equipment, the method comprising: Receiving an initiation message from a user at a user equipment UE, the initiation message including a mobile network operator MNO selection; receiving, at a management server, a first request for implementing a communication profile of a user in a user equipment UE, the first request being based on the initiation message; sending a third request for a token to a mobile network operator MNO from the management server to the mobile network operator MNO; and receiving, at the management server from the mobile network operator MNO, a token message from the mobile network operator MNO, the token message comprising an MNO token, the MNO token being a joint UUID generated by the mobile network operator MNO to be used by both the mobile network operator MNO and the management server to refer to the user; receiving, at a mobile network operator, MNO, from the management server a second request requesting activation of a communication profile based on the first request, the second request comprising an MNO token; and receiving, at the user equipment UE, an activation message enabling implementation of a communication profile in the user equipment UE, The mobile network operator MNO generates an activation code and submits the activation code to a management server, and the management server receives the activation code from the mobile network operator MNO and forwards the activation code to the user equipment UE.

2. The method (100) according to claim 1, wherein: The initiation message also includes the user's telephone number.

3. The method (100) according to claim 1 or 2, wherein: The initiation message is sent by a user to a user equipment UE, or the initiation message is sent by a user to a management server.

4. The method (100) according to claim 3, wherein: The initiation message is sent by another user equipment UE of the user to the user equipment UE or the management server.

5. The method according to claim 1 or 2, wherein: The method further comprises: A SIM profile is generated for the user at the Mobile Network Operator MNO.

6. A computer-readable storage medium comprising instructions which, when executed on one or more processors, cause the one or more processors to implement the method (100) according to any one of claims 1 to 5.

7. A management server, the management server comprising one or more processors, the one or more processors being configured to: A first request for implementing a communication profile of a user in a user equipment UE is received, wherein: The first request is based on an initiation message received at the user equipment UE from a user, the initiation message comprising a mobile network operator MNO selection; sending a third request for a token to a mobile network operator, MNO, to the mobile network operator, MNO; receiving a token message from a mobile network operator MNO, the token message including an MNO token, the MNO token being a joint UUID generated by the mobile network operator MNO to be used by both the mobile network operator MNO and a management server to refer to the user; sending a second request to a mobile network operator, MNO, requesting activation of a communication profile based on the first request, the second request comprising an MNO token; and An activation message enabling implementation of a communication profile in the user equipment UE is sent to the user equipment UE, wherein the one or more processors are configured to receive an activation code from a mobile network operator MNO and forward the activation code to the user equipment UE.

Images