How to monitor the management of network slices

Abstract

A method for monitoring management of network slices by a communications device (ME) having a secure element (USIM), the communications device conforming to at least a technology for implementing network slicing using a route selection policy, the communications device further supporting a USIM application toolkit framework implementing an event download envelope, the secure element having a memory storing rules for the route selection policy, the method including, for the communications device active in a network of the technology for implementing network slicing, receiving slice status and slice information from the network and pushing the slice status and slice information to the secure element using an event download envelope defined in the USIM application toolkit framework supported by the communications device.

Description

[Technical Field]

[0001] The present invention relates to a method for monitoring the management of a network slice by a communication device having a secure element.

[0002] The invention also relates to a communication device and a secure element implementing the method. [Background technology]

[0003] 5G network slices are used in 5G to provide tailored QoS for specific applications. Currently, five slice service types (SSTs) are defined as disclosed in 3GPP TS 23.501, section 5.15.2.2, but this number is expected to increase as 5G needs evolve. In addition, within each of the five slice service types, a special operator-dependent distinguisher generates a multiplication of the slice identifier in the device environment.

[0004] With the introduction of 5G slicing, applications must ensure that when slices are available, the slices served are consistent with their data and / or power consumption requirements. Thus, slice management becomes increasingly challenging.

[0005] As defined in the standard, a communication device (hereinafter ME) selects a network slice based on user equipment routing selection policy (URSP) rules provided by the network or by the USIM. Such URSP rules are generally under the control of an operator (PLMN). A secure element (hereinafter USIM) is advantageously used, which is configured with a home PLMN that has at least such URSP rules. Such a secure element is installed in the ME. According to the standard (3GPP TS 24.526), ​​a URSP rule consists of: A priority value for the URSP rule, which identifies the priority of the URSP rule among all existing URSP rules; Traffic descriptors, One or more route selection descriptors.

[0006] The ME selects a URSP rule by matching the characteristics of a Packet Data Unit (PDU) session establishment requested by an application with the traffic descriptor part of the URSP rule and based on the rule priority value, also known as priority, of such URSP rule. The traffic descriptor part of the URSP rule is a list of selection criteria used by the ME, which characterize the PDU session and the requesting application (e.g., requested destination IP address, requested data network name, application identifier...). Further information about URSPs stored in the USIM can be found in 3GPP TS 31.102, clause 4.4.11.12. As defined in the standard, a communication device ME with a secure element USIM is a user equipment (UE).

[0007] Currently, the 3GPP TS 31.1 11 specification allows the USIM to request slice-related status based on a polling mechanism. More precisely, the specification related to "slice information" in PROVIDE LOCAL INFORMATION, which is a way for USIM applications to retrieve information when only slices are served, has been agreed upon. Currently, information about allowed or rejected slices is not available.

[0008] According to this specification, applications on the USIM must periodically request slice information. Typically, every 30 seconds, the USIM requests the ME to provide slice information updates. Such an implementation is not entirely satisfactory because slice information may be missed if the "slice information" in the PROVIDE LOCAL INFORMATION is requested before the slice is requested by the ME or after the slice is no longer accessed, e.g., after a PDU session using that slice has been released. The polling mechanism allows the USIM to only learn about the served slice status at the moment the ME is polled. Typically, a change in the slice status, e.g., a served slice is no longer accessed by any PDU session and therefore no longer the served slice, may be missed if the slice status change polling request by the USIM arrives at the ME too late. Furthermore, rejected single network slice selection assistance information (hereinafter S-NSSAI) information cannot be shared with the USIM when network slice-specific authentication and authorization fails. Therefore, such slice status information, e.g., a slice request was rejected by the network, and the reason for such status, e.g., slice not available or rejection due to congestion, cannot be retrieved by the USIM by such a polling mechanism.

[0009] Furthermore, for future slice management needs, existing polling methods require an increased polling frequency. Increasing the polling frequency has a negative impact on battery consumption, which is not an option in general, but especially in IoT use cases. Therefore, unnecessary power consumption is generated by the polling mechanism, which reduces battery life. In fact, using the known PROVIDE LOCAL INFORMATION "slice information" mechanism may imply a too significant reduction in battery life, which is generally suboptimal and may even be unacceptable in IoT use cases.

[0010] Therefore, existing polling mechanisms allow the USIM to obtain knowledge of the status of slice requests made by the ME. However, such mechanisms do not allow the USIM to obtain all status changes in the correct time. Polling too infrequently can result in information being lost. Polling too frequently can result in too high power consumption.

[0011] Therefore, further alternative and advantageous solutions are desired in the art. Summary of the Invention

[0012] The present invention aims to reliably monitor slice management at low cost in terms of power consumption.

[0013] The present invention is defined in its broadest sense as a method for monitoring management of a network slice by a communication device having a secure element, the communication device conforming to at least a technology for implementing network slicing using a route selection policy, the communication device further supporting a USIM application toolkit framework implementing an event download envelope, the secure element having a memory for storing rules for the route selection policy, the method comprising: for communication devices active in a network of the technology for implementing network slicing: receiving slice status and slice information from the network; - Pushing slice status and slice information to the secure element using an event download envelope as defined in a USIM Application Toolkit framework supported by the communication device.

[0014] According to the present invention, all status of slices, not limited to served slices but extended to allowed and denied slice status, and slice life cycle are monitored in an operator-managed secure element, which can result in improved / optimized use of network slicing. The secure element captures all status changes related to slice requests made by the communication device while minimizing power consumption of the card and communication device. Implementations of the present invention are part of the USIM-ME interface for any form factor of the USIM, thus including removable, embedded or integrated, which further supports the application toolkit framework.

[0015] It should be noted that routing selection policy here specifies not only currently defined URSPs, but also all routing selection policy types, e.g., proprietary or implementation-specific rules that may be later defined by standards or by other entities for selecting and routing communications within a sliced ​​network.

[0016] The URSP rules stored in the USIM are a standard way for the PLMN to indicate to the UE how it requests a specific route for a given PDU session, including the slice type / identity. However, the ME may also be configured with other types of rules, i.e., proprietary rules, that allow the ME to select slice vs. PDU session establishment requests by applications. Such cases may exist, for example, when no URSP rules are configured in the UE, neither on the USIM nor in the ME.

[0017] The inventive mechanism, based on events sent by the ME to the USIM when updated slice status and slice information occurs on the ME, is an efficient solution for minimizing power consumption while ensuring reliable knowledge in the secure element of the slice status. Thus, slice status and slice information are available as an EVENT as soon as the device recognizes a slice status and slice information modification that should be pushed to the USIM for notification to USIM applications. This is particularly advantageous for restricted devices or devices in restricted networks.

[0018] According to an advantageous feature, the method includes a preliminary step for the secure element to register for slice events defined in a USIM Application Toolkit framework supported by the communication device.

[0019] This allows applications that need to have such slice status and slice information to subscribe to the associated events, which for the device means that slice events need to be sent to the secure element.

[0020] According to another advantageous feature, the method comprises the steps of: - recording slice status and slice information; - based on the slice status and the slice information, executing at least one process associated with the slice related by the slice status and the slice information.

[0021] The present invention actually allows the secure element to start slice-related processes when a slice request is accepted or rejected by the network, without waiting for a command to do so. Thus, typically, some processes may be performed in hidden time before the results of processes requested by the network or device. This is typically the case when predicting time-consuming calculations.

[0022] It should be noted here that the two above mentioned features can be combined according to the present invention.

[0023] According to the particular application, the associated process includes a combination of slice status and slice information with at least one secure element configuration parameter previously defined and stored within the secure element.

[0024] Such applications leverage the existence of secure element configuration parameters that can be highly variable, near real-time, within the same entity, and slice status and slice information related to the associated processes being executed.

[0025] According to another particular application, the associated process includes slice availability statistics calculation.

[0026] Such calculations are useful for many purposes, especially for monitoring slice availability depending on the device environment.

[0027] According to another particular application, the associated process comprises the calculation of new rules for the route selection policy, and the method further comprises a step of updating, by the secure element in its memory, stored rules for the route selection policy (URSP rules).

[0028] Changing priorities locally in the URSP minimizes the amount of data exchanged over the air interface, which allows for lower radio and network resource usage.

[0029] According to another particular application, the associated process comprises a cryptographic calculation involving slice status and slice information and at least one cryptographic configuration parameter of the secure element.

[0030] The present invention allows for time-consuming processes to be initiated while the results of cryptographic computations are not yet required, allowing such resource- and time-consuming processes to occur in hidden time. Thus, the present invention allows for cryptographic computations, e.g., SUCI computations, on-board key generation, to be predicted for the first EVENT that confirms the availability of a slice, before an application actually uses the slice and the associated cryptographic computations.

[0031] It should be noted here that all the applications mentioned above can be combined together: for example, statistical calculations can be used for URSP updates, and the combination of slice status and slice information with secure element configuration parameters can be performed in cryptographic calculations, among other combinations.

[0032] The present invention also relates to a communication device having a secure element, the communication device configured to monitor management of network slices, the communication device conforming to at least a technology implementing network slicing using a route selection policy, the communication device further supporting a USIM application toolkit framework implementing an event download envelope, the secure element having a memory for storing rules for the route selection policy, the communication device being active in a network of a technology implementing network slicing, which is further configured to receive slice status and slice information from the network and push the slice status and slice information to the secure element using the event download envelope as defined in the USIM application toolkit framework supported by the communication device.

[0033] Such a communication device monitors slice management, e.g., status, lifecycle, in an optimal manner in terms of reliability of slice status and slice information as provided to the secure element, and in terms of power consumption.

[0034] The present invention also relates to a secure element installed in a communication device configured to monitor the management of network slices using the secure element, the communication device being compliant with at least a technology implementing network slicing using a route selection policy, the communication device further supporting a USIM application toolkit framework implementing an event download envelope, the secure element having a memory storing rules for the route selection policy, and the secure element being configured to receive pushed slice status and slice information in an event download envelope as defined in the USIM application toolkit framework supported by the communication device when the communication device is active in a network of the technology implementing network slicing.

[0035] Such a secure element is adapted to receive an envelope dedicated to slice status and slice information, which prevents the secure element from requesting such information itself according to prior art polling mechanisms.

[0036] Advantageously, the secure element is configured to register at the device for slice events defined in a USIM Application Toolkit framework supported by the communication device.

[0037] Such registration enables the secure element to automatically receive slice status and slice information as received by the communication device from the network.

[0038] Preferably, the secure element is configured to record the slice status and slice information and, based on the slice status and slice information, execute at least one process associated with the slice concerned by the slice status and slice information.

[0039] Such a secure element has the possibility to trigger a process immediately after the pushed receipt of slice status and slice information according to the present invention.

[0040] Advantageously, the associated process is one of the processes mentioned above.

[0041] To the accomplishment of the foregoing and related ends, the one or more embodiments comprise the features hereinafter fully described and particularly pointed out in the claims. [Brief explanation of the drawings]

[0042] The following description and the annexed drawings set forth in detail certain illustrative aspects and indicate but a few of the various ways in which the principles of the embodiments may be employed. Other advantages and novel features will become apparent from the following detailed description when considered in conjunction with the drawings, and the disclosed embodiments are intended to include all such aspects and their equivalents. [Figure 1] 1 shows a time diagram of a prior art slice management mechanism; [Figure 2] 3 shows a time diagram of the slice management mechanism of the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0043] For a more complete understanding of the present invention, the invention will now be described in detail with reference to the accompanying drawings. The detailed description illustrates and describes what are considered to be preferred embodiments of the present invention. It will, of course, be understood that various modifications and changes in form or detail can be readily made without departing from the scope of the present invention. It is therefore intended that the present invention not be limited to the exact forms and details shown and described herein, nor be limited to less than the entire invention disclosed herein and claimed below. In different drawings, like elements are designated by like reference numerals. For clarity, only those elements and steps useful for understanding the present invention have been shown and described in the drawings.

[0044] FIG. 1 shows a schematic time diagram of slice management according to the prior art. This time diagram illustrates the interactions relevant to the present invention between a network NW, a communication device ME, and a secure element USIM. The secure element USIM is typically a SIM card of any form factor, for example, removable, embedded, or integrated. It can also be a Trusted Execution Environment (TEE) or any type of secure element configured to store confidential data on behalf of a third party, not held by the user of the user equipment (UE). Typically, the USIM belongs to the operator of the network NW, which is typically a PLMN. However, other types of networks are also covered according to the present invention.

[0045] The device is typically a terminal or mobile equipment (ME) as defined in ETSI or 3GPP standard documents.

[0046] In a first step S1, the ME is informed of the applicable rules of the UE routing selection policy URSP_R stored in the USIM. It should be noted that the routing selection policy URSP is managed by the operator associated with the device. Therefore, the home network operator and the visited network operator can influence the content of the URSP. While the URSP rules in the USIM are currently controlled by the home network operator, other configurations involving the visited network may be considered in the future in certain situations.

[0047] Next, in step S2, the application requests network access in the ME. Note that steps S1 and S2 can occur according to different timings, with S2 then occurring before S1. In step S3, the ME evaluates the URSP rules and selects a slice X. Next, in step S4, a slice request Req_SX is sent by the ME to the network NW. In response, in step S5, the network NW sends a rejection Rej_SX of the slice X request.

[0048] The 3GPP standard specifies that only for USIM applications implemented in polling mode, a PROVIDE LOCAL INFORMATION related to the slice is periodically sent to obtain the currently served slice.

[0049] It should also be noted that even if a polling event occurs quickly after a slice rejection, the USIM is never notified of unassigned or rejected slice events, since they are not taken into account in the polling mechanism. Only authorized slices are sent in response to the current polling event, which significantly limits the capacity of the secure element to monitor connectivity behavior. Typically today, there is no means to monitor rejection events, and therefore no means to establish statistics or any artificial intelligence in the USIM, for example, to adapt routing selection policies. Therefore, except for periodic polling requests from the USIM immediately after receiving a slice acceptance, the USIM does not know when slice status or information is updated in the ME based on information received from the network.

[0050] In step S6, the ME typically further evaluates a new request for a new PDU session establishment by an application in the ME that uses another URSP rule, e.g., slice Y, to select slice Y. This triggers the ME to execute step S7, requesting slice Y Req_SY. The network NW then accepts this request Acc_SY for slice Y in step S8. In the illustrative example of FIG. 1 , in step S9, a slice status polling message Pol_SS is sent immediately after the USIM receives the slice Y acceptance. Then, in step S10, the ME responds to the USIM by notifying the USIM of the availability of served slice Y Serv_SY. Note that if slice Y is accepted and no polling event occurs immediately after this acceptance, the USIM is notified only at the time of the next polling event, possibly outside the acceptance period. In such a case, the opportunity to monitor the slice is lost.

[0051] In the illustrative example of Figure 1, it is clear that the polling mode has the drawback of generating excessive battery consumption linked to regular commands sent from the USIM to the ME and of missing some served slices if the slice status is not requested at the right time. With a polling mechanism, information is available periodically, but not when the slice status and slice information are updated.

[0052] Furthermore, when a particular slice is selected by the ME based on URSP rules and is rejected by the network due to congestion on that particular slice, e.g., because there are too many UEs connected to that slice, such information cannot be received by the secure element USIM in the existing polling mode, since only served slice information Serv SY is currently sent to the USIM, which is currently the only slice-related information the USIM can obtain.

[0053] 2 shows a time diagram of the method of the present invention. According to this method, in step S5, the communications device ME prepares an event download envelope according to what is defined in the application toolkit in step S20, the event download envelope containing slice status and slice information, i.e., a response received from the network NW to a network slice request sent from the device ME to the network NW, where the status is rejected and the information is single network slice selection assistance information S-NSSAI for slice X and a rejection cause.

[0054] The information pushed to the card in the event envelope is the slice status, i.e., Allowed, Rejected, Service, and the minimum value associated with the slice information, i.e., the minimum value of the S-NSSAI of the corresponding slice. In case of a Rejected status, the reason for the rejection is also included in the slice information coming from the Rejected NSSAI information element and / or the Extended Rejected NSSAI information element, when available according to 3GPP TS 24.501 defining those information elements.

[0055] Such information is not already available between the device ME and the secure element USIM in any other event as currently standardized.

[0056] Then, in step S21, the device ME transmits the event download envelope EE (Rej_SX) to the secure element USIM.

[0057] In detail, the status of each slice can be as follows: The authorization is advantageously associated with a Single Network Slice Selection Assistance Information (S-NSSAI) value that the ME may use within a serving PLMN within its current registration area; -service, meaning that the requested slice is served by the network; - Rejection, preferably with grounds for rejection.

[0058] The slice information is: The Single Network Slice Selection Assistance Information (S-NSSAI) is defined in section 28.4.2 of document 3GPP TS 23.003. The S-NSSAI comprises a Slice Service Type (SST) that indicates the expected network slice behavior in terms of functionality and services, and a Slice Differentiator (SD) for distinguishing between multiple network slices of the same slice / service type. -If the status is rejected, it will be completed with a rejection reason defined as follows: "S-NSSAI not available in current PLMN or SNPN", - "S-NSSAI not available in current registration area", - "S-NSSAI not available due to failed or expired network slice specific authentication and authorization", - "S-NSSAI not available due to maximum number of UEs reached", -Rejection reasons identified later.

[0059] According to TS 31.111, in addition to the set of events currently defined in ETSI TS 102 223 clause 4.7, the following events may also be reported to the USIM as soon as the USIM is registered for the corresponding events, each event being associated with a class defined in the USIM Application Toolkit: -Network refusal, -CSG cell selection (if class "q" is supported), - Incoming IMS data (if classes "e" and "t" are supported), - IMS registration (if classes "e" and "t" are supported), -data connection status change (if class "e" is supported), - CAG cell selection (if class "ag" is supported).

[0060] Character classes and corresponding command / function descriptions are available in the standard document.

[0061] The present invention uses a previously unused class for slice status events, e.g. "ah". This provides the secure element USIM the opportunity to register for such slice events. Step SO of Figure 2 illustrates such pre-registration of a secure element in a device ME, said device supporting the application toolkit.

[0062] Advantageously, the ME stores a list of Single Network Slice Selection Assistance Information (S-NSSAI) in response to network negotiations, with the tree main list being Rejected S-NSSAIs that have been rejected due to the above-mentioned rejection causes, Authorized S-NSSAIs that may be queried, and Served S-NSSAIs that are currently being served by the network.

[0063] The invention makes it possible to notify the secure element USIM of any update of one of these lists, where an S-NSSAI is removed or inserted.

[0064] Therefore, as soon as the slice status event becomes part of the event list of the application toolkit, as set up by the last SET UP EVENT LIST command (see ETSI TS 102.223), when the ME detects any S-NSSAI status change, the device ME notifies the USIM according to the invention that this has occurred using ENVELOPE(EVENT DOWNLOAD-Slice Status), as described below.

[0065] According to TS 31.111, for the event list byte encoding, the following values ​​are defined in addition to those in ETSI TS 102 223 clause 8.25: - "11" = (l-) WLAN access status. - "12" = Network Reject - "15" = CSG cell selection - "17" = IMS Registration - "18" = Incoming IMS data - "1D" = Data connection status change - "1E" = CAG cell selection

[0066] The present invention uses a previously unused value for the slice status event, for example "1F".

[0067] In the following, an advantageous implementation of the event download envelope used in the present invention is presented: The direction of the event download envelope is defined as from the device ME to the secure element USIM.

[0068] The TERMINAL PROFILE and command header of the envelope as specified in 3GPP TS 31.111 are advantageously used to implement the invention. In the TERMINAL PROFILE the content is a list of USIM Application Toolkit features supported by the device ME. In the encoding, in one of the TERMINAL PROFILE bytes, one bit is used to encode the slice event feature according to the invention.

[0069] The following table illustrates the contents of the command parameters and data of the associated event download envelope slice status as prepared by a device supporting the class "ah" of the present invention, where the class actually determines the set of functions.

[0070] [Table 1]

[0071] The event list data object contains information of the associated event trigger, i.e. slice status. The device ME configures the event using the following additional data objects: device identity, access technology, slice status and slice information.

[0072] The device identity data object is set to source=network NW and destination=secure element USIM.

[0073] The access technology data object contains the access technology of the current serving cell. If the device is not camped on any cell, this data object is not present.

[0074] The slice status data object contains the slice status selected from the following: - Rejection means that any new S-NSSAI is included in the rejected S-NSSAI, - Admission means that any new S-NSSAI will be included in or removed from the Admitted NSSAI; -Servicing means that any new S-NSSAI is included in or removed from the served NSSAI.

[0075] The slice info data object contains a list of corresponding S-NSSAIs that are completed with the reject cause in case of rejected status.

[0076] If multiple changes to the rejected, admitted, and / or served S-NSSAI lists occur simultaneously, one event envelope is sent by the device ME for each status change.

[0077] As shown in Figure 2, after rejecting slice X, the ME typically requests another slice Y and gets acceptance of slice Y. Again, the device ME prepares an event download envelope according to that defined in the application toolkit in step S22. Then, in step S23, it sends an event envelope EE(Acc_SY) with an envelope event SIM Toolkit command to the USIM. This includes the slice status and slice information, i.e., the response received from the network NW to the network slice request sent from the device ME to the network NW. This time, the status is accepted and the information is the S-NSSAI for slice Y.

[0078] The slice status and slice information are then used by the USIM to enable processes linked to slice events, thereby affecting slice management in the ME.

[0079] Based on the slice event received from the device ME and the configuration information in the USIM, the USIM can start to perform slice-related processing.

[0080] In the example of FIG. 2 , in step S24, the secure element USIM adapts the URSP rules to the slice status and slice information, preferably to past slice status and slice information. These rules URSP_R are then sent to the device ME in step S25 to update the routing selection policy URSP used by the device for network slice management. Such updating of the URSP is advantageous for the device ME to always have behavior adapted to slice availability in real time. Based on the recorded status, the USIM typically calculates new priorities for the locally stored URSP rules and provides the prioritized URSP rules to the device ME. Any process based on a combination of the content of a received slice event and the content of a previously defined USIM configuration can benefit from the present invention. Typically, such a process uses a slice identifier as received in the slice event to execute the process.

[0081] Other types of USIM processes may also benefit from the present invention, and in particular, the present invention is advantageously combined with processes associated with specific slices that take a long time to accomplish.

[0082] Such processes are in particular on-board key generation, Subscription Concealed Identifier (SUCI) calculation, and any other processes involving cryptographic calculations. Knowing when a slice is selected as soon as possible is advantageously used to hide processing times.

[0083] Receipt of the event envelope of the present invention advantageously triggers the USIM to initiate an on-board key generation process, which is typically based on slice identity that is not readily available in the prior art.

[0084] According to the present invention, as soon as the slice request is accepted by the network and the acceptance status is received in the event envelope at the secure element, the secure element can start using the key generation parameters, e.g., type of key / algorithm, key length, required quality of the key, to generate a key, which can be used in the end-to-end encryption process, e.g., device authentication in the IoT Safe function, etc.

[0085] The envelope command contains information related to the accepted slice, i.e. at least the slice identity. The rest of the information required for e.g. key generation is configured in the USIM by the key owner, which can be either the HPLMN or a third party different from the HPLMN.

[0086] Upon receipt of the slice status in near real time at the secure element USIM, the secure element USIM may initiate a SUCI calculation for the slice, which may require network-specific slice authentication and authorization, for example in the case of a sliced ​​SIM use case.

[0087] The present invention also allows the USIM to calculate a reliable slice rejection rate in near real time. Furthermore, the present invention provides the possibility to calculate this rate per rejection cause, taking into account all rejected requests, which cannot be achieved with a polling mechanism where all rejected requests are possibly unknown. As a result, when such a rejection rate can be calculated, QoS can be improved by the USIM or a remote server. Based on the recorded slice status, the USIM advantageously calculates an availability score for each slice.

[0088] According to the present invention, in general, the USIM can perform statistics of slice availability and typically perform corresponding adjustments in the URSP rules to improve faster connectivity to adapted QoS via a particular slice.

[0089] The present invention allows the behavior of the secure element USIM to be changed without delay with respect to slice availability, a result that becomes increasingly useful as the amount of devices that benefit from network slicing increases.

[0090] Based on the near real-time slice status, the slice application can then, in the case of a rejection cause, notify the backend server that the slice has been rejected with the associated rejection cause, and the backend server can take action in real time within the network to prevent later rejections.

[0091] Based on the near real-time slice status, the slice application can also check that for a served S-NSSAI, the slice discriminator SD in the S-NSSAI (which gives the current instance of the slice) is consistent with its data and / or power consumption. It can then notify the backend server without delay, which can take action to prevent such inappropriate slice allocation later.

[0092] Also, in case of authorized S-NSSAI, the application can check that the URSP rules are properly adhered to.

[0093] In another advantageous implementation, the USIM with all information regarding slice acceptance and rejection notifies the PLMN operator's backend server, which can then consolidate the slice status and slice information collected from multiple USIMs and take action to update the USRP for all relevant subscriptions.

[0094] The configuration parameters in the USIM combined with the slice events including slice identity and slice status are process-specific configuration information.

[0095] USIM configuration parameters include key / algorithm type, key length, required quality of the key for on-board key generation.

[0096] The USIM configuration parameters include the private network's public key for encryption of the user identity in the context of the SUCI calculation.

[0097] The USIM configuration parameters include a scoring algorithm based on slice availability or rejection rate, possibly sorted by rejection cause, for reprioritization of URSP rules.

[0098] The USIM configuration parameters include the duration of the information, the remote server address, and the request information to be sent to notify the remote server of slice-related statistics.

[0099] Such configuration parameters depend on the process that should be executed in the USIM as soon as a slice event is received.

[0100] In an advantageous embodiment illustrated in FIG. 2 , the secure element USIM first provides the device ME with a first list of URSP rules with priority 1. When the device ME sends an EVENT STK command to the USIM including a slice status, i.e., a response received from the network to a network slice request sent from the device ME to the network, the secure element USIM records the status of the network slice request. Based on the recorded slice status, the USIM typically calculates an availability score for each slice, and based on the calculated score, the USIM derives a new priority of 2 for the URSP rules. The USIM then locally updates the priorities of the URSP rules according to the new priority of 2. Finally, the USIM updates the ME with a second list of URSP rules with a priority of 2.

[0101] In the foregoing detailed description, reference has been made to the accompanying drawings which show, by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Accordingly, the foregoing detailed description is not to be taken in a limiting sense, and the scope of the invention is defined only by the appended claims, appropriately interpreted.

Claims

1. 1. A method for monitoring management of a network slice by a communication device ME having a secure element USIM, the communication device being compliant with at least a technology for implementing network slicing using a route selection policy, the communication device further supporting a USIM application toolkit framework implementing an event download envelope, the method comprising the steps of: - receiving by the communication device ME a slice status and slice information from the network NW, wherein the slice status is a slice served by said network NW; slices authorized by the network NW; a slice rejected by the network NW, the slice information of which refers to a list of slices corresponding to the slice status; detecting by the communication device ME any slice status change from the slice status stored in the communication device ME; - the communication device ME pushing the slice status and the slice information to the secure element USIM using an event download envelope defined in the USIM application toolkit framework supported by the communication device ME.

2. 2. The method of claim 1, comprising a preliminary step for the secure element USIM to register with slice events defined in the USIM Application Toolkit Framework supported by the communication device ME.

3. The secure element USIM, - recording said slice status and slice information; The method of claim 1, further comprising: - executing, based on the slice status and slice information, at least one process associated with the slice related by the slice status and slice information.

4. 4. The method of claim 3, wherein the associated process comprises a combination of the slice status and slice information with at least one secure element configuration parameter previously defined and stored within the secure element USIM.

5. The method of claim 3 , wherein the associated process includes slice availability statistics calculation.

6. 4. The method of claim 3, wherein the secure element USIM has a memory for storing rules for the route selection policy, and the associated process comprises the calculation of new rules for the route selection policy, and the method further comprises the step of updating, by the secure element USIM in its memory, the stored rules for the route selection policy.

7. 4. The method of claim 3, wherein the associated process comprises a cryptographic calculation involving the slice status and slice information and at least one cryptographic configuration parameter of the secure element USIM.

8. A communication device ME having a secure element USIM, the communication device ME being configured to monitor management of a network slice, the communication device ME being compliant with at least a technology implementing network slicing using a route selection policy, the communication device ME further supporting a USIM application toolkit framework implementing an event download envelope, the communication device ME being active in a network of a technology implementing network slicing, the communication device ME including a microprocessor, the microprocessor comprising: Receive slice status and slice information from the network NW, and the slice status is a slice served by said network NW; slices authorized by the network NW; a slice rejected by the network NW, the slice information of which refers to a list of slices corresponding to the slice status; detecting any slice status change from the slice status stored in the communication device ME; A communication device ME configured to push the slice status and the slice information to the secure element USIM using an event download envelope defined in the USIM application toolkit framework supported by the communication device ME.

9. a secure element USIM installed in a communication device ME configured to monitor management of a network slice using the secure element USIM, the communication device ME conforming to at least a technology implementing network slicing using a route selection policy, the communication device ME further supporting a USIM application toolkit framework implementing an event download envelope, the secure element USIM including a microprocessor configured to receive slice status and slice information pushed in an event download envelope defined in the USIM application toolkit framework supported by the communication device ME when the communication device ME is active in a network of a technology implementing network slicing; The slice status is a slice served by said network NW; slices authorized by the network NW; a slice rejected by the network NW, the slice information of which refers to a list of slices corresponding to the slice status; One of these is the Secure Element USIM.

10. The secure element USIM according to claim 9, wherein the secure element USIM is configured to register at the communication device ME with slice events defined in the USIM application toolkit framework supported by the communication device ME.

11. The secure element USIM of claim 9, wherein the secure element USIM is configured to record the slice status and slice information and, based on the slice status and slice information, execute at least one process associated with the slice related by the slice status and slice information.

12. 12. The secure element USIM of claim 11, wherein the secure element USIM has a memory that stores rules for the route selection policy, and wherein the secure element USIM is further configured to perform associated processes including calculating new rules for the route selection policy and updating the stored rules for the route selection policy in its memory.

13. The secure element USIM of claim 11, wherein the secure element USIM is further configured to perform an associated process involving a combination of the slice status and slice information with at least one secure element configuration parameter predefined and stored within the secure element USIM.

14. The secure element USIM of claim 11, wherein the secure element USIM is further configured to perform associated processes including slice availability statistics calculation.

15. The secure element USIM of claim 11, wherein the secure element USIM is further configured to perform an associated process including a cryptographic calculation involving the slice status and slice information and at least one cryptographic configuration parameter of the secure element USIM.

Images