Method and apparatus for network slice registration

Abstract

The present invention provides a fifth-generation (5G) or pre-5G communication system that is provided to support higher data rates than fourth-generation (4G) communication systems such as Long Term Evolution (LTE). [Solution] A first method performed by a network entity of the present invention includes the steps of: receiving a request message from a user equipment (UE) via a first access type when there is a pending network slice selection assistance information (NSSAI) including at least one second single NSSAI (S-NSSAI) for the UE; and transmitting the pending NSSAI including the at least one first S-NSSAI to the UE, wherein the at least one first S-NSSAI is different from the at least one second S-NSSAI.

Description

[Technical Field]

[0001] The present invention relates to a method, an apparatus, and a system for registering to a network slice. More particularly, the present invention relates to a method, an apparatus, and a system for registering to an additional network slice during network slice-specific authentication and authorization in 3GPP 5G. Furthermore, the present invention relates to a method, an apparatus, and a system for conditionally performing NSSAA. [Background technology]

[0002] Here we refer to the following document: [1] 3GPP (registered trademark) TS23.501V16.5.0 [2] 3GPP (registered trademark) TS23.502V16.5.0 [3] 3GPP (registered trademark) TS24.501V16.5.0

[0003] Since the commercialization of 4G communication systems, efforts have been made to develop improved 5G or pre-5G communication systems to meet the increasing demand for wireless data traffic. Therefore, 5G or pre-5G communication systems are also called "Beyond 4G Networks" or "Post-LTE Systems." To achieve higher data rates, 5G communication systems are being considered for implementation in ultra-high frequency (mmWave) bands, such as the 60 GHz band. To reduce radio wave propagation loss and extend transmission distances, technologies such as beamforming, massive multiple-input multiple-output (MIMO), full-dimensional MIMO (FD-MIMO), array antennas, analog beamforming, and large-scale antennas are being discussed for 5G communication systems. In addition, in the 5G communication system, developments to improve the system network are progressing based on advanced small cells, cloud Radio Access Networks (cloud RAN), ultra-dense networks, device-to-device (D2D) communications, wireless backhaul, moving networks, cooperative communications, CoMP (Coordinated Multi-Points), and receiver-side interference cancellation.For 5G systems, advanced coding modulation (ACM) methods such as FQAM (Hybrid FSK and QAM Modulation) and SWSC (Sliding Window Superposition Coding) and advanced access technologies such as FBMC (Filter Bank Multi Carrier), NOMA (non-orthogonal multiple access), and SCMA (sparse code multiple access) are being developed.

[0004] The Internet is evolving from a human-centered connected network where humans generate and consume information to an IoT (Internet of Things) network where distributed entities such as things exchange and process information. IoE (Internet of Everything) technology, which combines IoT technology with big data processing technology through connections to cloud servers, is also emerging. To realize the IoT, technological elements such as sensing technology, wired and wireless communication and network infrastructure, service interface technology, and security technology are required. Recent research has focused on sensor networks, M2M (Machine-to-Machine) communication, and MTC (Machine-Type Communication). In such an IoT environment, intelligent IT (Internet of Things) services can be provided that create new value in human life by collecting and analyzing data generated between connected things. Through the integration and combination of existing IT (Information Technology) technologies and various industrial applications, the IoT has the potential to be applied in a variety of fields, including smart homes, smart buildings, smart cities, smart cars, connected cars, smart grids, healthcare, smart appliances, and advanced medical services.

[0005] Accordingly, various attempts are being made to apply 5G communication systems to IoT networks. For example, technologies such as sensor networks, M2M (Machine to Machine) communication, and MTC (Machine Type Communication) are being implemented using techniques such as beamforming, MIMO, and array antennas. The application of cloud radio access networks (cloud RAN), the aforementioned big data processing technology, is also considered an example of the fusion of 5G and IoT technologies.

[0006] 3GPP (registered trademark) 5GS (3rd Generation Partnership Project 5 th The Network Generation System (NNS) is defined as follows (e.g., in [1]): A network slice (NS) is defined as a logical network that provides specific network functions and network characteristics. A network slice instance (NSI) is defined as a set of network function instances and the required resources (e.g., compute, storage, and networking resources) that form a deployed NS. A network function (NF) is defined as a 3GPP-adopted or 3GPP-defined processing function in a network with defined functional operations and 3GPP-defined interfaces.

[0007] The NS is identified by a single network slice selection assistance information (S-NSSAI).

[0008] <Outline of network slice-specific authentication and authorization>

[0009] Network slice-specific authentication and authorization (NSSAA) was introduced as part of 3GPP Rel-16. With this feature, the network performs slice-specific authentication and authorization for a set of Single Network Slice Selection Assistance Information (NSSAI) (S-NSSAI) for a user to access these slices. This procedure is performed after the 5G mobility management (5GMM) authentication procedure and the registration procedure are completed. A high-level description of the above features can be found in [1]. Further details can be found in [2] and [3]. Key points regarding the NSSAA procedure are summarized in this section.

[0010] The NSSAA applies to both 3GPP® and non-3GPP® accesses and is, in fact, access agnostic. That is, if a slice is successfully authorized, it is considered authorized for both access types (i.e., 3GPP® and non-3GPP® access types). The term "authorized" means that slice-specific authentication / authorization was successful for a particular S-NSSAI. However, this does not mean that the S-NSSAI will be used in the user equipment's (UE's) current tracking area (TA) over 3GPP® access.

[0011] If a set of slices, each identified by an S-NSSAI, is subject to NSSAA during the registration procedure, the AMF sends the pending NSSAIs to the UE in a Registration Accept message indicating those S-NSSAIs for which NSSAA is performed (or for which NSSAA is required).

[0012] The access and mobility management function (AMF) does not send the allowed NSSAA in the registration accept message to the UE because it needs to perform NSSAA. In this case, the AMF sets the "NSSAA to be performed" indicator in the 5GS Registration Result IE set to "Network slice-specific authentication and authorization is to be performed" in addition to sending the pending NSSAI to the UE.

[0013] For example, there may be cases where the UE does not need to perform NSSAA again and uses some slices because the slices do not require NSSAA or the slices were already subject to NSSAA. In this case, the AMF sends the allowed NSSAIs in the registration accept, and the allowed NSSAIs include these S-NSSAIs that do not require NSSAA. However, there are other slices that require NSSAA for which the AMF sends pending NSSAIs in the registration accept message, and the pending NSSAIs include S-NSSAIs that require NSSAA.

[0014] There is a requirement that prohibits the UE from sending a requested NSSAI together with any S-NSSAI that is part of a pending NSSAI.

[0015] It should be noted that starting from Rel-15 (i.e. before the introduction of NSSAA), a UE initiates the registration procedure as specified in TS 24.501 when it needs to change the slice to which it is currently registered. In fact, this is explicitly captured in section 5.5.1.3.2 of [3] as a trigger for the UE to send a registration request.

[0016] i) when the UE needs to change the slice(s) it is currently registered to

[0017] Therefore, if a UE needs to change the slice it is currently registered on, it sends a registration request and includes the requested NSSAI IE in the message.

[0018] It should be noted that the current operation of the Access and Mobility Management Function (AMF) considers the last received Requested NSSAI as the set of S-NSSAIs that the user equipment (UE) wants to use. For example, if the UE sends a registration request with the Requested NSSAIs at time T1, the AMF considers the Requested NSSAI entries sent by the UE at T1 to be the latest set of S-NSSAIs that the UE wants to use. If the UE then sends a registration request with the Requested NSSAIs at time T2, the AMF considers the Requested NSSAI entries sent by the UE at T2 to be the latest set of S-NSSAIs that the UE wants to use.

[0019] Although the requested NSSAI sent at time T2 may contain some entries from the NSSAI requested at time T1, it is important to note that the AMF considers the last received requested NSSAI (i.e., in this example, at time T2) to contain the S-NSSAI that the UE should use, and therefore considers any NSSAI previously requested by the UE at, for example, time T1, to be valid.

[0020] As mentioned above, the following example is useful:

[0021] At time T1, the UE sends the requested NSSAI={A, B} for the S-NSSAI{A, B}.

[0022] At time T2, the UE needs to register with the new set of slices. If the UE still needs to use S-NSSAI B, the UE needs to ensure that the new requested NSSAI contains entry B. So, for example, if the UE needs to use S-NSSAI{B, C}, the UE must send the requested NSSAI set to {B, C}.

[0023] When the AMF receives the requested NSSAI {B, C}, the AMF considers that the previously requested NSSAI {A, B}, which may have a corresponding allowed NSSAI {A, B}, is no longer needed by the UE, and the AMF processes the requested NSSAI {B, C} to determine whether it is allowed. It should be noted that the previously allowed NSSAI based on {A, B} is no longer valid from this point onwards due to the new requested NSSAI including {B, C}.

[0024] <Allow use of specific slices based on registered area>

[0025] Prior to NSSAA, network slicing uses the permitted NSSAI to indicate the S-NSSAI that is allowed to be used by the UE in the current registration area (RA) (and for the current serving public land mobile network (PLMN)).

[0026] However, some slices may not be available or permitted in the UE's current RA. However, this does not mean that the slices are completely disallowed in the current serving PLMN. Thus, a slice may be unavailable or disallowed in an RA, e.g., Area 1, but the slice may be available or permitted in another RA, e.g., Area 2, of the same serving PLMN.

[0027] If the S-NSSAI in the requested NSSAI is not allowed for the UE in the current RA, the AMF shall include the S-NSSAI in the rejected NSSAI and set the associated cause to "S-NSSAI not available in the current registration area". This means that the UE can use the same slice when it enters a different RA.

[0028] On the other hand, if the S-NSSAI requested by the UE is not allowed to be used across the PLMN regardless of the RA, the AMF includes the S-NSSAI in the rejected NSSAI and sets the associated cause to "S-NSSAI not available in the current PLMN or SNPN", which means that the UE cannot use the slice in the current PLMN regardless of the RA.

[0029] It should be noted that NSSAA is provided as an addition to network slicing, where the network must further check whether the slice is subject to NSSAA, and if so, the network implements NSSAA. Summary of the Invention [Problem to be solved by the invention]

[0030] The present invention has been made in view of the above-mentioned prior art, and an object of the present invention is to provide a method performed by a network entity, a method performed by a user equipment (UE), a user equipment (UE), and a network entity. [Means for solving the problem]

[0031] A method by a network entity according to an embodiment of the present invention includes receiving, while there is a pending network slice selection assistance information (NSSAI) for the UE, a request from the UE indicating at least one first single NSSAI (S-NSSAI) via a first access technology; and, if the pending NSSAI includes an indication of one or more S-NSSAIs via the first access technology indicated in a previous request received from the UE, determining that the request is for using at least one new network slice and removing the indication of one or more S-NSSAIs from the pending NSSAI, wherein the at least one first S-NSSAI is different from any S-NSSAI indicated in the pending NSSAI.

[0032] In one embodiment of the present invention, the method further includes determining whether one or more of the at least one first S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA), and if so, adding an indication of one or more of the at least one first S-NSSAI to the pending NSSAI. In one embodiment of the present invention, the method further includes transmitting the pending NSSAI to the UE, the pending NSSAI including an indication of one or more of the at least one first S-NSSAI, or transmitting an additional pending NSSAI to the UE, the additional pending NSSAI including an indication of one or more of the at least one first S-NSSAI. In one embodiment of the present invention, the pending NSSAI includes an indication of at least one second S-NSSAI indicated in a previous request received from the UE via a second access technology different from the first access technology. In one embodiment of the present invention, the method further comprises maintaining an indication of the at least one second S-NSSAI in the pending NSSAI. In one embodiment of the present invention, the method further includes one or more of the following steps: transmitting an allowed NSSAI to the UE, the allowed NSSAI including information regarding an S-NSSAI previously allowed for the UE and information regarding one or more of the at least one first S-NSSAI determined to be allowed for the UE, or transmitting an additional allowed NSSAI to the UE, the additional allowed NSSAI including information regarding one or more of the at least one first S-NSSAI determined to be allowed for the UE; and, if it is determined that one or more of the at least one first S-NSSAI are not allowed for the UE or are not available in a current registration area (RA) of the UE, transmitting a rejected NSSAI to the UE, the rejected NSSAI including an indication of one or more of the at least one first S-NSSAI that are not allowed for the UE or are not available in a current RA of the UE. In one embodiment of the present invention, for each S-NSSAI indicated in the pending NSSAI, the network entity stores a record of the access technology for which the S-NSSAI is requested to be used.

[0033] A UE method according to an embodiment of the present invention includes, while there is a pending network slice selection assistance information (NSSAI) for a user equipment (UE), sending a request to a network entity indicating at least one first single NSSAI (S-NSSAI) via a first access technology, wherein if the pending NSSAI includes an indication of one or more S-NSSAIs via the first access technology indicated in a previous request sent by the UE, the request is a request to use at least one new network slice, and the at least one first S-NSSAI is different from any S-NSSAI indicated in the pending NSSAI.

[0034] In one embodiment of the invention, the method further comprises receiving a response to the request from the network entity. In one embodiment of the present invention, if the request is a request to use the at least one new network slice, the method further includes a step of removing an indication of the one or more S-NSSAIs from the pending NSSAI based on the response. In one embodiment of the present invention, the method further includes modifying the pending NSSAI based on the received response to include an indication of one or more of the at least one first S-NSSAI being subject to network slice-specific authentication and authorization (NSSAA). In one embodiment of the present invention, the received response includes a pending NSSAI that includes an indication of one or more of the at least one first S-NSSAI that is subject to the NSSAA, or the received response includes an additional pending NSSAI that includes an indication of one or more of the at least one first S-NSSAI that is subject to the NSSAA. In one embodiment of the present invention, the method further comprises maintaining an indication of any of at least one second S-NSSAI for which an NSSAA has not been completed in the pending NSSAI in response to the received response. In one embodiment of the present invention, the response includes at least one of an allowed NSSAI including information regarding an S-NSSAI previously allowed for the UE and information regarding one or more of the at least one first S-NSSAI allowed for the UE, or an additional allowed NSSAI including information regarding one or more of the at least one first S-NSSAI allowed for the UE, and a rejected NSSAI including an indication of one or more of the at least one first S-NSSAI that are not allowed for the UE or are unavailable in the UE's current registration area. In one embodiment of the present invention, the pending NSSAI includes an indication of at least one second S-NSSAI via a second access technology different from the first access technology indicated in the previous request sent from the UE to the network entity.

[0035] According to another embodiment of the present invention, a method by a network entity includes receiving, while there is a pending network slice selection assistance information (NSSAI) for a user equipment (UE), a request indicating at least one single NSSAI (S-NSSAI) from the UE, and determining whether the request is for using at least one additional network slice.

[0036] In one embodiment of the present invention, if the request includes a requested NSSAI, it is determined that the request is for using at least one additional network slice, and the request includes an additional requested NSSAI or the network entity receives an indication from the UE that the request is for using at least one additional network slice. In one embodiment of the present invention, the request is for using at least one network slice corresponding to the S-NSSAI indicated in the pending NSSAI via the same or a different access technology. In one embodiment of the present invention, the at least one S-NSSAI is different from any S-NSSAI indicated in the pending NSSAI. In one embodiment of the present invention, the method includes determining whether one or more of the at least one S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA), and if so, adding an indication of one or more of the at least one S-NSSAI to the pending NSSAI. In one embodiment of the present invention, the method includes transmitting the pending NSSAI to the UE, the pending NSSAI including an indication of one or more of the at least one S-NSSAI, or transmitting an additional pending NSSAI to the UE, the pending NSSAI including an indication of one or more of the at least one S-NSSAI. In one embodiment of the present invention, the method further includes one or more of the following steps: sending an allowed NSSAI to the UE, the allowed NSSAI including information regarding an S-NSSAI previously allowed for the UE and information regarding one or more of the at least one S-NSSAI determined to be allowed for the UE, or sending an additional allowed NSSAI to the UE, the additional allowed NSSAI including information regarding one or more of the at least one S-NSSAI determined to be allowed for the UE; and, if it is determined that one or more of the at least one S-NSSAI are not allowed for the UE or are not available in the UE's current registration area (RA), sending a rejected NSSAI to the UE, the rejected NSSAI including an indication of one or more of the at least one S-NSSAI that are not allowed for the UE or are not available in the UE's current RA. In one embodiment of the present invention, if the request is for using at least one additional network slice, the method further includes processing the request without removing an indication of an S-NSSAI from the pending NSSAI.

[0037] A method for a UE according to another embodiment of the present invention includes, while there is a pending network slice selection assistance information (NSSAI) for a user equipment (UE), transmitting a first request to a network entity to use at least one additional network slice, indicating at least one single NSSAI (S-NSSAI), or, while there is a pending NSSAI for the UE, transmitting a second request to the network entity to use at least one network slice corresponding to the S-NSSAI indicated in the pending NSSAI via the same or a different access technology.

[0038] In one embodiment of the present invention, the use of the at least one additional network slice is required in addition to the use of one or more network slices corresponding to one or more S-NSSAIs indicated in the pending NSSAI. In one embodiment of the present invention, the first request is at least one of a requested NSSAI or an additional requested NSSAI, and the UE sending an indication to the network entity that the first request is for using at least one additional network slice. In one embodiment of the present invention, the method further comprises receiving a response to the first request from the network entity. In one embodiment of the present invention, the method further includes modifying the pending NSSAI based on the received response to include an indication of one or more of the at least one first S-NSSAI that is subject to network slice specific authentication and authorization (NSSAA). In one embodiment of the present invention, the received response includes a pending NSSAI that includes an indication of one or more of the at least one first S-NSSAI that is subject to an NSSAA, or the received response includes an additional pending NSSAI that includes an indication of one or more of the at least one first S-NSSAI that is subject to an NSSAA. In one embodiment of the present invention, the method further includes maintaining an indication of any S-NSSAI corresponding to a previously requested network slice for which the NSSAI has not been completed in the pending NSSAI in response to the received response. In one embodiment of the present invention, the response includes at least one of an allowed NSSAI including information regarding an S-NSSAI previously allowed for the UE and information regarding one or more of the at least one S-NSSAI allowed for the UE, or an additional allowed NSSAI including information regarding one or more of the at least one S-NSSAI allowed for the UE, and a rejected NSSAI including an indication of one or more of the at least one S-NSSAI that are not allowed for the UE or are unavailable in the UE's current registration area.

[0039] According to yet another embodiment of the present invention, a method by a network entity includes determining whether a single network slice selection assistance information (S-NSSAI) is available or authorized for a user equipment (UE) based on a registration area (RA) of the UE, and if not, including the S-NSSAI in a rejected NSSAI without performing network slice-specific authentication and authorization (NSSAA) of the S-NSSAI, or performing NSSAA of the S-NSSAI and determining whether the S-NSSAI is available or authorized for the UE based on the RA of the UE after performing the NSSAA, and if not, including the S-NSSAI in the rejected NSSAI.

[0040] In one embodiment of the present invention, the S-NSSAI is indicated in a request for use of a network slice received from the UE, or the S-NSSAI is marked as default in the UE's subscription. In one embodiment of the present invention, if the S-NSSAI is not available in the RA via a particular access technology, it is determined that the S-NSSAI is not available or not allowed for the UE. In one embodiment of the present invention, the method further comprises setting an indication that the reason for the rejection is based on the RA. In one embodiment of the present invention, the method further comprises sending the rejected NSSAI and the indication to a UE.

[0041] According to one embodiment of the present invention, there is provided a network entity or UE configured to operate according to one or more of the above methods.

[0042] According to an embodiment of the present invention, there is provided a network including a network entity and / or a UE according to the preceding paragraph.

[0043] According to one embodiment of the present invention, there is provided a computer program comprising instructions which, when said program is executed by a computer or processor, cause said computer or processor to perform one or more of the methods described above.

[0044] According to one embodiment of the present invention, there is provided a computer or processor readable data carrier having stored thereon a computer program according to the preceding paragraph.

[0045] In order to achieve the above object, according to one aspect of the present invention, a method performed by a network entity includes: receiving, from a user equipment (UE) via a first access type, a request message including a requested NSSAI including at least one first NSSAI (S-NSSAI) when there is a pending NSSAI including at least one second single NSSAI (S-NSSAI) for the UE; and transmitting the pending NSSAI including the at least one first S-NSSAI to the UE, wherein the at least one first S-NSSAI is different from the at least one second S-NSSAI.

[0046] In one embodiment of the present invention, the method further includes, when the pending NSSAI includes the at least one second S-NSSAI requested in a previous request message received from the UE, determining whether the at least one first S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA), and, if the at least one first S-NSSAI is subject to NSSAA, adding the at least one first S-NSSAI to the pending NSSAI. In one embodiment of the present invention, the method further includes determining whether the request message is for using at least one new network slice. In one embodiment of the present invention, for each S-NSSAI in the pending NSSAIs, the network entity stores a record of a first access type for which use of the S-NSSAI is requested.

[0047] In order to achieve the above object, according to one aspect of the present invention, a method performed by a user equipment (UE) includes: when there is pending network slice selection assistance information (NSSAI) including at least one second single NSSAI (S-NSSAI) for the user equipment (UE), sending a request message to a network entity via a first access type, the request message including a requested NSSAI including at least one first S-NSSAI; and receiving the pending NSSAI including the at least one first S-NSSAI from the network entity, wherein the at least one first S-NSSAI is different from the at least one second S-NSSAI.

[0048] In one embodiment of the present invention, if the pending NSSAI includes the at least one second S-NSSAI requested in a previous request sent by the UE, and the at least one first S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA), the at least one first S-NSSAI is added to the pending NSSAI.

[0049] To achieve the above object, a method performed by a network entity according to another aspect of the present invention includes: receiving, when pending network slice selection assistance information (NSSAI) exists for a user equipment (UE), a request message including a requested NSSAI including at least one single NSSAI (S-NSSAI) from the UE; and determining whether the request message is for using at least one additional network slice.

[0050] In one embodiment of the present invention, if the request message includes a requested NSSAI, if the request message includes an additional requested NSSAI, or if the network entity receives an indication from the UE that the request message is for using at least one additional network slice, the request message is for using at least one additional network slice, and the request message is for using at least one network slice corresponding to an S-NSSAI in the pending NSSAI via the same or a different access type. In one embodiment of the present invention, the method further includes determining whether the at least one S-NSSAI is subject to Network Slice Specific Authentication and Authorization (NSSAA), and if the at least one S-NSSAI is subject to NSSAA, adding the at least one S-NSSAI to the pending NSSAI. In one embodiment of the present invention, the method further comprises transmitting the pending NSSAI including the at least one S-NSSAI to the UE. In one embodiment of the present invention, if the request message is for using at least one additional network slice, the method further includes processing the request message without removing an S-NSSAI from the pending NSSAI.

[0051] To achieve the above object, a method performed by a user equipment (UE) according to another aspect of the present invention includes, when pending network slice selection assistance information (NSSAI) exists for the UE, sending a first request message to a network entity for using at least one additional network slice, the first request message including at least one single NSSAI (S-NSSAI), wherein use of the at least one additional network slice is requested in addition to use of one or more network slices corresponding to the at least one S-NSSAI in the pending NSSAI.

[0052] In one embodiment of the present invention, the first request message includes a requested NSSAI or an additional requested NSSAI, and the UE sends an indication to the network entity that the first request message is for using at least one additional network slice.

[0053] Various aspects, advantages, and salient features will become apparent to those skilled in the art from the following detailed description, taken in conjunction with the drawings, which disclose embodiments of the invention. [Brief explanation of the drawings]

[0054] [Figure 1] FIG. 2 illustrates an example of the structure of a network entity according to an embodiment of the present invention. [Figure 2] FIG. 2 illustrates an example of the structure of a UE according to an embodiment of the present invention. [Figure 3] FIG. 2 illustrates a method of a network entity according to one embodiment of the present invention. [Figure 4] FIG. 1 illustrates a method for a UE according to an embodiment of the present invention. [Figure 5] FIG. 10 illustrates a method of a network entity according to another embodiment of the present invention. [Figure 6] FIG. 10 illustrates a method for a UE according to another embodiment of the present invention. [Figure 7] FIG. 10 illustrates a method of a network entity according to yet another embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0055] Specific examples of embodiments of the present invention will be described in detail below with reference to the drawings. The following detailed description is provided to facilitate a comprehensive understanding of the present invention as defined by the claims. Although the detailed description includes various specific details to facilitate understanding, these details should be considered as merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of the present invention.

[0056] The same or similar components may be shown in different drawings but are designated by the same or similar reference numerals.

[0057] Detailed descriptions of techniques, structures, configurations, functions, or processes known in the art will be omitted for clarity and conciseness, and to avoid obscuring the gist of the present invention.

[0058] The terms and words used in this specification are not limited to their bibliographical or standard meanings, but are merely used to enable a clear and consistent understanding of the invention.

[0059] As used herein, the words "comprise," "include," and "contain," and variations of words such as "comprising" and "comprises," mean "including but not limited to" and are not intended to exclude (or exclude) other features, elements, components, integers, steps, processes, operations, functions, characteristics, attributes, and / or groups thereof.

[0060] As used herein, singular forms such as "a," "an," and "the" include plural forms unless the context otherwise requires. For example, a reference to an "object" includes a reference to one or more of such objects.

[0061] As used herein, language of the general form "X for Y" (where Y is any action, process, operation, function, activity, or step, and X is any means for performing that action, process, operation, function, activity, or step) includes, but is not necessarily exclusive of, means for which X is particularly adapted, configured, or arranged to perform Y.

[0062] It is to be understood that any feature, element, component, integer, step, process, operation, function, characteristic, attribute, and / or group thereof described or disclosed in connection with one aspect, embodiment, example, or claim of the invention may be applied to any other aspect, embodiment, example, or claim described herein, unless separately incompatible therewith.

[0063] Embodiments of the present invention provide methods, apparatus, and systems for performing authentication and authorization in a network. The following embodiments are applicable to 3GPP® 5G and use terminology related to 3GPP® 5G. For example, embodiments of the present invention provide methods, apparatus, and systems for performing NSSAA in 3GPP® 5G. However, those skilled in the art will understand that the techniques disclosed herein are not limited to these embodiments or to 3GPP® 5G, but may be applied to any suitable system or standard, such as one or more existing and / or next-generation wireless communication systems or standards.

[0064] For example, the functionality and other features of various network entities disclosed herein may be applied to corresponding or equivalent entities or features in other communication systems or standards. Corresponding or equivalent entities or features may be considered to be entities or functions that perform the same or similar role, function, operation, or purpose within a network. For example, in the following embodiments, the functionality of the AMF may be applied to any other suitable type of entity that performs access and mobility management functions, and the functionality of the SMF in the following embodiments may be applied to any other suitable type of entity that performs session management functions.

[0065] Those skilled in the art will appreciate that the present invention is not limited to the specific embodiments disclosed herein.

[0066] The technology disclosed in this specification is not limited to 3GPP 5G.

[0067] In the embodiments disclosed herein, one or more entities may be replaced by one or more alternative entities that perform equivalent or corresponding functions, processes, or operations.

[0068] In the embodiments disclosed herein, one or more messages may be replaced with one or more alternative messages, signals, or other types of information carriers that communicate equivalent or corresponding information.

[0069] One or more additional elements, entities, and / or messages are added to the embodiments disclosed herein.

[0070] In one embodiment, one or more non-essential elements, entities, and / or messages may be omitted.

[0071] A function, process, or operation of a particular entity in one embodiment is split into two or more separate entities in other embodiments.

[0072] A function, process, or operation of two or more separate entities in one embodiment is performed by a single entity in another embodiment.

[0073] Information conveyed by a particular message in one embodiment is conveyed by two or more separate messages in other embodiments.

[0074] Information conveyed by two or more separate messages in one embodiment is conveyed by a single message in another embodiment.

[0075] The order in which the operations are performed may be varied in other embodiments where possible.

[0076] The transmission of information between network entities is not limited to the particular formats, types, and / or sequences of messages described in connection with the embodiments disclosed herein.

[0077] Embodiments of the present invention are provided in the form of an apparatus / device / network entity configured to perform one or more defined network functions and / or methods therefor. Embodiments of the present invention are provided in the form of a system (e.g., a network) including one or more such apparatus / device / network entities and / or methods therefor. For example, in the following embodiments, the network includes a UE, an AMF, and an SMF.

[0078] Considering the related art, at least the following problems exist.

[0079] 1. Problem: Registering to a slice when NSSAA is ongoing

[0080] The following scenarios may occur:

[0081] Step 1: The UE sends a requested NSSAI in a Registration Request message.

[0082] o For simplicity, assume this requested NSSAI contains the entries {A, B}.

[0083] Step 2: The UE receives the pending NSSAI in a Registration Accept message.

[0084] o For simplicity, assume that this pending NSSAI contains {B}, reflecting that an NSSAA must be performed for slice B.

[0085] Step 3: The UE also receives the granted NSSAI in the registration accept message.

[0086] oFor simplicity, let's assume this contains {A}.

[0087] Step 4: The UE needs to register for additional slices, i.e. the UE needs to use more slices in addition to those requested in step 1.

[0088] o For simplicity, assume the UE needs to use {A, B, C}.

[0089] If the pending NSSAIs include at least one S-NSSAI requested by the UE in step 1 (in the requested NSSAI), then the UE cannot send the requested NSSAI containing entry {B} because S-NSSAI B is in the pending NSSAI list, according to the requirements above.

[0090] Therefore, when the UE sends the requested NSSAI {A, C}, the AMF checks the new requested NSSAI {A, C} and considers the last requested NSSAI (i.e., {A, B}) invalid. The AMF then concludes that the UE currently wants to use only slice {A, C} and does not want to use slice {B}. This causes the AMF to remove the S-NSSAI for slice B from the pending NSSAIs.

[0091] In the above embodiment, it can be seen that due to the specific requirement that the requested NSSAI cannot include the S-NSSAI in the pending NSSAI, there may be cases where the UE cannot inform the AMF about the actual slices that the UE needs to use, and the AMF may make an incorrect decision about the slices that the UE actually wants to use.

[0092] <2. Problem: NSSAA slice not available in UE's registration area>

[0093] As indicated previously, the slice must be made available to the UE at least in the UE's Registration Area (RA). If available, and if the slice is subject to NSSAA, the network will perform NSSAA for the S-NSSAI in question.

[0094] As mentioned above, the current specification does not require the UE RA to check the availability of a slice before checking whether NSSAA needs to be performed. That is, the AMF directly checks whether the S-NSSAI in the requested NSSAA is subject to NSSAA, and if so, the AMF performs NSSAA. If this occurs, a situation may arise in which signaling is unnecessarily used to perform NSSAA for an S-NSSAI that is not actually available to the UE. This also results in unnecessary use of computational resources.

[0095] If the network is configured so that the availability of slices is not verified first in the UE RA, the AMF must perform this verification after the execution of the NSSAA. The AMF can then allow or indicate that slices are not allowed for the combination of PLMN and registration area. This component does not exist in the current specification.

[0096] To further clarify the issue, the following text from [3] can be used (see: 5.5.1.2.4; 5.5.1.3.4):

[0097] If the UE indicates support for network slice-specific authentication and authorization and the requested NSSAIIE contains one or more S-NSSAIs that are subject to network slice-specific authentication and authorization, the AMF shall include the following in the REGISTRATION ACCEPT message:

[0098] a) The S-NSSAI or the permitted NSSAI that contains the mapped S-NSSAI, if any.

[0099] 1) Not subject to network slice-specific authentication and authorization, but permitted by the AMF, or

[0100] 2) Network slice-specific authentication and authorization have been successfully performed;

[0101] b) Rejected NSSAIs of failed or cancelled NSSAAs, where appropriate;

[0102] c) Pending NSSAIs (if any) including one or more S-NSSAIs for which network slice-specific authentication and authorization has been performed or is in progress, and

[0103] d) If an authorized NSSAI is not included in the REGISTRATION ACCEPT message, an "NSSAA to be performed" indicator in the 5GS Registration Result IE is configured to indicate whether network slice-specific authentication and authorization procedures are performed by the network.

[0104] From bullet point a1), we can see that the AMF verifies whether the S-NSSAI is "allowed by the AMF or not." Here, it should be noted that the AMF takes into account the RA of the UE, since the concept of allowed NSSAI is per RA of the UE (i.e., the entry of allowed NSSAI is only valid for the current RA).

[0105] However, from bullet point c), we can see that the AMF only verifies if NSSAA is required. Therefore, it is possible that NSSAA is always required for S-NSSAI, but this does not mean that S-NSSAI can be used in the current RA, even if NSSAA is successful in this slice. Therefore, the AMF behavior needs to be updated to consider the case where S-NSSAI requires NSSAA, but S-NSSAI is not allowed in the current RA.

[0106] <1. Solution to allow registration to slices when NSSAA is in progress>

[0107] As explained above, problems can arise if the UE needs to register on an additional slice, i.e., in addition to the slice on which it has a pending NSSAA.

[0108] 1a. Use of new information elements (IEs) to register for additional slices

[0109] The first solution disclosed here is to use a new IE to solve the problem, which can be defined to indicate that the UE wants to register or use at least one S-NSSAI in addition to the S-NSSAI that the UE originally requested and that is in the pending NSSAI.

[0110] The new IE can be named anything, but in this description, we will refer to this IE as the Additional requested NSSAI IE (or additional requested NSSAI for short).

[0111] Although two options for this first solution are disclosed, it will be understood that embodiments of the present invention are not limited to these.

[0112] Option 1

[0113] If the UE needs to register to a set of slices where any of these slices have a corresponding S-NSSAI in the UE's pending NSSAI, the UE sends a Registration Request and includes an Additional Requested NSSAI IE (Additional Requested NSSAI). The UE must set the contents of the Additional Requested NSSAI IE to include the set of S-NSSAIs that the UE needs to register (or use) in addition to the set of S-NSSAIs in the pending NSSAI. However, the Additional Requested NSSAI does not include an S-NSSAI from the pending NSSAI.

[0114] It should be noted that the UE can transmit additional requested NSSAIs over a different access than the one over which it previously transmitted the requested NSSAI that resulted in at least one S-NSSAI being included in the pending NSSAI. By doing so, i.e., by transmitting the requested additional NSSAIs over a different access technology (or access type), the UE indicates that it wishes to use the S-NSSAI in the requested additional NSSAI in addition to the S-NSSAI in the pending NSSAI (and, if applicable, in addition to the S-NSSAI in the allowed NSSAI, if present). Thus, the use of the requested additional NSSAI, as described herein, applies to any access technology (or access type). Furthermore, the same UE behavior described herein applies regardless of the access technology used by the UE to transmit the additional requested NSSAI. In various embodiments, the access technology is referred to as the access type.

[0115] The content of the Additional Requested NSSAI is considered to be the set of S-NSSAIs requested in addition to any S-NSSAIs in the Allowed NSSAIs, if the UE has them (or if the AMF has them for the UE). As such, the purpose of the Additional Requested NSSAI is to indicate the slices that the UE wants to use in addition to the S-NSSAIs in the Pending NSSAI and, if present, the S-NSSAIs that the UE received in the Allowed NSSAIs. Therefore, in this option, the Additional Requested NSSAI does not contain any entries for the Allowed NSSAIs.

[0116] When the AMF receives an additional requested NSSAI, the AMF shall ensure that the total number of S-NSSAI entries in the pending NSSAI (by request from the current access technology), allowed NSSAIs (if any) and the additional requested NSSAI does not exceed a specific maximum number for the current access technology, for example 8. If it exceeds 8, the AMF shall ignore the last M entries (M is an integer) in the additional requested NSSAI so that the maximum number of S-NSSAIs that the UE requests to use does not exceed a specific maximum number, for example 8.

[0117] When the AMF receives the Additional Requested NSSAI IE (or Additional Requested NSSAI), and (optionally) there is a pending NSSAI for the UE, the AMF considers the S-NSSAI in the Additional Requested NSSAI as a new additional slice that the UE wants to use or register in addition (in addition to the S-NSSAI entries in the pending NSSAI and (optionally) in the Allowed NSSAI, if present). The AMF then needs to verify whether any S-NSSAI in the Additional Requested NSSAI is allowed for the UE (i.e., not subject to NSSA, or NSSAA is not requested, or is running successfully), and also verify whether any S-NSSAI that is subject to NSSAA and requires NSSAA exists.

[0118] It should be noted that the AMF performs the actions described herein even if the additional requested NSSAI is received via an access technology different from the one previously used to request the set of slices in which at least one of the requested S-NSSAIs is placed in a pending NSSAI. Therefore, the AMF takes the same actions described herein regardless of the access technology on which the additional requested NSSAI is received. Therefore, reception of the additional requested NSSAI means that the UE wants to use the S-NSSAI of the additional requested NSSAI and the S-NSSAI of the pending NSSAI (and optionally, the S-NSSAI of the authorized NSSAI, if any) on the access technology on which the requested NSSAI was received by the AMF. This also means that if the NSSAI is successful, the AMF (as described above) needs to transmit the authorized NSSAIs via each and every access technology on which the AMF has determined that the UE wants to use the corresponding S-NSSAI, based on the access technology on which the additional requested NSSAI is received. For example, the AMF sends the allowed NSSAI to the UE using a Configuration Update Command message, which must be sent via each access technology after being determined by the AMF, as described above.

[0119] If at least one of the S-NSSAIs in the additional requested NSSAIs is subject to NSSAA, the AMF should update the list of pending NSSAIs (or S-NSSAIs for which NSSAA is required) to also make this S-NSSAI (from the additional requested NSSAIs) subject to NSSAA. The AMF should perform NSSAA for this S-NSSAI. The AMF should also update the UE with the new list of pending NSSAIs so that the pending NSSAIs include S-NSSAIs from the additional requested NSSAIs for which NSSAA is required. The AMF should send the new list of pending NSSAIs to the UE in a Registration Accept message.

[0120] If at least one S-NSSAI in the additional requested NSSAI is allowed for the UE, the AMF also includes the allowed NSSAI in the Registration Accept message, where the allowed NSSAI is as follows:

[0121] If present, it contains all S-NSSAIs that are authorized for the UE, including all S-NSSAIs that were previously authorized for the UE. Note that if any S-NSSAI does not require an NSSAA (or an NSSAA has previously been successfully performed) and is authorized for the UE (optionally in the current registration area), the authorized NSSAIs may include S-NSSAIs from additional requested NSSAIs.

[0122] - Includes any S-NSSAI for which the NSSAA has been successfully completed (optionally from previously requested NSSAIs). It should be noted that the AMF may also optionally remove such S-NSSAI from the pending NSSAIs sent to the UE in the Registration Accept message.

[0123] If at least one S-NSSAI in the additional requested NSSAIs is not authorized for the UE or is not available in the current registration area, the AMF shall send a rejected NSSAI containing any such S-NSSAIs and a corresponding cause value indicating the reason for the rejection.

[0124] In one embodiment, the AMF may use a new Additional Allowed NSSAI IE (or Additional Allowed NSSAI) to include any S-NSSAI from the additional requested NSSAIs that are allowed for the UE. The AMF may send this IE to the UE in a registration accept message.

[0125] In one embodiment, the AMF may use a new Additional Pending NSSAI IE (or Additional Pending NSSAI) to include any S-NSSAI from the additional requested NSSAIs that are subject to (or for which) the NSSAA is performed. The AMF may send this IE to the UE in a registration accept message.

[0126] In one embodiment, the additional Allowed NSSAI IEs and / or the additional Pending NSSAI IEs may be sent to the UE in a Configuration Update Command (CUC) message.

[0127] If the UE receives an additional allowed NSSAI IE in the registration accept message (or CUC message), the UE MUST add the entry for this IE to the list of allowed NSSAIs. The UE MUST also remove any (additional) pending NSSAIs that match any S-NSSAI from the rejected NSSAIs or S-NSSAI from the additional allowed NSSAIs.

[0128] If the UE receives an Additional Pending NSSAI IE in the Registration Accept message (or CUC message), the UE MUST add an entry for this IE to the list of pending NSSAIs. The UE MUST also remove any S-NSSAIs from the Rejected NSSAIs or (additional) Allowed NSSAIs that match the S-NSSAI from the Additional Pending NSSAIs.

[0129] In one embodiment, when the UE sends additional requested NSSAIs, the UE may not send the requested NSSAIs in the same NAS message.

[0130] In one embodiment, when the AMF sends an additional allowed NSSAI, the AMF cannot send the allowed NSSAI in the same NAS message.

[0131] In one embodiment, when the AMF sends an additional pending NSSAI, the AMF cannot send the pending NSSAI in the same NAS message.

[0132] Option 2:

[0133] In contrast to option 1, here the additional requested NSSAIs MUST include any S-NSSAIs that are in the allowed NSSAIs, if they exist. Thus, if the UE needs to register to (or use) slices in addition to the previously requested ones, the UE MUST send a registration request message containing additional requested NSSAIs, where the latter includes the additional (new) S-NSSAIs that the UE wants to register to (or use) and the S-NSSAIs that are included in the allowed NSSAIs.

[0134] When the AMF receives an additional requested NSSAI, the AMF shall ensure that the total number of S-NSSAI entries in the pending NSSAI (due to request from the current access technology) and the additional requested NSSAI does not exceed a specific maximum number for the current access technology, for example 8. If it exceeds 8, the AMF shall ignore the last M entries (M is an integer) in the additional requested NSSAI so that the maximum number of S-NSSAIs that the UE requests to use does not exceed a specific maximum number, for example 8.

[0135] It should be noted that the UE may transmit additional requested NSSAIs over a different access than the one over which it previously transmitted the requested NSSAI that resulted in at least one S-NSSAI being included in the pending NSSAI. By doing so, i.e., by transmitting the requested additional NSSAIs over a different access technology, the UE indicates that it wishes to use the S-NSSAIs in the requested additional NSSAIs in addition to the S-NSSAIs in the pending NSSAI. Thus, the use of the requested additional NSSAIs applies to any access technology described herein. Furthermore, the same UE behavior described herein applies regardless of the access technology used by the UE to transmit the additional requested NSSAIs.

[0136] When the AMF receives an additional requested NSSAI, and (optionally) if there is a pending NSSAI for the UE, the AMF verifies whether there are any S-NSSAIs that are allowed for the UE (i.e., whether they are not subject to an NSSAA or whether an NSSAA is not required or is running normally), and whether any S-NSSAIs are subject to an NSSAA and require an NSSAA.

[0137] It should be noted that the AMF performs the actions described herein even if the additional requested NSSAI is received via an access technology different from the one previously used to request the set of slices in which at least one of the requested S-NSSAIs is placed in the pending NSSAI. Therefore, the AMF takes the same actions described herein regardless of the access technology on which the additional requested NSSAI is received. Therefore, reception of the additional requested NSSAI means that the UE wants to use the S-NSSAI in the additional requested NSSAI and the S-NSSAI in the pending NSSAI on the access technology on which the requested NSSAI was received by the AMF. This also means that if the NSSAI is successful, the AMF (as described above) needs to transmit the allowed NSSAIs via each and every access technology for which the AMF has determined that the UE wants to use the corresponding S-NSSAI, based on the access technology on which the additional requested NSSAI is received. For example, the AMF can transmit the allowed NSSAIs to the UE using a Configuration Update Command message, which needs to be transmitted via each access technology after the determination by the AMF, as described above.

[0138] If at least one S-NSSAI among the additional requested NSSAIs is subject to NSSAA, the AMF MUST update the list of pending NSSAIs (or S-NSSAIs that require NSSAA), and therefore this S-NSSAI (from the additional requested NSSAIs) is also subject to NSSAA. The AMF MUST perform NSSAA for this S-NSSAI. The AMF MUST also update the UE with the new list of pending NSSAIs so that the pending NSSAIs include any S-NSSAIs from the additional requested NSSAIs that require NSSAA. The AMF MUST send the new list of pending NSSAIs to the UE in the Registration Accept message.

[0139] If at least one S-NSSAI in the additional requested NSSAI is allowed for the UE, the AMF also includes the allowed NSSAI in the registration accept message, where the allowed NSSAI is as follows:

[0140] -If present, it contains all S-NSSAIs authorized for the UE, including all S-NSSAIs previously authorized for the UE. Note that the authorized NSSAIs may include S-NSSAIs from additional requested NSSAIs if any S-NSSAIs are authorized for the UE (optionally in the current registration area) without requiring NSSAA (or NSSAA has previously been successfully performed).

[0141] -Includes any S-NSSAI for which the NSSAA has been successfully completed. Note that the AMF may also optionally remove such S-NSSAI from the pending NSSAIs sent to the UE in the registration accept message.

[0142] If at least one S-NSSAI in the additional requested NSSAIs is not authorized for the UE or is not available in the current registration area, the AMF shall send a rejected NSSAI containing any such S-NSSAIs and a corresponding cause value indicating the reason for the rejection.

[0143] In one embodiment, the AMF may use a new Additional Allowed NSSAI IE (or Additional Allowed NSSAI) to include any S-NSSAI from the additional requested NSSAIs that are allowed for the UE. The AMF may send this IE to the UE in a registration accept message.

[0144] In one embodiment, the AMF may use a new Additional Pending NSSAI IE (or Additional Pending NSSAI) to include any S-NSSAI from the additional requested NSSAI that is the subject of (or for which) the NSSAA is performed. The AMF may send this IE to the UE in a registration accept message.

[0145] In one embodiment, the additional allowed NSSAI IEs and / or the additional pending NSSAI IEs may be sent to the UE in a Configuration Update Command (CUC) message.

[0146] If the UE receives an additional allowed NSSAI IE in the registration accept message (or CUC message), the UE MUST add the entry for this IE to the list of allowed NSSAIs, and MUST remove any S-NSSAI from the rejected NSSAIs or (additional) pending NSSAIs that match the S-NSSAI from the additional allowed NSSAIs.

[0147] If the UE receives an Additional Pending NSSAI IE in the Registration Accept message (or CUC message), the UE MUST add an entry for this IE to the list of pending NSSAIs, and MUST remove any S-NSSAI from the Rejected NSSAIs or (additional) Allowed NSSAIs that match the S-NSSAI from the Additional Pending NSSAIs.

[0148] In one embodiment, when the UE sends an additional requested NSSAI, the UE may not send the requested NSSAI in the same NAS message.

[0149] In one embodiment, when the AMF sends an additional allowed NSSAI, the AMF cannot send the allowed NSSAI in the same NAS message.

[0150] In one embodiment, when the AMF sends an additional pending NSSAI, the AMF cannot send the pending NSSAI in the same NAS message.

[0151] <1b. Register for additional slices using the requested NSSAI IE>

[0152] The second solution disclosed herein is to solve the above problem by using the existing Requested NSSAI IE (or Requested NSSAI), where the Requested NSSAI needs to be used by the UE to register to the slice in addition to the S-NSSAI entry included in the Pending NSSAI.

[0153] Although four options for this second solution are disclosed, it will be understood that embodiments of the present invention are not limited to these.

[0154] Option 1

[0155] If the UE needs to register to a set of slices where any of these slices have a corresponding S-NSSAI in the UE's pending NSSAIs, the UE sends a registration request and includes a Requested NSSAI IE. The UE must set the content of the Requested NSSAI IE to include the set of S-NSSAIs that the UE needs to register to (or use) in addition to the set of S-NSSAIs that are in the pending NSSAIs. However, the Requested NSSAI does not include an S-NSSAI from the pending NSSAIs.

[0156] The contents of the Requested NSSAI are considered to be the set of requested S-NSSAIs in addition to any S-NSSAIs in the Allowed NSSAIs, if the UE has them (or if the AMF has them for the UE). As such, the purpose of the Requested NSSAI is to indicate the slices that the UE wants to use in addition to the S-NSSAIs in the Pending NSSAIs and, if present, the S-NSSAIs received by the UE in the Allowed NSSAIs. Therefore, with this option, the Requested NSSAI does not contain any entries in the Allowed NSSAIs.

[0157] In one embodiment, the UE may use a new bit in the 5GS Update Type IE to indicate whether the contents of the requested NSSAI are new or are to be sent in addition to those already requested by the UE in the pending NSSAI and in addition to any S-NSSAI in the selectively allowed NSSAI. The new bit may be referred to, for example, as an "Additional slice(s) indication," where, for example, if the bit is set to "1," the bit means "Additional slice(s) requested," or if the bit is set to "0," the bit means "Additional slice(s) not requested." Thus, if the UE is requesting additional slices in the slices of the pending NSSAI and the slices of the selectively allowed NSSAI, the UE transmits the requested NSSAI and sets the new bit accordingly, for example, to "1." On the other hand, if the UE is registering to an entirely new slice (i.e., a slice different from the one present in the pending NSSAI and, if available, the granted NSSAI), the UE sends the requested NSSAI and sets the value of this bit accordingly, for example to "0".

[0158] It should be noted that the use of the bit as proposed above can inform the AMF that the UE wants to use all S-NSSAI entries in the pending NSSAI via the access technology that sends the registration request with the bit set to '1'. Therefore, as explained above, setting the bit to, for example, [1], should mean that the UE wants to use S-NSSAI entries in the pending NSSAI via the use of the access technology to send the NAS message with the bit set to '1'. However, this does not mean that the UE also needs to send the requested NSSAI.

[0159] For example, if the UE only wants to register or use slices in a pending NSSAI (e.g., from another / previous registration procedure via another access technology) via the current access technology, the UE should set the bit, e.g., to '1'. Furthermore, if the UE needs to register or use another slice in addition to the one in the pending NSSAI, the UE should also include a requested NSSAI, which should include the additional S-NSSAIs that the UE wants to register or use. Such a solution can be used with any bit proposed herein, where it should be noted that the bit can have a different name instead of "Additional slice(s) indication." For example, this bit can be called "Request to use slice(s) in pending NSSAI," or any different name can be used. Therefore, the name and / or value of the bit is used to mean only a specific indication and is used as an example. It should be noted that this bit is used for reasons that the S-NSSAI present in the pending NSSAI is indicated with the same access technology previously used or via a different access technology as described above (i.e., to indicate a request to use a slice in the pending NSSAI or to request that a slice be used in the pending NSSAI).

[0160] It should be noted that the bit examples above mean that these two bits are both present and used as above, or that one of these bits is used as above.

[0161] If the AMF receives the requested NSSAI IE (or the requested NSSAI) and (optionally) the UE has a pending NSSAI, the AMF considers the S-NSSAI in the requested NSSAI as a new additional slice that the UE wants to use or register additionally.

[0162] In one embodiment, the AMF determines whether the contents of the requested NSSAI are added to what the UE has already requested in the pending NSSAI, and in a further embodiment, to what is requested in the allowed NSSAI, based on the value of the new bit in the 5GS Update Type IE.

[0163] If the bit is set, for example, to '1', the AMF considers the requested NSSAI content to be requested in addition to the entry in the pending NSSAI, and optionally in addition to the entry in the current allowed NSSAI, if one is available to the UE.

[0164] If the AMF receives a new indication, for example a new bit in the 5GS Update Type IE (for example, this bit is set to '1' to indicate that the UE wants to use additional slices, or that the UE wants to use slices of a pending NSSAI), but does not receive the requested NSSAI (or does not receive any other IE containing the requested set of slices), the AMF should consider that the UE wants to use the S-NSSAI of the pending NSSAI in the access technology for which the bit was received (or for which the indication was received), even though the NAS message did not contain the requested NSSAI. Thus, reception of a new bit at the AMF may mean (and thus the AMF may decide) that the UE also wants to use the S-NSSAI of the pending NSSAI in the access technology for which the indication is received. Furthermore, if the requested NSSAI is also received by the AMF, the AMF considers the bits in the pending NSSAI for the contents of that S-NSSAI to be additional slices that the UE wishes to register or use in addition to those for which the UE wishes to use these slices in the access technologies for which the UE may have received the bits in the pending NSSAI and optionally also received the requested NSSAI.

[0165] Otherwise, if the bit is set, for example, to "0", the AMF determines that the content of the requested NSSAI is requested as an entirely new slice, and therefore the UE does not want to use a pending NSSAI entry requested via the current access, and optionally, if one is available to the UE, the UE does not want to use an allowed NSSAI entry. The AMF then processes the content of the requested NSSAI as follows:

[0166] If the bit is set to '0', the AMF shall selectively process the content of the requested NSSAI as proposed herein.

[0167] As mentioned above, the use of the new bit by the UE and the handling of the new bit by the AMF, and, if necessary, the handling of the requested NSSAI, can be applied to other solution options of the present invention, and therefore this proposal for the UE and AMF based on the new bit in the 5GS Update Type IE is not specific to only this solution option.

[0168] According to one embodiment, the new bit can be sent in any other IE and any other NAS message, and therefore the above proposal is not limited to only the 5GS Update Type IE, nor is it specific to only the Registration Request message.

[0169] Next, the AMF verifies whether any S-NSSAI within the requested NSSAI is allowed for the UE (i.e., whether it is not subject to NSSA, or whether the NSSAA is not requested, or is being performed successfully), and also verifies whether there are any S-NSSAIs that are subject to NSSAA and request NSSAA.

[0170] If at least one of the S-NSSAIs in the requested NSSAI is subject to NSSAA, the AMF updates the list of pending NSSAIs (or S-NSSAIs for which NSSAA is required), and therefore this S-NSSAI (from the requested NSSAI) is also subject to NSSAA. The AMF MUST perform NSSAA for this S-NSSAI. The AMF MUST also update the UE with the new list of pending NSSAIs so that the pending NSSAIs include any S-NSSAIs for which NSSAA is required from the requested NSSAI. The AMF MUST send the new list of pending NSSAIs to the UE in the Registration Accept message.

[0171] If at least one S-NSSAI in the requested NSSAI is allowed for the UE, the AMF also includes the allowed NSSAI in the registration accept message, where the allowed NSSAI is as follows:

[0172] -If present, it contains all S-NSSAIs authorized for the UE, including all S-NSSAIs previously authorized for the UE. Note that if any S-NSSAI does not require NSSAA (or NSSAA has previously been successfully performed) and is authorized for the UE (optionally in the current registration area), the authorized NSSAIs may include S-NSSAIs from the requested NSSAI.

[0173] -Includes any S-NSSAI for which the NSSAA has been successfully completed. Note that the AMF may also optionally remove such S-NSSAI from the pending NSSAIs sent to the UE in the Registration Accept message.

[0174] In one embodiment, the AMF may use a new Additional Allowed NSSAI IE (or Additional Allowed NSSAI) to include any S-NSSAIs from the Requested NSSAIs that are allowed for the UE. The AMF may send this IE to the UE in a registration accept message.

[0175] In one embodiment, the AMF may use a new Additional Pending NSSAI IE (or Additional Pending NSSAI) to include any S-NSSAI from the requested NSSAI that is the subject of (or for which) the NSSAA is performed. The AMF may send this IE to the UE in a registration accept message.

[0176] In one embodiment, the additional allowed NSSAI IEs and / or the additional pending NSSAI IEs may be sent to the UE in a Configuration Update Command (CUC) message.

[0177] If the UE receives an additional allowed NSSAI IE in the registration accept message (or CUC message), the UE MUST add the entry for this IE to the list of allowed NSSAIs. The UE MUST also remove any S-NSSAI from the rejected NSSAIs or remove any (additional) pending NSSAIs that match the S-NSSAI from the additional allowed NSSAIs.

[0178] If the UE receives an Additional Pending NSSAI IE in the Registration Accept message (or CUC message), the UE MUST add an entry for this IE to the list of pending NSSAIs. The UE MUST also remove any S-NSSAI from the Rejected NSSAIs or (additional) Allowed NSSAIs that match the S-NSSAI from the Additional Pending NSSAIs.

[0179] Option 2

[0180] In contrast to option 1, the Requested NSSAI here MUST also include any S-NSSAIs that are in the Allowed NSSAIs, if they exist. Thus, if the UE needs to register to (or use) slices in addition to the ones previously requested, the UE MUST send a Registration Request message containing the Requested NSSAIs, where the latter contains the additional (new) S-NSSAIs that the UE wants to register to (or use) and the S-NSSAIs included in the Allowed NSSAIs.

[0181] When the AMF receives the requested NSSAI, (optionally) if there is a pending NSSAI for the UE, the AMF verifies whether there are any S-NSSAIs that are allowed for the UE (i.e., whether they are not subject to NSSA or whether an NSSAA is not requested or has been performed successfully), and whether any S-NSSAIs are subject to and require an NSSAA.

[0182] If at least one S-NSSAI among the requested NSSAIs is subject to NSSAA, the AMF updates the pending NSSAI (or S-NSSAI for which NSSAA is required) list so that this S-NSSAI (from the requested NSSAI) is still subject to NSSAA. The AMF MUST perform NSSAA for this S-NSSAI. The AMF MUST also update the UE with the new list of pending NSSAIs so that the pending NSSAIs include any S-NSSAIs for which NSSAA is required from the requested NSSAI. The AMF MUST send the new list of pending NSSAIs to the UE in the Registration Accept message.

[0183] If at least one S-NSSAI in the requested NSSAI is allowed for the UE, the AMF also includes the allowed NSSAI in the registration accept message, where the allowed NSSAI is as follows:

[0184] -If present, it contains all S-NSSAIs authorized for the UE, including all S-NSSAIs previously authorized for the UE. Note that if any S-NSSAI does not require NSSAA (or NSSAA has been previously performed successfully) and is authorized for the UE (optionally in the current registration area), the authorized NSSAIs may include S-NSSAIs from the requested NSSAI.

[0185] -Includes any S-NSSAI for which the NSSAA has been successfully completed. Note that the AMF may also optionally remove such S-NSSAI from the pending NSSAIs sent to the UE in the Registration Accept message.

[0186] In one embodiment, the AMF may use a new Additional Allowed NSSAI IE (or Additional Allowed NSSAI) to include any S-NSSAIs from the Requested NSSAIs that are allowed for the UE. The AMF may send this IE to the UE in a registration accept message.

[0187] In one embodiment, the AMF may use a new Additional Pending NSSAI IE (or Additional Pending NSSAI) to include any S-NSSAI from the requested NSSAI that is the subject of (or for which) the NSSAA is performed. The AMF may send this IE to the UE in a registration accept message.

[0188] In one embodiment, the additional allowed NSSAI IEs and / or the additional pending NSSAI IEs may also be sent to the UE in a Configuration Update Command (CUC) message.

[0189] If the UE receives an additional allowed NSSAI IE in the registration accept message (or CUC message), the UE MUST add the entry for this IE to the list of allowed NSSAIs. The UE MUST also remove any S-NSSAI from the rejected NSSAIs or remove any (additional) pending NSSAIs that match the S-NSSAI from the additional allowed NSSAIs.

[0190] If the UE receives an Additional Pending NSSAI IE in the Registration Accept message (or CUC message), the UE MUST add an entry for this IE to the list of pending NSSAIs. The UE MUST also remove any S-NSSAI from the Rejected NSSAIs or (additional) Allowed NSSAIs that match the S-NSSAI from the Additional Pending NSSAIs.

[0191] Option 3

[0192] Here, the UE is not allowed to subscribe to any S-NSSAI in the pending NSSAIs if such a list is available to the UE and / or the AMF. Therefore, the UE is only allowed to send the requested NSSAI if the UE needs to register or use a set of S-NSSAIs for which there is no S-NSSAI entry matching the pending NSSAI. Furthermore, this means that all S-NSSAI entries in the pending NSSAIs previously requested via the same access as the access used to send the new requested NSSAI are considered unnecessary for use by the UE. In some embodiments, the "matching entry" takes into account the access technology for which registration to the corresponding slice is requested.

[0193] In this case, when the AMF receives the requested NSSAI, the AMF considers that the UE is requesting an entirely new set of S-NSSAIs for which no S-NSSAIs match any pending NSSAIs. Thus, when the AMF receives the requested NSSAI, and (optionally) if the AMF has pending NSSAIs for the UE, the AMF considers the newly received requested NSSAI to be valid and the previously granted NSSAI for the current access to be invalid.

[0194] The AMF must validate the content of the requested NSSAI and compare it with the content of the pending NSSAI.

[0195] For any S-NSSAI included in the Requested NSSAI received over this access technology, the AMF MUST remove any S-NSSAI that matches an entry from the Requested NSSAI from the Pending NSSAI if the S-NSSAI has not been requested over another access technology. This is because the UE may have requested another set of S-NSSAIs via another access technology that is subject to an NSSAI and therefore present in the Pending NSSAI. The AMF MUST stop any ongoing NSSAA for the S-NSSAI that was requested over this access technology (i.e., over which the Requested NSSAI was received).

[0196] For any S-NSSAI included in a requested NSSAI received via this access technology, if the S-NSSAI was previously requested via another access technology, the AMF MUST NOT remove the S-NSSAI's entry from the pending NSSAIs, if it exists. The AMF MUST then verify whether the newly requested NSSAI is subject to an NSSAI according to existing procedures.

[0197] If the UE is not registered with another access technology, the AMF may immediately consider the content of the pending NSSAI to be invalid or may remove all S-NSSAIs from the pending NSSAI when the requested NSSAI is received.

[0198] Next, the AMF MUST verify whether the newly requested NSSAI is subject to NSSAA according to existing procedures. If so, the AMF MUST include any S-NSSAIs that are subject to NSSAA in the pending NSSAI and send the updated pending NSSAI to the UE, and the AMF MUST perform NSSAA for the S-NSSAIs that are subject to NSSAA. Otherwise, if the S-NSSAI is allowed and available to the UE in the current RA, the AMF MUST include the S-NSSAI in the allowed NSSAI and send it to the UE. It should be noted that the newly requested NSSAI may not be subject to NSSAA, and therefore the AMF may have deleted some entries from the pending NSSAI as described above. In this case, even if the AMF does not contain any S-NSSAI entries, the AMF MUST send an updated pending NSSAI after deleting any S-NSSAI entries and send it to the UE.

[0199] The above content is explained with reference to the following example:

[0200] Example 1

[0201] - The UE sent the requested NSSAI={A, B} via the first access.

[0202] The UE sent the requested NSSAI={C, D} via the second access.

[0203] -AMF has pending NSSAI = {A, B, C, D} for UE.

[0204] The UE sends the requested NSSAI={E, F} via the first access.

[0205] oAMF should remove {A, B} from the pending NSSAI.

[0206] oAMF needs to verify whether {E, F} is subject to NSSAA.

[0207] Otherwise, the AMF must send the pending NSSAI={C, D} to the UE.

[0208] If so, the AMF needs to send the pending NSSAI={C, D, E, F} to the UE.

[0209] Option 4

[0210] Here, the UE is configured to indicate whether the requested NSSAI can include an S-NSSAI entry from the pending NSSAI.

[0211] The UE is pre-configured with this information in the USIM or ME. Alternatively, the network notifies the UE using a new bit defined as part of the 5GS Registration Result IE or the 5GS Network Capability Support IE.

[0212] For example, a new bit is defined, e.g., the "Registration to an S-NSSAI from the pending NSSAI" (RSPN) bit (it should be noted that this name is just an example and the bit may be called differently). For example, if the bit is set to the value "1", this means "Registration to an S-NSSAI from the pending NSSAI allowed", and if set to "0", it means "Registration to an S-NSSAI from the pending NSSAI not allowed". The AMF sets this bit to the corresponding value based on operator policy or UE subscription.

[0213] If configured to request or register an S-NSSAI from a pending NSSAI, either pre-configured or using an indication from the network as described above, the UE includes any S-NSSAI in the requested NSSAI, even if this S-NSSAI is present in the pending NSSAI.

[0214] If the UE is not configured to request or register an S-NSSAI from a pending NSSAI, it operates using one of the solution options proposed above. For example, whenever the UE sends a requested NSSAI, it means that it is requesting a slice in addition to the pending NSSAI, as in option 2 above (for solution 1b). However, other solution options can also be used in this case.

[0215] <1c. Wait until the pending NSSAI is empty>

[0216] As another solution to the above problem, the UE is configured to wait until the pending NSSAIs are empty before sending a request to use at least one other S-NSSAI in addition to the at least one S-NSSAI that is in the pending NSSAIs.

[0217] For example, the UE may wait until the NSSAA ends or completes before registering to a new slice, or may wait to ensure that the slice the UE wants to use (e.g., via an access technology) has no corresponding S-NSSAI entries in the pending NSSAI (even if the pending NSSAI is not empty). For example, assume that the UE requests to use slice {A, B} via 3GPP® access. Also assume that the pending NSSAI contains {A, B}. If the UE wants to use slice {A, B, C} during the NSSAA or while the pending NSSAI is not empty, the UE must wait until the pending NSSAI also contains no S-NSSAI entries from the set of slices the UE wants to use (i.e., from {A, B, C} in this example). Therefore, if the pending NSSAI is empty or has been modified so that no S-NSSAI entries required by the UE exist, the UE requests to use the corresponding S-NSSAI by including the corresponding S-NSSAI in the requested NSSAI and sending the latter in a registration request.

[0218] Alternatively, the UE is configured to wait a known time T during which the UE cannot request an S-NSSAI that is present in a specific pre-configuration (e.g., USIM or non-volatile memory or managed object file) or a pending NSSAI. To this end, each time a pending NSSAI is received or the content of a pending NSSAI is changed, the UE starts a timer with a length in T units (e.g., seconds, minutes, hours, etc.). During this time T, the UE is not allowed to request an S-NSSAI that is present in the pending NSSAI. When the timer expires, the UE is allowed to request an S-NSSAI even if the S-NSSAI is still present in the pending NSSAI. Alternatively, the UE is provided with the value of timer T in any NAS message, such as a Registration Accept message or a Configuration Update Command message. The AMF provides the length of timer T in the above NAS message, and the AMF can do so at any time, or whenever required by its policy, or whenever the AMF decides to change the duration of this timer.

[0219] <2. Solution for handling S-NSSAI, which is subject to NSSAA but not permitted in the UE's current registration area>

[0220] As mentioned above, problems can occur when there is an S-NSSAI that is subject to NSSAA but is not available or authorized in the UE's RA. We disclose two solutions to handle the case where an S-NSSAI is subject to NSSAA but is not available in the UE's current Registration Area (RA).

[0221] <2a. AMF does not perform NSSAA for slices that are not available in the UE's RA>

[0222] Here, the AMF needs to check whether the S-NSSAI is available / allowed for the UE in the UE's RA (selectively: if the S-NSSAI is present in the requested NSSAI (or the requested mapped NSSAI or the additional requested NSSAI) and the latter was sent by the UE, or if the UE did not send the requested NSSAI (or the requested mapped NSSAI or the additional requested NSSAI), or the S-NSSAI or requested NSSAI entry (or in the requested mapped NSSAI or the additional requested NSSAI) marked as default in the UE's subscription is not available / allowed for the UE). In one embodiment, this condition needs to be checked in advance, regardless of whether an NSSAI is required for this S-NSSAI or not.

[0223] If the AMF determines that the S-NSSAI is not available / authorized for the UE in this RA, the AMF should not initiate an NSSAA for the S-NSSAI. The AMF should include the S-NSSAI in the rejected NSSAI and set the cause value accordingly to indicate why the S-NSSAI was rejected. For example, the cause value can be set to "S-NSSAI not available in the current registration area".

[0224] This solution is applied selectively on a per-access basis, since the S-NSSAI may be available to the UE in the current RA via one access technology but not another.

[0225] <2b. AMF performs NSSAA for slices that are not available in the UE's RA>

[0226] Here, the AMF checks whether the S-NSSAI is available / authorized to the UE in the UE's RA (optionally: if the S-NSSAI is present in the requested NSSAI (or the requested mapped NSSAI or the additional requested NSSAI) and the latter was sent by the UE, or if the UE did not send the requested NSSAI (or the requested mapped NSSAI or the additional requested NSSAI), or if the S-NSSAI or the requested NSSAI entry (or in the requested mapped NSSAI or the additional requested NSSAI) marked as default in the UE's subscription is not available / authorized to the UE).

[0227] If the S-NSSAI is subject to NSSAA, the AMF will perform the NSSAA even if the S-NSSAI is not available in the current RA. After completion of the NSSAA: The AMF

[0228] If the NSSAA fails for the S-NSSAI, the AMF includes the S-NSSAI in the rejected NSSAI and sets the cause to "S-NSSAI not available due to the failed or revoked network slice-specific authentication and authorization" or "S-NSSAI not available in the current registration area." The AMF sends the rejected NSSAI to the UE in a NAS message (for example, a Configuration Update Command message).

[0229] If the NSSAA is successful for the S-NSSAI, the AMF includes the S-NSSAI in the rejected NSSAI and sets the cause to "S-NSSAI not available in the current registration area". The AMF sends the rejected NSSAI to the UE in a NAS message (e.g., a Configuration Update Command message).

[0230] It should be understood that Solution 2a and / or Solution 2b can be combined with any of the options in Solutions 1a and 1b as needed.

[0231] <3. Further discussion>

[0232] Further embodiments of the present invention are provided, and those skilled in the art will understand how these further embodiments relate to one or more of the solution options described above.

[0233] 1 provides a schematic diagram of the structure of a network entity 100 (e.g., AMF) configured to operate according to one or more of the above-described embodiments. Network entity 100 includes a transmitter 102 configured to transmit signals to UEs, a receiver 104 configured to receive signals from the UEs, and at least one controller (or processor) 106 configured to control the transmitter and receiver to perform processing, such as in accordance with the methods described above, and to communicate with the network. In one embodiment, network entity 100 includes a transceiver including transmitter 102 and receiver 104.

[0234] 2 provides a structural schematic diagram of a UE 200 configured to operate in accordance with one or more of the embodiments of the present invention described above. The UE 200 includes a transmitter 202 configured to transmit signals to a network entity, a receiver 204 configured to receive signals from the network entity, and at least one controller (or processor) 206 configured to control the transmitter and receiver to perform processing in accordance with the methods described above. In one embodiment, the UE 200 includes a transceiver including the transmitter 202 and the receiver 204.

[0235] Although the transmitter, receiver, and controller (or processor) are shown as separate elements in Figures 1 and 2, the above-described embodiments of the present invention may be implemented using a single element or multiple elements providing equivalent functionality.

[0236] FIG. 3 illustrates a method according to various embodiments of the present invention.

[0237] In one embodiment, the method of Figure 3 is performed by a network entity such as that shown in Figure 1. For example, the network entity is an AMF.

[0238] In step 310, while there is a pending NSSAI for the UE, the network entity receives a request from the UE via a first access technology indicating at least one first S-NSSAI, the first S-NSSAI being different from any NSSAI indicated in the pending NSSAI.

[0239] It is understood that the request is a request to use (e.g., register) at least one network slice corresponding to at least one first S-NSSAI via a first access technology, for example, the request is or includes a requested NSSAI (e.g., a requested NSSAI IE).

[0240] In one embodiment, any S-NSSAIs indicated in the pending NSSAIs each correspond to a (different) network slice that the UE has previously used (i.e., the previous / optionally other request) to send a request to. Upon receiving the previous request, the network entity determines that one or more S-NSSAIs contained therein are subject to the NSSAI, and accordingly adds such one or more S-NSSAIs to the pending NSSAIs.

[0241] In one embodiment, the UE is prohibited or prevented from including any S-NSSAI indicated in a pending NSSAI in a request to use a slice (such as the request mentioned in connection with step 310), i.e., a request to use a network slice cannot indicate an S-NSSAI included in a pending NSSAI.

[0242] In one embodiment, when the request is received by a network entity, the NSSAA for one or more S-NSSAIs included in the UE's pending NSSAI at the time the UE sent the request has been completed (e.g., the NSSAA was successful). At the network entity, the UE's pending NSSAI is now updated to remove an indication of the one or more S-NSSAIs for which the NSSAA has been completed. However, the UE has not yet been notified of this, in which case the pending NSSAI at the UE still includes the indication. When the network entity sends a response to the request, the response includes an indication that the NSSAA has been completed for one or more of the S-NSSAIs still indicated in the UE's pending NSSAI, thereby notifying the UE. For example, the network entity sends the (updated) pending NSSAI and the allowed NSSAI to the UE. Here, information about one or more second S-NSSAIs for which the NSSAA was successful is deleted from the pending NSSAI, and the allowed NSSAI indicates one or more of such second S-NSSAIs.

[0243] In one embodiment, if the NSSAA is successful and the AMF locally moves the S-NSSAI to the Allowed NSSAI, and if the request from the UE is considered new (e.g., does not indicate any S-NSSAI indicated in the previous request), the AMF removes the S-NSSAI for which the NSSAA was successful from the Allowed NSSAI, because the AMF considers that the first request contains an S-NSSAI entry that is mutually exclusive with the entry in the second request.

[0244] Similarly, if the NSSAI fails for any of the S-NSSAIs that were in the pending NSSAIs at the UE when the UE sent the request, the network entity shall remove the information of such S-NSSAIs from the pending NSSAIs and include the instructions for these S-NSSAIs in a rejected NSSAI, which is sent to the UE to notify it that the slice usage request corresponding to these S-NSSAIs has been rejected.

[0245] It is understood that the request for at least one first S-NSSAI, in one embodiment, includes information about the at least one first S-NSSAI or an indication of each of the first S-NSSAIs, so that the network entity is informed of the network slice that the UE wants to use. Here, when reference is made to an S-NSSAI or an indication of at least one S-NSSAI (or the like), it is understood that said indication may be or include the S-NSSAI itself, or may include a plurality of individual indications each indicating one of the S-NSSAIs in some appropriate way (such as providing or including the S-NSSAI itself).

[0246] In step 320, it is basically determined (or verified, checked, etc.) whether the pending NSSAI includes an indication of one or more S-NSSAIs indicated in a previous request received from the UE via the first access technology. That is, it is checked whether the pending NSSAI includes an indication of one or more S-NSSAIs indicated in a request previously sent by the UE to a network entity, where this previously sent request is for using the network slice(s) corresponding to one or more S-NSSAIs via the same access technology as the most recent request received from the UE. The indication of one or more S-NSSAIs according to the first access technology in the pending NSSAI includes all S-NSSAIs in the pending NSSAI that are / were requested via the first access technology.

[0247] Additionally or alternatively, the network entity determines (or confirms, checks, etc.) whether the pending NSSAI includes an indication of any previously requested S-NSSAI via a different access technology (i.e., a second access technology different from the first access technology). For example, such S-NSSAI was indicated in a request / another request previously sent by the UE to the network entity, and this previously sent request was for using a network slice corresponding to such S-NSSAI via an access technology different from the first access technology.

[0248] In step 330, if the pending NSSAI includes an indication of one or more S-NSSAIs indicated in a previous request from the UE via the first access technology, the network entity assumes that the request is for the use of at least one new network slice. In one embodiment, the assumption that the request is for the use of at least one new network slice also requires that the pending S-NSSAI does not include an S-NSSAI (or an indication thereof) previously requested by the UE via an access technology different from the first access technology.

[0249] Following this, in step 340, the network entity removes one or more S-NSSAI indications from the pending NSSAI. For example, any S-NSSAI indications for the first access technology that were indicated to the network entity in a previous request from the UE in the pending NSSAI are removed from the pending NSSAI. It should be understood that in one embodiment, this can be considered to reflect the above request, which is a request to use a new network slice, in particular a new network slice via the first access technology. It should be understood that in one embodiment, a request to use a new network slice via an access technology is interpreted by the network entity to mean that a previous request via the same access technology is no longer valid.

[0250] Additionally, alternatively, or selectively, step 330 may be considered to include, when the request is received, determining whether to delete the S-NSSAI indicated in the pending NSSAI based on the access technology for which the S-NSSAI is requested to be used. If the access technology for which the S-NSSAI is requested to be used in the pending NSSAI is the first access technology, the method proceeds to step 340, where the indication of the S-NSSAI is deleted from the pending NSSAI. However, if the access technology for which the S-NSSAI is requested to be used in the pending NSSAI is an access technology different from the first access technology, the indication of the S-NSSAI is not deleted from the pending NSSAI.

[0251] Although not shown in FIG. 3, it is understood that in one embodiment, the network entity sends a response to the first request.

[0252] For example, as further described above, the network entity may send to the UE an (updated) pending NSSAI indicating one or more of the at least one first S-NSSAI, where the one or more first S-NSSAIs correspond to the slices for which the NSSAI is required. Alternatively, the network entity may send to the UE an additional pending NSSAI (which may be a new IE) indicating one or more of the first S-NSSAIs.

[0253] In another embodiment, as described above, the network entity also sends to the UE an allowed NSSAI, which is modified based on the request, for example, including one or more indications of the at least one first S-NSSAI with which the UE is registered. Alternatively, the network entity is configured to include an indication of one or more of the first S-NSSAIs and sends additional allowed NSSAIs to the UE.

[0254] In yet another embodiment, as described above, the network entity also sends a rejected NSSAI to the UE, which may be modified or generated based on the request, for example, including an indication of one or more of the at least one first S-NSSAI for which the usage request (e.g., registration request) from the UE was rejected. Alternatively, some other signal is sent to the UE to indicate one or more of the first S-NSSAIs for which the UE registration was rejected.

[0255] It will be appreciated that one or more of the signals / messages sent in response to the above request may be sent in a single signal, such as a registration accept message or a CUC (Configuration Update Command) message.

[0256] Figure 4 illustrates a UE method according to various embodiments of the present invention. It will be understood that the method is performed by a UE such as that shown in Figure 2. It will also be understood that the method embodiment of Figure 4 correlates with the method embodiment of Figure 3.

[0257] In step 410, while there is a pending NSSAI for the UE, the UE sends a request to a network entity via a first access technology indicating at least one first S-NSSAI, where the at least one first S-NSSAI is different from any S-NSSAI indicated in the pending NSSAI.

[0258] If the pending NSSAI includes an indication of one or more S-NSSAIs via a first access technology indicated in a previous request sent by the UE, the request is a request to use at least one new network slice, i.e., if the at least one first S-NSSAI is different from any S-NSSAI indicated in the pending NSSAI and the request is sent via the same access technology as the previous request that indicated one or more S-NSSAIs indicated in the pending NSSAI, the request is considered to be a request to use a new network slice.

[0259] 4 also shows step 420 of receiving a response to the request from a network entity, it should be understood that this step is omitted in one embodiment of the present invention. This step 420 is useful for additional embodiments in which the contents of the response are used by the UE. For example, the response may include (individually or collectively) a pending NSSAI, additional pending NSSAIs, allowed NSSAIs, additional allowed NSSAIs, and / or rejected NSSAIs.

[0260] The pending NSSAI and the additional pending NSSAI include an indication of one or more of the first S-NSSAIs that are the subject of the NSSAA, which the UE uses to update the pending NSSAI at the UE to include said indication.

[0261] The allowed NSSAIs include an indication of any S-NSSAIs previously allowed for the UE and an indication of any of the first S-NSSAIs allowed for the UE, and the additional allowed NSSAIs include an indication of any of the first S-NSSAIs allowed for the UE.

[0262] The rejected NSSAI includes an indication of a first S-NSSAI that is either not authorized for the UE or is not available in the UE's current registration area.

[0263] 5 illustrates a method of a network entity according to various embodiments of the present invention. It will be understood that the method is performed by a network entity such as that shown in FIG. 1. For example, the network entity is an AMF.

[0264] In step 510, while there is an NSSAI pending for the UE, the network entity receives a request from the UE indicating at least one S-NSSAI.

[0265] In step 520, the network entity determines whether the request is for use of at least one additional network slice.

[0266] In one embodiment, this determination is performed based on the request. For example, if the request is or includes a requested NSSAI (e.g., a requested NSSAI IE), the network entity is configured to consider the request to be for using an additional network slice. In another embodiment, if the request is or includes an additional requested NSSAI (e.g., an additional requested NSSAI IE), the network entity is configured to consider the request to be for using an additional network slice.

[0267] In one embodiment, the UE sends, in or separately from the request indicating at least one first S-NSSAI, an indication that the request is a request to use at least one additional network slice. Upon receiving such an indication, the network entity is configured to assume that the request is for using (e.g., registering with) the at least one additional network slice. The indication is received in addition to the requested NSSAI or an additional requested NSSAI.

[0268] In one embodiment, because the request is to request the use of at least one additional slice, the network entity does not remove the S-NSSAI (for which the NSSAA is still in progress or pending) from the pending NSSAI. However, the network entity adds an indication of any of the requested first S-NSSAIs that are the subject of the NSSAA to the pending NSSAI. In one embodiment, the network entity transmits this pending NSSAI to the UE, or includes this indication in an additional pending NSSAI and transmits the additional pending NSSAI to the UE.

[0269] In one embodiment, the network entity also determines whether any of the first S-NSSAIs are allowed for the UE. The network entity includes any allowed first S-NSSAIs in an allowed NSSAI (or additional allowed NSSAIs) and sends this to the UE. In one embodiment, the network entity determines whether any of the first S-NSSAIs are rejected for the UE (e.g., for one or more of the rejection reasons described throughout this invention). The network entity includes any rejected first S-NSSAIs in a rejected NSSAI and sends this to the UE.

[0270] Figure 6 illustrates a UE method according to various embodiments of the present invention. It will be understood that the method is performed by a UE such as that shown in Figure 2. It will also be understood that the method embodiment of Figure 6 is interrelated with the method embodiment of Figure 5.

[0271] In step 610, while there is a pending NSSAI for the UE, the UE sends a first request to the network entity to use at least one additional network slice. The first request indicates at least one S-NSSAI, or the UE sends a second request to the network entity via a different access technology to use at least one network slice corresponding to the S-NSSAI indicated in the pending NSSAI. For example, the second request is a (new) bit, as described in option 1 of solution 1b.

[0272] It will be appreciated that in one embodiment, this is achieved by a request that is or includes a requested NSSAI (e.g., a requested NSSAI IE), and the network entity is configured to consider the request to be for using an additional network slice. In another embodiment, if the request is or includes an additional requested NSSAI (e.g., a requested additional NSSAI IE), the network entity is configured to consider the request to be for using an additional network slice. Furthermore, in one embodiment, the UE sends, in the request or separately, an indication that the request indicating at least one first S-NSSAI is a request to use at least one additional network slice. Upon receiving such an indication, the network entity is configured to assume that the request is for using (e.g., registering with) at least one additional network slice. The indication is sent in addition to the requested NSSAI or the additional requested NSSAI.

[0273] 6 also shows step 620 of receiving a response to the request from a network entity, although it should be understood that this step is omitted in one embodiment of the present invention. This step 620 is useful in additional embodiments in which the contents of the response are used. For example, the response may include (individually or collectively) a pending NSSAI, additional pending NSSAIs, allowed NSSAIs, additional allowed NSSAIs, and / or rejected NSSAIs. These and their uses are described above in connection with the method of FIG. 5.

[0274] FIG. 7 illustrates another method according to various embodiments of the present invention.

[0275] In one embodiment, the method of Figure 7 is performed by a network entity such as that shown in Figure 1. For example, the network entity is an AMF.

[0276] In one embodiment, Figure 7 begins with a network entity being in a state to determine whether access to a network slice is permitted for a UE. In one embodiment, this follows receipt of a request from the UE to use the network slice, or if the network slice is marked as default in the UE's subscription. Following this, the network entity is configured to perform one or two procedures. It will be appreciated that the present invention encompasses network entities configured to perform only one of these procedures, as well as network entities configured to perform both (and configured to switch between any of the procedures, for example, or in response to some factor or condition).

[0277] In step 710, the network entity determines / identifies whether the S-NSSAI is available or allowed for the UE based on the UE's registration area (RA). In one embodiment, the determination includes checking whether the S-NSSAI is available or allowed in the UE's current registration area.

[0278] In one embodiment (not shown in FIG. 7), if the S-NSSAI is available or authorized for the UE, the network entity proceeds as described in [3]. For example, the network entity checks whether the S-NSSAI is subject to an NSSAI and, depending on the result, includes the S-NSSAI in the pending NSSAI, authorized NSSAI, or rejected NSSAI.

[0279] However, if in step 720 it is determined that the S-NSSAI is not available or not permitted for the UE based on the UE's RA, the network entity includes the S-NSSAI in the rejected NSSAI without performing an NSSAA for the S-NSSAI. In one embodiment, the network entity indicates as the reason for the rejection that the S-NSSAI is not available in the UE's RA. That is, the network entity configures an indication indicating the cause of the rejection that the S-NSSAI is not available in the UE's current RA.

[0280] In step 730, as an alternative to step 710, the network entity performs an NSSAA on the S-NSAI.

[0281] In step 740, the network entity determines whether an S-NSSAI is available or allowed for the UE based on the UE's RA. It should be appreciated that in one embodiment, this is performed regardless of the outcome of the NSSAA.

[0282] In step 750, if it is determined that the S-NSSAI is not available or not authorized for the UE based on the UE's RA, the S-NSSAI is included in the rejected NSSAI. For example, if the S-NSSAI is not available in the UE's RA, the S-NSSAI is included in the rejected NSSAI. In one embodiment, the network entity also indicates as a reason for the rejection that the S-NSSAI is not available in the UE's RA. That is, the network entity configures an indication indicating the cause of the rejection that the S-NSSAI is not available in the UE's current RA.

[0283] In one embodiment (not shown in FIG. 7), the network entity sends a rejected NSSAI for either alternative to the UE and / or sends the reason for the rejection (or an indication thereof) to the UE.

[0284] The techniques described herein can be implemented using any suitably configured apparatus and / or system. Such an apparatus and / or system is configured to perform a method according to any aspect, embodiment, example, or claim disclosed herein. Such an apparatus includes one or more elements, such as one or more receivers, transmitters, transceivers, processors, controllers, modules, units, etc., each configured to perform one or more corresponding processes, operations, and / or method steps to implement the techniques described herein. For example, operation / function X is performed by a module configured to perform X (or an X module). One or more elements can be implemented in hardware, software, or any combination of hardware and software.

[0285] It is to be understood that embodiments of the present invention can be implemented in the form of hardware, software, or any combination of hardware and software, and such software can be stored in the form of volatile or non-volatile storage, whether erasable or rewritable, such as storage devices, for example, ROM, or in the form of memory, for example, RAM, memory chips, devices, or integrated circuits, or on an optically or magnetically readable medium, for example, a CD, DVD, magnetic disk, or magnetic tape.

[0286] It will be understood that the storage devices and storage media are embodiments of a program containing instructions that, when executed, implement embodiments of the present invention, or a machine-readable storage device suitable for storing a program. Accordingly, embodiments of the present invention provide a program containing code for implementing a method, apparatus, or system according to any example, embodiment, aspect, and / or claim disclosed herein, and / or a machine-readable storage device storing such a program. Furthermore, such a program may be transmitted electronically over any medium, such as, for example, a communication signal transmitted over a wired or wireless connection.

[0287] While the present invention has been described with reference to embodiments, it will be understood by those skilled in the art that various changes in the embodiments and details thereof can be made without departing from the scope of the invention as defined by the claims. [Explanation of symbols]

[0288] 100 Network Entities (Mobility Management Function: AMF) 102, 202 transmitter 104, 204 receiver 106, 206 Controller (or processor) 200 User Equipment (UE)

Claims

1. 1. A method performed by a network entity, comprising: receiving, from a user equipment (UE) via a first access type, a request message including a requested NSSAI including at least a first single network slice selection assistance information (NSSAI) (S-NSSAI); sending an accept message to the UE including the at least one first S-NSSAI and a second pending NSSAI including the at least one second S-NSSAI; the at least one first S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA); and The method, wherein the requested NSSAI does not include any S-NSSAI within a first pending NSSAI for the UE that includes at least one second S-NSSAI.

2. 2. The method of claim 1, wherein the at least one second S-NSSAI in the first pending NSSAI is previously requested by the UE via the first access type.

3. 1. A method performed by a user equipment (UE), comprising: sending a request message including a requested NSSAI that includes at least one first single network slice selection assistance information (NSSAI) (S-NSSAI) via a first access type to a network entity; receiving an accept message from the network entity, the accept message including the at least one first S-NSSAI and a second pending NSSAI including the at least one second S-NSSAI; the at least one first S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA); and The method, wherein the requested NSSAI does not include any S-NSSAI within a first pending NSSAI for the UE that includes at least one second S-NSSAI.

4. The method of claim 3, characterized in that the at least one second S-NSSAI within the first pending NSSAI is previously requested by the UE via the first access type.

5. 1. A wireless communication user equipment (UE), comprising: A transceiver; at least one processor coupled to the transceiver; The at least one processor sending a request message including a requested NSSAI that includes at least a first single network slice selection assistance information (NSSAI) (S-NSSAI) via a first access type to a network entity; configured to receive an accept message from the network entity, the accept message including the at least one first S-NSSAI and a second pending NSSAI including the at least one second S-NSSAI; the at least one first S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA); and The UE, wherein the requested NSSAI does not include any S-NSSAI within a first pending NSSAI for the UE that includes at least one second S-NSSAI.

6. The UE described in Claim 5, characterized in that the at least one second S-NSSAI within the first pending NSSAI is previously requested by the UE via the first access type.

7. A network entity in wireless communications, comprising: A transceiver; at least one processor coupled to the transceiver; The at least one processor receiving, from a user equipment (UE) via a first access type, a request message including a requested NSSAI that includes at least a first single network slice selection assistance information (NSSAI) (S-NSSAI); configured to send to the UE an accept message including the at least one first S-NSSAI and a second pending NSSAI including the at least one second S-NSSAI; the at least one first S-NSSAI is subject to network slice-specific authentication and authorization (NSSAA); and The network entity, wherein the requested NSSAI does not include any S-NNSAI within a first pending NSSAI for the UE that includes at least one second S-NSSAI.

8. The network entity described in claim 7, characterized in that the at least one second S-NSSAI within the first pending NSSAI is previously requested by the UE via the first access type.

Images