Improvements in and relating to multi-USIM operation in a mobile telecommunications environment

Abstract

A method of operating a user equipment (UE) with multi universal subscriber identity module (MUSIM) capability, wherein if the UE does not have an allowed network slice selection assistance informatio

Description

A Multi-USIM (MUSIM) User Equipment, UE, is a UE that supports more than one Universal Subscriber Identity Module, USIM, and hence can be simultaneously registered to multiple Public Land Mobile Networks, PLMNs, (or more conveniently, networks). When this is the case, the multiple registrations can lead to the UE switching between the PLMNs for the purpose of getting a particular service e.g. voice service. The UE can send some information to a serving network (e.g. the Access and Mobility Management Function, AMF of the network) which helps determine the UE’s preferences with respect to MUSIM operations. For example, the UE may send a so called ‘paging restriction’ to inform the network about whether the UE would preferto be paged, or whether paging should be restricted for all or some services, etc. The description of the MUSIM features is shown below from 3GPP TR 23.501 V17.1.1: 5.38 Support for Multi-USIM UE 5.38.1 General A network and a UE may support one or more of the following enhancements for Multi-USIM UE operation: - Connection release as described in clause 5.38.2; - Paging Cause Indication for Voice Service, as described in clause 5.38.3; - Reject paging request, as described in clause 5.38.4; - Paging Restriction, as described in clause 5.38.5. In the Registration procedure (as specified in clause 4.2.2.2.2), when a Multi-USIM UE has more than one USIM active, supports and intends to use one or more Multi-USIM specific features, it indicates to the AMF the corresponding Multi-USIM feature(s) are supported. Based on the received indication of supported Multi-USIM features from the UE, the AMF shall indicate to the UE the support of the Multi-USIM features based on the Multi-USIM features supported by network and any preference policy by the network, if available. When a UE turns to have only one USIM active from a Multi-USIM UE that previously indicated to the network for the USIM with supported Multi-USIM feature(s), the UE shall indicate all the Multi-USIM features are not supported to the network for the USIM. The AMF shall indicate the support of Paging Restriction feature together with the support of either Connection Release feature or Reject Paging feature. The Multi-MUSIM UE includes the support of individual features for Connection release, Paging Cause Indication for Voice Service, Reject paging request and Paging Restriction as specified in clause 5.4.4a. A Multi-USIM UE shall use a separate PEI for each USIM when it registers to the network. 5.38.2 Connection release A Multi-USIM UE may request the network to release the UE from RRC-CONNECTED state for a USIM due to activity on another USIM, if both UE and network indicate this feature is supported to each other. The UE indicates that it requests to be released from RRC-CONNECTED state, by initiating either a Service Request procedure or a Registration procedure (in case the UE needs to perform Registration Update at the same time with this network), including a Release Indication. If supported by the UE, the UE may also provide, only together with the Release Indication, a Paging Restriction Information, as specified in clause 5.38.5, which requests the network to restrict paging. The Paging Restriction Information from the UE is stored in the UE context in the AMF. If no Paging Restriction Information is provided in the Service Request or the Registration Request, any stored Paging Restriction Information in the UE context is removed. When the UE initiates a Service Request procedure or Registration procedure without providing a Release Indication, the network removes any stored Paging Restriction Information. NOTE: When there is no PLMN-wide support for the Connection Release feature, it can occur that upon mobility update with Connection Release request the UE is not released by the network. The UE behaviour, when it detects that the network does not support the feature in a new RA, is outside the scope of this specification. Editor's note: It is FFS if the connection release is performed via AS procedure for NR connects to 5GC. 5.38.3 Paging cause indication for voice service The UE and the network may support Paging Cause Indication for Voice Service feature. The network that supports Paging Cause Indication for Voice Service feature shall provide a Voice Service Indication for IMS voice service in the Paging message, only if the UE indicates the Paging Cause Indication for Voice Service feature is supported to the network. The network determines the IMS voice service based on the Paging Policy Indicator as specified in clause 5.4.3.2. Upon reception of the Voice Service Indication in NGAP Paging Message from AMF, the NG-RAN supporting Paging Cause Indication for Voice Service should include the Voice Service Indication in the Uu Paging message to the UE. When the UE context indicates Paging Cause Indication for Voice Service feature is supported, in order to require NG RAN to deliver the Voice Service Indication in RAN paging for UE in RRC-lnactive state, the AMF provides an indication indicating the Paging Cause Indication for Voice Service feature is supported to the NG-RAN. Upon reception the indication, the NG-RAN supporting the Paging Cause Indication for Voice Service indication feature stores it into the UE context. For a UE in RRC-lnactive, the NG-RAN should provide the Voice Service Indication in the RAN Paging message only when there is Paging Cause Indication for Voice Service indication in the UE context and detects the downlink data which triggers the RAN Paging message is related to voice service based on the Paging Policy Indicator, in the header of the received downlink data, as specified in clause 5.4.3.2. UE that supports the Paging Cause Indication for Voice Service feature is capable of differentiation between Paging from a network that does not support the Paging Cause Indication for Voice Service feature and Paging without the Voice Service Indication. Editor's note: How the UE can distinguish the Paging from a network that does not support the Paging Cause Indication for Voice Service feature and Paging without the Voice Service Indication depends upon RAN's decision. 5.38.4 Reject paging request A Multi-USIM UE may setup connection to respond to a page with a Reject Paging Indication to the network indicating that the UE does not accept the paging and requests to return to CM-IDLE state after sending this response, if both UE and network indicate this feature is supported to each other. Upon being paged by the network, the Multi-USIM UE in CM-IDLE state attempts to send a Service Request message to this network including the Reject Paging Indication, unless it is unable to do so, e.g. due to UE implementation constraints. In addition to the Reject Paging Indication, the UE may include Paging Restriction Information as specified in clause 5.38.5 in the Service Request message, if supported by UE. 5.38.5 Paging restriction The UE and the network may support Paging Restriction. The UE, if the AMF indicates that the network supports Paging Restriction feature, may indicate Paging Restriction Information in the Service Request or Registration Request message as specified in clauses 5.38.2 and 5.38.4. The Paging Restriction Information may indicate any of the following: a) all paging is restricted; or b) all paging is restricted, except paging for voice service (IMS voice); or c) all paging is restricted, except for certain PDU Session(s); or d) all paging is restricted, except paging for voice service (IMS voice) and certain PDU session(s). NOTE 1: The UE expects not to be paged for any purpose in case a). The UE expects to be paged only for voice service in case b). The UE expects to be paged only for certain PDU Session(s) in case c). The UE expects to be paged for voice service and certain PDU session(s) in case d). NOTE 2: In the case of roaming, the Paging Restrictions for voice service implied by bullet b) and d) depends on the existence of an agreement with the HPLMN to support voice service via IMS. Hence the support of paging restrictions in bullets b) and d) takes the IMS voice service agreement into consideration. Other details regarding the UE behaviour with respect to the MUSIM feature can be found in 3GPP TS 24.501 V17.3.1. The following provides an overview of Network Slice-Specific Authentication &Authorization (NSSAA). NSSAA is a feature which ensures that a registered UE will always have a slice which is either allowed because is it not subject to NSSAA or if it is subject to NSSAA then the authentication must first succeed before the allowed Network Slice Selection Assistance Information, NSSAI, is provided to the UE. When slices are subject to NSSAA, the UE can receive a Registration Accept message with no allowed NSSAI as described in 3GPP TS 24.501 V17.3.1. In this case, the message will contain a pending NSSAI and the "NSSAA to be performed" indicator set to "Network slicespecific authentication and authorization is to be performed". The network then performs the NSSAA procedure and if there is at least one slice for which the NSSAA succeeds, then the slice is provided to the UE as the allowed NSSAI. Otherwise, if no slice is available due to failed NSSAA, then the UE will be deregistered. What is important to note in this application is that whilst the UE is awaiting the result of NSSAA, i.e. whilst no allowed NSSAI is received by the UE, the UE is prohibited from initiating certain procedures e.g. the service request procedure, except if specific conditions are met. This behaviour is described below from 3GPP TS 24.501 V17.3.1: “If the REGISTRATION ACCEPT message: a) includes the 5GS registration result IE with the "NSSAA to be performed" indicator set to "Network slice-specific authentication and authorization is to be performed" the "NSSAA to be performed" indicator in the 5GS registration result IE; b) includes a pending NSSAI; and c) does not include an allowed NSSAI, the UE shall delete the stored allowed NSSAI, if any, as specified in subclause 4.6.2.2, and the UE: a) shall not initiate a 5GSM procedure except for emergency services; and b) shall not initiate a service request procedure except for cases f) and i) in subclause 5.6.1.1 ; c) shall not initiate a NAS transport procedure except for sending SMS, an LPP message, a location service message, an SOR transparent container, a UE policy container, a UE parameters update transparent container or a CioT user data container until the UE receives an allowed NSSAI; until the UE receives an allowed NSSAI.” For the sake of clarity, the cases defined as triggers for the service request procedure are shown below from 3GPP TS 24.501 V17.3.1: “The UE shall invoke the service request procedure when: a) the UE, in 5GMM-IDLE mode over 3GPP access, receives a paging request from the network; NOTE 3: As an implementation option, the MUSIM capable UE is allowed to not invoke service request to respond to paging based on the information available in the paging message, e.g. voice service indication. b) the UE, in 5GMM-CONNECTED mode over 3GPP access, receives a notification from the network with access type indicating non-3GPP access; c) the UE, in 5GMM-IDLE mode over 3GPP access, has uplink signalling pending (except in case i); d) the UE, in 5GMM-IDLE mode over 3GPP access, has uplink user data pending (except in case j); e) the UE, in 5GMM-CONNECTED mode or in 5GMM-CONNECTED mode with RRC inactive indication, has user data pending due to no user-plane resources established for PDU session(s) used for user data transport; f) the UE in 5GMM-IDLE mode over non-3GPP access, with T3346 not active or upon expiry of T3346, receives or has already received an indication from the lower layers of non-3GPP access, that the access stratum connection is established between UE and network; g) the UE, in 5GMM-IDLE mode over 3GPP access, receives a notification from the network with access type indicating 3GPP access when the UE is in 5GMM-CONNECTED mode over non-3GPP access; h) the UE, in 5GMM-IDLE, 5GMM-CONNECTED mode over 3GPP access. or 5GMM-CONNECTED mode with RRC inactive indication, receives a request from the upper layers to perform emergency services fallback and performs emergency services fallback as specified in subclause 4.13.4.2 of3GPP TS 23.502 [9]; i) the UE, in 5GMM-CONNECTED mode over 3GPP access or in 5GMM-CONNECTED mode with RRC inactive indication, receives a fallback indication from the lower layers (see subclauses 5.3.1.2 and 5.3.1.4) and the UE has a pending NAS procedure other than a registration, service request, or de-registration procedure; j) the UE, in 5GMM-CONNECTED mode over 3GPP access or in 5GMM-CONNECTED mode with RRC inactive indication, receives a fallback indication from the lower layers (see subclauses 5.3.1.2 and 5.3.1.4) and the UE has pending uplink user data for PDU session(s) with user-plane resources already established but no pending NAS procedure; k) the UE, in 5GMM-CONNECTED mode and has a NAS signalling connection only, is using 5GS services with control plane CloT 5GS optimization and has pending user data to be sent via user-plane resources; I) the UE in 5GMM-IDLE mode over 3GPP access has to request resources for V2X communication over PC5 (see 3GPP TS 23.287 [6C]); m) the UE that is MUSIM capable and in 5GMM-IDLE mode is requesting the network to remove the paging restriction; n) the UE in 5GMM-IDLE mode over 3GPP access has to request resources for ProSe direct discovery over PC5 or ProSe direct communication over PC5 (see 3GPP TS 23.304 [6E]); o) the UE supports MUSIM, in 5GMM-CONNECTED mode requests the network to release the NAS signalling connection and optionally includes paging restrictions; or p) the UE supports MUSIM, in 5GMM-IDLE mode when responding to paging rejects the paging request from the network, requests the network to release the NAS signalling connection and optionally includes paging restrictions.” As can be seen from the text above, the exceptions to the initiation of the service request procedure when no allowed NSSAI is available include cases 1) and i) which are: “f)the UE in 5GMM-IDLE mode over non-3GPP access, with T3346 not active or upon expiry of T3346, receives or has already received an indication from the lower layers of non-3GPP access, that the access stratum connection is established between UE and network; i) the UE, in 5GMM-CONNECTED mode over 3GPP access or in 5GMM-CONNECTED mode with RRC inactive indication, receives a fallback indication from the lower layers (see subclauses 5.3.1.2 and 5.3.1.4) and the UE has a pending NAS procedure other than a registration, service request, or de-registration procedure;” All other cases (of triggers for the service request procedure) would therefore be prohibited when no allowed NSSAI is available at the UE. The following relates to 5GMM-CONNECTED mode with RRC inactive indication. One of the modes of a UE in 5GS is to be in 5GMM-CONNECTED mode with RRC inactive indication. In this mode, the NAS connection is considered to be established while the RRC is considered to apply the procedures of RRC_IDLE state. The detailed behaviour of a UE in 5GMM-CONNECTED mode with RRC inactive indication is provided below from section 5.3.1.4 in 3GPP TS 24.501 V17.3.1: This subclause is only applicable for UE's 5GMIVI mode over 3GPP access. The 5GMM-CONNECTED mode with RRC inactive indication is not supported when the UE is in NB-N1 mode. The UE is in 5GMM-CONNECTED mode with RRC inactive indication when the UE is in: a) 5GMM-CONNECTED mode over 3GPP access at the NAS layer; and b) RRC_INACTIVE state at the AS layer (see 3GPP TS 38.300

[27] ). Unless stated otherwise, the UE behaviour in 5GMM-CONNECTED mode with RRC inactive indication follows the UE behaviour in 5GMM-CONNECTED over3GPP access, except that: a) the UE shall apply the mobility restrictions; and b) the UE shall perform the PLMN selection procedures as in 5GMM-IDLE mode over 3GPP access. The UE shall transition from 5GMM-CONNECTED mode over 3GPP access to 5GMM-CONNECTED mode with RRC inactive indication upon receiving an indication from the lower layers that the RRC connection has been suspended. NOTE 0: Any pending procedure or uplink data packet when receiving an indication from the lower layers that the RRC connection has been suspended, triggers a request to the lower layers to transition to RRC_CONNECTED state. This is also the case when the pending procedure or uplink data packet triggered a previous request to the lower layers to transition to RRC_CONNECTED state. Upon: a) a trigger of a procedure which requires sending of a NAS message different from a REGISTRATION REQUEST message with the NG-RAN-RCU bit of the 5GS update type IE set to "UE radio capability update needed"; or b) an uplink user data packet to be sent for a PDU session with suspended userplane resources; the UE in 5GMM-CONNECTED mode with RRC inactive indication over 3GPP access shall request the lower layers to transition to RRC_CONNECTED state (see 3GPP TS 38.300

[27] ). Upon a trigger to send a REGISTRATION REQUEST message with the NG-RAN-RCU bit of the 5GS update type IE set to "UE radio capability update needed", the UE in 5GMM-CONNECTED mode with RRC inactive indication shall move to 5GMM-IDLE mode over 3GPP access and proceed with the registration procedure for mobility and periodic registration as specified in subclause 5.5.1.3.2. The UE shall transition from 5GMM-CONNECTED mode with RRC inactive indication to 5GMM-CONNECTED mode over 3GPP access upon receiving an indication from the lower layers that the UE has transitioned to RRC_CONNECTED state (see 3GPP TS 38.300

[27] ). NOTE 1: The AMF can be aware of the transition between 5GMM-CONNECTED mode and 5GMM-CONNECTED mode with RRC inactive indication for a UE (see 3GPP TS 23.502 [9]). The UE shall trigger a transition from 5GMM-CONNECTED mode with RRC inactive indication to 5GMM-IDLE mode upon selection of a PLMN that is not an equivalent PLMN to the registered PLMN. The UE shall not trigger a transition from 5GMM-CONNECTED mode with RRC inactive indication to 5GMM-IDLE mode upon entering a new PLMN which is in the list of equivalent PLMNs. The UE shall trigger a transition from 5GMM-CONNECTED mode with RRC inactive indication to 5GMM-IDLE mode upon receiving REFRESH command from the UICC as specified in subclause 5.4.5.3.3. If the UE in 5GMM-CONNECTED mode with RRC inactive indication receives an indication from the lower layers that the RRC connection has been suspended, the UE shall stay in 5GMM-CONNECTED mode with RRC inactive indication. The UE shall re-initiate any pending procedure that had triggered the request to the lower layers to transition to RRC_CONNECTED state, if still needed. When the UE in 5GMM-CONNECTED mode with RRC inactive indication receives a fallback indication from lower layers, and the UE has no pending NAS procedure and no pending uplink user data for PDU session(s) with user-plane resources already established, the UE shall: a) enter 5GMM-IDLE mode; and b) initiate the registration procedure for mobility and periodic registration update and include the Uplink data status IE in the REGISTRATION REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.5.1.3 for further details). If the UE requests the lower layers to transition to RRC_CONNECTED state at initiation of a registration procedure, a service request procedure or a de-registration procedure, upon fallback indication from lower layers, the UE shall: enter 5GMM-IDLE mode; proceed with the pending procedure; and if the pending procedure is a service request or registration request procedure, the UE shall include the Uplink data status IE in the SERVICE REQUEST message, the CONTROL PLANE SERVICE REQUEST message or in the REGISTRATION REQUEST message, indicating the PDU session(s) without active user-plane resources for which the UE has pending user data to be sent, if any, and the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclauses 5.5.1.3 and 5.6.1 for further details). If the UE requests the lower layers to transition to RRC_CONNECTED state for other reason than initiation of a registration procedure, or for other reason than a service request procedure, or for other reason than a de-registration procedure, upon fallback indication from lower layers, the UE shall: 1) enter 5GMM-IDLE mode; 2) initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message or the CONTROL PLANE SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication, if any (see subclause 5.6.1 for further details). If the procedure that triggered the request to the lower layers to transition to RRC_CONNECTED state is the UE-initiated NAS transport procedure and the UE had SMS, location services message, or CioT user data to send, the UE shall also include the SMS, location services message, or CioT user data in the CONTROL PLANE SERVICE REQUEST message as described in subclause 5.6.1.2.2; and 3) upon successful service request procedure completion, proceed with any pending procedure. If the UE in 5GMM-CONNECTED mode with RRC inactive indication receives a fallback indication from lower layers, and the UE has pending uplink user data for PDU session(s) with user-plane resources already established but no pending NAS procedure, the UE shall: 1) enter 5GMM-IDLE mode; and 2) initiate the service request procedure and include the Uplink data status IE in the SERVICE REQUEST message or the CONTROL PLANE SERVICE REQUEST message indicating the PDU session(s) for which user-plane resources were active prior to receiving the fallback indication (see subclause 5.6.1 for further details). In the above cases when the UE receives a fallback indication from lower layers, if the UE is in non-allowed area or not in allowed area, the UE shall behave as specified in subclause 5.3.5. If the UE in 5GMM-CONNECTED mode with RRC inactive indication receives an indication from the lower layers that the resumption of the RRC connection has failed, and: a) if the lower layers indicate that access barring is applicable for all access categories except categories 0 and 2, or access barring is applicable for all access categories except category 0, the UE shall: 1) stay in 5GMM-CONNECTED mode with RRC inactive indication; b) else, the UE shall: 1) enter 5GMM-IDLE mode; and 2) initiate the registration procedure for mobility and periodic registration update used for mobility (i.e. the 5GS registration type IE set to "mobility registration updating" in the REGISTRATION REQUEST message) for N1 NAS signalling connection recovery as specified in subclause 5.5.1.3.2. NOTE 2: An indication from the lower layer that the RRC connection has been released with cause "RRC resume failure" can be considered as an indication that the resumption of the RRC connection has failed. The UE shall transition from 5GMM-CONNECTED mode with RRC inactive indication to 5GMM-IDLE mode over 3GPP access upon receiving from the lower layers: a) indication of transition from RRCJNACTIVE state to RRCJDLE state; or b) indication of cell selection to E-UTRAN or another RA T that the UE supports. If the UE in 5GMM-CONNECTED mode with RRC inactive indication receives an indication from the lower layers about the cell (re-)selection to different RAT that the UE supports, the UE shall initiate the registration procedure for mobility or periodic registration update used for mobility (i.e. the 5GS registration type IE set to "mobility registration updating" in the REGISTRATION REQUEST message) as specified in subclause 5.5.1.3.2. If the UE in 5GMM-CONNECTED mode with RRC inactive indication receives an indication from the lower layers of a transition from RRCJNACTIVE state to RRCJDLE state and 5GMM-REGISTERED.LIMITED-SERVICE is entered, the UE shall subsequently upon entering state 5GMM-REGISTERED.NORMAL-SERVICE and if there is no uplink user data or signalling pending, initiate the registration procedure for mobility and periodic registration update used for mobility (i.e. the 5GS registration type IE set to "mobility registration updating" in the REGISTRATION REQUEST message) for N1 NAS signalling connection recovery as specified in subclause 5.5.1.3.2. Upon receiving AMF paging indication from the lower layers, the UE shall transition from 5GMM-CONNECTED mode with RRC inactive indication to 5GMM-IDLE mode over 3GPP access and handle the AMF paging same as the paging request received in the 5GMM-IDLE mode over 3GPP access as specified in subclause 5.6.1. As can be seen, the text above defines the current triggers for which the UE (or NAS) will request the lower layers to resume the connection. After the connection is resumed i.e. the RRC enters RRC_CONNECTED state, then the NAS would enter 5GMM-CONNECTED mode with RRC inactive indication. There are a number of problems associated with the aforementioned description of the prior art. The first relates to impacts to the MUSIM feature due to a lack of an allowed NSSAI. As explained earlier, a UE without an allowed NSSAI e.g. due to an ongoing NSSAA procedure, would not be allowed to initiate a service request procedure unless the trigger is related to the current existing exceptions as defined in 3GPP TS 24.501 V17.3.1. However, since the use of a MUSIM feature is currently not part of these exceptions, the UE which requires its NAS connection to be released so that it can get service on another PLMN will face delays since it cannot send a (CONTROL PLANE) Service Request message to request the release of the NAS connection. This means that the UE which needs to leave its current PLMN to go to another PLMN and place a voice call will not be able to do so i.e. the UE without an allowed NSSAI is not able to request the network to release the NAS connection as required (and as explained above). This will cause a very negative user experience since the call will be delayed. As such, the problem is that the current exceptions are not addressing the MUSIM feature and hence should be updated. A second problem relates to undefined UE behaviour for a MUSIM service when in 5GMM-CONNECTED mode with RRC inactive indication. For a UE in 5GMM-CONNECTED mode with RRC inactive indication, the UE may require use of a MUSIM service e.g. to leave the current PLMN and use another PLMN and hence another USIM. How the UE would achieve this is currently unspecified. This leads to different UE behaviours and the network would not be able to predict how different UEs will behave. In other words, therefore, the UE will not be able to leave to another PLMN and this will cause a delay in the service. This can also potentially lead to different UEs behaving in an unexpected manner which leaves the network unable to control how the UEs would leave to get service in another PLMN. It is normally desired that UEs should follow a standardized behaviour as otherwise there will be negative outcomes when different UEs behave differently e.g. by generating signalling or leaving a network without notification that can later lead to wasted transmissions of downlink signalling, etc. Moreover, the UE behaviour needs to be defined so as to reduce delays in obtaining MUSIM services. A third problem relates to undefined UE behaviour for a MUSIM service when in 5GMM-IDLE mode with suspend indication. For a UE in 5GMM-IDLE mode with suspend indication, the UE may require to use a MUSIM service e.g. to leave the current PLMN and use another PLMN and hence another USIM. How the UE would achieve this is currently unspecified. This leads to different UE behaviours and the network would not be able to predict how different UEs will behave. It is normally desired that UEs should follow a standardized behaviour as otherwise there will be negative outcomes when different UEs behave differently e.g. by generating signalling or leaving a network without notification that can later lead to wasted transmissions of downlink signalling, etc. Moreover, the UE behaviour needs to be defined so as to reduce delays in obtaining MUSIM services. According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows. According to a first aspect of the invention, there is provided a method of operating a User Equipment, UE, with MUSIM capability, wherein if the UE does not have an allowed NSSAI, a service request procedure is permitted if an associated trigger is related to a MUSIM feature. In an embodiment, if a REGISTRATION ACCEPT message: a) includes a 5GS registration result Information Element, IE, with the "Network slicespecific authentication and authorization, NSSAA, to be performed" indicator set to "Network slice-specific authentication and authorization is to be performed"; b) includes a pending Network Slice Selection Assistance Information, NSSAI; and c) does not include an allowed NSSAI, then the UE shall delete a stored allowed NSSAI, if present and shall not initiate the service request procedure unless associated with a MUSIM feature. According to a second aspect of the invention, there is provided a method of operating a User Equipment, UE, with MUSIM capability, wherein if the UE is in 5GMM-CONNECTED mode with RRC inactive indication, and experiences a MUSIM request, the UE either sends a NAS message to request the MUSIM service from a connected network, or the UE autonomously enters 5GMM-IDLE mode. In an embodiment, the UE requests the network to release the NAS signalling connection In an embodiment, the request further includes paging restrictions. According to a third aspect of the invention, there is provided a method of operating a User Equipment, UE, with MUSIM capability, wherein if the UE is in EMM-IDLE mode with suspend indication, and experiences a MUSIM request, the UE either sends a NAS message to request the MUSIM service from a connected network or the UE autonomously enters EMM-IDLE mode. In an embodiment, if the NAS message is i) a SERVICE REQUEST message; ii) a CONTROL PLANE SERVICE REQUEST message, and the UE did not include any ESM message container, NAS message container, EPS bearer context status information element, or UE request type information element; or Hi) an EXTENDED SERVICE REQUEST message, and the Service type information element indicates "packet services via S1" and the UE did not include any EPS bearer context status information element, or UE request type information element; then the message shall not be sent. In an embodiment, the MUSIM feature is one of: Connection release, Paging Cause Indication, Reject paging request, Paging Restriction and delete stored paging restrictions information. According to a fourth aspect of the invention, there is provided apparatus arranged to perform the method of any preceding aspect. Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims. For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows an example of UE behaviour for an exception to the service request procedure due to a MUSIM feature according to an embodiment of the invention; Figure 2 shows an example of how a UE may obtain MUSIM service when in 5GMM-CONNECTED mode with RRC inactive indication; and Figure 3 shows an example of how a UE may obtain MUSIM service when in 5GMM-IDLE / EMM-IDLE mode with suspend indication. Note that the term “MUSIM feature” can be related to, or can refer to, any of the following: connection release (e.g. for MUSIM), paging cause indication (e.g. for MUSIM), reject paging request (e.g. for MUSIM), or paging restriction (e.g. for MUSIM), or any combination of these features. Note that the details set out herein can be applied in any combination and in any order. They can also be applied to the UE in S1 mode (if possible) or N1 mode, or both (if possible). Note that S1 mode may refer to EPS, and N1 mode may refer to 5GS and as such the network may refer to one or more nodes such as the MME (in EPS) or the AMF (in 5GS). Note that throughout this application, a request that is related to a MUSIM feature, or a request to obtain a MUSIM service, may refer to the sending of a NAS message where optionally the NAS message includes the UE request type Information Element, IE, where optionally the IE may be set to indicate "NAS signalling connection release" or "Rejection of paging" or any value that may be defined in the future for this IE. In an embodiment, the UE allows the initiation of service request procedure for MUSIM even when no allowed NSSAI is available. When the UE receives a REGISTRATION ACCEPT message which does not include an allowed NSSAI and optionally which includes a pending NSSAI and optionally which includes the 5GS registration result IE with the "NSSAA to be performed" indicator set to "Network slice-specific authentication and authorization is to be performed", then the UE should not permit the initiation of the (or should not initiate the) service request procedure except if the reason to do so is for a MUSIM feature, where for example the UE needs to indicate in / set the Request type to "NAS signalling connection release" or to "Rejection of paging" in the UE request type IE of the Service Request message or of the Control Plane Service Request message (or when any other new value that is related to a MUSIM feature is defined in the future). As such, when the UE does not have an allowed NSSAI, optionally due to an ongoing NSSAA procedure, the UE should verify the trigger for a service request procedure based on which the UE should determine whether to initiate the procedure (by sending the appropriate NAS message e.g. Service Request message or of the Control Plane Service Request message) or not. If the UE determines that the trigger is for a MUSIM feature, then the UE should allow / initiate the procedure by sending the Service Request message or the Control Plane Service Request message. Otherwise, if the trigger is not related to a MUSIM feature, the UE should not initiate the procedure except if the trigger is for an existing exception as described in 3GPPTS 24.501 V17.3.1. Note that for all of the details set out herein, the UE may first determine what action to take based on configuration that is stored in the UE, where this configuration is either preconfigured in the UE or is received from the network e.g. in any NAS message. Figure 1 shows an example UE behaviour as per the embodiment set out above. At step S10, the UE receives a Registration Accept without an allowed NSSAI message from the network. At step S20, a trigger for a service request is received or is available. As step S30, the UE verifies if the trigger is related to at least one MUSIM feature. If not, at step S40, the procedure is blocked and flow returns to S10. If the result of the verification at S30 is positive, then the procedure is allowed or initiated and the necessary NAS message is sent. The NAS message may be e.g. a (Control Plane) Service Request message. A second embodiment involves obtaining MUSIM services when a UE is in 5GMM-CONNECTED mode with RRC inactive indication. This embodiment sets out new behaviour for a UE to obtain a USIM service. Optionally this section only applies to mobile originated requests for MUSIM feature i.e. requests that are originated by the UE and not terminated at the UE (i.e. not initiated by the network). Note that in this entire document, a request that is related to a MUSIM feature, or a request to obtain a MUSIM service, may refer to the sending of a NAS message where optionally the NAS message includes the UE request type IE, where optionally the IE may be set to indicate "NAS signalling connection release" or any value that may be defined in the future for this IE. In a first option, when the UE in 5GMM-CONNECTED mode with RRC inactive indication requires to use a MUSIM feature / service, the UE should send a NAS message and include the UE request type IE, where the IE may be set to "NAS signalling connection release" or any value that may be defined in the future for this IE. The UE may first request the lower layers (e.g. the RRC layer) to resume the connection and then the UE sends the NAS message optionally after the connection is resumed. The NAS message that should be used may be any of the following: Registration Request, Service Request, or Control Plane Service Request. At least for the case when the UE request type IE is set to "NAS signalling connection release", the UE should ensure that the NAS message (e.g. any of those listed above) should not include the Uplink data status IE. Figure 2 shows a flowchart associated with this embodiment. At step S110, the UE is in 5GMM-CONNECTED mode with RRC inactive indication. At S120, a trigger for a MUSIM service becomes available. At S130, the UE sends a NAS message for a MUSIM feature (e.g. including the UE request type IE set accordingly) or else autonomously enters 5GMM-IDLE mode. As mentioned before, the NAS message that can be sent in Step S130 may be a Registration Request, Service Request or Control Plane Service Request, where the NAS message should include the UE request type IE set to the appropriate value. When the UE (e.g. NAS) in 5GMM-CONNECTED mode with RRC inactive indication requests the lower layers (e.g. RRC layer) to resume the connection for a MUSIM service, and the UE then receives an indication from the lower layers that the resumption of the RRC connection has failed, then the UE should behave in the following manner: The UE may autonomously enter 5GMM-IDLE mode. The UE may autonomously attempt to select another PLMN for the related MUSIM service If the UE e.g. as required in 3GPP TS 24.501 V17.3.1, enters 5GMM-IDLE mode after which the UE is required to trigger a NAS procedure (e.g. registration procedure) for the N1 NAS signalling connection recovery, the UE may determine to delay the procedure until the MUSIM service is obtained e.g. by the UE using another USIM or attempting to use another PLMN. As such, the UE should delay the NAS procedure (e.g. registration procedure) until the UE terminates the MUSIM service and the UE should later perform the procedure after using a service on another PLMN. As such, after entering 5GMM-IDLE mode as required in 3GPP TS 24.501 V17.3.1, the UE selects another PLMN to use a service, and after that is done the UE can later reselect to this PLMN (where the indication about the resumption failure was received) and the UE then performs the NAS procedure (e.g. registration procedure) to recover the N1 NAS signalling connection. If the UE in 5GMM-CONNECTED mode with RRC inactive indication transitions to 5GMM-IDLE mode for any trigger e.g. due to a trigger to send a REGISTRATION REQUEST message with the NG-RAN-RCU bit of the 5GS update type IE set to "UE radio capability update needed" or due to a fallback indication from the lower layers, then if the UE also requires to select another PLMN to obtain services on another USIM, then the UE may delay the NAS procedure that is required to be sent on the current PLMN. The UE may first attempt to use another PLMN to obtain the necessary services and then upon termination of the service (or after some other time elapses), the UE may then return to this PLMN (where the UE initially needed to perform a NAS procedure from 5GMM-IDLE mode) and perform the necessary NAS procedure. As such, the UE should delay the procedure instead of immediately performing upon transitioning to 5GMM-IDLE mode. This will help reduce any delays in obtaining services from another PLMN. Note that the UE may behave as set out above with the respective steps being performed in any combination or in any order. In a second option, when the UE in 5GMM-CONNECTED mode with RRC inactive indication requires to use a MUSIM feature / service, the UE should autonomously enter 5GMM-IDLE mode e.g. by locally releasing its NAS connection. The UE can then attempt to use a MUSIM service on another PLMN by reselecting to that PLMN once in 5GMM-IDLE mode. An example UE behaviour based on this option can also be seen in Figure 2, in step S130. In a third embodiment, MUSIM services may be obtained when a UE is in 5GMM-IDLE mode with suspend indication. This embodiment proposes new behaviour for a UE to obtain a USIM service. Note that throughout this application, a request that is related to a MUSIM feature, or a request to obtain a MUSIM service, may refer to the sending of a NAS message where optionally the NAS message includes the UE request type IE, where optionally the IE may be set to indicate "NAS signalling connection release" or "Rejection of paging" or any value that may be defined in the future for this IE. Note that the following applies to a UE that is either in N1 mode (5GS) or in S1 mode (EPS) and as such the appropriate NAS mode and NAS message can be used accordingly. In a first option, when the (N1 mode) UE in 5GMM-IDLE mode with suspend indication requires to use a MUSIM feature / service, the UE should send a NAS message and include the UE request type IE, where the IE may be set to "NAS signalling connection release" or "Rejection of paging" or any value that may be defined in the future for this IE. The UE may first request the lower layers (e.g. the RRC layer) to resume the connection and then the UE sends the NAS message optionally after the connection is resumed. The NAS message that should be used may be any of the following: Registration Request, Service Request, or Control Plane Service Request. At least for the case when the UE request type IE is set to "NAS signalling connection release", the UE should ensure that the NAS message (e.g. any of those listed above) should not include the Uplink data status IE. When the (S1 mode) UE in EMM-IDLE mode with suspend indication requires to use a MUSIM feature / service, the UE should send a NAS message and include the UE request type IE, where the IE may be set to "NAS signalling connection release" or "Rejection of paging" or any value that may be defined in the future for this IE. The UE may first request the lower layers (e.g. the RRC layer) to resume the connection and then the UE sends the NAS message optionally after the connection is resumed. The NAS message that should be used may be any of the following: (Combined) Tracking Area Update Request, Service Request, or Control Plane Service Request, (Combined) Attach Request. At least for the case when the UE request type IE is set to "NAS signalling connection release", the UE should ensure that the NAS message (e.g. any of those listed above) should not include the Uplink data status IE. In a second option, when the (N1 mode) UE in 5GMM-IDLE mode with suspend indication requires to use a MUSIM feature / service, the UE may autonomously enter 5GMM-IDLE mode and attempt to use a MUSIM feature e.g. on another PLMN. When the (S1 mode) UE in EMM-IDLE mode with suspend indication requires to use a MUSIM feature / service, the UE may autonomously enter EMM-IDLE mode and attempt to use a MUSIM feature e.g. on another PLMN. Figure 3 shows an example of how the details of the third embodiment, set out above, can be used by the UE. At step S210, the UE is in 5GMM-IDLE (or EMM-IDLE) mode with suspend indication. At step S220, a trigger for a MUSIM service becomes available. At step S230, the UE sends a NAS message for a MUSIM feature (e.g. including the UE request type IE set accordingly) or else the UE autonomously enters 5GMM-IDLE (or EMM-IDLE) mode, as per the second option, set out above. As mentioned before, the NAS message that can be sent in Step S230 may be a Registration Request, Service Request or Control Plane Service Request, where the NAS message should include the UE request type IE set to the appropriate value. The next embodiment applies to all cases and is not necessarily limited to one mode only. In S1 mode, when the UE sends the Control Plane Service Request message or the Tracking Area Update Request message in which the UE request type IE is included (that may be set to any value), the UE should not set the “Active flag” bit to a value which indicates that the radio bearer establishment is required / requested (i.e. the value should not be set to 1). The UE should set the value of the bit such that it indicates that no radio bearer establishment is required / requested (i.e. the bit should be set to 0). This is to avoid the establishment of user plane which leads to delays in the MUSIM feature / service. When the network (e.g. MME) receives a NAS message (e.g. Control Plane Service Request message or the Tracking Area Update Request message) in which the “Active flag” bit is set to a value such that the value indicates that radio bearer establishment is required / requested (i.e. the value is set to 1), then the network (e.g. MME) should ignore the bit or treat the bit as if it was set to a value indicating that no radio bearer establishment is required / requested (i.e. treat the bit as if it was set to 0) and hence the network (e.g. MME) should not establish the user plane resources (or should not establish the radio bearer resources and / or other corresponding EPS bearer resources for the user plane). When the network (e.g. MME) receives a NAS message (e.g. Control Plane Service Request message or the Tracking Area Update Request message) in which: • the “Active” flag bit is set to a value such that the value indicates that radio bearer establishment is required / requested (i.e. the value is set to 1), and • the UE request type IE is included in the NAS message such that the Request type indicates "NAS signalling connection release" (or optionally indicates "Rejection of paging" or any value that may be defined in the future) then the network (e.g. MME) should ignore the bit or treat the bit as if it was set to a value indicating that no radio bearer establishment is required / requested (i.e. treat the bit as if it was set to 0) and hence the network (e.g. MME) should not establish the user plane resources (or should not establish the radio bearer resources and / or other corresponding EPS bearer resources for the user plane). Alternatively, when the NAS message includes the UE request type IE such that the Request type indicates "NAS signalling connection release", the MME may simply ignore the value of the “Active” flag bit in the NAS message regardless of its value and as such the MME may always consider the bit to indicate a value of zero even when the bit indicates a value of 1, and hence the network (e.g. MME) should not establish the user plane resources (or should not establish the radio bearer resources and / or other corresponding EPS bearer resources for the user plane). Alternatively, whenever the MME receives a NAS message e.g. (e.g. Control Plane Service Request message or the Tracking Area Update Request message) in which the “active” flag is set to 1 (in the appropriate IE e.g. in the Control plane service type IE or in the EPS update type IE, respectively), then the MME should verify if the NAS message also contains the UE request type IE, where optionally the IE is set to a value which indicates "NAS signalling connection release" (or optionally any other value). If that is the case (i.e. if the NAS message also indicates that the NAS signalling should be released as explained), then the MME should ignore the value of the “active” flag bit regardless of its value or even if the bit is set to a value of 1. As such, under the conditions explained above, the MME should consider that the value of the “active” flag is 0 and hence the MME should not establish the user plane resources for the EPS bearers. In other words, if the MME verifies a NAS message in which the “active” flag is set to 1 and determines that the UE request type IE is not included, or the UE request type IE is included but does not indicate "NAS signalling connection release", then the MME should establish the user plane resources for the EPS bearers of the UE. Otherwise, the MME should not establish the user plane resources. Based on the proposals above, the following MME behaviour can be defined: If the "active" flag is set in the TRACKING AREA UPDATE REQUEST message and: • control plane CloT EPS optimization is not used by the MME; and • the UE request type IE is not included in the TRACKING AREA UPDATE REQUEST message or the UE request type IE is included in the TRACKING AREA UPDATE REQUEST message but the Request type is not set to "NAS signalling connection release"; the MME shall re-establish the radio and S1 bearers for all active EPS bearer contexts. If the "active" flag is set in the TRACKING AREA UPDATE REQUEST message and: • control plane CloT EPS optimization is used by the MME, . the UE request type IE is not included in the TRACKING AREA UPDATE REQUEST message or the UE request type IE is included in the TRACKING AREA UPDATE REQUEST message but the Request type is not set to "NAS signalling connection release"; the MME shall re-establish the radio and S1 bearers for all active EPS bearer contexts associated with PDN connections established without Control plane only indication. If the "active" flag is set in the TRACKING AREA UPDATE REQUEST message, the message does not contain the UE request type IE with the Request type indicating "NAS signalling connection release", and control plane CloT EPS optimization is not used by the MME, the MME shall re-establish the radio and S1 bearers for all active EPS bearer contexts. If the "active" flag is set in the TRACKING AREA UPDATE REQUEST message, the message does not contain the UE request type IE with the Request type indicating "NAS signalling connection release", and control plane CloT EPS optimization is used by the MME, the MME shall reestablish the radio and S1 bearers for all active EPS bearer contexts associated with PDN connections established without Control plane only indication. Note that the steps set out above can also apply for any other NAS message in which the “active” flag may be set / sent / included. Note that a similar proposal would apply for an AMF in 5GS, where the AMF should only establish the user plane resources (when requested to do so by the UE via the use of the Uplink data status IE) if the NAS message (e.g. Registration Request, Service Request, or Control Plane Service Request message) either: • does not include the UE request type IE, or • includes the UE request type IE but the Request type is not set to "NAS signalling connection release". As such, if the UE request type IE is included in a NAS message such that the Request type is set to "NAS signalling connection release" (or optionally any other value), then the AMF should not request the SMF to establish the user plane resources for the UE regardless of the values of the individual bits in the Uplink data status IE (i.e. even if the bits are set such that user plane resources are requested to be established for a corresponding PDU session identity). Note that the details above can also apply to the Allowed PDU session status IE. Alternatively, when the AMF receives the Uplink data status IE (and / or the Allowed PDU session status IE) such that any bit in the IE is set to the value 1 (i.e. there is at least one PDU session identify for which user plane resources are being requested to be (re)established), then the AMF should further verify if the UE request type IE is included and if so what value does the Request type indicate. If the IE is included and the Request type is set to "NAS signalling connection release" (or optionally any other value), then the AMF should not indicate / request the SMF to establish the user plane resources for a given PDU session identity (for which the bit is in the Uplink data status IE is set to 1). However, if the IE is not included, or if the IE is included but the Request type is not set to "NAS signalling connection release", then the AMF can / should request / indicate to the SMF to establish the user plane resources for the UE (assuming no other conditions for not doing so applies). Note that the proposals above apply for any NAS message. Note that the core network node (e.g. MME or AMF) may be configured to operate such that if the core network receives: • any NAS message with the “active” flag set to 1 (i.e. user plane resource activation is requested) and the UE request type IE for which the Request type is set to "NAS signalling connection release", then the core network node (e.g. MME) may determine to establish the user plane resources and optionally ignore the request to release the NAS signalling connection (i.e. the user plane resource establishment request overrides the request to release the NAS connection). The MME may additionally send the EMM STATUS message to inform the UE about the error of sending these two conflicting requests • any NAS message which includes any of the Uplink data status IE or the Allowed PDU session status IE, such that one or more bit in the IE is set to a value that requests the establishment of user plane resources for a PDU session (identity), then the AMF may determine to establish the user plane resources and optionally ignore the request to release the NAS signalling connection (i.e. the user plane resource establishment request overrides the request to release the NAS connection). The AMF may additionally send the 5GMM STATUS message to inform the UE about the error of sending these two conflicting requests. As such, in general, the core network node may be configured to either prioritize the establishment of user plane resources (via the active flag or the Uplink data status lE / Allowed PDU session status IE for an MME or AMF respectively) over NAS connection release, when both are requested, or vice versa i.e. the core network node prioritizes NAS connection release over establishment of user plane resources when both are requested in the same message as explained above. The core network behaviour may be based on implementation and may be either of the options proposed herein. Additionally, when the UE wants to request the establishment of user plane resources by: • setting the “active” flag to 1 in any NAS message (e.g. Control Plane Service Request message or Tracking Area Update Request message), then the UE should ensure that the NAS message does not include the UE request type IE such that the Request type indicates "NAS signalling connection release". In other words, for any NAS message which contains an “active” flag with a value of 1, the UE request type IE may be included but its value should not be set to "NAS signalling connection release". In this case, it may be preferred that the UE request type IE is not sent. • requesting the establishment of user plane resources via the Uplink data status IE or via the Allowed PDU session status IE (e.g. when the UE uses these lEs and sets the bits to 1 such that the UE is requesting the establishment of user plane resources), then the UE should ensure that the NAS message does not include the UE request type IE such that the Request type indicates "NAS signalling connection release". In other words, for any NAS message which contains the Uplink data status IE or the Allowed PDU session status IE such that any of the bits is set to 1 (i.e. the UE is requesting the establishment of user plane resources), the UE request type IE may be included but its value should not be set to "NAS signalling connection release". In this case, it may be preferred that the UE request type IE is not sent. For cases b and m in clause 5.6.1.1, if the UE has pending IP, non-IP or Ethernet user data that is to be sent via the user plane radio bearers, the UE shall set the Control plane service type of the CONTROL PLANE SERVICE REQUEST message to "mobile originating request" and the "active" flag in the Control plane service type IE to 1. The UE shall not include any ESM message container or NAS message container IE in the CONTROL PLANE SERVICE REQUEST message. Additionally for case m, the CONTROL PLANE SERVICE REQUEST message shall not include the UE request type IE with the Request type indicating "NAS signalling connection release". Similarly in 5GS i.e. in N1 mode, when the UE wants to request the establishment of user plane resources via the Uplink data status IE (or the Allowed PDU session status IE which may be used to transfer a session across non-3GPP access and 3GPP access), the UE should not include the UE request type IE with the Request type set to "NAS signalling connection release". Note that this applies to all NAS messages such as the Service Request message, Registration Request message, and Control Plane Service Request message. Additionally for case e) of the service request procedure, the SERVICE REQUEST message shall not include the UE request type IE with the Request type indicating "NAS signalling connection release". Additionally for case k) of the service request procedure, the CONTROL PLANE SERVICE REQUEST message shall not include the UE request type IE with the Request type indicating "NAS signalling connection release". Note that the proposals in this document may be applies in different combination or order and may be application in at least one mode only. Examples of specific modes are not to be considered as limitations of the proposal but rather as an example to describe the proposed solution(s). At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises" means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention 5 extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

08 11 241. A method of operating a User Equipment, UE, with MUSIM capability, wherein if the UE does not have an allowed NSSAI, a service request procedure is initiated if an associated 5 trigger is related to a MUSIM feature.

2. The method of claim 1 wherein if a REGISTRATION ACCEPT message:a) includes a 5GS registration result Information Element, IE, with the "Network slice-specific authentication and authorization, NSSAA, to be performed" indicator set to "Network slice-specific authentication and authorization is to be performed";10 b) includes a pending Network Slice Selection Assistance Information, NSSAI; andc) does not include an allowed NSSAI,then the UE shall delete a stored allowed NSSAI, if present and shall not initiate the service request procedure unless associated with a MUSIM feature.

3. The method of any preceding claim wherein the MUSIM feature is one of: Connection 15 release, Paging Cause Indication, Reject paging request, Paging Restriction and delete stored paging restrictions information.

4. Apparatus arranged to perform the method of any preceding claim.

Images