Network slice-specific authentication and authorization
By standardizing network slice-specific authentication and authorization methods in 3GPP 5G systems, the issues of improper PDU session release and process conflicts during roaming in NSSAA were resolved, ensuring correct operation under abnormal conditions and improving user experience and system stability.
Patent Information
- Application Number
- CN202180026606.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-03-30
- Filing Date
- 2021-03-29
- Publication Date
- 2025-10-24
- Estimated Expiration
- 2041-03-29
AI Technical Summary
The existing NSSAA process fails to effectively handle PDU session release during roaming in 5G network slicing authentication and authorization, does not consider process conflicts, lacks abnormal situation handling and service request process prohibition, resulting in unnecessary PDU session release and user experience interruption.
It provides a method for implementing network slicing-specific authentication and authorization in 3GPP 5G systems. By standardizing the behavior of UE and AMF, it ensures the correct handling of requested NSSAI IEs and mapped NSSAI IEs, resolves process conflicts, and defines behavior under abnormal conditions to avoid unnecessary PDU session releases and user experience interruptions.
It improves the accuracy of network slicing-specific authentication and authorization processes, ensures correct operation in roaming and process conflict situations, reduces unnecessary PDU session releases, and enhances the user experience.
Smart Images

Figure CN115362704B_ABST
Abstract
Description
TECHNICAL FIELD
[0001] Certain examples of the present disclosure provide methods, apparatuses, and systems for performing network slice-specific authentication and authorization. For example, certain examples of the present disclosure provide methods, apparatuses, and systems for implementing correct operation of network slice-specific authentication and authorization in 3GPP 5G. BACKGROUND
[0002] To meet the demand for wireless data traffic having increased since deployment of 4G (4th-Generation) communication systems, efforts have been made to develop an improved 5G (5th-Generation) or pre-5G communication system. Therefore, the 5G or pre-5G communication system is also called a "beyond 4G network" or a "post LTE system."
[0003] The 5G communication system is considered to be implemented in a frequency band of 6 GHz or more, e.g., a 60 GHz band, so as to accomplish a higher data rate. To reduce propagation loss of radio waves and increase a transmission distance, the beamforming, massive multiple-input multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam forming, large scale antenna techniques are discussed in 5G communication systems.
[0004] In addition, in 5G communication systems, development for system network improvement is under way based on advanced small cells, cloud radio access networks (RANs), ultra-dense networks, a device to device (D2D) communication, a wireless backhaul, a mobile network, a cooperative communication, coordinated multi-points (CoMP), a reception-end interference cancellation, and the like.
[0005] In the 5G system, hybrid FSK and QAM modulation (FQAM) and sliding window superposition coding (SWSC) as an advanced coding modulation (ACM), and filter bank multi carrier (FBMC), a non-orthogonal multiple access (NOMA), and a sparse code multiple access (SCMA) as an advanced access technology have been developed.
[0006] Reference is made herein to the following documents: [1] 3GPP TS 23.501 V16.4.0; [2] 3GPP TS 23.502 V16.4.0; and [3] 3GPP TS 24.501 V16.4.0.
[0007] In 3GPP 5G system, the following are defined (e.g., in [1]). A network slice (NS) is defined as a logical network that provides specific network capabilities and network characteristics. A network slice instance (NSI) is defined as a set of network function instances and required resources (e.g., compute, storage, and network resources) that form a deployed NS. A network function (NF) is defined as a processing function in the network that is either adopted by 3GPP or defined by 3GPP, with a defined functional behavior and 3GPP-defined interfaces.
[0008] A NS can be identified by a single network slice selection assistance information (S-NSSAI).
[0009] Network slice-specific authentication and authorization (NSSAA) overview
[0010] NSSAA was introduced in 3GPP as part of Rel-16. This feature enables the network to perform slice-specific authentication and authorization for a set of S-NSSAI(s) to ensure that the user is allowed to access these slices. This procedure is performed after the 5G mobility management (5GMM) authentication procedure has been completed and after the registration procedure is completed. A high-level description of this feature can be found in [1], while further details can be found in [2] and [3]. This section summarizes the key points regarding the NSSAA procedure.
[0011] The NSSAA procedure is access-independent, i.e., if a slice is successfully authorized, it is considered authorized for both access types (i.e., 3GPP and non-3GPP access types).
[0012] The term “authorized” means that the slice-specific authentication / authorization for a specific S-NSSAI has been successful, however this does not imply that the S-NSSAI is allowed to be used in the current tracking area (TA) of the UE over 3GPP access.
[0013] When a UE registers with the network, it can include a requested NSSAI (R-NSSAI) in the registration request message if available at the UE. The network behavior specified in [3] is described below:
[0014] If the UE indicates support for network slice-specific authentication and authorization, and:
[0015] a) if the Requested NSSAI IE includes only S-NSSAIs for which:
[0016] 1) network slice-specific authentication and authorization is experienced; and
[0017] 2) network slice-specific authentication and authorization procedure has not been initiated;
[0018] The AMF can include in the REGISTRATION ACCEPT message:
[0019] 1) a "NSSAA to be performed" indicator in the 5GS registration result IE set to indicate whether the network will perform network slice-specific authentication and authorization procedure;
[0020] 2) a pending NSSAI containing one or more S-NSSAIs for which network slice-specific authentication and authorization is to be performed; and
[0021] 3) the current registration area in the list of "not allowed tracking areas" in the service area list IE; or
[0022] b) if the Requested NSSAI IE includes one or more S-NSSAIs for which network slice-specific authentication and authorization is experienced, the AMF can include in the REGISTRATION ACCEPT message:
[0023] 1) an allowed NSSAI containing S-NSSAIs for which network slice-specific authentication and authorization is not experienced or for which network slice-specific authentication and authorization has been successfully performed or mapped S-NSSAIs; and
[0024] 2) a pending NSSAI containing one or more S-NSSAIs for which network slice-specific authentication and authorization is to be performed, if any.
[0025] If the UE indicates support for network slice-specific authentication and authorization and if:
[0026] a) the UE does not include Requested NSSAI in the REGISTRATION REQUEST message or none of the S-NSSAIs in the Requested NSSAI in the REGISTRATION REQUEST message is present in the subscribed S-NSSAIs; and
[0027] b) all S-NSSAIs in the subscribed S-NSSAIs experience network slice-specific authentication and authorization;
[0028] The AMF can include in the REGISTRATION ACCEPT message:
[0029] a) "NSSAA to be performed" indicator in the 5GS registration result IE to indicate whether the network will perform network slice specific authentication and authorization procedure or not;
[0030] b) Pending NSSAI containing one or more S-NSSAI for which network slice specific authentication and authorization is to be performed; and
[0031] c) Current registration area in the "not allowed tracking area" list in the service area list IE.
[0032] NSSAA can be re-initiated at any time as specified in section 5.15.10 of [1]:
[0033] This procedure can be invoked by the AMF at any time for a supported UE, e.g., when:
[0034] a. The UE is registered with the AMF and one of the S-NSSAI of the HPLMN mapped to the S-NSSAI in the requested NSSAI requires network slice specific authentication and authorization (see clause 5.15.5.2.1 for details) and once the network slice specific authentication and authorization for the S-NSSAI is successful, it can be added to the allowed NSSAI by the AMF; or
[0035] b. Network slice specific AAA server triggers re-authentication and re-authorization of the UE for a S-NSSAI; or
[0036] c. The AMF decides to initiate network slice specific authentication and authorization procedure for a certain S-NSSAI that was previously authorized based on operator policy or subscription change.
[0037] In case of re-authentication and re-authorization (b. and c. above), the following applies:
[0038] If the S-NSSAI requiring network slice specific authentication and authorization is included in the allowed NSSAI per access type, the AMF selects one access type based on network policy to be used for performing the network slice specific authentication and authorization procedure.
[0039] If the network slice specific authentication and authorization for some S-NSSAI in the allowed NSSAI is not successful, the AMF can update the allowed NSSAI per access type to the UE via the UE configuration update procedure.
[0040] If network slice specific authentication and authorization fails for all S-NSSAIs in the allowed NSSAI, the AMF can perform the network initiated de-registration procedure described in TS 23.502 [2] clause 4.2.2.3.3 and can include in the explicit de-registration request message a list of rejected S-NSSAIs, with each of the rejected S-NSSAI having the appropriate rejection cause value.
[0041] Overview of S-NSSAI IE and its handling during roaming
[0042] The S-NSSAI IE is encoded as shown in Figure 1
[0043] When the UE is in the home PLMN (HPLMN), then the mapped HPLMN SST (octet 7) and the mapped HPLMN SD (octets 8 to 10) do not apply. Indeed, in the HPLMN, these octets correspond to the SST field (octet 3) and the SD field (octets 4 to 6), respectively.
[0044] On the other hand, when the UE is roaming in a visited PLMN (VPLMN), then the UE can include the mapped slice information corresponding to the slices used in the VPLMN. For example, assume that in the VPLMN 1, the UE has the following S-NSSAI entries in the allowed NSSAI, as shown in Figure 2
[0045] Basically, the above means that the slices accessed in the VPLMN 1 [V1-Cars, V1-BMW] correspond to the slices in the HPLMN [H1-Cars, H1-BMW]. It can be noted that, as shown in Figure 1
[0046] The network slice selection assistance information (NSSAI) is a list of single NSSAI (S-NSSAL) and there are different types of NSSAI, such as requested NSSAI (with at most 8 entries), allowed NSSAI (with at most 8 entries), configured NSSAI (with at most 16 entries) and pending NSSAI (with at most 8 entries).
[0047] The NSSAI IE is encoded as shown in Figure 3
[0048] Requested mapped NSSAI is a mapped NSSAI which is requested by the UE as Figure 4 indicated in the encoding.
[0049] The mapped NSSAI contains a list of mapped S-NSSAI entries, where each mapped S- NSSAI entry is encoded as Figure 5 indicated in the encoding.
[0050] In roaming cases, the Requested mapped NSSAI IE is sent in the following roaming cases:
[0051] - the UE moves across visited PLMNs and attempts to transfer a protocol data unit (PDU) session across these visited PLMNs,
[0052] - the UE already has a PDU session established in the source VPLMN,
[0053] - the UE knows the mapped HPLMN slice information (i.e. mapped HPLMN SST and optionally, mapped HPLMN SD) for the PDU session established in the source VPLMN, and
[0054] - the UE does not have any slice information for the target VPLMN (i.e. does not have configured NSSAI or allowed NSSAI).
[0055] As an example to explain this, assume that the UE is in VPLMN 1 and has a PDU session for which the S-NSSAI is {V1-Cars, H-Cars}. For simplicity, the value V-Cars corresponds at least to the SST field of Figure 1 but can also include the SD field of Figure 1 Similarly, for simplicity, the value H-Cars corresponds at least to the mapped HPLMN SST field of Figure 1 but can also include the mapped HPLMN SD field of Figure 1 .
[0056] Now, if the UE moves from VPLMN 1 to a target VPLMN, say VPLMN 2, and the UE does not have any slice information for VPLMN 2, then the UE can include the Requested mapped NSSAI IE in the registration request message sent in VPLMN 2. In this case, the non-access stratum (NAS) message does not include the Requested NSSAI IE because the UE does not have any slice information for VPLMN 2.
[0057] Now assume that the UE in VPLMN 1 has two PDU sessions, each associated with one of the following S-NSSAI:
[0058] -{V1-Cars, H-Cars}; and
[0059] -{V1-SmartPhone, H-SmartPhone}
[0060] Furthermore, it is assumed that the UE has the following slice information of the potential target VPLMN 2:
[0061] -{V2-Cars, H-Cars}
[0062] When the UE enters VPLMN 2, the UE may include the following IE in the Registration Request message:
[0063] - Requested NSSAI IE, which may include the entry {V2-Cars, H-Cars}. This IE may be sent because the UE has slice information for VPLMN 2 and the mapped slice component, i.e. the value "H-Cars", matches the mapped slice component of the existing PDU session, and
[0064] - Requested mapped NSSAI IE, which may include the entry {H-SmartPhone}. This IE may be included because the UE does not have slice information for VPLMN 2 that matches the mapped slice component (i.e., value "H-SmartPhone") of the existing PDU session.
[0065] In the above example, in order to send the allowed NSSAI IE to the UE in the registration accept message, the AMF may consider the requested NSSAI IE and the requested mapped NSSAI IE.
[0066] Note that, for the sake of example and to clarify how slicing works, if the UE also has {V2-SmartPhone, H-SmartPhone} as the slice information for VPLMN 2, then in this case the UE will only include the Requested NSSAI IE in the Registration Request message because the mapped slice information of the existing PDU session from VPLMN 1 matches the mapped slice information of VPLMN 2. In this case, the Requested Mapped NSSAI IE is not included in the Registration Request message.
[0067] In summary, it should be understood that in roaming cases, the UE can send in the registration request message either the requested NSSAI IE, or the requested mapped NSSAI IE, or both the requested NSSAI IE and the requested mapped NSSAI IE. The determination of which IE(s) to include depends on whether the UE has slice information of the target VPLMN, and whether there is a match between the mapping components of the S-NSSAI associated with the existing PDU session(s) from the source VPLMN.
[0068] Finally, it is very important to note that if the UE receives in the registration accept message the allowed NSSAI IE, and:
[0069] - the entries of the allowed NSSAI IE do not match the entire S-NSSAI of the existing PDU session, or
[0070] - the mapping slice information (i.e. the mapped HPLMN SST and optionally the mapped HPLMN SD) of the entries in the allowed NSSAI IE do not match the mapping slice information of the existing PDU session,
[0071] then the UE can locally release the PDU session whose associated S-NSSAI does not match any of the entries in the allowed NSSAI IE, as described above. This behavior is described in [3] as follows:
[0072] With respect to each of the PDU session(s) active in the UE, if the allowed NSSAI does not contain:
[0073] a) the S-NSSAI that matches the S-NSSAI of the PDU session; nor
[0074] b) the mapped S-NSSAI that matches the mapped S-NSSAI of the PDU session;
[0075] then the UE can perform a local release of all such PDU sessions except the persistent PDU session(s).
[0076] The above information is presented as background information only to assist with an understanding of the present disclosure. No determination has been made, and no assertion is made, as to whether any of the above might be applicable as prior art with regard to the present disclosure. SUMMARY
[0077] Solution to the problem
[0078] It is a purpose of certain examples of the present disclosure to at least partially address, solve, and / or relieve at least one of the issues and / or disadvantages associated with the related art, e.g., at least one of the issues and / or disadvantages described herein. It is a purpose of certain examples of the present disclosure to provide at least one advantage over the related art, e.g., at least one of the advantages described herein.
[0079] The present disclosure is defined in the independent claims. Advantageous features are defined in the dependent claims.
[0080] Other aspects, advantages, and salient features of the disclosure will become apparent to those of ordinary skill in the art from the following detailed description, which, when taken in
[0081] Before undertaking the below-enumerated DETAILED DESCRIPTION, it can be advantageous to set forth definitions of certain words and phrases to be used throughout this patent document: the terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation; the term “or,” is inclusive, meaning and / or; the phrases “associated with” and “associated therewith,” as well as derivatives thereof, can mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have a property of, have, have a property, or the like; and the term “controller” means any device, system or part thereof that controls at least one operation, such a device can be implemented in hardware, firmware or software, or some combination of at least two of the same. It should be noted that the functionality associated with any particular controller can be centralized or distributed, whether locally or remotely.
[0082] Moreover, various functions described below can be implemented or supported by one or more computer programs, each of which is formed from computer readable program code and embodied in a computer readable medium. The terms “application” and “program” refer to one or more computer programs, software components, sets of instructions, procedures, functions, objects, classes, instances, related data, or a portion thereof that can be suitably implemented in appropriate computer readable program code. The phrase “computer readable program code” includes any type of computer code, including source code, object code, and executable code. The phrase “computer readable medium” includes any type of medium capable of being accessed by a computer, such as read only memory (ROM), random access memory (RAM), a hard disk drive, a compact disc (CD), a digital video disc (DVD), or any other type of memory. A “non-transitory” computer readable medium excludes wired, wireless, optical, or other communication links. Non-transitory computer readable media include media that can be permanently stored in that the medium has a shelf life and a data retention period. A non-transitory computer readable medium includes media where data can be stored and overwritten, such as a rewritable optical disc or an erasable memory device.
[0083] Definitions for certain words and phrases are provided throughout this patent document, and include the following terms and phrases, which must be interpreted in light of this disclosure: BRIEF DESCRIPTION OF DRAWINGS
[0084] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings in which like parts are marked with like numerals:
[0085] Figure 1 An S-NSSAI information element is shown;
[0086] Figure 2 An example S-NSSAI value is shown;
[0087] Figure 3 A NSSAI information element is shown;
[0088] Figure 4 A mapped NSSAI information element is shown;
[0089] Figure 5 The mapped S-NSSAI content is shown; and
[0090] Figure 6 is a block diagram of an example network entity that can be used in certain examples of the present disclosure. DETAILED DESCRIPTION
[0091] The following discussed Figures 1 to 6 The principles of the present disclosure described in this patent document can be implemented in any suitably arranged system or device, and can be implemented at least in part as computer programs running on one or more computers, which programs can be stored on one or more computer readable media:
[0092] The following description of examples of the present disclosure provides for the purpose of helping to understand the present disclosure, and is not meant to limit the scope of the present disclosure as defined by the claims. The description includes various specific details to assist in that understanding but these are to be considered merely exemplary. Accordingly, one of ordinary skill in the art will recognize that various changes and modifications of the examples described herein can be made without departing from the scope of the present disclosure.
[0093] The same or similar components can be denoted by the same or similar reference numbers, although the same or similar components can be shown in different figures.
[0094] For the sake of brevity and clarity, detailed descriptions of techniques, structures, constructions, functions or processes known in the art can not be provided.
[0095] The terms and words used herein are not limited to the bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the present disclosure.
[0096] Throughout the description and claims of this specification, the words "comprise", "contain", and "include", and variations of the words, mean "including but not limited to", and are not intended to (and do not) exclude other features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof.
[0097] Throughout the description and claims of this specification, the singular forms "a", "an" and "the" include plural referents unless the context requires otherwise. For example, reference to "an object" includes a single or a plurality of such objects.
[0098] Throughout the description and claims of this specification, the language in general form of "X for Y" where Y is an action, process, operation, function, activity or step and X is a specific means for carrying out the action, process, operation, function, activity or step, encompasses an X which is specifically adapted, configured or arranged to carry out Y.
[0099] Features, elements, components, integers, steps, processes, operations, functions, characteristics, properties and / or groups thereof, which are described in conjunction with a specific aspect, embodiment, example, or claim of the present disclosure, should be understood to be applicable to any other aspect, embodiment, example or claim described herein, unless incompatible therewith.
[0100] Certain examples of the present disclosure provide methods, apparatus and systems for performing network slice-specific authentication and authorization. The following examples are applicable to 3GPP 5G and use terminology related thereto. For example, certain examples of the present disclosure provide methods, apparatus and systems for enabling correct operation of network slice-specific authentication and authorization in 3GPP 5G. However, those skilled in the art will appreciate that the techniques disclosed herein are not limited to these examples or 3GPP 5G, and can be applied to any suitable system or standard, for example one or more existing and / or future generation wireless communication systems or standards.
[0101] For example, the functionality of various network entities and other features disclosed herein can be applied to corresponding or equivalent entities or features in other communication systems or standards. A corresponding or equivalent entity or feature can be regarded as an entity or feature that performs the same or similar role, function, operation or purpose in a network. For example, the functionality of the AMF in the following examples can be applied to any other suitable type of entity that performs mobility management functionality.
[0102] Those skilled in the art will appreciate that the present disclosure is not limited to the specific examples disclosed herein. For example:
[0103] - The technology disclosed herein is not limited to 3GPP 5G;
[0104] - One or more entities in the examples disclosed herein can be replaced with one or more alternative entities that perform equivalent or corresponding functions, procedures, or operations;
[0105] - One or more messages in the examples disclosed herein can be replaced with one or more alternative messages, signals, or other types of information carriers that communicate equivalent or corresponding information;
[0106] - One or more additional elements, entities, and / or messages can be added to the examples disclosed herein;
[0107] - In certain examples, one or more non-essential elements, entities, and / or messages can be omitted;
[0108] - The functions, procedures, or operations of a particular entity in one example can be divided among two or more separate entities in alternative examples;
[0109] - The functions, procedures, or operations of two or more separate entities in one example can be performed by a single entity in alternative examples;
[0110] - Information carried by a particular message in one example can be carried by two or more separate messages in alternative examples;
[0111] - Information carried by two or more separate messages in one example can be carried by a single message in alternative examples;
[0112] - In alternative examples, the order of performing operations can be modified, if possible; and
[0113] - Information transmissions between network entities are not limited to the particular forms, types, and / or orders of messages described in connection with the examples disclosed herein.
[0114] Certain examples of the disclosure can be provided in the form of apparatuses / devices / network entities configured to perform one or more defined network functions and / or methods thereof. Certain examples of the disclosure can be provided in the form of systems (e.g., networks) comprising one or more such apparatuses / devices / network entities and / or methods thereof.
[0115] For example, in the following examples, the network can include a user equipment (UE) and an access and mobility management function (AMF) entity.
[0116] 5G Core (5GC) AMF receives all connection and session related information from the UE (N1 / N2) but is only responsible for handling connection and mobility management tasks. All messages related to session management are forwarded to the session management function (SMF) over the N11 reference interface. The AMF performs the role of an access point to the 5GC. The functionality of the AMF is described in 3GPP TS 23.501 V16.3.0 clause 6.2.1.
[0117] In view of the related art, at least the following problems exist:
[0118] 1. NSSAA does not consider the requested mapped NSSAI IE and the UE can incorrectly release PDU sessions, impacting the user's experience
[0119] As described above, when the UE is roaming, the UE can include in the registration request message the requested NSSAI IE, the requested mapped NSSAI IE, or both the requested NSSAI IE and the requested mapped NSSAI IE.
[0120] The current NSSAA procedure does not consider roaming UEs, so it is unclear what the AMF can do when it receives the requested mapped NSSAI IE and how this can impact NSSAA.
[0121] With respect to roaming, as also described above, when the UE receives in the registration accept message the allowed NSSAI IE, where there are no S-NSSAI entries in the allowed NSSAI or the mapped S-NSSAI components of the allowed NSSAI that match the mapped S-NSSAI information of existing PDU sessions, the UE can perform local release of these PDU sessions. This can be an incorrect behavior that can lead to unnecessary release of PDU sessions and disruption of the user experience. For example, the allowed NSSAI can not include an S-NSSAI that can match the slice information of an existing PDU session, as this slice is subject to NSSAA. Therefore, there is potential matching slice information that can be in the pending NSSAI IE, so considering only the allowed NSSAI IE in this case can lead to premature and incorrect local release of PDU sessions in the UE.
[0122] 2. No consideration of conflicting procedures
[0123] The NAS specification [3] generally considers the collision of different NAS procedures or messages and specifies which procedure or message can be prioritized in some cases depending on the collision procedure in question. There are some collision cases that can occur during NSSAA that have not been considered, resulting in unclear UE and network behavior when these cases occur. The following cases are identified as lacking any defined behavior.
[0124] Case 1: Collision of authentication procedure and NSSAA procedure
[0125] As mentioned above, NSSAA can occur after the authentication procedure is completed. However, the same AMF that initiates the NSSAA procedure can also initiate the authentication procedure. This is because re-initiation of the authentication procedure can occur at any time in connected mode. For example, assume that the UE is registered on one access (e.g., say 3GPP access), the UE is in connected mode, and the network is performing NSSAA. The UE then registers on a second access (e.g., say non-3GPP access) to the same PLMN or AMF. The AMF can have a policy to run authentication for each initial registration. In this case, the AMF can initiate the authentication procedure and send an Authentication request message to the UE, despite the fact that NSSAA is in progress. At the UE, the Authentication request message can be received after (or before) the network slice-specific authentication command message is received in the UE but before the UE responds with the network slice-specific authentication complete message, there must be a specified behavior for the UE to follow in terms of which message to prioritize. The same question can be asked of the AMF, i.e., if the AMF sends the Authentication request message after sending the network slice-specific authentication command message to the UE, and the AMF has not received the authentication response but receives the network slice-specific authentication complete message, it is unclear whether the AMF can accept the latter or wait for the authentication procedure to complete.
[0126] Case 2: Collision of generic UE configuration update procedure and NSSAA procedure
[0127] The generic UE configuration update procedure can be initiated at any time when the UE is in connected mode. Similarly, the NSSAA procedure can be initiated at any time for a UE in connected mode. As such, these procedures can collide and the related messages can be sent by the AMF at about the same time, resulting in the UE receiving these messages at about the same time. The NAS specification [3] generally defines the behavior of the receiver in collision cases, but the current specification does not define the collision behavior of these procedures. Certain examples of the present disclosure aim to mitigate such collisions by specifying the correct behavior, thereby addressing this issue.
[0128] Case 3: Collision of service request procedure and NSSAA procedure
[0129] While in connected mode, a UE can initiate a service request procedure. Meanwhile, the network can initiate NSSAA for a UE in connected mode. For example, a UE can be in 5GMM-CONNECTED mode over non-3GPP access, then the UE performs a registration procedure over 3GPP access. The AMF can indicate that NSSAA can be performed in the 5GS registration result IE and can include the pending NSSAI IE in the registration accept message, but the AMF can not include the allowed NSSAI IE in the NAS message. Meanwhile or about the same time, the UE can send a service request message over non-3GPP access, although existing requirements make it unlikely that this can happen. There is currently no mechanism to handle such a conflict.
[0130] 3. Lack of method to handle exceptional cases
[0131] The NAS specification [3] handles exceptional cases that can occur and describes methods to recover from them.
[0132] Case 1: Transmission of network slice-specific authentication complete message with TAI change from lower layers fails
[0133] The following exceptional cases are identified for NSSAA in section 5.4.7.2.4 in [3]:
[0134] a) Transmission of network slice-specific authentication complete (NETWORK SLICE-SPECIFIC AUTHENTICATION COMPLETE) message with TAI change from lower layers fails
[0135] If the current TAI is not in the TAI list, the network slice-specific authentication and authorization procedure can be aborted and a registration procedure for mobility and periodic registration update indicated in the 5GS registration type IE of the registration request message as "mobility registration update" can be initiated.
[0136] If the current TAI is still part of the TAI list, how to re-run the ongoing procedure that triggered the network slice-specific authentication and authorization procedure depends on the UE implementation.
[0137] The above case refers to the UE entering a new tracking area identity (TAI) during an ongoing NSSAA, which is not in the UE's current TAI list, so the UE will need to perform the registration procedure again.
[0138] While the above behavior is good, what has not been considered is how the UE handles the Requested NSSAI IE that can be sent in the registration request procedure.
[0139] It can be noted that there is a requirement that if the UE sends a registration request again, the UE with pending NSSAI can not include the S-NSSAI in the pending NSSAI unless at the occurrence of certain conditions. However, before entering a new TAI as described above, the UE can have received the pending NSSAI IE but not the allowed NSSAI IE, or the UE can have received both IEs. In any case, when the UE moves to a new TAI, this new area can be served by a new AMF. Therefore, if the UE does not send the Requested NSSAI IE again, the determination of the entries of the allowed NSSAI IE (by the AMF) will be different compared to the case when the UE actually sends the Requested NSSAI IE. Therefore, not sending the Requested NSSAI IE can lead to incorrect behavior and undesirable results. This disclosure analyzes different cases to determine whether the Requested NSSAI IE can be included in the registration request message after an exceptional case to avoid undesirable results.
[0140] Case 2: Performing NSSAA for S-NSSAI in the allowed NSSAI list or not in the pending NSSAI
[0141] The UE can register to the network, for example, at initial registration, and obtain an allowed NSSAI with S-NSSAI entries (say, for example, S-NSSAI X). The network can also provide a pending NSSAI list in the registration accept message, for which NSSAA will be performed.
[0142] The UE can then receive a network slice-specific authentication complete message for S-NSSAI (say, S-NSSAI X), where this S-NSSAI is already in the allowed NSSAI list in the UE or not in the pending NSSAI list in the UE. This is an exceptional case, and the UE behavior to handle this scenario has not been defined.
[0143] Case 3: Unnecessary release of NAS connection
[0144] To avoid unnecessarily maintaining the NAS connection, the UE starts a timer T3540 in some cases to protect the maximum time period during which the network is expected to release the NAS signaling connection. The cases in which the UE starts T3540 are described in section 5.3.1.3 of the NAS specification in [3].
[0145] However, the current conditions for the opening of T3540 (which can lead to a local release of the NAS connection in the UE when it expires), in particular associated with the registration procedure, are not complete and therefore need to be updated. Otherwise, the NAS connection can be released earlier than needed.
[0146] 4. Problem with the barring of service request procedure during NSSAA
[0147] The AMF can indicate that NSSAA is pending by including the "NSSAA to be performed" indicator in the 5GS registration result IE and the AMF can include the pending NSSAI IE in the registration accept message without including the allowed NSSAI IE. In this case, the UE is not allowed to perform the service request procedure except for emergency services or high priority access, or for responding to paging or notification over non-3GPP access.
[0148] However, when NSSAA is ongoing, the UE can be in 5GMM connected mode over non-3GPP access. If the lower layer connection of the non-3GPP access is lost, then when the lower layers (of the non-3GPP access) indicate that the connection has been regained, the UE can perform the service request procedure to re-establish the NAS connection as specified in section 5.6.1.1 of [3], which is already the existing trigger:
[0149] This procedure is used in the following cases:
[0150] - a UE in 5GMM idle (5GMM-IDLE) mode over non-3GPP access receives from the lower layers of the non-3GPP access an indication that an access stratum connection has been established between the UE and the network; or...
[0151] However, the barring of the service request procedure due to ongoing NSSAA leads to contradictory requirements at the UE, where:
[0152] - on the one hand, the loss of the lower layer connection needs to initiate the service request procedure, and
[0153] - on the other hand, the ongoing NSSAA procedure bars the initiation of the service request procedure because the loss of the lower layer connection is not one of the identified exceptions to initiate the service request procedure.
[0154] 5. fallback indication from lower layers and the UE has a NSSAA complete message to send
[0155] As described in section 5.3.1.2 of the NAS specification in [3], a UE in 5GMM connected mode can receive a fallback indication from the lower layers (reproduced below for reference):
[0156] When a UE in 5GMM-CONNECTED mode on 3GPP access receives a fallback indication from lower layers and the UE has no pending NAS procedures and no pending uplink user data for PDU session(s) for which user plane resources have been established, the UE can:
[0157] a) enter 5GMM-IDLE mode; and
[0158] b) initiate a registration procedure for mobility and periodic registration update and include an uplink data status IE in the REGISTRATION REQUEST message to indicate PDU session(s) for which user plane resources were active prior to receiving the fallback indication (see subclause 5.5.1.3 for more details).
[0159] When a UE in 5GMM-CONNECTED mode on 3GPP access receives a fallback indication from lower layers and the UE has pending uplink user data for PDU session(s) for which user plane resources have been established, but no pending NAS procedures, the UE can:
[0160] a) enter 5GMM-IDLE mode; and
[0161] b) initiate a SERVICE REQUEST procedure and include an uplink data status IE in the SERVICE REQUEST message to indicate PDU session(s) for which user plane resources were active prior to receiving the fallback indication (see subclause 5.6.1 for more details).
[0162] When a UE in 5GMM-CONNECTED mode on 3GPP access receives a fallback indication from lower layers and the UE has a pending registration procedure, a SERVICE REQUEST procedure or a Deregistration procedure, the UE can:
[0163] a) enter 5GMM-IDLE mode;
[0164] b) continue with the pending procedure; and
[0165] c) if the pending procedure is a SERVICE REQUEST or a registration procedure, the UE can include an uplink data status IE in the SERVICE REQUEST message or the REGISTRATION REQUEST message to indicate PDU session(s) for which user plane resources were not active prior to receiving the fallback indication from lower layers and the UE has pending user data to send on 3GPP access, if any, and 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 more details).
[0166] When a UE in 5GMM-CONNECTED mode on 3GPP access receives a fallback indication from lower layers and the UE has a pending NAS procedure other than a registration procedure, a service request procedure or a deregistration procedure, the UE can:
[0167] a) enter 5GMM-IDLE mode;
[0168] b) initiate a service request procedure and include an uplink data status IE in the service request message indicating that user plane resources were active PDU session(s) (if any) prior to receiving the fallback indication (see subclause 5.6.1 for more details); and
[0169] c) continue any pending procedures upon successful completion of the service request procedure.
[0170] The above applies if the UE is in an allowed area or the UE is not in a not-allowed area.
[0171] When a UE:
[0172] a) is in a not-allowed area or is not in an allowed area;
[0173] b) is in 5GMM-CONNECTED mode on 3GPP access;
[0174] c) receives a fallback indication from lower layers; and
[0175] d) has no pending signalling,
[0176] The UE can:
[0177] a) enter 5GMM-IDLE mode; and
[0178] b) initiate a registration procedure for mobility and periodic registration update. The UE can not include an uplink data status IE in the registration request message unless the user plane resources were active PDU session is an emergency PDU session or if the UE is configured for high priority access in the selected PLMN.
[0179] In the above case, when the UE receives a fallback indication from lower layers, if the UE is in a not-allowed area or is not in an allowed area, the UE can operate as specified in subclause 5.3.5.
[0180] A particular behaviour to note is that if the UE has a pending procedure other than a registration procedure, other than a service request procedure, and other than a deregistration procedure, upon receiving a fallback indication from lower layers, the UE can initiate a service request procedure from idle mode and upon completion of that procedure, the UE continues the pending NAS procedure.
[0181] During the registration procedure, the UE can receive the pending NSSAI list in the registration accept message, then the network can start the NSSAA. The UE can receive the network slice specific authentication command message and the UE can have to respond to this message, so the UE has a pending NAS message which is not a registration procedure, not a service request procedure, nor a deregistration procedure. Then, the UE can receive the fallback indication from lower layers. Since there is a requirement that the UE can not initiate the service request procedure during the NSSAA, optionally when no allowed NSSAI is available in the UE, the recovery from fallback would contradict this requirement. In this case, the UE behavior needs to be defined so that proper recovery from fallback can occur.
[0182] 6. Handling of timer T3346 when the UE receives a NAS message for NSSAA
[0183] The UE can be in 5GMM-CONNECTED mode where the NAS congestion control timer T3346 is running. Then, the UE can receive the network slice specific authentication command message for NSSAA. Currently, if the timer T3346 is running, the UE does not stop the timer T3346, which is an incorrect behavior.
[0184] 7. Impact on NSSAA during periodic update registration procedure
[0185] During periodic registration, the UE is not mandated to send the requested NSSAI, which means that the UE requested NSSAI information has not changed since the last signaling or registration with the network. However, if the UE’s allowed NSSAI has changed, the AMF can provide the new allowed NSSAI in the registration accept message.
[0186] Currently, the provision of allowed NSSAI and / or pending NSSAI to the UE during the registration procedure depends on whether the UE sends the requested NSSAI and the content of the requested NSSAI. For example, the UE can not have any slice information for the current PLMN, so it can not send the requested NSSAI, although the registration is not triggered due to periodic registration. In this case, the AMF can consider the default slices for the UE.
[0187] However, as mentioned above, since the UE does not provide the requested NSSAI during periodic registration, the AMF can consider the default slices for the UE and thus provide the wrong allowed NSSAI. Therefore, the current procedure for NSSAA needs to consider whether the UE is performing periodic registration and determine the content of the pending NSSAA accordingly. The current handling of the registration request message does not consider this aspect, so it needs to be updated to correctly handle and perform the NSSAA procedure.
[0188] In view of the above problems, certain examples of the present disclosure provide one or more of the following solutions.
[0189] 1. Solution to enable NSSAA during roaming case (and non-roaming case)
[0190] As mentioned above, a roaming UE can include the Requested mapped NSSAI IE in the Registration Request message, and the S-NSSAI(s) included in this IE can undergo NSSAA.
[0191] Therefore, it is provided that, optionally in addition to the S-NSSAI entries of the Requested NSSAI IE (if it is also included in the Registration Request message), the AMF can consider and take into account the mapped S-NSSAI content in the Requested mapped NSSAI IE for NSSAA.
[0192] In addition to the current behavior, the AMF can also perform the following actions:
[0193] - If the UE does not support NSSAA, the UE sends the Requested mapped NSSAI IE in the Registration Request, and the S-NSSAI entries in the IE undergo NSSAA, and optionally
[0194] = the Requested NSSAI IE is not included in the Registration Request message, or
[0195] = the Requested NSSAI IE is included in the Registration Request message, and the entries in the Requested NSSAI IE undergo NSSAA,
[0196] then the AMF can reject the registration by sending a Registration Reject message, and include the 5GMM cause #62 "No available network slices", and the AMF can also include the Rejected NSSAI IE. In this case, the SST field of the Rejected S-NSSAI can be set to the mapped HPLMN SST included in the Requested mapped NSSAI IE that requires NSSAA, and the SD field of the Rejected S-NSSAI can be set to the mapped HPLMN SD field (if the latter is included in the Requested mapped NSSAI IE).
[0197] - If the entries in the Requested mapped NSSAI do not undergo NSSAA, and the policy of the AMF allows these slices can be used by the UE, and the associated PDU sessions are allowed to be transferred, the AMF can include the corresponding S-NSSAI in the Allowed NSSAI IE, and send the IE to the UE in the Registration Accept message.
[0198] - If the UE supports NSSAA and the UE includes the Requested Mapping of NSSAI IE in the Registration Request message, where the entries in the Requested Mapping of NSSAI are subject to NSSAA, the AMF can include the corresponding S-NSSAIs in the Pending NSSAI IE and send the IE to the UE in the Registration Accept message. Note that the Pending NSSAI IE can also include the entries from the Requested NSSAI IE if the latter is included by the UE in the Registration Request message.
[0199] - When the Registration Request message from the UE is rejected due to NSSAA, the AMF can also consider different cases, i.e. it can consider whether the Requested Mapping of NSSAI IE is included in the message or the Requested NSSAI IE is included in the message. The AMF behavior is provided as follows:
[0200] = If the Registration Request message includes the Requested Mapping of NSSAI IE but not the Requested NSSAI IE and for all entries in the Requested Mapping of NSSAI IE, NSSAA is revoked or failed (or all entries are rejected for the current registration area or all entries are rejected for the current PLMN) and optionally there are no entries that the network allows the UE to use without NSSAA or there is no default S-NSSAI allowed for the UE, the network can send a Registration Reject and include the Rejected NSSAI IE. For each rejected S-NSSAI entry in the Rejected NSSAI IE, the AMF can set the rejection cause to "S-NSSAI not available due to network slice specific authentication and authorization failure or revocation".
[0201] = If the Registration Request message includes the Requested Mapping of NSSAI IE as well as the Requested NSSAI IE and for all entries in both IEs, NSSAA is revoked or failed (or all entries are rejected for the current registration area or all entries are rejected for the current PLMN) and optionally there are no entries that the network allows the UE to use without NSSAA or there is no default S-NSSAI allowed for the UE in any of these IEs, the network can send a Registration Reject and include the Rejected NSSAI IE. For each rejected S-NSSAI entry in the Rejected NSSAI IE, the AMF can set the rejection cause to "S-NSSAI not available due to network slice specific authentication and authorization failure or revocation". The deregistration request message can include the 5GMM cause indicating #62 "no available network slice".
[0202] = When the AMF sends the rejected NSSAI IE due to the failure of NSSAA or the revocation of NSSAA, or the UE does not support NSSAA, but all S-NSSAIs requested by the UE (either in the mapped NSSAI IE of the request, or in the requested NSSAI IE, or in both) are subject to NSSAA, then the entries in the rejected NSSAI IE can be set to the mapped S-NSSAIs (i.e., S-NSSAIs of the HPLMN). The registration reject message can include the 5GMM cause indicating #62 "No available network slice".
[0203] = Alternatively, when any of the above occurs for a UE in connected mode, i.e., when the AMF considers the content of the requested mapped NSSAI IE and / or the content of the requested NSSAI IE, and for all entries in the IEs, NSSAA fails, and optionally, there is no default slice allowed for the UE, or optionally, the entries in the IEs are rejected for the current PLMN or the registration area, then the AMF can send the deregistration request message and set the 5GMM cause to #62 "No available network slice". The AMF can also include the rejected NSSAI.
[0204] When NSSAA is to be performed, the UE can receive the registration accept message with the pending NSSAI IE and optionally, the allowed NSSAI IE. According to the current behavior, if the UE receives the allowed NSSAI IE in which there is no match between the S-NSSAI entries and the S-NSSAI associated with the PDU session, or between the mapped S-NSSAI (of the allowed NSSAI entries) and the mapped S-NSSAI associated with the PDU session, then the UE can locally release the PDU session for which there is no match as described above.
[0205] However, during NSSAA, the S-NSSAI associated with the PDU session can not be in the allowed NSSAI IE, but can be in the pending NSSAI IE. Therefore, a UE supporting NSSAA can not ignore the content of the pending NSSAI IE before inferring or determining that a PDU session can be released. Therefore, it is provided that:
[0206] - If the UE receives the allowed NSSAI IE and the pending NSSAI IE, then even if there is no match between:
[0207] = the S-NSSAI in the allowed NSSAI IE and the S-NSSAI of the respective and each PDU session, or
[0208] = mapped S-NSSAI of the entries in the Allowed NSSAI IE and mapped S-NSSAI of the respective and each PDU session,
[0209] then the UE can check for a match as described above, i.e. a match between:
[0210] = S-NSSAI entries in the Pending NSSAI IE and S-NSSAI of the respective and each PDU session, or
[0211] = mapped S-NSSAI of the entries in the Pending NSSAI IE and mapped S-NSSAI of the respective and each PDU session.
[0212] If there is a match, the UE can not release the PDU session for which the match occurs and can wait to determine whether the session can be released after NSSAA completion and after the UE obtains the Allowed NSSAI IE for which the UE can perform the check again. Optionally, the UE performs the check again (e.g. on the Allowed NSSAI entries) after the Pending NSSAI list is empty.
[0213] As described above, if there is no match with any of the entries of the Pending NSSAI IE, the UE can (for each PDU session for which no match occurs) locally release the PDU session, except for a persistent PDU session or a PDU session for emergency services.
[0214] - If the UE does not receive the Allowed NSSAI IE but receives the Pending NSSAI IE, the UE can maintain the PDU session until the Allowed NSSAI IE is received, wherein after the Allowed NSSAI IE is received, the UE performs the check as described above and determines whether the PDU session can be released.
[0215] = Alternatively, the UE can perform the check for the entries in the Pending NSSAI IE as described above, i.e. the UE checks for a match between:
[0216] * S-NSSAI entries in the Pending NSSAI IE and S-NSSAI of the respective and each PDU session, or
[0217] * mapped S-NSSAI of the entries in the Pending NSSAI IE and mapped S-NSSAI of the respective and each PDU session.
[0218] If there is a match, the UE maintains the PDU session for which the match occurs until the Allowed NSSAI IE is received, wherein after the Allowed NSSAI IE is received, the UE performs the check again and then determines whether the PDU session can be released.
[0219] As mentioned above, the UE can locally release the PDU session if there is no match with any entry of the pending NSSAI IE, except for the persistent PDU session or the PDU session for emergency services.
[0220] The embodiments provided above can also be implemented by the following checks at the UE:
[0221] With respect to each of the PDU session(s) active in the UE, if the UE does indicate support for network slice-specific authentication and authorization, and:
[0222] 1) if the UE receives a pending NSSAI but no allowed NSSAI, and each mapped S-NSSAI in the pending NSSAI does not match the mapped S-NSSAI of the PDU session;
[0223] 2) if the UE receives a pending NSSAI and an allowed NSSAI, and
[0224] i) the allowed NSSAI contains neither:
[0225] A) an S-NSSAI that matches the S-NSSAI of the PDU session; nor
[0226] B) a mapped S-NSSAI that matches the mapped S-NSSAI of the PDU session; and
[0227] ii) each mapped S-NSSAI in the pending NSSAI does not match the mapped S-NSSAI of the PDU session; or
[0228] 3) if the UE receives an allowed NSSAI but no pending NSSAI, and the allowed NSSAI contains neither:
[0229] i) an S-NSSAI that matches the S-NSSAI of the PDU session; nor
[0230] ii) a mapped S-NSSAI that matches the mapped S-NSSAI of the PDU session;
[0231] The UE can perform the local release of all such PDU sessions except for the emergency PDU session, if any.
[0232] Optionally, the UE can maintain the PDU session as long as it has a pending NSSAI that is not empty, or optionally as long as the 5GS registration result IE indicates "NSSAA to be performed". When the UE receives the allowed NSSAI and / or the rejected NSSAI such that as part of storing this information, the UE's pending NSSAI becomes empty, the UE then performs the check (as currently specified in TS 24.501 and also described above) on the allowed NSSAI to determine whether the session can be maintained. In other words, the UE maintains the PDU session until the UE receives the allowed NSSAI and / or the UE's pending NSSAI is empty, then the UE checks the allowed NSSAI for a match between:
[0233] - the S-NSSAI in the allowed NSSAI IE and the S-NSSAI of the respective and each PDU session, or
[0234] - the mapped S-NSSAI of the entries in the allowed NSSAI IE and the mapped S-NSSAI of the respective and each PDU session.
[0235] If there is no match as described above, the UE releases the PDU session for which there is no match, except for PDU sessions for emergency services or high priority access.
[0236] Note that the embodiments provided above apply even for non-roaming cases, i.e. even if the UE does not send the requested mapped NSSAI IE. Note that the embodiments provided above also apply for the case when the UE performs an inter-system change from S1 mode (i.e. from EPS) to N1 mode (i.e. to 5GS) (and optionally when the N26 interface is supported in the system).
[0237] Furthermore, the checks as described above can also be made between the content sent by the UE in the {requested NSSAI IE or requested mapped NSSAI IE} and the entries of the {allowed NSSAI IE or pending NSSAI IE}.
[0238] Note that when the UE receives the same information or a subset of the information (i.e. only the allowed NSSAI, or only the pending NSSAI, or both the allowed NSSAI and the pending NSSAI) in the configuration update command message, some or all of the checks above (i.e. the check in the UE based on the received NSSAI information to determine whether the PDU session can be released locally) can also be performed.
[0239] Note that the term "mapped S-NSSAI in the pending NSSAI" also refers to the S-NSSAI entry in the pending NSSAI.
[0240] 2. Solutions to deal with conflicts between the NSSAA process and other processes
[0241] Case 1: Resolution of the conflict between the authentication process and the NSSAA process
[0242] As described above, during NSSAA, the network may initiate the NSSAA process and then initiate the authentication process.
[0243] If the UE receives a network slice specific Authentication Command message over any access type (e.g., 3GPP access or non-3GPP access), and (at about the same time or shortly thereafter) the UE also receives an Authentication Request message over any access type (e.g., 3GPP access or non-3GPP access), where the access type over which one of the NAS messages is received is not necessarily the same as the access type over which the other NAS message is received, the UE may ignore or abort the NSSAA procedure (i.e., ignore the network slice specific Authentication Command message) and continue the authentication procedure (i.e., process the Authentication Request message). Alternatively, the UE may first process the Authentication Request message and successfully complete the authentication and, optionally, security mode control procedures before responding to the network slice specific Authentication Command message. In this case, the UE may send a network slice specific Authentication Complete message only after sending an Authentication Response or Security Mode Complete message.
[0244] Note that the embodiments provided above are applicable to conflicts between the NSSAA process and the security control process.
[0245] Thus, if the UE receives a network slice specific authentication command message over one access type, and (at about the same time or shortly thereafter) the UE also receives a security mode command message over the same access type, the UE may process the security mode command message (i.e., may process the security mode control procedure) in preference to the network slice specific authentication command message (i.e., in preference to the NSSAA procedure). The UE may ignore the network slice specific authentication command message (i.e., ignore or abort the NSSAA procedure) and process the security mode command message (i.e., continue with the security mode control procedure). Alternatively, the UE may first complete the ongoing security mode control procedure, and after that procedure completes successfully (i.e., after the UE sends the security mode complete message), the UE may then process the network slice specific authentication command message and potentially respond with a network slice specific authentication complete message.
[0246] Case 2: Resolution of conflict between general UE configuration update procedure and NSSAA procedure
[0247] As mentioned above, during NSSAA, the network can initiate the NSSAA procedure and then initiate the generic UE configuration update procedure. If the UE receives the network slice specific authentication command message over any access type (e.g., 3GPP access or non-3GPP access) and (roughly at the same time or shortly after) the UE also receives the configuration update command message over any access type (e.g., 3GPP access or non-3GPP access), where the access type over which one of the NAS messages is received is not necessarily the same as the access type over which the other NAS message is received, and if the configuration update command message indicates that registration is required (e.g., the "Request Registration" bit of the Configuration Update Indication IE or any other way that can be used to indicate that registration is required), the UE can ignore or abort the NSSAA procedure (i.e., ignore the network slice specific authentication command message) and proceed with the generic UE configuration update procedure (i.e., process the configuration update command message).
[0248] - Alternatively, if the configuration update command message does not contain any parameters other than the registration indication (e.g., the message does not contain other IEs other than the Configuration Update Indication IE), the embodiments provided above can be applied.
[0249] - Alternatively, if the configuration update command message indicates that registration is required and the message also includes the network slice indication IE with the NSSCI bit (see [3]) set to "Network Slice Subscription Changed", the embodiments provided above can be applied.
[0250] - Alternatively, if the UE is requested to perform registration in connected mode, e.g., when the MICO indication IE is present in the configuration update command message, the embodiments provided above can not be applicable, i.e., the UE continues both the NSSAA procedure and the generic UE configuration update procedure. Note that the presence of the MICO indication IE is an example when the UE is requested to perform the registration procedure in connected mode, but there can be other cases when the UE is requested to perform registration in connected mode and for these cases, the embodiments provided above are not applicable.
[0251] Note that "the embodiments provided above can not be applicable" means that the UE does not ignore the NSSAA procedure and the UE continues to process both the network slice specific authentication command message and the configuration update command message, and no procedure is aborted.
[0252] Case 3: Resolution of conflict between service request procedure and NSSAA procedure
[0253] As mentioned above, during an ongoing NSSAA procedure over, e.g., 3GPP access, the UE can initiate a service request procedure over non-3GPP procedure.
[0254] When the AMF receives a service request message from a UE in 5GMM-CONNECTED mode over a non-3GPP access over the non-3GPP access, if:
[0255] - the AMF has initiated NSSAA for the UE over the same or different access,
[0256] - and optionally, the AMF has sent a registration accept message to the UE (before the NSSAA started) over the different access, where the message contains the pending NSSAI IE and the 5GS registration result IE indicating "NSSAA to be performed", and the message does not contain the allowed NSSAI IE,
[0257] - and the AMF receives the service request message from the UE over the non-3GPP access, optionally from the UE in 5GMM-CONNECTED mode, and optionally the service request message includes the uplink data status IE,
[0258] then the AMF can abort the service request procedure (i.e. ignore the service request message) and continue with the NSSAA procedure (i.e. send the network slice specific authentication command message to the UE if it has not been sent yet, or process the network slice specific authentication complete message if it is received from the UE).
[0259] Otherwise, if the above conditions are not met, the AMF can handle both procedures simultaneously.
[0260] 3. Handling of exceptional cases
[0261] Case 1: Transmission failure of network slice specific authentication complete message with TAI change from lower layers
[0262] As specified in [3], when the identified exceptional case occurs, the UE aborts the network slice specific authentication and authorization procedure and can initiate the registration procedure for mobility and periodic registration update with the 5GS registration type IE in the registration request message indicating "mobility registration update". In this case, the UE can also include the requested NSSAI IE or the requested mapped NSSAI IE, or both IEs, even if the S-NSSAI entries constituting these IEs are in the pending NSSAI IE.
[0263] Alternatively, if the UE has sent the requested NSSAI IE or the requested mapped NSSAI IE or both IEs in a previous or last registration procedure, the IEs can be included even if the UE has S-NSSAI entries in the pending NSSAI list that were previously included in the requested NSSAI IE or the requested mapped NSSAI IE or both IEs.
[0264] Case 2: Performing NSSAA for S-NSSAI that is in the allowed NSSAI list or not in the pending NSSAI
[0265] The UE can perform a registration procedure, e.g., for initial registration, and the UE can obtain the allowed NSSAI in the registration accept message, which can include the pending NSSAI.
[0266] After the registration procedure is completed, the AMF can initiate NSSAA and send the network slice-specific authentication command message with the S-NSSAI field set to either in the allowed NSSAI or not in the pending NSSAI. When this happens, optionally after initial registration, the UE can consider this an exceptional case or an error.
[0267] When the UE considers the network slice-specific authentication command message problematic or erroneous or an exceptional case, such as but not limited to the example scenarios discussed above, the UE can send a 5GMM status message to the AMF as defined in [3]. In this case, the UE can use a new 5GMM cause code indicating NSSAA error, e.g., “Network Slice-Specific Authorization and Authentication Error”. Note that this is an example 5GMM cause code, but any other value can be defined for this purpose.
[0268] Alternatively, a new 5GMM message can be used for this purpose. For example, a new network slice-specific authentication reject message can be defined to report errors or exceptional cases, such as the scenarios described above. The new message can include at least the S-NSSAI received in the corresponding network slice-specific authentication command message, the 5GMM cause, and the EAP message (optionally). The EAP message can be the same message received in the corresponding network slice-specific authentication command message.
[0269] When the UE sends the 5GMM status message or the new NAS message as provided above, the UE can optionally send the allowed NSSAI and the list of pending NSSAI to the AMF to inform the AMF of the S-NSSAIs available in the UE for each list. The new message, i.e., the network slice-specific authentication message, provided is shown in Table 1 below.
[0270] [Table 1]
[0271]
[0272]
[0273] Note that the IEs in the above message can be optional (identified by an "O" in the "Presence" column), although some are shown as mandatory (identified by an "M" in the "Presence" column), and vice versa.
[0274] When the AMF receives a new message or a 5GMM status message as provided above with a new 5GMM cause code, the AMF can re-initiate the NSSAA procedure with the correct S-NSSAI. If the 5GMM cause code indicates that the S-NSSAI is not correct, the AMF can optionally re-initiate the NSSAA with the correct S-NSSAI by ensuring that the S-NSSAI used is actually part of the pending NSSAI list in the UE, which can have also been received by the AMF.
[0275] Running the NSSAA for an S-NSSAI that is not in the pending NSSAI list can not be an error or exceptional case. This can happen, for example, for the default S-NSSAI(s) for which the UE has not requested but the AMF needs to perform NSSAA. Therefore, an alternative approach for the UE is to continue processing the related NSSAA message even if the S-NSSAI for which the NSSAA is being performed is not in the pending NSSAI (or optionally in the allowed NSSAI).
[0276] Another way to indicate to the UE that the NSSAA procedure is not an error is to include a new indication in the network slice-specific authentication command message, informing the recipient (e.g., the UE) that the procedure is intentional, i.e., not an error. The indication can be in any form, such as defining an operation type, where the operation can be set to, for example, "initial NSSAA", "re-authentication", "NSSAA for default slice", etc. The indication can be in the form of a new IE. Note that this indication can be used in general to indicate to the UE why a particular NSSAA message is being sent. The UE can use this indication to identify whether the message being sent is for initial NSSAA or re-running NSSAA, etc., so the UE can take specific actions based on this. For example, if the network is performing re-authentication for a certain S-NSSAI in the allowed NSSAI, the UE can block 5GSM requests associated with this S-NSSAI assuming the UE knows that the NSSAA procedure is a re-run and therefore the UE does not consider this an error.
[0277] Currently, the UE (in particular the 5GMM entity in the UE) for NSSAA involvement is that the NAS forwards the content of the NETWORK SLICE-SPECIFIC SESSION AUTHENTICATION COMMAND message to the upper layer. However, it can be good for the UE (or NAS or 5GMM entity) to take other actions, such as ensuring that the S-NSSAI received in the message is part of any combination of the following:
[0278] - Pending NSSAI list;
[0279] - Allowed NSSAI; or
[0280] - Rejected NSSAI.
[0281] Then, when the check condition occurs, the UE can take any of the provided actions.
[0282] Alternatively, the UE can also check whether the S-NSSAI is not part of the allowed NSSAI, nor part of the pending NSSAI, and if so, the UE can consider this an error and take any of the actions provided above.
[0283] Note that if the AMF receives a NETWORK SLICE-SPECIFIC SESSION AUTHENTICATION COMPLETE message and the S-NSSAI included in this message is invalid, e.g. it does not match any of the S-NSSAIs that NSSAA is ongoing, or it is not part of the S-NSSAIs that NSSAA is performing, or it is not part of the pending NSSAI list in the AMF, the AMF can ignore or discard the received message and re-send the NETWORK SLICE-SPECIFIC SESSION AUTHENTICATION COMMAND message with a valid S-NSSAI (i.e. an S-NSSAI that NSSAA is ongoing or has not completed, or a different S-NSSAI than the one known to be invalid). Note that this requires the AMF to store and compare the S-NSSAI sent in the NETWORK SLICE-SPECIFIC AUTHENTICATION message and the S-NSSAI received in the NETWORK SLICE-SPECIFIC SESSION AUTHENTICATION COMPLETE message. When there is no match, or when the S-NSSAI received in the NETWORK SLICE-SPECIFIC SESSION AUTHENTICATION COMPLETE message is not part of the S-NSSAIs that NSSAA is ongoing (as described differently above), the AMF can ignore the received message, or optionally abort the existing procedure, and re-send the NETWORK SLICE-SPECIFIC SESSION AUTHENTICATION COMMAND message with the desired and valid S-NSSAI.
[0284] Note that throughout the document, the term "NSSAA to be performed" is synonymous with the 5GS registration result IE in which the "NSSAA to be performed" indicator is set to "NSSAA to be performed" being received.
[0285] Case 3: Unnecessary release of NAS connection
[0286] To ensure that T3540 is started correctly during the registration procedure, in addition to what is specified in section 5.3.1.3 of the NAS specification in [3] for case (b) (i.e. the UE receives a registration accept), the UE must also check the following conditions:
[0287] - whether the registration accept message indicates "NSSAA to be performed" in the 5GS registration result IE, or
[0288] - whether the registration accept message includes pending NSSAI (i.e. the pending NSSAI IE is not included).
[0289] If the registration accept:
[0290] - indicates "NSSAA to be performed" in the 5GS registration result IE, or
[0291] - includes pending NSSAI (i.e. the pending NSSAI IE is not included),
[0292] then the UE can not start T3540.
[0293] If T3540 is running in the UE, upon reception of the network slice specific authentication command message, the UE can stop T3540.
[0294] 4. Allowing some procedures while NSSAA is ongoing
[0295] The UE can be in 5GMM connected mode at least over non-3GPP access and optionally over 3GPP access, and the AMF can perform the NSSAA procedure over non-3GPP access or optionally over 3GPP access. The UE can have received the pending NSSAI IE in the registration accept message but no allowed NSSAI IE, and the 5GS registration result IE can have indicated "NSSAA to be performed".
[0296] While NSSAA is ongoing, the UE can lose its lower layer connection over non-3GPP access. When the connection is regained, NAS can receive from the lower layers of non-3GPP access an indication that an access layer connection is established between the UE and the network. The UE can initiate the service request procedure and send the service request message over non-3GPP access, even though NSSAA is ongoing, under the above conditions.
[0297] The above can also be implemented by imposing a restriction on the UE with respect to the service request procedure, such that the UE can not initiate the service request procedure from 5GMM connected mode (i.e., can not send the service request message) during an ongoing NSSAA procedure (optionally, if the UE has received pending NSSAI and has not received allowed NSSAI, and the 5GS registration result IE indicates "NSSAA to be performed"). Thus, this restriction does not apply to a UE in 5GMM idle mode. Thus, when a UE in 5GMM idle mode on non-3GPP access receives an indication from lower layers of non-3GPP access that an access stratum connection is established between the UE and the network, the UE will be able and can send the service request message on non-3GPP access to establish a NAS connection with the network. The UE can send the service request message even if NSSAA is ongoing on 3GPP access under the above conditions (regardless of what the UE receives or does not receive in the registration accept message, e.g., even if the UE does not receive allowed NSSAI in the registration accept message). Note that the embodiments provided apply to initial registration as well as registration for mobility and periodic updates.
[0298] Note that the UE can be allowed to send the service request message in 5GMM connected mode if the UE does so for the purpose of requesting establishment of a PDU session for emergency services or for a PDU session for which the UE has user plane resources to send for abnormal data reporting. Similarly, the UE can be allowed to send data over the control plane (i.e., send UL NAS transport message with CIoT user data or location services or SMS (optionally)) when the UE does so for abnormal data reporting or if the UE is a high priority access UE.
[0299] Alternatively, the UE can send the registration request message instead of the service request procedure when the NAS receives an indication from lower layers of non-3GPP access that an access stratum connection is established between the UE and the network. If the UE has included one or both of these IEs during the last registration procedure (or if the UE has slice information for the current PLMN), the UE can include the requested NSSAI IE or the requested mapped NSSAI IE or both, even if the S-NSSAI is included in the UE's current pending NSSAI list.
[0300] Note that the embodiments provided above can also be applied during any other procedure and are not limited to the registration procedure. For example, if in the future a configuration update command message can be used to provide the UE with a pending NSSAI, and optionally without an allowed NSSAI, and optionally based on the content of the message, the UE considers that it does not have a valid allowed NSSAI, then the embodiments provided above would still apply if the lower layer connection fails and is later established (as described above). Thus, the embodiments provided are not limited to the registration procedure only and can be applied during any procedure or at any time in the connected mode when the UE determines that it does not have an allowed NSSAI.
[0301] The NAS specification [3] already allows the UE to initiate a 5GSM procedure, e.g. a PDU session establishment procedure, during NSSAA when the above conditions are met (i.e. the UE receives a pending NSSAI IE in the registration accept message, but no allowed NSSAI IE, and the 5GS registration result IE can have indicated “NSSAA to be performed”). However, if the UE does send a PDU session establishment request message (in an UL NAS transport message), the UE can not include the S-NSSAI IE in the UL NAS transport message, as the UE does not yet have an allowed NSSAI. Alternatively, the UE can include the S-NSSAI IE and set it to a pre-configured value in the UE.
[0302] 5. Recovery from fallback during NSSAA
[0303] As mentioned above, the UE can receive a fallback indication during NSSAA, so the UE has a pending NAS procedure (e.g. the UE can need to send a NAS message in response to a network slice specific authentication command message). When the fallback occurs, the UE can take any one of the following measures as provided by the embodiments to recover from the fallback:
[0304] - The UE can be allowed to initiate a service request procedure (i.e. send a service request message) to recover from the fallback as currently specified. To allow this, the current restriction that can not allow a service request procedure during NSSAA needs to be updated in order to define more exceptions to address this issue. For example, the restriction (prohibiting the UE from initiating a service request procedure during NSSAA) can not apply to a service request procedure initiated from 5GMM idle mode. Thus, a UE with a pending NSSAI and during the NSSAA procedure (optionally if the UE does not have an allowed NSSAI, or if the UE receives an “NSSAA to be performed indicator” indicating that NSSAA is to be performed) can be allowed to send a service request message from 5GMM idle mode to recover from the fallback.
[0305] = Optionally, the above operations are allowed only when the UE has registered to the system or when the NSSAA is performed after a registration procedure with 5GS registration type IE set to "mobility registration update" or "periodic registration update".
[0306] = Optionally, when sending the service request message, the UE can not include the uplink data status IE unless the corresponding PDU session (for which the specific bit in the IE is set to 1) is associated with an S-NSSAI in the allowed NSSAI or is not associated with an ongoing S-NSSAI for NSSAA or the PDU session is an always-on PDU session or if the PDU session has user plane resources established prior to the fallback indication
[0307] - Alternatively, if to recover from fallback, the UE can send a registration request message with 5GS registration type IE set to "mobility registration update". The UE is allowed to include the requested NSSAI IE or the requested mapped NSSAI IE in the registration request sent to recover from fallback even if the entry is in the pending NSSAI or even if the UE has a pending NSSAI.
[0308] Note that the embodiments provided above can also apply at any time when the UE is in connected mode and NSSAA is ongoing and the UE receives a fallback indication. Thus, the provided UE behavior is not limited to scenarios that only occur during a registration procedure. The provided embodiments still apply if other procedures are ongoing or generally for a UE in connected mode.
[0309] = Optionally, when sending the service request message, the UE can not include the uplink data status IE unless the corresponding PDU session (for which the specific bit in the IE is set to 1) is associated with an S-NSSAI in the allowed NSSAI or is not associated with an ongoing S-NSSAI for NSSAA or the PDU session is an always-on PDU session.
[0310] When the AMF receives a service request message or a registration request message as provided above and the AMF has an ongoing NSSAA procedure, the AMF can process the service request message or the registration request message and optionally abort the NSSAA procedure. The AMF can determine to do so based on the fact that the NAS message is received as an initial NAS message from the N2 interface and the protocol running between the NG-RAN and the AMF.
[0311] 6. When the UE receives a NAS message for NSSAA, stop timer T3346
[0312] It is provided that the UE can stop T3346 (if running) upon reception of the network slice specific authentication command message. Thus, upon reception of the network slice specific authentication command message, the UE can stop the timer T3346 if it is running.
[0313] 7. Consideration of a registration update type of solution for NSSAA
[0314] It is provided that the current handling of NSSAA is performed only when the 5GS registration type IE indicates "mobility registration update" in the registration request message, optionally when the NAS message is received from a UE not in narrowband N1 (NB-N1) mode. Thus, when the NAS message is received from a UE not in NB-N1 mode, the AMF can take the actions currently specified in TS 24.501 if the 5GS registration type IE optionally indicates "mobility registration update" in the registration request message.
[0315] The AMF can have new NSSAI information for the UE, i.e. the allowed NSSAI previously sent to the UE can have changed. The new NSSAI that the UE can use can also require the execution of NSSAA. In fact, the AMF can need to re-initiate NSSAA for the UE due to internal policy or upon request from the AAA server related to NSSAA. The UE can then send a registration request with the 5GS registration type IE indicating "periodic registration update" or "mobility registration update" for a UE in NB-N1 mode. Thus, it is provided that:
[0316] - if the allowed NSSAI for the UE has not changed and the re-initiation of NSSAA for the UE is not required, the AMF does not need to take any action; and
[0317] - if the allowed NSSAI (or S-NSSAI that the UE is allowed to use) has changed and at least one new S-NSSAI requires NSSAA, the AMF can:
[0318] = send to the UE an allowed NSSAI containing S-NSSAI that does not require re-initiation of NSSAA (if any), or
[0319] = Send pending NSSAI containing S-NSSAI(s) for which NSSAA needs to be re-initiated. In addition, the AMF can also set the "NSSAA to be performed" indicator in the 5GS registration result IE if no allowed NSSAI can be provided to the UE. The content of the pending NSSAI can also include default slices (i.e., slices that are marked as default slices in the UE's subscription information and for which NSSAA needs to be initiated or re-initiated).
[0320] During a periodic registration procedure (i.e., the 5GS registration type IE indicates "periodic registration update"), or during a registration procedure where the 5GS registration type IE is set to "mobility registration update", the UE can receive the pending NSSAI in the registration accept message. The UE works in a similar way as currently specified when receiving the same information in a registration accept message as part of a registration procedure that is not triggered for periodic update.
[0321] If the 5GS registration result IE indicates "NSSAA to be performed" in the registration accept message and the 5GS registration type IE in the registration request message indicates:
[0322] a) "periodic registration update" (i.e., the procedure is triggered due to periodic registration update); or
[0323] b) "mobility registration update" and the UE is in NB-N1 mode (i.e., the procedure is not triggered for periodic registration update by a NB-N1 mode UE),
[0324] The UE can consider the previously stored allowed NSSAI as invalid, i.e., the UE can delete any stored allowed NSSAI.
[0325] Note that the above provided embodiment, i.e., considering the stored allowed NSSAI as invalid, can alternatively also apply to all UEs sending a registration request message with the 5GS registration type IE set to "mobility registration update" and the UE then obtaining the 5GS registration result IE in the registration accept message indicating "NSSAA to be performed".
[0326] It can be noted that throughout the document, the term "NSSAA to be performed" is synonymous with the "NSSAA to be performed indicator" set to the value "NSSAA to be performed".
[0327] Note that if the NSSAA is revoked for all slices, the AMF can also reject the registration request message for the UE whose 5GS registration type IE indicates "periodic registration update" (i.e., the procedure is triggered due to periodic registration update) or indicates "mobility registration update" and the UE is in NB-N1 mode (i.e., the procedure is not triggered by the NB-N1 mode UE for periodic registration update), although the UE does not send the requested NSSAI IE (or the requested mapped NSSAI IE) in the registration request message. The AMF takes the same behavior as provided earlier in this document (for the case when the AMF needs to consider the requested mapped NSSAI IE and / or the requested NSSAI IE).
[0328] Certain examples of the present disclosure provide a method for a network entity (e.g., an AMF entity), the method comprising: if the allowed NSSAI of the UE has changed from the allowed NSSAI previously sent to the UE, and at least one new S-NSSAI requires NSSAA, sending to the UE: the allowed NSSAI containing S-NSSAIs for which re-initiation of NSSAA is not required, and / or the pending NSSAI containing S-NSSAIs for which re-initiation of NSSAA is required. Those skilled in the art will appreciate that this technique can be applied to the case described above under item 7 (i.e., the UE is performing periodic update, or the NB-N1 mode UE is sending a registration request for mobility update). In either case, the AMF does not receive the requested NSSAI, so certain examples send: (a) the allowed NSSAI with slices that are allowed to be used, (b) the pending NSSAI if some (potentially new) slices require NSSAA.
[0329] Certain examples of the present disclosure provide a method for a network entity (e.g., an AMF entity), the method comprising: if the allowed NSSAI of the UE has changed from the allowed NSSAI previously sent to the UE, and at least one new S-NSSAI requires NSSAA, sending to the UE: the allowed NSSAI containing S-NSSAIs for which re-initiation of NSSAA is not required, and / or the pending NSSAI containing S-NSSAIs for which re-initiation of NSSAA is required. Those skilled in the art will appreciate that this technique can be generalized to all types of registration requests, where for these registration requests, the UE can set the allowed NSSAI to be invalid if "NSSAA to be performed" is received.
[0330] Figure 6 is a block diagram of an example network entity that can be used in examples of the present disclosure. For example, a UE and / or an AMF can be provided in the form of the network entity shown. Figure 6 Those skilled in the art will appreciate that the network entity shown can be used in examples of the present disclosure. For example, a UE and / or an AMF can be provided in the form of the network entity shown.Figure 6 The network entities shown in FIG. 6 can be implemented as, for example, network elements on dedicated hardware, software instances running on dedicated hardware, or virtualized functions instantiated on an appropriate platform, such as a cloud infrastructure.
[0331] The entity 600 includes a processor (or controller) 601, a transmitter 603, and a receiver 605. The receiver 605 is configured to receive one or more messages or signals from one or more other network entities. The transmitter 603 is configured to transmit one or more messages or signals to one or more other network entities. The processor 601 is configured to perform one or more operations and / or functions as described above. For example, the processor 601 can be configured to perform operations of a UE or an AMF.
[0332] The techniques described herein can be implemented using any suitably configured apparatus and / or system. Such apparatus and / or system can be configured to perform a method according to any aspect, embodiment, example, or claim disclosed herein. Such apparatus can include one or more elements, such as one or more of a receiver, a transmitter, a transceiver, a processor, a controller, a module, a unit, etc., each configured to perform one or more respective processes, operations, and / or method steps to implement the techniques described herein. For example, the operations / functions of X can be performed by a module configured to perform X (or X module). One or more elements can be implemented in the form of hardware, software, or any combination of hardware and software.
[0333] It should be understood that examples of the present disclosure can be implemented in the form of hardware, software, or any combination of hardware and software. Any such software can be stored in the form of volatile or non-volatile storage, such as, for example, storage devices like ROM, whether erasable or rewritable or memory chips, device or integrated circuits or in the form of memory such as RAM, minimizing, memory chips, device or integrated circuits, or stored as electronic signals on a tangible medium at a storage, such as, for example, a database or a file system.
[0334] It should be understood that the storage devices and storage media are embodiments of machine-readable storage media suitable for storing one or more programs comprising instructions to be executed by a machine (e.g., a processor of a computer) and thereby implement certain examples of the present disclosure. Thus, certain examples provide a program comprising code for implementing a method, apparatus, or system according to any example, embodiment, aspect, and / or claim disclosed herein, and / or storing such a program; and a machine-readable storage device storing such a program. Further, such programs can be electronically transferred across any media as electronic signals, which are stored in memory of a machine (e.g., a computer) and executed by the machine.
[0335] While the present disclosure has been described with various embodiments, various changes and modifications can be suggested to one skilled in the art. It is intended that the present disclosure encompass such changes and modifications as fall within the scope of the appended claims.
Claims
1. A method performed by a user equipment, UE, the method comprising: sending, by the UE to a network entity, a registration request message including a registration type information element, IE, indicating a periodic registration update or a mobility registration update; and receiving, by the UE from the network entity, a registration accept message including a registration result IE having an indicator indicating that network slice- specific authentication and authorization, NSSAA, is to be performed and pending network slice selection assistance information, NSSAI; determining, by the UE based on the registration accept message, that a previously received allowed NSSAI is invalid; and initiating, by the UE, a service request message in case the UE in idle mode obtains an indication that an access stratum connection is established between the UE and the network or in case the UE in connected mode obtains a fallback indication and the UE has a pending procedure.
2. The method of claim 1, wherein, The registration accept message does not include an allowed NSSAI.
3. The method of claim 1, wherein, The UE in idle mode over a non-third generation partnership project, 3GPP, access obtains the indication that an access stratum connection is established between the UE and the network from a lower layer of the non-3GPP access.
4. The method of claim 1, wherein, The pending procedure is a NSSAA procedure.
5. The method of claim 1, wherein, In case the registration type IE indicates the mobility registration update, the UE is in a narrow band mode that allows access to a fifth generation, 5G, network.
6. A method performed by a network entity, the method comprising: receiving, by the network entity from a user equipment, UE, a registration request message including a registration type information element, IE, indicating a periodic registration update or a mobility registration update; and sending, by the network entity to the UE, a registration accept message including a registration result IE having an indicator indicating that network slice- specific authentication and authorization, NSSAA, is to be performed and pending network slice selection assistance information, NSSAI, wherein a service request procedure is initiated in case an access stratum connection is established between the UE in idle mode and the network or in case the UE in connected mode has a pending procedure.
7. The method of claim 6, wherein, The registration accept message does not include an allowed NSSAI.
8. The method of claim 6, wherein, The UE in idle mode over a non-third generation partnership project, 3GPP, access obtains the indication that an access stratum connection is established between the UE and the network from a lower layer of the non-3GPP access.
9. The method of claim 6, wherein, The pending procedure is a NSSAA procedure.
10. A user equipment, UE, the UE comprising: a transceiver; and at least one processor configured to control the transceiver to: send, to a network entity, a registration request message including a registration type information element, IE, indicating a periodic registration update or a mobility registration update, receive, from the network entity, a registration accept message including a registration result IE having an indicator indicating that network slice- specific authentication and authorization, NSSAA, is to be performed and pending network slice selection assistance information, NSSAI, determining that a previously received allowed NSSAI is invalid based on the registration accept message, and initiating a service request message in case the UE in idle mode obtains an indication that an access stratum connection between the UE and the network is established, or in case the UE in connected mode obtains a fallback indication and the UE has a pending procedure.
11. The UE according to claim 10, adapted to operate according to one of claims 2 to 5.
12. A network entity, the network entity comprising: a transceiver; and at least one processor configured to control the transceiver to: receive a registration request message from a user equipment, UE, the registration request message comprising a registration type information element, IE, indicating a periodic registration update or a mobility registration update; and send a registration accept message to the UE, wherein the registration accept message comprises a registration result IE with an indicator indicating that network slice specific authentication and authorization, NSSAA, is to be performed and a pending network slice selection assistance information, NSSAI, wherein a service request procedure is initiated in case the UE in idle mode has an access stratum connection established with the network, or in case the UE in connected mode has a pending procedure.
13. The network entity according to claim 12, adapted to operate according to one of claims 7 to 9.