Enhanced network slice management for user equipment

Abstract

This invention relates to enhancements for user equipment network slice management. A user equipment (UE) is configured to: transmit a registration request message to a network, the registration request message including a request to register to a group of one or more Single Network Slice Selection Assistance Information (S-NSSAI); receive a response to the registration request message, the response indicating that the request to register to the group of one or more S-NSSAIs is rejected; and locally store the group of one or more S-NSSAIs in a list of rejected NSSAIs at the UE.

Description

[0001] Priority claims / incorporation by reference

[0002] This application claims priority to U.S. Provisional Application Serial No. 63 / 263,412, filed November 2, 2021, entitled “Enhancements for User Equipment Network Slice Management,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to wireless communication systems and methods, including techniques for network slicing management. Background Technology

[0004] User equipment (UE) can connect to a network that deploys multiple network slices. Generally speaking, a network slice refers to an end-to-end logical network configured to provide specific services and / or have specific network characteristics. Each network slice can be isolated from each other, but operates on a shared network infrastructure. Therefore, each network slice can share network resources but facilitate different functions. Summary of the Invention

[0005] Some exemplary embodiments relate to a method performed by a user equipment (UE). The method includes: transmitting a registration request message to a network, the registration request message including a request to register to a set of one or more Single Network Slice Selection Assistive Information (S-NSSAI); receiving a response to the registration request message, the response indicating that the request to register to the set of one or more S-NSSAIs has been rejected; and locally storing the set of one or more S-NSSAIs in a list of rejected NSSAIs at the UE.

[0006] Other exemplary embodiments relate to a method performed by a user equipment (UE). The method includes: registering to a first public terrestrial mobile network (PLMN); establishing a packet data unit (PDU) session on first single network slice selection assistance information (S-NSSAI), the first S-NSSAI corresponding to the PLMN; registering to a second PLMN; receiving an allowed NSSAI corresponding to the second PLMN, the allowed NSSAI including a second S-NSSAI, wherein the first S-NSSAI is mapped to the second S-NSSAI; and updating the S-NSSAI associated with the PDU session from the first S-NSSAI to the second S-NSSAI.

[0007] Other exemplary embodiments relate to a method performed by a user equipment (UE). The method includes: registering to a first public land mobile network (PLMN); establishing a packet data unit (PDU) session on a first single network slice selection assistance information (S-NSSAI), the first S-NSSAI corresponding to a VPLMN; registering to a home PLMN (HPLMN); receiving an allowed NSSAI corresponding to the HPLMN, wherein the allowed NSSAI does not include an S-NSSAI matching the first S-NSSAI; and releasing the PDU session unless predetermined conditions are met.

[0008] Another exemplary implementation relates to a method performed by a user equipment (UE). The method includes: registering to a Home Public Land Mobile Network (HPLMN); receiving Allowed Network Slice Selection Assistance Information (NSSAI) from the HPLMMN; receiving a list of TAIs containing Tracking Area Identifiers (TAIs) belonging to the HPLMMN; receiving a Configuration Update Command (CUC) including an updated list of TAIs containing TAIs belonging to an Equivalent PLMN (EPLMN); and storing the allowed NSSAIs in a list of allowed NSSAIs for the EPLMN. Attached Figure Description

[0009] Figure 1 Exemplary network arrangements according to various exemplary implementations are shown.

[0010] Figure 2 Exemplary network architectures according to various exemplary implementations are shown.

[0011] Figure 3 Exemplary user equipment (UE) according to various exemplary embodiments are shown.

[0012] Figure 4 An exemplary base station according to various exemplary embodiments is shown.

[0013] Figure 5 The diagram illustrates a signaling diagram of a UE-initiated permitted Network Slice Selection Auxiliary Information (NSSAI) modification according to various exemplary implementations.

[0014] Figure 6 The diagram illustrates a signaling diagram of a permitted NSSAI modification initiated by a UE according to various exemplary implementations.

[0015] Figure 7 Signaling diagrams for S-NSSAI rejection according to various exemplary implementations are shown. Detailed Implementation

[0016] The exemplary embodiments can be further understood with reference to the following description and related figures, wherein similar elements have the same reference numerals. The exemplary embodiments introduce various enhancements to network slicing. In one aspect, the exemplary embodiments relate to network slice access. In another aspect, the exemplary embodiments relate to how a user equipment (UE) manages rejected Network Slice Selection Assistance Information (NSSAI). In another aspect, the exemplary embodiments relate to NSSAI mapping. In yet another aspect, the exemplary embodiments relate to how a UE manages permitted NSSAI for an Equivalent Public Land Mobile Network (EPLMN). Each of these exemplary aspects is described in more detail below.

[0017] The exemplary embodiments are described with respect to a UE. However, the term "UE" is used for illustrative purposes only. The exemplary embodiments can be utilized with any electronic component capable of establishing a connection to a network and configured with hardware, software, and / or firmware for exchanging information and data with that network. Therefore, the UE described herein is used to represent any suitable electronic component.

[0018] Exemplary implementations are also described with reference to fifth-generation (5G) networks that support network slicing. Generally, a network slice refers to a network architecture in which multiple end-to-end logical networks operate on a shared physical network infrastructure. Each network slice can be configured to provide a specific set of capabilities and / or features. Therefore, the physical infrastructure of a 5G network can be sliced ​​into multiple virtual networks, each configured for a different purpose. Throughout this specification, references to network slices can refer to any type of end-to-end logical network configured for a specific purpose and implemented on a 5G physical infrastructure.

[0019] Those skilled in the art will understand that 5G can support a wide variety of use cases, such as enhanced mobile broadband (eMBB), enhanced machine-type communications (eMTC), high-performance machine-type communications (HMTC), industrial IoT (IIoT), massive IoT (MIoT), ultra-reliable low-latency communications (URLLC), vehicle-to-everything (V2X), and so on. Each type of use case can involve various different types of applications and / or services. A network slice can be characterized by the type of use case, the type of application and / or service, or the entity providing the application and / or service via the network slice. Furthermore, operators can deploy multiple network slices for different vertical applications, and operator-specific applications can use different network slices. However, any examples of network slices characterized in a particular manner in this specification are provided for illustrative purposes only. Throughout this specification, references to network slices can refer to any type of end-to-end logical network configured for a particular purpose and implemented on a 5G physical infrastructure.

[0020] Network slices can be identified via a single Network Slice Selection Auxiliary Information (S-NSSAI). Each S-NSSAI instance can be associated with a Public Land Mobile Network (PLMN) and may include a Slice Service Type (SST) and a Slice Descriptor (SD). The SST identifies the expected behavior of the corresponding network slice in terms of services, functions, and characteristics. Those skilled in the art will understand that the SST can be associated with a standardized SST value. The SD identifies any one or more entities associated with the network slice. For example, the SD may indicate the owner or entity managing the network slice (e.g., an operator) and / or the entity providing applications / services via the network slice (e.g., a third party, an entity providing applications or services, etc.). In some embodiments, the same entity may own the network slice and provide services (e.g., operator services). Throughout this specification, S-NSSAI refers to a single network slice, and the terms "NSSAI" or "S-NSSAI" can be used interchangeably to refer to one or more network slices.

[0021] The UE can be configured to perform any of a variety of different tasks. Therefore, the UE can be configured to utilize one or more network slices. For example, the UE can serve one or more operators (e.g., voice, multimedia messaging service (MMS), the Internet, etc.) and utilize different second network slices for third-party services. However, the purpose of configuring network slices is beyond the scope of this exemplary embodiment. The exemplary embodiment is not limited to any particular type of network slice.

[0022] The examples described in this article may refer to the terms “allowed NSSAI,” “configured NSSAI,” “requested NSSAI,” and “denied NSSAI.” Before discussing exemplary enhancements, a brief description of each of these terms and how they relate to each other is provided below.

[0023] Those skilled in the art will understand that the term "permitted NSSAI" refers to the S-NSSAI provided by the network that a UE can use in a serving PLMN for a specific registration area. As will be detailed below, permitted NSSAI can be provided by the network to the UE during a registration process (e.g., a mobility registration update process or any other suitable type of registration process). Due to the relationship between registered NSSAI and permitted NSSAI, in some embodiments, the term "registered network slice" may be used interchangeably with permitted NSSAI to refer to the same concept.

[0024] To track allowed NSSAIs, the UE can manipulate a list of allowed NSSAIs stored locally at the UE, or employ any other suitable mechanism. The number of network slices that can be considered as allowed NSSAIs of the UE can be limited to a predetermined maximum number of allowed NSSAIs. For example, the 3GPP specification limits the maximum number of allowed NSSAIs to a length of 8 S-NSSAIs. However, exemplary implementations are not limited to the maximum number of allowed NSSAIs of 8 S-NSSAIs and can be applied to any suitable maximum number of allowed NSSAIs. In some cases, when an S-NSSAI is stored locally as an allowed NSSAI, the UE may attempt to establish a Packet Data Unit (PDU) session on the S-NSSAI. However, when an S-NSSAI is not considered part of an allowed NSSAI, the UE may ignore upper-layer requests for the S-NSSAI and the UE may not initiate PDU session establishment on the network slice.

[0025] Those skilled in the art will understand that the term "configured NSSAI" refers to an S-NSSAI provided in the UE and applicable to one or more PLMNs. To track configured NSSAIs, the UE can manipulate a list of configured NSSAIs stored locally at the UE, or employ any other suitable mechanism. When a network slice is stored locally as a configured NSSAI, the value of the S-NSSAI is known to the UE. When a network slice is not stored locally as a configured NSSAI, the UE may not know the value of the S-NSSAI. The number of configured NSSAIs can be limited to a predetermined maximum number. For example, the 3GPP specification limits the maximum number of configured NSSAIs to a length of 16 S-NSSAIs. However, exemplary embodiments are not limited to a maximum number of configured NSSAIs of 16 S-NSSAIs and can be applied to any suitable number. In some embodiments, the term "subscribed network slice" may be used interchangeably with configured NSSAI to refer to the same concept.

[0026] During operation, the number of configured NSSAIs stored locally at the UE may be greater than the number of allowed NSSAIs stored locally at the UE. Therefore, one or more S-NSSAIs may be considered by the UE as configured NSSAIs, rather than as part of the allowed NSSAIs. For example, S-NSSAI-A may be part of the list of configured NSSAIs stored locally at the UE, rather than the list of allowed NSSAIs stored locally at the UE. In such a configuration, the UE will not initiate a PDU session establishment on S-NSSAI-A because S-NSSAI-A is not part of the list of allowed NSSAIs. Throughout this specification, any reference to "S-NSSAI-A" is provided merely to distinguish one network slice from other network slices and is not intended to limit the exemplary implementation in any way.

[0027] Those skilled in the art will understand that the term "requested S-NSSAI" refers to the S-NSSAI provided to the network by the UE during the registration process. The network may then determine whether to allow the UE to register to each requested S-NSSAI. For example, the UE may store S-NSSAI-A as part of its configured S-NSSAIs. The UE may then transmit a registration request message to the network, indicating that the UE wishes to register to one or more network slices, such as S-NSSAI-A, etc. In response, the network may indicate that the requested S-NSSAI is an allowed S-NSSAI. The UE may then store S-NSSAI-A in the list of allowed S-NSSAIs.

[0028] Alternatively, in response to a requested NSSAI, the network may indicate that the request for S-NSSAI-A is rejected. For example, rejection might be due to a lack of available resources in the registration area or due to the inability to verify the UE's access to a specific network slice. The UE may subsequently treat S-NSSAI-A as a "rejected NSSAI". To track rejected NSSAIs, the UE may manipulate a list of rejected NSSAIs stored locally at the UE, or employ any other appropriate mechanism. In some cases, the UE may be configured to omit or ignore rejected NSSAIs during other operations and / or procedures. For example, under certain conditions, the UE cannot attempt to register on a network slice that is stored locally as part of a rejected NSSAI.

[0029] The examples above provide a general overview of the relationship between the terms “permitted NSSAI,” “configured NSSAI,” “requested NSSAI,” and “rejected NSSAI.” These examples are not intended to limit the scope of these terms or exemplary implementations in any way.

[0030] Some of the exemplary implementations are described in conjunction with a scenario where the UE wishes to access a network slice that is not part of a permitted NSSAI. To provide an example, consider a scenario where the UE is deployed within a PLMN and remains stationary for a relatively long period. Upon deployment, applications requiring connectivity to S-NSSAI-A may be downloaded to the UE. However, S-NSSAI-A is not part of a permitted NSSAI. Due to the UE's stable behavior, it may not trigger the UE to initiate a registration process. Therefore, the UE may not be able to obtain access to the desired network slice (e.g., S-NSSAI-A) for an unreasonable duration.

[0031] In normal circumstances, as in the examples provided above, even though the desired network slice is not part of the permitted NSSAI, the UE may not trigger a change to the permitted NSSAI, and the UE may not gain access to the desired network slice within an unreasonable timeframe. As will be detailed below, in one aspect, exemplary embodiments introduce techniques that enable the UE to initiate modifications to the permitted NSSAI. These techniques allow the UE to quickly gain access to the desired network slice, even when the network slice is not part of the permitted NSSAI.

[0032] On the other hand, exemplary embodiments involve managing rejected NSSAIs stored locally at the UE. Typically, the UE does not register with network slices stored in the rejected NSSAI list. Various conditions exist that could trigger the UE to remove a network slice from the rejected NSSAI list. However, it has been confirmed that, under normal circumstances, there may be scenarios where the UE should be able to access a specific network slice that was previously rejected, but nothing triggers the UE to remove the network slice from the rejected NSSAI list. Therefore, the UE can prevent itself from registering with network slices that are actually available to the UE and allow the UE to use them. As will be detailed below, exemplary embodiments introduce techniques that enable the UE to remove entries from the rejected NSSAI list stored locally at the UE.

[0033] On the other hand, exemplary implementations involve NSSAI mapping. Different PLMNs may interpret the same S-NSSAI value in different ways. It has been confirmed that during UE mobility from the home PLMN (HPLMN) to the visited PLMN (VPLMN) or vice versa, the UE does not adequately consider the S-NSSAI mapping. This can lead to inconsistencies between the UE and the network in how the S-NSSAI value is interpreted, potentially resulting in unpredictable behavior and a poor user experience through accidental PDU session deletion. Therefore, it may be necessary to map S-NSSAI values ​​across PLMNs to ensure adequate interpretation of the S-NSSAI value. As will be detailed below, exemplary implementations introduce techniques configured to improve how the UE manages S-NSSAI mapping across different PLMNs.

[0034] On the other hand, exemplary implementations relate to UEs managing permitted NSSAIs for EPLMNs. It has been confirmed that when managing permitted NSSAIs, the UE does not adequately consider Tracking Area Identifiers (TAIs) belonging to different PLMNs. As will be detailed below, exemplary implementations introduce techniques configured to improve the way UEs manage permitted NSSAIs for EPLMNs. Each of the exemplary enhancements described herein can be used independently of each other, in conjunction with currently implemented network slicing mechanisms, future implementations of network slicing mechanisms, or independently of other network slicing mechanisms. Specific examples of each of these exemplary enhancements are described in detail below.

[0035] Figure 1 An exemplary network arrangement 100 according to various exemplary embodiments is illustrated. The exemplary network arrangement 100 includes a UE 110. Those skilled in the art will understand that the UE 110 can be any type of electronic component configured to communicate via a network, such as a mobile phone, tablet computer, desktop computer, smartphone, phablet, embedded device, wearable device, Internet of Things (IoT) device, etc. It should also be understood that a practical network arrangement can include any number of UEs used by any number of users. Therefore, for illustrative purposes, only an example with a single UE 110 is provided.

[0036] UE 110 can be configured to communicate with one or more networks. In the example of network arrangement 100, the network with which UE 110 can wirelessly communicate is the 5G NR Radio Access Network (RAN) 120. However, UE 110 can also communicate with other types of networks (e.g., 5G cloud RAN, next-generation RAN (NG-RAN), LTE RAN, legacy cellular networks, wireless local area networks (WLANs), etc.), and UE 110 can also communicate with the network via a wired connection. Regarding an exemplary implementation, UE 110 can establish a connection with the 5G NR RAN 120. Therefore, UE 110 may have a 5G NR chipset to communicate with the 5G NR RAN 120.

[0037] The 5G NR RAN 120 can be part of a cellular network that can be deployed by network operators (e.g., Verizon, AT&T, T-Mobile, etc.). The 5G NR RAN 120 may include, for example, nodes, cells, or base stations (e.g., Node B, eNodeB, HeNB, eNBS, gNB, gNodeB, macrocell base station, microcell base station, small cell base station, femtocell base station, etc.) configured to send and receive communication services from UEs equipped with appropriate cellular chipsets.

[0038] Those skilled in the art will understand that any relevant procedures can be performed for UE 110 to connect to 5G NR-RAN 120. For example, as described above, 5G NR-RAN 120 can be associated with a specific cellular provider, where UE 110 and / or its user have protocol and credential information (e.g., stored on a SIM card). Upon detecting the presence of 5G NR-RAN 120, UE 110 can transmit the corresponding credential information to associate with 5G NR-RAN 120. More specifically, UE 110 can be associated with a specific base station (e.g., Next Generation Node B (gNB) 120A).

[0039] Network deployment 100 also includes a cellular core network 130, an Internet 140, an IP Multimedia Subsystem (IMS) 150, and a network services backbone 160. The cellular core network 130 can refer to an interconnected set of components that manage the operation and traffic of the cellular network. It may include an evolved packet core (EPC) and / or a fifth-generation core (5GC). The cellular core network 130 also manages the traffic flowing between the cellular network and the Internet 140. The IMS 150 can generally be described as an architecture for delivering multimedia services to the UE 110 using IP protocols. The IMS 150 can communicate with the cellular core network 130 and the Internet 140 to provide multimedia services to the UE 110. The network services backbone 160 communicates directly or indirectly with the Internet 140 and the cellular core network 130. The network services backbone 160 can generally be described as a set of components (e.g., servers, network storage deployments, etc.) that implement a set of services that can be used to extend the functionality of the UE 110 to communicate with various networks.

[0040] Figure 2 An exemplary network architecture 200 according to various exemplary embodiments is illustrated. The following description will provide a general overview of the various components of the exemplary architecture 200. Specific operations performed by the components with respect to the exemplary embodiments will be described in more detail after the description of architecture 200.

[0041] Those skilled in the art will understand that the components of the exemplary architecture 200 can be relative to... Figure 1 The network deployment 100 resides in various physical and / or virtual locations. These locations may include: within the access network (e.g., RAN 120), within the core network 130, as a basis for... Figure 1 Individual components other than those mentioned above.

[0042] exist Figure 2In this specification, various components are shown connected via connections labeled Nx (e.g., N1, N2, N11). Those skilled in the art will understand that each of these connections (or interfaces) is defined in the 3GPP specification. Exemplary architecture 200 uses these connections in the manner defined in the 3GPP specification. Furthermore, while these interfaces are referred to as connections throughout the specification, it should be understood that these interfaces do not need to be direct wired or wireless connections; for example, these interfaces may communicate via intermediate hardware and / or software components. For example, UE 110 may exchange signals with gNB 120A via radio. However, in architecture 200, UE 110 is shown as having a connection to AMF 205. This connection or interface is not a direct communication link between UE 110 and AMF 205; rather, it is a connection facilitated by intermediate hardware and software components. Therefore, throughout the specification, the terms "connection" and "interface" are used interchangeably to describe the Nx interfaces between various components.

[0043] Architecture 200 includes UE 110 and 5G NR RAN 120. UE 110 and 5G NR RAN 120 are connected to Access and Mobility Management Function (AMF) 205. AMF 205 is typically responsible for connectivity and mobility management within 5G NR RAN 120. Those skilled in the art will understand that AMF 205 is a control plane function and performs operations related to registration and connectivity management. For example, AMF 205 can perform operations related to registration management between UE 110 and core network 130. Exemplary embodiments are not limited to AMFs performing the operations described above. Those skilled in the art will understand that AMFs can perform various different types of operations. Furthermore, references to a single AMF 205 are for illustrative purposes only, and actual network deployments may include any appropriate number of AMFs.

[0044] AMF 205 connects to Session Management Function (SMF) 210. SMF 210 performs operations related to session management, such as, but not limited to, session establishment, session release, IP address allocation, policy and QoS enforcement. During operation, UE 110 and SMF 210 can exchange PDU session establishment requests and PDU session establishment responses. Exemplary implementations are not limited to SMFs performing the above operations. Those skilled in the art will understand that various different types of operations can be performed by an SMF. Furthermore, the reference to a single SMF 210 is merely illustrative; actual network deployments may include any appropriate number of SMFs.

[0045] Figure 3 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1The network layout 100 is used to describe UE 110. UE 110 may include a processor 305, a memory layout 310, a display device 315, an input / output (I / O) device 320, a transceiver 325, and other components 330. Other components 330 may include, for example, audio input devices, audio output devices, power sources, data acquisition devices, ports for electrically connecting UE 110 to other electronic devices, etc.

[0046] Processor 305 can be configured to execute multiple engines of UE 110. For example, engines may include an allowed NSSAI engine 335, a rejected NSSAI engine 340, and an NSSAI mapping engine 345. The allowed NSSAI engine 335 can perform various operations related to managing allowed NSSAI stored locally at UE 110, including but not limited to initiating modifications to allowed NSSAI and managing allowed NSSAI for EPLMN. The rejected NSSAI engine 340 can perform various operations related to managing rejected NSSAI stored locally at UE 110. The NSSAI mapping engine 345 can perform various operations related to tracking NSSAI mappings across different PLMNs.

[0047] The engines 335 to 345 described above are provided for illustrative purposes only as applications (e.g., programs) executed by processor 305. The functionality associated with engines 335 to 345 may also be represented as separate integrated components of UE 110, or as modular components coupled to UE 110, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. Engines may also be embodied as a single application or multiple separate applications. Furthermore, in some UEs, the functionality described for processor 305 is distributed among two or more processors (such as a baseband processor and an application processor). Exemplary implementations may be implemented according to any of these or other configurations of the UE.

[0048] Memory arrangement 310 may be a hardware component configured to store data related to operations performed by UE 110. Display device 315 may be a hardware component configured to display data to a user, while I / O device 320 may be a hardware component enabling user input. Display device 315 and I / O device 320 may be separate components or may be integrated together (such as a touchscreen). Transceiver 325 may be a hardware component configured to establish connections with 5G NR-RAN 120, LTE-RAN (not shown), legacy RAN (not shown), WLAN (not shown), etc. Therefore, transceiver 325 may operate on a variety of different frequencies or channels (e.g., consecutive frequency groups).

[0049] Figure 4 An exemplary base station 400 according to various exemplary embodiments is shown. Base station 400 may represent a gNB 120A or any other access node that UE 110 can use to establish connections and manage network operations.

[0050] Base station 400 may include processor 405, memory arrangement 410, input / output (I / O) devices 415, transceiver 420, and other components 425. These other components 425 may include, for example, audio input devices, audio output devices, batteries, data acquisition devices, ports for electrically connecting base station 400 to other electronic devices, etc.

[0051] Processor 405 may be configured to execute multiple engines of base station 400. For example, an engine may include network fragmentation engine 430. Network fragmentation engine 430 may perform various operations related to enabling network fragmentation, including but not limited to facilitating communication between UE 110 and various network components (e.g., AMF 205, SMF 210, etc.).

[0052] The engine 430 described above, as an application (e.g., a program) executed by the processor 405, is merely exemplary. Functions associated with the engine 430 may also be represented as separate components of the base station 400, or as modular components coupled to the base station 400, such as integrated circuits with or without firmware. For example, the integrated circuit may include input circuitry for receiving signals and processing circuitry for processing signals and other information. Furthermore, in some base stations, the functions described for the processor 305 are distributed among multiple processors (e.g., a baseband processor, an application processor, etc.). Exemplary implementations can be implemented according to any of these or other configurations of the base station.

[0053] Memory 410 may be a hardware component configured to store data related to operations performed by base station 400. I / O device 415 may be a hardware component or port enabling a user to interact with base station 400. Transceiver 420 may be a hardware component configured to exchange data with UE 110 and any other UE in network arrangement 100. Transceiver 420 may operate on a variety of different frequencies or channels (e.g., a set of consecutive frequencies). Therefore, transceiver 420 may include one or more components (e.g., radio components) to enable data exchange with various networks and UEs.

[0054] During operation, UE 110 may wish to obtain access to a network slice that is not part of an authorized NSSAI for any of a variety of reasons. To provide some examples, an application may be installed on UE 110, or a specific feature requiring connectivity to a particular network slice may be activated by an upper layer of UE 110. Under normal circumstances, if the desired network slice is not part of an authorized NSSAI, UE 110 may not be able to obtain access to the desired network slice for an unreasonable amount of time.

[0055] In one aspect, exemplary embodiments introduce techniques that enable the UE to initiate modifications to permitted NSSAIs. Signaling diagram 500 illustrates an example of a UE-initiated permitted NSSAI modification where the desired network slice is part of a configured NSSAI but not a permitted NSSAI. Signaling diagram 600 illustrates an example of a UE-initiated permitted NSSAI modification where the desired network slice is neither part of a configured NSSAI nor a permitted NSSAI. Even when the network slice is not part of a permitted NSSAI, these techniques allow the UE 110 to quickly gain access to the desired network slice.

[0056] Figure 5 Signaling diagram 500 is shown, illustrating a permitted NSSAI modification initiated by a UE according to various exemplary embodiments. Signaling diagram 500 includes UE 110, AMF 205, and SMF 210. In some examples, reference may be made to the application processor and baseband processor when describing operations performed by UE 110. However, these examples are not intended to limit the exemplary embodiments in any way. UE 110 may use any suitable combination of hardware, software, and / or firmware to perform the operations described herein.

[0057] In 505, UE 110 identifies a desired network slice (e.g., S-NSSAI-A) as part of a configured NSSAI but not a permitted NSSAI. For example, consider a scenario where UE 110 is deployed within a PLMN and has already been provided with permitted NSSAIs by the network. S-NSSAI-A is provided to UE 110 and has been locally stored as a configured NSSAI. However, at this point, S-NSSAI-A is not part of a permitted NSSAI. An application mapped to S-NSSAI-A can then be installed on UE 110. However, the exemplary implementation is not limited to this scenario, and UE 110 may wish to gain access to the desired network slice for any appropriate reason.

[0058] Continuing with the example provided above, in some implementations, the application processor may determine that a new application requiring connectivity to S-NSSAI-A has been installed. The application processor may then send a request to the baseband processor to access the desired S-NSSAI-A. The baseband processor may detect that UE 110 has subscribed to S-NSSAI-A but has not registered with S-NSSAI-A.

[0059] In 510, UE 110 triggers a mobility registration update procedure to register to the desired network slice. As will be detailed below in conjunction with 515, UE 110 may transmit a registration request message to AMF 205 as part of the mobility registration update procedure. This registration request message includes an NSSAI request containing the desired network slice (e.g., S-NSSAI-A).

[0060] One or more triggering conditions for the mobility registration update process in 510 are configured to balance the functionality and / or user experience of network slices already registered on UE 110 and desired network slices. As described above, an exemplary triggering condition for the mobility registration update process may include a request to an upper layer (e.g., an application processor) for an NSSAI that includes one or more S-NSSAIs that are not present in the allowed NSSAIs in local storage but are included as part of the configured NSSAIs in local storage. In other words, the mobility registration update process may be triggered in response to detecting that UE 110 has subscribed to but not registered to one or more S-NSSAIs corresponding to an application running on UE 110.

[0061] One or more trigger conditions may also include conditions related to the currently stored allowed NSSAIs. An exemplary trigger condition could be that the number of stored allowed NSSAIs is less than a predetermined maximum number of allowed NSSAIs. Another exemplary trigger condition could be that the list of allowed NSSAIs does not include S-NSSAIs corresponding to new applications or features as indicated in the upper-layer request for the NSSAI. This may indicate that UE 110 is maintaining registration with S-NSSAIs that are unlikely to be utilized by UE 110 when the currently registered network slice does not match the NSSAIs requested by the upper layer.

[0062] One or more triggering conditions may also include conditions related to the 5G Mobility Management (5GMM) operating mode of UE 110. Those skilled in the art will understand that UE 110 can be configured in one of several different 5GMM operating modes. When UE 110 is in 5GMM connected mode, UE 110 may not trigger the mobility registration update process to register to the desired network slice. However, when UE 110 is in 5GMM idle mode, UE 110 may trigger the registration process to register UE 110 to the desired network slice.

[0063] In step 515, UE 110 transmits a registration request message to AMF 205. The registration request message may include an NSSAI (e.g., S-NSSAI-A) requesting the desired network slice. In step 520, AMF 205 transmits a registration acceptance message to UE 110. The registration acceptance message may include an allowed NSSAI for the desired network slice S-NSSAI-A. At this point, UE 110 is now registered to S-NSSAI-A and can establish a PDU session on that network slice. Therefore, in step 525, UE 110 transmits a PDU session establishment request to SMF 210 to establish a PDU session on network slice S-NSSAI-A.

[0064] Continuing with the example above, in some implementations, the baseband processor may send an updated list of allowed NSSAIs to the application processor. The application processor may then detect that the S-NSSAI-A is available for the corresponding application and send a request to the baseband processor to establish a data call with a remote server on the S-NSSAI-A.

[0065] In 530, SMF 210 transmits a registration acceptance message to UE 110, indicating that a PDU session has been established on network slice S-NSSAI-A. However, the PDU session establishment process mentioned above is provided for illustrative purposes only. The exemplary enhancements described in signaling diagram 500 target modified permitted NSSAIs, and what happens after UE 110 registers to the desired network slice is beyond the scope of the exemplary implementation.

[0066] Figure 6 Signaling diagram 600 illustrates a permitted NSSAI modification initiated by a UE according to various exemplary embodiments. Signaling diagram 600 includes UE 110, AMF 205, and SMF 210. In some examples, reference may be made to the application processor and baseband processor when describing operations performed by UE 110. However, these examples are not intended to limit the exemplary embodiments in any way. UE 110 may use any suitable combination of hardware, software, and / or firmware to perform the operations described herein.

[0067] In case 605, UE 110 identifies that the desired network slice (e.g., S-NSSAI-A) is not part of the configured NSSAI. For example, consider a scenario where UE 110 is deployed within a PLMN, a configured NSSAI is prepared, and the network provides permitted NSSAIs. However, S-NSSAI-A is not prepared for UE 110. An application mapped to S-NSSAI-A is subsequently installed on UE 110; however, S-NSSAI-A is not part of the NSSAI configured for UE 110. Exemplary implementations are not limited to this scenario, and UE 110 may wish to gain access to the desired network slice for any appropriate reason.

[0068] Continuing with the example described above, in some implementations, the application processor may determine that a new application requiring connectivity to S-NSSAI-A has been installed. The application processor may then send a request to the baseband processor to access the desired S-NSSAI-A. The baseband processor may then detect that UE 110 is not subscribed to S-NSSAI-A.

[0069] In 610, AMF 205 transmits the configured NSSAI, including the desired network slice (e.g., S-NSSAI-A), to UE 110. AMF 205 may transmit the configured NSSAI to UE 110 in response to an explicit request from UE 110 or in response to other conditions experienced by UE 110 and / or the network. In one example, UE 110 performs an initial registration with the NR network to receive the configured NSSAI. In another example, the UE receives a newly configured NSSAI due to a switch from LTE Radio Access Technology (RAT) to 5G NR RAT. In yet another example, the network transmits the newly configured NSSAI in a Registration Acceptance Message or Configuration Update Command (CUC) in response to a user subscribing to a desired network slice. However, exemplary embodiments are not limited to these examples, and UE 110 may receive the configured NSSAI in any suitable manner.

[0070] In 615, UE 110 identifies that the desired network slice (e.g., S-NSSAI-A) is part of a configured NSSAI but not part of an allowed NSSAI. In 620, UE 110 triggers a mobility registration update procedure to register to the desired network slice. As will be detailed below in conjunction with 625, UE 110 may transmit a registration request message to AMF 205 as part of the registration procedure, the registration request message including a requested NSSAI containing the desired network slice (e.g., S-NSSAI-A).

[0071] One or more triggering conditions for the mobility registration update process in 620 are configured to balance the functionality and / or user experience of the currently registered network slice and the desired network slice. As described above, an exemplary triggering condition for the mobility registration update process may include receiving an S-NSSAI from the network that was previously requested by an upper layer (e.g., an application processor) for a configured NSSAI. In other words, the mobility registration update process may be triggered in response to detecting that UE 110 has now subscribed to a network slice previously requested by an upper layer.

[0072] One or more trigger conditions may also include conditions related to the currently stored allowed NSSAIs. An example trigger condition could be that the number of stored allowed NSSAIs is less than a predetermined maximum number of allowed NSSAIs. Another example trigger condition could be that the S-NSSAIs included in the list of allowed NSSAIs are not included in the upper-level request for the NSSAI.

[0073] One or more triggering conditions may also include conditions related to the 5GMM operating mode of UE 110. When UE 110 is in 5GMM connected mode, UE 110 may not trigger the mobility registration update procedure to register to the desired network slice. However, when UE 110 is in 5GMM idle mode, UE 110 may trigger the registration procedure to register UE 110 to the desired network slice.

[0074] In step 625, UE 110 transmits a registration request message to AMF 205. The registration request message may include an NSSAI (e.g., S-NSSAI-A) containing a request for the desired network slice. In step 630, AMF 205 transmits a registration acceptance message to UE 110. The registration acceptance message may include an allowed NSSAI containing the desired network slice S-NSSAI-A. At this point, UE 110 is now registered to S-NSSAI-A and can establish a PDU session on that network slice. Therefore, in step 635, UE 110 transmits a PDU session establishment request to SMF 210 to establish a PDU session network slice S-NSSAI.

[0075] Continuing with the example above, in some implementations, the baseband processor may send an updated list of allowed NSSAIs to the application processor. The application processor may then detect that the S-NSSAI-A is available for the corresponding application and send a request to the baseband processor to establish a data call with a remote server on the S-NSSAI-A.

[0076] In 640, SMF 210 transmits a registration acceptance message to UE 110, indicating that a PDU session has been established on network slice S-NSSAI-A. However, the PDU session establishment process mentioned above is provided for illustrative purposes only. The exemplary enhancements described in signaling diagram 600 target modified permitted NSSAIs, and what happens after UE 110 registers to the desired network slice is beyond the scope of the exemplary implementation.

[0077] As described above, one of the triggering conditions for a UE-initiated permitted NSSAI modification can be 5GMM idle mode. For example, UE 110 may initiate a mobility registration update procedure in 5GMM idle mode to register to the new NSSAI list based on i) changes in the network slice requested by the policy upper layer and / or ii) an updated configured NSSAI list received by UE 110 as part of a configuration update command (CUC) or registration acceptance message.

[0078] In some implementations, for initial registration accepted by the network, if the registration acceptance message contains a Network Fragmentation Subscription Change Indicator (IE) set to "Network Fragmentation Subscription Changed", or contains an NSSAI IE with a new NSSAI configuration for the current PLMN, then UE 110 may wait until it enters 5GMM idle mode, and then UE 110 may initiate a mobility registration update procedure to register to a new NSSAI group based on the new NSSAI configuration.

[0079] In some implementations, for a mobility registration update accepted by the network, if it includes an NSSAI for a new configuration for the current PLMN, the AMF 205 may also include an S-NSSAI mapped to the NSSAI for the current PLMN (if available) in the registration acceptance message. In this case, the UE 110 may wait until it enters 5GMM idle mode, and the UE 110 may initiate a registration process for the mobility registration update to register to a new NSSAI group based on the new NSSAI configuration.

[0080] In some implementations, the triggering conditions for the mobility registration update process may also include the state of a 5G system (5GS) mobility management timer. In this example, the timer is referred to as "T3540," which is defined in various 3GPP specifications. The exemplary implementation introduces a technique for using this timer in an exemplary UE-initiated permitted NSSAI modification process. However, the exemplary implementation is not limited to the T3540 timer and new timers or any other suitable mechanism may be introduced for this purpose.

[0081] In one example, if UE 110 receives a Configuration Update Command (CUC) message that does not indicate "Registration Requested" in the registration request bit of the Configuration Update Indicator (IE), UE 110 may initiate T3540. Upon T3540 expiration (and reaching zero or several other triggering conditions), UE 110 may initiate a mobility registration update procedure to register to a network slice based on the newly configured NSSAI. For example, in the context of signaling diagram 600, UE 110 may receive a CUC message and initiate T3540 in 610. In 620, UE 110 may trigger the mobility registration update procedure at least in part based on the expiration of T3540.

[0082] Timer T3540 can also be used to release N1 Non-Access Stratum (NAS) signaling connections. In some implementations, T3540 can be triggered if i) no CUC message indicating "registration requested" is included in the registration request bit of the Configuration Update Indicator (IE), ii) no user plane resources for the PDU session are set, and / or iii) no emergency PDU session is established.

[0083] After T3540 begins, UE 110 can be triggered to stop the timer and perform specific operations. For example, based on an indication from a lower layer that the access layer connection has been released, UE 110 can stop T3540 and perform a new registration procedure. In another example, based on an indication from a lower layer that user plane resources have been set up for a PDU session, the UE can stop T3540 and send user data via the user plane. In this scenario, a new registration procedure can be performed when UE 110 moves to 5GMM idle mode. In another example, based on a request to perform an emergency service rollback received from an upper layer when UE 110 is configured with 3GPP access or has established an emergency PDU session, UE 110 can stop T3540 and locally release the N1 NAS signaling connection.

[0084] In signaling diagrams 500 to 600, UE 110 does not need to wait for network or mobility conditions to trigger network slice registration for the desired network slice. Instead, the exemplary implementation provides fast access to the desired network slice by enabling UE 110 to initiate modifications to the permitted NSSAI when UE 110 wishes to access a network slice that is not part of a permitted NSSAI.

[0085] On the other hand, an exemplary implementation relates to UE 110 managing a rejected NSSAI. As described above, AMF 205 may reject a requested network slice during the registration process. For example, AMF 205 may transmit a message including a rejection reason code in response to a requested S-NSSAI. The rejection reason code may indicate the reason for the rejection, such as S-NSSAI being unavailable in the current PLMN, S-NSSAI being unavailable in the current registration area, etc.

[0086] UE 110 can operate on a list of rejected NSSAIs stored locally on UE 110. Typically, if an S-NSSAI is stored as part of a list of rejected NSSAIs, UE 110 cannot register to a network slice. For example, if an S-NSSAI is part of a list of rejected NSSAIs, UE 110 can ignore or omit the S-NSSAI requested by the upper layer for subsequent operations.

[0087] UE 110 may not register on a network slice stored in the list of rejected NSSAIs until that network slice is removed from the list. Under normal circumstances, UE 110 may not remove S-NSSAI from the list of rejected NSSAIs in a timely manner. This can lead to scenarios where S-NSSAI-A is rejected by the network during registration, but the conditions have changed and the reason for rejection is no longer valid. In such scenarios, UE 110 should be able to access the network slice, but since nothing triggers UE 110 to remove S-NSSAI from the list of rejected NSSAIs, UE 110 continues to behave as if the network slice is unavailable. As will be detailed below, the exemplary implementation introduces a technique for handling rejected NSSAIs that enables UE 110 to avoid the aforementioned scenario types that may occur under normal circumstances.

[0088] Figure 7 Signaling diagram 700 for S-NSSAI rejection according to various exemplary embodiments is shown. Signaling diagram 700 includes UE 110 and AMF 205. Signaling diagram 700 provides a general overview of network slice rejection and is used to provide context for exemplary enhancements for managing rejected NSSAIs at UE 110. In this example, references to PLMN_1 and S-NSSAI-A are not intended to limit the exemplary embodiments in any way. Rather, PLMN_1 is used to distinguish one PLMN from other PLMNs. Similarly, S-NSSAI-A is used to distinguish one S-NSSAI from other S-NSSAIs.

[0089] In 705, UE 110 transmits a registration request message to AMF 205. The registration request message may include an NSSAI containing at least the S-NSSAI-A request.

[0090] In 710, AMF 205 transmits a response to a registration request message (e.g., registration accepted, registration rejected, etc.) that includes an indication of a rejected network slice. For example, the response may include a rejection reason code associated with S-NSSAI-A, indicating why the network does not accept UE 110's registration request for S-NSSAI-A. For the sake of illustration, the rejection reason code may indicate that S-NSSAI is unavailable in the current PLMN or that S-NSSAI is unavailable in the current registration area. In other examples, the rejection reason code may indicate that the network slice quota has been reached. However, these examples are provided for illustrative purposes only, and the basis for network rejection of network slices is beyond the scope of the exemplary implementation.

[0091] One exemplary technique relates to a scenario where UE 110 is registered in PLMN_1 and has a list of rejected NSSAIs for PLMN_1. For example, UE 110 may receive rejected NSSAIs for PLMN_1 at 710 of signaling diagram 700.

[0092] UE 110 also receives a network fragmentation indication IE in the registration accept message or CUC message where the network fragmentation subscription change indication is set to "Network fragmentation subscription has changed". In response, UE 110 can be triggered to perform mobility registration on PLMN_1.

[0093] On the network side, a change in UE 110's subscription information can be detected. This change indicates that UE 110 is now allowed access to a previously rejected network slice (e.g., S-NSSAI-A). However, under normal circumstances, this may not trigger UE 110 to remove the rejected NSSAI list for the current PLMN (e.g., PLMN_1). Furthermore, there may be no direct mechanism available on the network to request UE 110 to remove a rejected NSSAI. Therefore, even if UE 110 should be able to access S-NSSAI-A because the network slice is no longer considered a rejected NSSAI on the network side, UE 110 may still be unable to access the network slice because it has not been removed from the list of rejected NSSAIs.

[0094] An exemplary implementation introduces a technique in which UE 110 deletes rejected NSSAIs (if any) when it receives an indication of a change in subscription information from the network. For example, when UE 110 receives a Network Fragmentation Subscription Change Indicator (IE) set to "Network Fragmentation Subscription Changed" in a Registration Acceptance message or a CUC message, UE 110 may delete the network fragmentation information of each PLMN in which UE 110 has stored fragmentation information (excluding the current PLMN), and UE 110 may also delete any rejected NSSAIs (if any).

[0095] Another exemplary technique relates to a scenario where UE 110 is registered to PLMN_1 and has a list of rejected NSSAIs for PLMN_1. For example, UE 110 may receive rejected NSSAIs for PLMN_1 at 710 of signaling diagram 700. UE 110 also performs an inter-RAT (IRAT) transition from N1 mode to S1 mode and remains in 5GMM registration state. Those skilled in the art will understand that N1 mode is the mode in which UE 110 is allowed to access the 5G core network via the 5G access network, while S1 mode is the mode in which UE 110 applies to both 5G System (5GS) and Evolved Packet System (EPS). Due to a change in user subscription, one or more network slices stored in the list of rejected NSSAIs for PLMN_1 are no longer considered rejected NSSAIs by the 5GS network. In response, UE 110 performs an IRAT transition to move to N1 mode and triggers mobility registration.

[0096] On the network side, changes to UE 110's subscription information can be detected. This change indicates that UE 110 is now allowed access to a previously rejected network slice (e.g., S-NSSAI-A). Normally, when IRAT transitions to S1 mode, UE 110 may not remove the rejected NSSAI for PLMN_1; therefore, when IRAT transitions to N1 mode, UE 110 may not include the rejected NSSAI. Consequently, UE 110 cannot obtain access to network slices that were previously rejected but have now been removed from the rejected NSSAI by the network.

[0097] An exemplary implementation introduces a technique in which, when UE 110 performs an IRAT transition from N1 mode to S1 mode and UE 110 is not registered with the current PLMN through another access, the rejected NSSAI for the current PLMN and the rejected NSSAI for failed or revoked Network Slice Specific Authentication and Authorization (NSSAA) should be deleted by UE 110. In another technique, when UE 110 performs an IRAT transition from N1 to S1 mode, the rejected NSSAI for the current registration area corresponding to the access type should be deleted by UE 110.

[0098] Another exemplary technique relates to a scenario where UE 110 is registered in PLMN_1 and has a list of rejected NSSAIs for PLMN_1. For example, UE 110 may receive rejected NSSAIs for PLMN_1 at 710 of signaling diagram 700.

[0099] UE 110 also receives a CUC message indicating that the registration request bit of the configuration update indicator IE is set to "registration requested" and contains no other parameters. In response, UE 110 may trigger mobility registration on PLMN_1.

[0100] On the network side, the allowed NSSAIs may change. Under normal circumstances, UE 110 may not delete rejected NSSAIs used for the current PLMN, and may even want UE 110 to delete allowed NSSAIs. However, in the scenario described above, UE 110 may not use rejected NSSAIs for subsequent registration, which could result in the user still being unable to access the slice despite changes in the allowed NSSAIs on the network side.

[0101] An exemplary implementation introduces a technique in which UE 110 can remove a rejected NSSAI if UE 110 receives a CUC message in which the registration request bit of the Configuration Update Indicator IE is set to "registration requested" and does not contain other parameters.

[0102] Another exemplary technique involves two different scenarios. In one scenario, UE 110 is registered in PLMN_1 and has a list of rejected NSSAIs for PLMN_1. For example, UE 110 may receive a rejected NSSAI for PLMN_1 at 710 of signaling diagram 700. UE 110 then attempts to perform mobility registration on a different PLMN (e.g., PLMN_2) and receives a registration rejection message with reason code #62 (e.g., no network slice available) and a list of rejected NSSAIs for PLMN_2. UE 110 remains in 5GMM registration status.

[0103] In the exemplary scenario described above, after an unsuccessful registration in the new PLMN, it may be desirable for UE 110 to delete the rejected NSSAI upon deregistration. However, under normal circumstances, UE 110 may not delete the rejected NSSAI and may retain the rejected NSSAI used for PLMN_1 and the rejected NSSAI used for PLMN_2.

[0104] In the second scenario, UE 110 is registered in PLMN_1 and receives rejection reason code #62, which has a rejected NSSAI containing all network slices rejected for PLMN_1. When reason code #62 is received on the current PLMN, UE 110 may not have any other network slices to register with and UE 110 may disable N1 mode. In response, UE 110 performs an IRAT transition to S1 mode.

[0105] In the above exemplary scenario, after an unsuccessful registration in the current PLMN due to a 5GMM reason other than cause code #62, it is desirable for UE 110 to delete the rejected NSSAI when cancelling registration. However, in the above scenario, UE 110 does not delete the rejected NSSAI and may retain the rejected NSSAI used for PLMN_1.

[0106] An exemplary implementation introduces a technique for NSSAI storage, wherein when UE 110 enters a 5GMM deregistration state after an unsuccessful registration for the current PLMN due to a 5GMM reason other than cause code #62 (e.g., no available network slice), UE 110 may delete the rejected NSSAI for the current PLMN and the rejected NSSAI for the failed or revoked NSSAA, unless N1 mode is disabled as part of processing cause code #62. In another technique, when UE 110 enters a 5GMM deregistration state or a 5GMM registration state after an unsuccessful registration to a new PLMN, UE 110 may delete the rejected NSSAI for the current PLMN and the rejected NSSAI for the failed or revoked NSSAA.

[0107] On the other hand, exemplary implementations involve NSSAI mapping. NSSAIs with similar functionality may have different values ​​across different PLMNs. Each S-NSSAI in the HPLMN is mapped to a corresponding S-NSSAI in the VPLMN, depending on the VPLMN operator's policies and configuration. It has been confirmed that during UE mobility from an HPLMN to a VPLMN or vice versa, UE 110 may not adequately consider NSSAI mapping. This can lead to inconsistencies between the UE and the network, potentially resulting in unpredictable behavior (e.g., release of PDU sessions, etc.) and a poor user experience.

[0108] To provide an example, consider a scenario where UE 110 is registered in an HPLMN and has an ongoing PDU session with S-NSSAI-A but no corresponding mapped S-NSSAI. UE 110 then roams to a VPLMN, registers on the VPLMN, and receives allowed NSSAIs including S-NSSAI-B and the corresponding mapped NSSAI S-NSSAI-A. Under normal circumstances, UE 110 may not update the local S-NSSAI associated with the PDU session, resulting in inconsistency between UE 110 and the network.

[0109] To provide another example, consider a scenario where UE 110 is registered in the VPLMN and has an ongoing PDU session with S-NSSAI-B, as well as an S-NSSAI that is the corresponding mapping to S-NSSAI-A. UE 110 then returns to the HPLMMN, registers on the HPLMMN, and receives an allowed NSSAI with S-NSSAI-A but no corresponding mapping to S-NSSAI. Under normal circumstances, UE 110 may not update the local S-NSSAI associated with the PDU session, resulting in inconsistency between UE 110 and the network.

[0110] As will be detailed below, the exemplary implementation introduces a technique configured to improve how a UE manages NSSAI mappings across different PLMNs. For an active PDU session in UE 110, if the allowed NSSAI contains an HPLMN S-NSSAI that matches the HPLMN S-NSSAI of the PDU session (e.g., a mapped S-NSSAI, if available), then UE 110 should locally update the S-NSSAI associated with the PDU session to the corresponding S-NSSAI received in the allowed NSSAI. If the allowed NSSAI does not contain an HPLMN S-NSSAI that matches the HPLMN S-NSSAI of the PDU session (e.g., a mapped S-NSSAI, if available), then UE 110 may perform a local release of the PDU session, except in the following cases: emergency PDU sessions (if any), and PDU sessions established when UE 110 is registered for new user bootstrapping services in a Standalone Non-Public Network (SNPN) (if any).

[0111] In some implementations, AMF 205 can also determine which PDU session is no longer supported based on the new allowed NSSAI, and it will indicate in the PDU session state IE which PDU session will be released locally on the network side or trigger SMF 210 to initiate the release via 5G session management signaling. In some exemplary implementations, if a network slice (e.g., S-NSSAI) is no longer available under the same AMF, the AMF indicates to the SMF which PDU session ID corresponding to the relevant S-NSSAI will be released, and the SMF releases the PDU session. In other exemplary implementations, if a network slice (e.g., S-NSSAI) is no longer available when the AMF changes (e.g., due to a change in registration area), the new AMF indicates to the old AMF that the PDU session corresponding to the relevant S-NSSAI will be released. The old AMF notifies the corresponding SMF to release the indicated PDU session. The new AMF then modifies the PDU session state accordingly. After receiving the call state in the registration accept message, the PDU session context is released locally in the UE.

[0112] On the other hand, an exemplary implementation involves a UE managing permitted NSSAIs for an equivalent PLMN (EPLMN). It has been confirmed that when managing permitted NSSAIs, the UE does not adequately consider TAIs belonging to different PLMNs. For example, consider a scenario where UE 110 is registered in an HPLMN, has permitted NSSAIs, and a list of TAIs containing TAIs belonging to the HPLMN. UE 110 then receives a CUC message containing an updated list of TAIs belonging to different PLMNs that are EPLMNs, and new permitted NSSAIs now exist. Normally, UE 110 may not update the list of permitted NSSAIs associated with those EPLMNs.

[0113] The exemplary implementation introduces a technique configured to improve how a UE manages allowed NSSAIs for an EPLMN. If UE 110 receives a new TAI list in a CUC message, UE 110 may treat the new TAI list as valid and the old TAI list as invalid. Otherwise, UE 110 may treat the old TAI list as valid. If the new TAI list contains TAIs belonging to different PLMNs for the EPLMN, and if UE 110 contains allowed locally stored NSSAIs, UE 110 may store the allowed NSSAIs in each of the allowed NSSAIs associated with each of the PLMNs. Therefore, if UE 110 containing stored allowed NSSAIs receives a CUC message with an updated TAI list containing different PLMNs for a registered area, UE 110 may store the allowed NSSAIs in each of the allowed NSSAIs associated with each of the PLMNs.

[0114] Example

[0115] In a first embodiment, a method includes: receiving from a user equipment (UE) a registration request message including requested network slice selection assistance information (NSSAI), the NSSAI including single network slice selection assistance information (S-NSSAI); determining whether to allow the UE to register with the S-NSSAI; and based on the determination of whether to allow the UE to register with the S-NSSAI, transmitting a response to the registration request message to the UE.

[0116] In a second embodiment, the method according to the first embodiment further includes registering the UE with S-NSSAI when the UE is allowed to register with S-NSSAI, wherein the response includes a registration acceptance message indicating that S-NSSAI is an allowed S-NSSAI.

[0117] In a third embodiment, according to the method of the first embodiment, the response includes a registration rejection message indicating a reason code for rejection when the UE is not allowed to register with S-NSSAI.

[0118] In the fourth embodiment, a network function is configured to perform any one of the methods described according to the first to third embodiments.

[0119] In the fifth embodiment, one or more processors are configured to perform any one of the methods described according to the first to third embodiments.

[0120] In a sixth embodiment, a method includes: storing allowed network slice selection assistance information (NSSAI) for a user equipment (UE), the NSSAI including one or more single network slice selection assistance information (S-NSSAI); determining that at least one of the S-NSSAIs is no longer an allowed NSSAI; and determining that there is a valid protocol data unit (PDU) session valid for at least one S-NSSAI.

[0121] In the seventh embodiment, the method according to the sixth embodiment further includes instructing the network's Session Management Function (SMF) to release the PDU session.

[0122] In the eighth embodiment, the method according to the sixth embodiment further includes instructing the UE that the PDU session will be released.

[0123] In the ninth embodiment, according to the method of the sixth embodiment, the instruction includes a registration acceptance message containing PDU session state information elements.

[0124] In the tenth embodiment, according to the method of the sixth embodiment, wherein the network function is a first access and mobility management function (AMF) to which the UE is currently registered, the method further includes instructing a second AMF previously registered to the UE to release the PDU session.

[0125] In the eleventh embodiment, a network function is configured to perform any one of the methods described according to the sixth to tenth embodiments.

[0126] In the twelfth embodiment, one or more processors are configured to perform any one of the methods described according to the sixth to tenth embodiments.

[0127] In the thirteenth embodiment, the operations performed by the user equipment (UE) include: identifying that the Single Network Slice Selection Assistance Information (S-NSSAI) is a configured NSSAI rather than an allowed NSSAI; initiating a mobility registration update process based on one or more triggering conditions; transmitting a registration request message to the network, the registration request message including a requested NSSAI containing the S-NSSAI; receiving a response to the registration request message, the response indicating that the S-NSSAI is an allowed NSSAI; and establishing a Packet Data Unit (PDU) session on the S-NSSAI.

[0128] In the fourteenth embodiment, the method according to the thirteenth embodiment further includes receiving, prior to identification, a list of NSSAI requests including S-NSSAI from the application processor, wherein the requested list of NSSAI is received based on a new application, an activated feature, or a higher-level request.

[0129] In the fifteenth embodiment, according to the method of the fourteenth embodiment, one or more triggering conditions include detecting that the requested NSSAI list includes network slices that are configured NSSAIs rather than allowed NSSAIs.

[0130] In the sixteenth embodiment, according to the method of the fourteenth embodiment, one or more triggering conditions include detecting that the allowed NSSAI received from the network at the non-access stratum (NAS) layer does not include network slices that are not part of the list of requested NSSAIs received from the application processor at the NAS layer.

[0131] In the seventeenth embodiment, the method according to the thirteenth embodiment further includes receiving a newly configured NSSAI list from the network in a configuration update command (CUC) or registration acceptance message before identification, wherein the newly configured NSSAI is an S-NSSAI.

[0132] In the eighteenth embodiment, according to the method of the seventeenth embodiment, one or more triggering conditions include detecting that an updated configured NSSAI list includes a network slice previously requested by an upper layer.

[0133] In the nineteenth embodiment, according to the method of the seventeenth embodiment, one or more triggering conditions include detecting that the allowed NSSAI does not include a network slice that is part of a list of newly configured NSSAIs received from the network and was previously requested by an upper layer.

[0134] In the twentieth embodiment, according to the method of the thirteenth embodiment, one or more triggering conditions include detecting that the number of network slices included in the stored permitted NSSAI list for the Public Land Mobile Network (PLMN) is less than a predetermined maximum number of permitted NSSAIs for the PLMN.

[0135] In the twenty-first embodiment, according to the method described in the thirteenth embodiment, one or more triggering conditions include the UE's fifth-generation mobility management (5GMM) idle operation mode.

[0136] In the twenty-second embodiment, the method according to the thirteenth embodiment further includes starting a timer configured to trigger the release of an N1 Non-Access Stratum (NSA) signaling connection when: i) the configuration update command (CUC) includes a newly configured NSSAI; ii) no user plane resources are set for a Packet Data Unit (PDU) session; iii) no emergency PDU session is established; and iv) the CUC does not include a registration request bit set to true in the registration request bit of the configuration update indication information element (IE).

[0137] In the twenty-third embodiment, according to the method of the twenty-second embodiment, one or more triggering conditions include timer expiration.

[0138] In the twenty-fourth embodiment, a processor is configured to perform any one of the methods described according to the thirteenth to twenty-third embodiments.

[0139] In the twenty-fifth embodiment, a user equipment is configured to perform any one of the methods described according to the thirteenth to twenty-third embodiments.

[0140] Those skilled in the art will understand that the exemplary embodiments described above can be implemented with any suitable software or hardware configuration or combination thereof. Exemplary hardware platforms for implementing the exemplary embodiments may include, for example, Intel x86-based platforms with compatible operating systems, Windows OS, Mac platforms and MAC OS, and mobile devices with operating systems such as iOS, Android, etc. Exemplary embodiments of the methods described above may be embodied as programs comprising lines of code stored on a non-transitory computer-readable storage medium, which, at compile time, can be executed on a processor or microprocessor.

[0141] Although this patent application describes various combinations of various embodiments, each with different features, those skilled in the art will understand that any feature of an embodiment can be combined with features of other embodiments or features that are not functionally or logically inconsistent with the operation or function of the device of the disclosed embodiment of the invention in any manner not explicitly denied.

[0142] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0143] It will be apparent to those skilled in the art that various modifications can be made to this disclosure without departing from its spirit or scope. Therefore, this disclosure is intended to cover all modifications and variations thereof, provided that such modifications and variations are within the scope of the appended claims and their equivalents.

Claims

1. A method executed by a user equipment (UE), comprising: Transmit a registration request message to the network, the registration request message including a request to register to a set of one or more Single Network Slice Selection Assistance Information (S-NSSAI); Receive a response to the registration request message, the response indicating that the request to register to the group of one or more S-NSSAIs is rejected; The group of one or more S-NSSAIs is locally stored in the list of rejected NSSAIs at the UE; After storing the set of one or more S-NSSAIs in the list of rejected NSSAIs, an indication is received from the network to indicate a change in the network slice subscription of the UE; as well as In response to the IRAT transition between radio access technologies from N1 mode to S1 mode, the group of one or more S-NSSAIs is removed from the list of rejected NSSAIs.

2. The method according to claim 1, further comprising: After storing the group of one or more S-NSSAIs in the list of rejected NSSAIs, the registration request bit of the configuration update instruction information element (IE) is set to the first value in the configuration update command CUC.

3. The method according to claim 2, wherein the configuration update command CUC does not contain any other parameters.

4. The method according to claim 1, further comprising: After storing one or more S-NSSAIs in the list of rejected NSSAIs and failing to register on a new Public Land Mobile Network (PLMN), the system enters the 5GMM registration mode.

Images