Network slice allocation and network slice rejection

Abstract

The present disclosure relates to network slice allocation and network slice rejection. A user equipment (UE) configured to transmit, to a network, a first registration request, receive, in response to the first registration request, a registration accept message including a rejected network slice and an indication of a rejection cause corresponding to the rejected network slice, and transmit, to the network, a second registration request including a requested network slice, wherein the requested network slice and the rejected network slice are a same network slice.

Description

Technical Field

[0001] The embodiments of this disclosure generally relate to a method for communication. Background Technology

[0002] 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.

[0003] During operation, scenarios may occur where the UE is unable to access its desired network slice. This could negatively impact the user experience associated with the UE and / or the applications running on the UE. Therefore, a mechanism is needed to enable the UE to access its desired network slice. Summary of the Invention

[0004] Some exemplary embodiments relate to a processor of a user equipment (UE) configured to perform operations. These operations include transmitting a first registration request to a network, receiving a registration acceptance message in response to the first registration request, including a rejected network slice and an indication of a rejection reason corresponding to the rejected network slice, and transmitting a second registration request to the network including a requested network slice, wherein the requested network slice and the rejected network slice are the same network slice.

[0005] Other exemplary embodiments relate to a processor configured to perform operations for a network function. The operations include receiving a first registration request from a user equipment (UE), transmitting a first registration acceptance message in response to the first registration request, including a rejected network slice and an indication of a rejection reason corresponding to the rejected network slice, receiving a second registration request from the UE including a requested network slice, wherein the requested network slice and the rejected network slice are the same network slice, and transmitting a second registration acceptance message in response to the second registration request.

[0006] A further exemplary embodiment relates to a processor of a user equipment (UE) configured to perform operations. These operations include establishing a packet data unit (PDU) session on a first network slice, determining to perform a PDU session transfer from the first network slice to a second different network slice, and continuing the PDU session on the second different network slice. Attached Figure Description

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

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

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

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

[0011] Figure 5 Examples of registered areas (RAs) including multiple tracking areas are shown according to various exemplary implementation schemes.

[0012] Figure 6 The signaling diagram shows an example of network slice rejection at the tracking region level.

[0013] Figure 7 A table is shown that includes the reason value for the Network Slice Selection Auxiliary Information (NSSAI) for the rejected slice and the corresponding rejection reason.

[0014] Figure 8 The signaling diagram shows an example of network slice rejection at the Access and Mobility Management Function (AMF) level.

[0015] Figure 9 A table is shown that includes the reason value for the rejected NSSAI and the corresponding rejection reason.

[0016] Figure 10 Methods for transferring an existing Packet Data Unit (PDU) session from a first network slice to a second different network slice, according to various exemplary embodiments, are illustrated.

[0017] Figure 11 Signaling diagrams for PDU session modifications for UE initiation according to various exemplary implementations are shown.

[0018] Figure 12 Signaling diagrams for establishing a PDU session with handover for UE initiation are shown according to various exemplary embodiments.

[0019] Figure 13 Signaling diagrams of a PDU session modification process for network initiation according to various exemplary embodiments are shown.

[0020] Figure 14 Signaling diagrams of a PDU session modification process for network initiation according to various exemplary embodiments are shown. Detailed Implementation

[0021] 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 enhancements to network slicing. In one aspect, the exemplary embodiments relate to network slice rejection. In another aspect, the exemplary embodiments relate to network slice allocation and include mechanisms for transferring existing Packet Data Unit (PDU) sessions from a first network slice to a second, different network slice. Each of these exemplary aspects will be described in more detail below.

[0022] Exemplary embodiments are described with reference to User Equipment (UE). However, the term "UE" is used for illustrative purposes only. The exemplary embodiments can be utilized with any electronic components 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.

[0023] Exemplary implementations are 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.

[0024] 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), and industrial Internet of Things (IIoT). 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. 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.

[0025] 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 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.

[0026] 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.

[0027] In one aspect, an exemplary implementation relates to network slice rejection. During operation, the UE may transmit a registration request to the network. The registration request may include in part a request for one or more network slices that the UE may want to access (e.g., “requested NSSAI”). In response, the network may transmit a registration acceptance message to the UE, which includes an indication that the UE is allowed to access one or more of the requested NSSAIs (e.g., “allowed NSSAI”) and / or an indication that one or more of the requested NSSAIs are unavailable (e.g., “rejected NSSAI”).

[0028] Exemplary implementations are also described with reference to Registration Areas (RAs). Those skilled in the art will understand that “RA” refers to a set of tracking areas configured for a particular UE. For example, an RA may include Tracking Area Identity (TAI)-1, TAI-2, TAI-3, and TAI-4. Throughout this specification, any references to RAs comprising a specific number of TAIs are provided for illustrative purposes only. Each RA may include any appropriate number of TAIs.

[0029] Each tracking area within an RA may not support the same network slice. For example, an RA may include TAI-1, which is configured to support access to network slice A, and TAI-2, which is configured to support access to network slice B.

[0030] Under normal circumstances, a rejected network slice is applied to the entire RA, even if some individual tracking areas within the RA may not support that network slice. It has been confirmed that this can lead to scenarios where the UE is located within a TAI that supports the desired network slice, but the UE has already been barred from accessing that network slice within the current RA. For example, consider a scenario where the RA consists of TA-1 and TA-2. The UE may transmit a registration request to the network while located in TAI-1, which includes network slice B within the requested NSSAI. A registration acceptance message may indicate that the request for network slice B is rejected in that RA because TAI-1 does not support access to network slice B. The UE can be configured to apply the rejected NSSAI to the current RA. Therefore, if the UE moves from TAI-1 to TAI-2, based on the rejected NSSAI received while located in TAI-1, the UE may not be allowed access to network slice B because the rejected NSSAI applies to the entire RA including TAI-2.

[0031] Exemplary implementations introduce techniques for implementing network slice rejection at the Tracking Area Level (TAI). These exemplary techniques allow a UE to avoid scenarios where the UE is located within a TAI that supports a specific network slice but cannot access that specific network slice. These exemplary techniques can be used in conjunction with currently implemented network slice rejection mechanisms, future implementations of network slice rejection mechanisms, or independently of other network slice rejection mechanisms.

[0032] Exemplary implementations are also described with reference to the Access and Mobility Management Function (AMF). Those skilled in the art will understand that the AMF is a control plane function and can perform operations related to registration and connection management. Each RA and / or TAI may be configured with one or more AMFs. It should be understood that the operations performed by the AMF as described herein can be performed by one or more other network functions; for example, the use of the AMF is merely exemplary.

[0033] Under normal circumstances, a requested network slice may be rejected because it is not supported by the serving AMF. This rejection can apply to the entire Tracking Area (RA), even if other AMFs within the current RA may be able to serve the UE. It has been confirmed that this can lead to scenarios where the UE is located within a Tracking Area (TAI) that supports the desired network slice, but the UE is already prohibited from accessing that network slice within the current RA. For example, a UE may transmit a registration request to the serving AMF while located within TAI-1, including network slices A and B within the requested NSSAI. A registration acceptance message may indicate that the request for network slice A is accepted, while the request for network slice B is rejected within the RA because the serving AMF does not support access to network slice B. This rejection applies to the entire RA, even though other AMFs configured to support network slice B may be able to serve the UE in the same tracking area. Therefore, if a UE wants to use the services of network slice B instead of network slice A, it may not be allowed to access network slice B based on the rejected NSSAI received when it is located within TAI-1, even though the tracking area where different AMFs can support access to network slice B, because the rejected NSSAI applies to the RA level rather than the AMF level.

[0034] Exemplary implementations introduce techniques for implementing network slice rejection at the AMF level when multiple AMFs exist in the AMF pool. These exemplary techniques allow the UE to avoid scenarios where the UE is located within a TAI that supports a specific network slice but cannot access that specific network slice. These exemplary techniques can be used in conjunction with currently implemented network slice rejection mechanisms, future implementations of network slice rejection mechanisms, or independently of other network slice rejection mechanisms.

[0035] Exemplary implementations are also described with reference to PDU sessions. Those skilled in the art will understand that the term "PDU session" generally refers to the logical connection between the UE and the data network. A UE may be configured with a PDU session to access network services associated with a network slice.

[0036] On the other hand, exemplary implementations introduce mechanisms for transferring existing PDU sessions from one network slice to another. It has been established that, under normal circumstances, it is not possible to transfer existing PDU sessions from one network slice to another while maintaining service continuity in a 3GPP network. Instead, to obtain network services on a different network slice, the UE may need to activate a new PDU session on a desired network slice located within 3GPP access and the same PLMN (or equivalent PLMN). The exemplary mechanisms described herein allow the transfer of existing PDU sessions from one network slice to another. These exemplary mechanisms can be used in conjunction with currently implemented network slice allocation mechanisms, future implementations of network slice allocation mechanisms, or independently of other network slice rejection mechanisms. Specific examples of these exemplary mechanisms are described in detail below.

[0037] 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, 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.

[0038] UE 110 can be configured to communicate with one or more networks. In the example of network configuration 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.

[0039] 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.

[0040] 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).

[0041] 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.

[0042] 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.

[0043] Those skilled in the art will understand that the components of the exemplary architecture 200 can be relative to... Figure 1The 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.

[0044] exist Figure 2 In this specification, various components are shown connected via connections labeled Nx (e.g., N1, N2, N11, Nnssf). 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.

[0045] Architecture 200 includes UE 110 and 5G NR RAN 120. UE 110 and 5G NR RAN 120 can be connected to AMF 205. AMF 205 is typically responsible for connectivity and mobility management in 5G NR RAN 120. For example, AMF 205 can perform operations related to registration management between UE 110 and core network 130. Exemplary implementations are not limited to AMFs performing the operations described above. Those skilled in the art will understand that various different types of operations can be performed by an AMF. Furthermore, references to a single AMF 205 are for illustrative purposes only, and actual network deployments may include any appropriate number of AMFs.

[0046] 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, etc. Exemplary implementations are not limited to SMFs performing the above operations. Those skilled in the art will understand the various different types of operations that an SMF can perform. Furthermore, the reference to a single SMF 210 is merely illustrative; actual network deployments may include any appropriate number of SMFs.

[0047] AMF 205 and SMF 210 are also connected to the Network Slice Selection Function (NSSF) 215. NSSF 215 performs various operations related to network slicing. For example, NSSF 215 can select a set of network slice instances to serve UE 110. NSSF 215 can also manage one or more databases that include mappings of S-NSSAI and the frequency bands that S-NSSAI is allowed to operate on. Exemplary implementations are not limited to the NSSF performing the operations described above. Those skilled in the art will understand the various different types of operations that an NSSF can perform. Furthermore, the reference to a single NSSF 215 is merely illustrative; actual network deployments may include any appropriate number of SMFs.

[0048] Figure 3 An exemplary UE 110 according to various exemplary embodiments is shown. Reference will be made to... Figure 1 The 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.

[0049] Processor 305 may be configured to execute multiple engines for UE 110. For example, engines may include a network slice rejection engine 335 and a PDU session transfer engine 340. Network slice rejection engine 335 may perform various operations related to processing rejected NSSAIs at UE 110, including but not limited to receiving the rejection reason and associating the rejected NSSAI with a specific TAI or AMF. PDU session transfer engine 340 may perform various operations related to transferring an existing PDU session from a first network slice to a second different network slice. These operations may include, but are not limited to, initiating a process for activating a specific network slice at UE 110 and requesting that the PDU session be transferred to a different network slice.

[0050] The engines 335 and 340 described above, each as an application (e.g., a program) executed by processor 305, are provided for illustrative purposes only. The functionality associated with engines 335 and 340 may also be represented as separate 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 can be implemented according to any of these or other configurations of the UE.

[0051] 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).

[0052] 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.

[0053] 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.

[0054] 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.).

[0055] 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.

[0056] 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 system 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.

[0057] As described above, an RA can include multiple tracking areas. However, each tracking area does not necessarily support the same network slice. Similarly, an RA can be configured with multiple AMFs; however, each AMF does not necessarily support the same network slice. Under normal circumstances, when a requested network slice is not supported by the current tracking area or the serving AMF, the network can reject the requested network slice by providing a rejection reason indicating that a specific network slice (e.g., S-NSSAI) is unavailable in the current RA. This conventional rejection reason does not accurately reflect the actual deployment scenario of UE 110. For example, the current tracking area may not support the requested S-NSSAI, but there may be another tracking area within the RA that does support the requested S-NSSAI. Similarly, the serving AMF may not support the requested S-NSSAI, but there may be another available AMF that does support the requested S-NSSAI. Because the rejection reason applies to the entire RA, UE 110 does not attempt to register with the rejected S-NSSAI until UE 110 moves out of the RA.

[0058] In one aspect, exemplary embodiments introduce techniques for implementing network slice rejection at the tracking area level. These exemplary techniques allow UE 110 to avoid scenarios where UE 110 is located within a tracking area that supports a specific network slice, but UE 110 is unable to access that specific network slice.

[0059] Figure 5 An example of a registration region 500 comprising multiple tracking regions according to various exemplary embodiments is shown. Each TAI may support a different network slice. In this example, TAI-1 and TAI-2 support S-NSSAI-A, and TAI-1, TAI-3, and TAI-4 support S-NSSAI-B. Throughout this specification, any references to “S-NSSAI-A” and “S-NSSAI-B” are provided only to distinguish between two different network slices and are not intended to limit the exemplary embodiments in any way.

[0060] To provide an example of the issue referenced above within the context of RA 500, consider a scenario where UE 110 is located within TAI-4 and transmits a registration request to the network. The registration request may include requests for S-NSSAI-A and S-NSSAI-B. In response, UE 110 may receive a registration acceptance message indicating that S-NSSAI-B is allowed while S-NSSAI-A is rejected. The reason for rejection may indicate that S-NSSAI-A is unavailable in the current RA 500. However, S-NSSAI-A may actually be available in other tracking areas, such as TAI-1 and TAI-2, which are part of the RAs provided to the UE.

[0061] When the rejection reason for a rejected network slice indicates that the network slice is unavailable in the RA, UE 110 can be configured to add the rejected S-NSSAI to the rejected NSSAIs for the current RA (e.g., RA 500). Additionally, UE 110 can be configured not to attempt to use the S-NSSAI in the current registered area until subsequent conditions occur, such as, but not limited to, disconnecting UE 110 and moving outside the current RA. Therefore, if UE 110 moves to RA 500 and S-NSSAI-A is allowed on TAI-1, UE 110 will not attempt to obtain the service associated with S-NSSAI-A because TAI-1 and TAI-4 are part of the same RA, and the rejection reason indicates that S-NSSAI-A is unavailable in the current RA 500.

[0062] The exemplary implementation introduces a rejection reason that is specific to the tracking region. Throughout this specification, this rejection reason may be referred to as "S-NSSAI non-service region" or "S-NSSAI unavailable in the current tracking region". However, these headings for rejection reasons are provided for illustrative purposes only, and different entities may refer to similar concepts using different names.

[0063] Additionally, the exemplary implementation introduces a list of Service NSSAI TAIs. The Service NSSAI TAI list can be configured to include all TAIs in the Public Land Mobile Network (PLMN) within the RA that are permitted for a specific denied network slice. For example, within the context of RA 500, the Service NSSAI TAI list may include indications that S-NSSAI-A is supported by TAI-1 and TAI-2, and indications that S-NSSAI-B is supported by TAI-1, TAI-3, and TAI-4. However, references to the Service NSSAI TAI list are provided for illustrative purposes only, and different entities may refer to similar concepts using different names.

[0064] Figure 6 Signaling diagram 600 shows an example of network slice rejection including at the tracking region level. (Refer to...) Figures 1-2 Network setup 100-200 Figure 3 UE 110 and Figure 5 Signaling diagram 600 is described using RA 500. Signaling diagram 600 includes UE110 and AMF 205.

[0065] In 605, UE 110 is deployed within TAI-4. In 610, UE 110 transmits a registration request to AMF 205. The registration request may include the requested NSSAI S-NSSAI-A and S-NSSAI-B. In this example, it is assumed that registration is successful.

[0066] In step 615, AMF 205 transmits a registration acceptance message to UE 110. The registration acceptance message may include allowed and rejected NSSAIs. For each rejected S-NSSAI, there may be an information element including one or more bits indicating a reason value. The reason value may be associated with the rejection reason "S-NSSAI not serving area" or "S-NSSAI not available in the current tracking area". Therefore, UE 110 can determine the rejection reason based on its association with the reason value.

[0067] Figure 7Table 700 is shown, which includes reason values ​​for rejected NSSAIs and corresponding rejection reasons. Table 700 may resemble the extended table of rejected NSSAI information elements provided in the 3GPP standard, except for the rejection reasons “S-NSSAI not serving area” or “S-NSSAI not available in the current tracking area”. Table 700 shows an example of a bit-indicated reason value (e.g., 0011) that can be used to indicate that S-NSSAI is not allowed in a particular TAI. However, exemplary embodiments are not limited to this reason value, and any reason value or any other suitable type of indication can be used to communicate to UE 110 that the requested S-NSSAI is not allowed within the TAI.

[0068] Return to Figure 6 In signaling diagram 600, in some implementations, the registration acceptance message may also include a list of Service NSSAIs (TAIs) for the rejected network slice. As described above, the Service NSSAI list can be configured to include all TAIs (TAIs) within the RA (Regional Area Network) that are permitted for a particular rejected network slice. Within the context of RA 500, the Service NSSAI list may indicate that S-NSSAI-A is permitted in TAI-1 and TAI-2.

[0069] In step 620, UE 110 moves to TAI-1 and initiates a Mobility Registration Update (MRU). Based on the rejection reasons and / or Service NSSAI list that can be received in the registration acceptance message, UE 110 knows that other TAIs within the RA may allow network slices that were rejected in TAI-4 (e.g., S-NSSAI-A). Therefore, even though there is no movement outside RA 500, UE 110 can initiate an MRU. This MRU allows UE 110 to attempt to access network slices that are not allowed in different TAIs.

[0070] In step 625, UE 110 transmits a registration request to AMF 205. The registration request may include the requested NSSAIs S-NSSAI-A and S-NSSAI-B. In step 630, UE 110 receives a registration acceptance message. Unlike the previous registration acceptance message received in TAI-4, this registration acceptance message does not contain the rejected NSSAIs because the requested NSSAIs are allowed in TAI-1. Therefore, UE 110 can access the network services associated with S-NSSAI-A when located within TAI-1 of RA 500.

[0071] On the other hand, exemplary embodiments introduce techniques for implementing network slice rejection at the AMF level. These exemplary techniques allow UE 110 to avoid scenarios where UE 110 is located within a tracking area supporting a specific network slice, but UE 110 cannot access that specific network slice via its serving AMF.

[0072] There may be multiple AMFs available to a RA, and each AMF may support different network slices. As mentioned above, under normal circumstances, when a serving AMF does not support the requested network slice, the reason for rejection could be that the network slice is not allowed within the current RA. However, this does not accurately reflect real-world deployment scenarios, as different AMFs may support the rejected network slice.

[0073] Figure 8 Signaling diagram 800 shows an example of network slice rejection at the AMF level. (Refer to...) Figures 1-2 Network deployment 100-200 and Figure 3 The UE 110 is used to describe the signaling diagram 800.

[0074] Signaling diagram 800 includes UE 110, gNB 120A, and NSSF 215. Additionally, the signaling diagram illustrates an AMF pool 801 comprising three AMFs 802-804. Throughout this specification, the term "AMF pool" generally refers to a set of AMFs that can be configured for the serving AMF of UE 110 relative to a specific RA. However, the reference to an AMF pool comprising three AMFs is merely illustrative. In a real-world deployment scenario, an AMF pool may include any appropriate number of AMFs.

[0075] In this example, AMF 802 is configured to support S-NSSAI-A and S-NSSAI-B, AMF 803 is configured to support S-NSSAI-B and S-NSSAI-C, and AMF 804 is configured to support S-NSSAI-A and S-NSSAI-C. Similar to the examples provided above, references to "S-NSSAI-A," "S-NSSAI-B," and "S-NSSAI-C" are provided to distinguish between different network slices and are not intended to limit the exemplary implementation in any way.

[0076] In step 805, UE 110 transmits a registration request to gNB 120. The registration request may include the requested NSSAI S-NSSAI-A, S-NSSAI-B, and S-NSSAI-C. It may be beneficial for UE 110 to indicate a preference or priority corresponding to the requested network slice. This can assist the network in determining which AMF is suitable for UE 110. In this example, UE 110 indicates that S-NSSAI-A takes precedence over other network slices, and S-NSSAI-B takes precedence over S-NSSAI-C. UE 110 can sort the requested network slices according to its preferences, or it can indicate priorities to the network in any appropriate manner.

[0077] In step 810, gNB 120A selects an AMF from AMF pool 801. In this example, gNB 120A selects AMF 802 based on preferences indicated by UE 110 in the registration request, whether UE 110 is allowed access to the requested network slice, and / or which network slice is supported by AMF pool 801. Although not shown in signaling diagram 800, gNB 120A may communicate with one or more AMFs in AMF pool 801 and / or any other suitable network entity to select an appropriate AMF. In some embodiments, the selection may be performed downstream by a different network entity and provided to gNB 120A. Exemplary embodiments are applicable to this AMF selection being performed by any suitable network component on any appropriate basis.

[0078] In some implementations, in addition to or instead of considering the network slice priority indicated by UE 110, the network may select the AMF capable of providing access to the maximum number of slices in the requested NSSAI. In other implementations, UE 110 may indicate that one or more network slices need to be supported by the selected AMF. In still other implementations, UE 110 may indicate whether it prefers access-priority network slices or the maximum number of network slices.

[0079] In step 815, AMF 802 queries NSSF 215 for available network slices at other AMFs in AMF pool 801. In step 820, NSSF 215 transmits indications of network slices supported by each AMF in AMF pool 801. In this example, NSSF 215 might indicate to AMF 802 that AMF 803 supports S-NSSAI-B and S-NSSAI-C, and AMF 804 supports S-NSSAI-A and S-NSSAI-C.

[0080] In step 825, AMF 802 transmits a registration acceptance message to UE 110. The registration acceptance message may include allowed NSSAIs, rejected NSSAIs with an indication of the rejection reason, and / or network slices supported by each AMF in AMF pool 801. Therefore, AMF 802 can indicate to UE 110 network slices that are not supported by the serving AMF but are supported by other AMFs within AMF pool 801.

[0081] As noted above, AMF 802 can indicate to UE 110 the available slice combinations for each AMF in AMF pool 801. In this example, this information is provided to UE 110 in a registration accept message. In other embodiments, this information may be provided to UE 110 in a registration reject message, a configuration update command message, or any other suitable type of message. In some embodiments, the message may contain information elements indicating available S-NSSAI combinations and / or supported network slices.

[0082] The exemplary implementation introduces a rejection reason that enables the network to indicate that the rejected network slice is unavailable in the serving AMF. This can instruct UE 110 that UE 110 is allowed to re-request the rejected network slice within that RA. As described above, under normal circumstances, the network can indicate to UE 110 that the rejected NSSAI is unavailable in the RA, even if other AMFs within the RA are able to provide access to the rejected NSSAI.

[0083] Figure 9 Table 900 is shown, which includes reason values ​​for rejected NSSAIs and corresponding rejection reasons. Except for the rejection reason "S-NSSAI is not available in the current AMF," Table 900 may resemble the extended table of rejected NSSAI information elements provided in the 3GPP standard. Table 900 shows an example of a bit-indicated reason value (e.g., 0011) that can be used to indicate that S-NSSAI is not permitted in a particular AMF. However, exemplary embodiments are not limited to this reason value, and any reason value or any other suitable type of indication can be used to communicate to UE 110 that the requested S-NSSAI is not permitted within the AMF.

[0084] During operation, UE 110 may want to use network slices that are not permitted on serving AMF 802, such as S-NSSAI-C. Based on the combination of the rejection reasons received during the registration process and / or the supported network slices on each AMF within AMF pool 801, UE 110 knows that access to S-NSSAI-C is permitted on different AMFs within AMF pool 801.

[0085] In 830, UE 110 initiates the MRU. When UE 110 wants to access a network slice that has been rejected by the reason "not available in the serving AMF", UE 110 initiates the MRU, so that the AMF supporting the desired network slice is selected to serve UE 110.

[0086] In 835, UE 110 transmits a registration request to gNB 120A. In this example, the registration request may include a requested NSSAI with an S-NSSAI-C that was rejected within the RA during a previous registration process. Similar to the registration request referenced above in 805, UE 110 may indicate the priority or preference corresponding to the requested network slice, or may indicate that a particular network slice needs to be allowed on the AMF to be selected by the network to serve UE 110. Thus, despite no movement outside the RA or power failure, UE 110 activates the MRU to access the previously rejected network slice.

[0087] In 840, gNB 120A selects AMF 804 because AMF 804 allows the requested network slice. Alternatively, when the serving AMF 802 receives a registration request associated with an MRU that includes a requested network slice not supported by the serving AMF but supported by another AMF in AMF pool 801, the AMF can be triggered to begin the AMF reallocation process. In 845, AMF 804 transmits a registration acceptance message to UE 110, indicating that the requested NSSAI is allowed.

[0088] On the other hand, exemplary embodiments introduce mechanisms for transferring existing PDU sessions from a first network slice to a second, different network slice within the same PLMN (or equivalent PLMN) and within the 3GPP access area. Some exemplary mechanisms are described below with reference to a scenario in which UE 110 is triggered to dynamically register an existing PDU session to a network slice different from the currently configured network slice. UE 110 is triggered to register to this new network slice when the user is actively using a corresponding application running on UE 110 (e.g., streaming video, cloud gaming, extended reality (XR), etc.). However, exemplary embodiments are not limited to this type of scenario and can be applied to any scenario in which UE 110 is triggered to attempt to register to a network slice different from the currently configured network slice for existing PDU sessions.

[0089] Figure 10 A method 1000 for transferring an existing PDU session from a first network slice to a second, different network slice, according to various exemplary embodiments, is illustrated. Method 1000 provides a general overview of the process for transferring an existing PDU session from the perspective of UE 110. Reference is made below. Figures 11-14Signaling diagrams 1100-1400 provide additional details about network-side operations associated with PDU session transfer.

[0090] Initially, consider a scenario where UE 110 is registered to a network and configured with permitted S-NSSAI, including S-NSSAI-A. Additionally, an application running on UE 110 is configured to access a data network (e.g., Internet 140) and utilize S-NSSAI-A. As will be described in more detail below, the exemplary mechanism allows a PDU session to be transferred from a first network slice (e.g., S-NSSAI-A) to a second different network slice (e.g., S-NSSAI-B). Similar to the example provided above, any references to "S-NSSAI-A" and "S-NSSAI-B" are provided only to distinguish between two different network slices and are not intended to limit the exemplary implementation in any way.

[0091] In 1005, the PDU session is activated on the first network slice (e.g., S-NSSAI-A). The PDU session can be identified by the PDU session ID. In this example, the PDU session ID is referred to as "PDU Session ID 1". The PDU session can connect UE 110 to a server hosted on a data network (e.g., Internet 140, etc.). In this example, the PDU session corresponds to a game application running on UE 110.

[0092] In 1010, UE 110 receives an indication to request a second different network slice for a PDU session. As will be described below with reference to 1015, the indication in 1010 triggers UE 110 to initiate a PDU session transfer to a second different network slice (e.g., S-NSSAI-B). For the sake of illustration, during the operation of a gaming application, a user may decide to change their service type. This may include purchasing or unlocking a high-quality service offered by the gaming application. From a network perspective, this high-quality service may be provided by different network slices offering different guaranteed quality of service (QoS). However, this example is provided for illustrative purposes only. Exemplary implementations are not limited to PDU session transfers occurring in this context. Network slices can be used in a variety of different applications, and exemplary implementations are applicable to any scenario in which a UE is triggered to request a network slice for an existing PDU session.

[0093] Similar to the examples provided above, the indication provided in 1010 can be received via user input at UE 110, such as the user selecting a high-quality service. In other embodiments, a corresponding application running on UE 110 can trigger UE 110 to request a new network slice. For example, when a user's profile or avatar reaches a certain level or acquires a certain state relative to a game application, the game application can provide the indication in 1010 without any explicit user selection. In other embodiments, the indication in 1010 can be received from the network side. For example, a server, third-party server, or network component at another remote endpoint of the PDU session can send a signal to UE 110 indicating that a new network slice can be requested. In other examples, instead of upgrading to a better or higher-quality service, a PDU session transfer can be performed to degrade from a high-quality service. However, the examples provided above are not intended to limit the exemplary embodiments in any way. Exemplary embodiments can utilize any suitable triggering conditions for PDU session transfers initiated by the UE.

[0094] In step 1015, UE 110 initiates a PDU session transfer from the first network slice to a second, different network slice. In step 1020, UE 110 determines whether the desired network slice is activated at UE 110. If the desired network slice is not activated, step 1000 continues to step 1025. In step 1025, UE 110 performs a registration procedure to activate the desired network slice at UE 110. Once activated, step 1000 continues to step 1030.

[0095] Returning to 1020, if the desired network slice has been activated, method 1000 continues to 1030. In 1030, UE 110 transmits a request to transfer the PDU session from the first network slice to a second, different network slice. In some implementations, the signal in 1030 may be a PDU session modification request enhanced to enable UE 110 to request a change in the S-NSSAI associated with the PDU session (e.g., PDU session ID 1). See below for reference. Figure 11 Signaling diagram 1100 illustrates an example of this. In other embodiments, the signaling in 1030 may be a PDU session establishment request enhanced to support the handover of a PDU session from one S-NSSAI to another S-NSSAI on the same access. See below for reference. Figure 12 The signaling diagram 1200 illustrates an example of this.

[0096] In step 1035, UE 110 and the network continue the same PDU session on a second, different network slice (e.g., S-NSSAI-B). Subsequently, method 100 ends.

[0097] When UE 110 (or the network) is triggered to initiate a PDU session transfer and the desired network slice is not configured as an allowed network slice, there may be a scenario where the maximum number of allowed network slices has already been configured. If activating the desired network slice would exceed the network slice limit, the UE or the network may remove the network slice from the allowed network slice configuration.

[0098] In some implementations, multiple combinations of PDU sessions and network slices can be kept active for an application. This allows users to seamlessly switch between different services. For example, a video streaming application might combine a first PDU session and network slice for a first type of video quality, a second PDU session and network slice for a second type of video quality, and a third PDU session and network slice for a third type of video quality. All three combinations can be active simultaneously, allowing users to seamlessly switch between different video qualities.

[0099] In some implementations, PDU session transfer can be initiated by the network. Specific examples of network-initiated PDU session transfer are shown below with reference to signaling figures 1300-1400.

[0100] Figure 11 Signaling diagram 1100 for PDU session modifications for UE initiation according to various exemplary embodiments is shown. Signaling diagram 1100 includes UE 110, AMF 205, SMF 215, and application server 1102. (Refer to...) Figures 1-2 Network deployment 100-200 and Figure 3 The signaling diagram 100 is described using UE 110.

[0101] In 1105, a PDU session is established between UE 110 and application server 1102. The PDU session is established on the first network slice (e.g., S-NSSAI-A).

[0102] Within the context of network arrangement 100, application server 1102 may be hosted on Internet 140. However, the exemplary implementation is not limited to this arrangement and can be applied to any type of server deployed within any suitable type of data network.

[0103] In 1110, UE 110 is triggered to initiate a PDU session transfer. As noted above, in some embodiments, UE 110 may receive a signal from application server 1102 indicating that a user's subscription to the corresponding service has changed (e.g., from a "normal" subscription to a "high-quality" subscription or vice versa). In other embodiments, UE 110 may be triggered to initiate the transfer based on user input received at UE 110. However, exemplary embodiments are not limited to the example triggering conditions mentioned above, and any suitable type of triggering condition can be used to initiate a transfer (or handover) of a PDU session from one network slice to another.

[0104] In this example, it is assumed that the desired network slice (e.g., S-NSSAI-B) has already been activated at UE 110 prior to 1110. However, as noted above in the methodology section, there may be scenarios where the desired network slice is not activated at UE 110 when a triggering condition for PDU session transfer occurs. In this type of scenario, UE 110 may initiate a registration process to activate the desired network slice (e.g., S-NSSAI-B). This may include AMF reallocation, where existing PDU session information is transferred to a new AMF. Alternatively, this may also include a network providing a new UE route selection policy (USRP) rule indicating that S-NSSAI-B is a preferred network slice over S-NSSAI-A for that service.

[0105] In step 1115, UE 110 transmits a PDU session modification request to AMF 205. To enable PDU session transfer, an exemplary implementation introduces a PDU session modification request that indicates UE 110 is requesting a change to the network slice associated with a specific PDU session. For example, the request may explicitly or implicitly involve a specific PDU session ID and / or a specific desired S-NSSAI.

[0106] In 1120, the PDU session modification process is successful, and the network transfers the existing PDU session context to the desired network slice (e.g., S-NSSAI-B) while ensuring IP continuity.

[0107] In 1125, the PDU session continues on a second, different network slice (e.g., S-NSSAI-B). As mentioned above, network slices can have different QoS parameters. Therefore, before the modification process, the PDU session may undergo a first set of one or more QoS parameters, and after a successful PDU session modification process, the same PDU session may undergo a second, different set of one or more QoS parameters.

[0108] Figure 12Signaling diagram 1200 for establishing a PDU session with handover for UE initiation is shown according to various exemplary embodiments. Signaling diagram 1200 includes UE 110, AMF 205, SMF 210, and application server 1202. Reference will be made to... Figures 1-2 Network deployment 100-200 and Figure 3 The signaling diagram 1200 is described using UE 110.

[0109] In step 1205, a PDU session is established between UE 110 and application server 1202. The PDU session is established on the first network slice (e.g., S-NSSAI-A). Figure 11 Similar to the example provided, application server 1202 may be hosted on the Internet 140. However, the exemplary implementation is not limited to this arrangement and can be applied to any type of server deployed within any suitable type of data network.

[0110] In 1210, UE 110 is triggered to initiate a PDU session transfer. As noted above, in some embodiments, UE 110 may receive a signal from application server 1202 indicating that a user's subscription to the corresponding service has changed (e.g., from a "normal" subscription to a "high-quality" subscription or vice versa). In other embodiments, UE 110 may be triggered to initiate the transfer based on user input received at UE 110. However, exemplary embodiments are not limited to the example triggering conditions mentioned above, and any suitable type of triggering condition can be used to initiate a transfer (or handover) of a PDU session from one network slice to another.

[0111] In this example, with Figure 11 The example shown is similar, assuming the desired network slice (e.g., S-NSSAI-B) was already activated at UE 110 prior to 1210. However, when a trigger condition for PDU session transfer occurs, there may be a scenario where the desired network slice is not activated at UE 110. In this type of scenario, UE 110 may initiate a registration process to activate the desired network slice (e.g., S-NSSAI-B). This may include AMF reallocation, where existing PDU session information is transferred to a new AMF. Alternatively, this may also include a network providing new USRP rules indicating that S-NSSAI-B is a preferred network slice over S-NSSAI-A for that service.

[0112] In step 1215, UE 110 transmits a PDU session establishment request to AMF 205. To enable PDU session transfer, an exemplary implementation introduces a PDU session establishment request that indicates UE 110 is requesting the transfer of the context of an existing PDU session from one network slice (e.g., S-NSSAI-A) to a different network slice (e.g., S-NSSAI-B). For example, the request may explicitly or implicitly involve a specific PDU session ID and / or a specific desired S-NSSAI.

[0113] In 1220, the PDU session establishment process is successful, and the network transfers the existing PDU session context to the desired network slice (e.g., S-NSSAI-B) while ensuring IP continuity. No new PDU sessions are created. Instead, the existing PDU session is transferred to the desired network slice.

[0114] In 1225, the same PDU session continues on a second, different network slice (e.g., S-NSSAI-B). As mentioned above, different network slices can have different QoS parameters. Therefore, before the modification process, the PDU session may undergo a first set of one or more QoS parameters, and after a successful PDU session modification process, the same PDU session may undergo a second, different set of one or more QoS parameters.

[0115] The examples provided above in signaling diagrams 1100-1200 illustrate a PDU session transfer initiated by UE 110. The examples below, referring to signaling diagrams 1300-1400, will describe a network-initiated PDU session transfer.

[0116] Figure 13 Signaling diagram 1300 illustrates a PDU session modification process for network initiation according to various exemplary embodiments. Signaling diagram 1300 includes UE 110, AMF 205, SMF 210, and application server 1302. Reference will be made to... Figures 1-2 Network deployment 100-200 and Figure 3 The signaling diagram 1300 is described using UE 110.

[0117] In step 1305, a PDU session is established between UE 110 and application server 1302. The PDU session is established on the first network slice (e.g., S-NSSAI-A). Similar to the example provided above, application server 1302 may be hosted on Internet 140. However, the exemplary implementation is not limited to this arrangement and can be applied to any type of server deployed within any suitable type of data network.

[0118] In step 1310, AMF 205 is triggered to initiate a PDU session transfer. Application server 1302 can identify UE 110 to AMF 205 using a Common Public Subscription Identifier (GPSI) or any other suitable parameter. For example, AMF 205 may receive a signal from application server 1302 indicating that the user's subscription to the corresponding service has changed (e.g., from a "normal" subscription to a "high-quality" subscription or vice versa). However, exemplary implementations are not limited to the example triggering conditions mentioned above, and any suitable type of triggering condition can be used to cause the AMF to initiate a transfer (or handover) of a PDU session from one network slice to another.

[0119] In this example, it is assumed that the desired network slice (e.g., S-NSSAI-B) has already been activated for UE 110. Signaling diagram 1400 provides an example of network-initiated PDU session transfer where the desired network slice has not yet been activated for UE 110.

[0120] In step 1315, AMF 205 transmits a request for PDU session transfer to SMF 210. In step 1320, a PDU session modification procedure is performed to transfer the PDU session from the first network slice to a second, different network slice. In step 1325, the same PDU session continues on the second, different network slice (e.g., S-NSSAI-B).

[0121] If SMF reallocation is not required, SMF 210 triggers PDU session modification to modify an existing PDU session on the first network slice (e.g., S-NSSAI-A) by transferring the PDU session to a second different network slice (e.g., S-NSSAI-B). Alternatively, SMF 210 can trigger PDU session modification by indicating that an existing PDU session ID associated with the currently configured network slice (e.g., S-NSSAI-A) is to be used for the reactivation of a PDU session on the desired network slice (e.g., S-NSSAI-B).

[0122] If SMF reallocation is required, the current SMF 210 can initiate PDU session release by indicating that the existing PDU session ID associated with the first network slice (e.g., S-NSSAI-A) is to be used for the reactivation of the PDU session on the desired network slice (e.g., S-NSSAI-B). In this example, UE 110 and the new SMF can activate the existing PDU session on the desired network slice.

[0123] As mentioned above, different network slices can have different QoS parameters. Therefore, before the modification process, a PDU session can undergo a first set of one or more QoS parameters, and after a successful PDU session modification process, the same PDU session can undergo a second, different set of one or more QoS parameters.

[0124] Figure 14 Signaling diagram 1400 illustrates a PDU session modification process for network initiation according to various exemplary embodiments. Signaling diagram 1400 includes UE 110, AMF 205, SMF 210, and application server 1402. Reference will be made to... Figures 1-2 Network deployment 100-200 and Figure 3 The signaling diagram 1400 is described using UE 110.

[0125] In step 1405, a PDU session is established between UE 110 and application server 1402. The PDU session is established on the first network slice (e.g., S-NSSAI-A). Similar to the example provided above, application server 1402 may be hosted on Internet 140. However, the exemplary implementation is not limited to this arrangement and can be applied to any type of server deployed within any suitable type of data network.

[0126] In step 1410, the AMF is triggered to initiate a PDU session transfer in response to a signal received from application server 1402. Application server 1402 can identify UE 110 to AMF 205 using GPSI or any other suitable parameters. For example, AMF 205 may receive a signal from application server 802 indicating that the user's subscription to the corresponding service has changed (e.g., from a "normal" subscription to a "high-quality" subscription or vice versa). However, exemplary implementations are not limited to the example triggering conditions mentioned above, and any suitable type of triggering condition can be used to cause AMF 205 to initiate a transfer (or handover) of a PDU session from one network slice to another.

[0127] In this example, it is assumed that the desired network slice (e.g., S-NSSAI-B) is not activated for UE 110. This contrasts with signaling diagram 1300, in which the desired network slice has been activated.

[0128] Since the desired network slice is not activated at UE 110, in step 1415, AMF 205 transmits a configuration update command to UE 110, which triggers UE 110 to initiate activation of the desired slice. In some embodiments, the configuration update command may be configured to include an indication regarding whether UE 110 can activate the desired network slice without sending an indication for the desired network slice in the requested NSSAI.

[0129] In 1420, UE 110 initiates the registration process using AMF 205 to activate the desired network slice. Normally, network slice activation is initiated by UE 110. Therefore, when the desired network slice is not activated, AMF 205 triggers UE 110 to initiate registration. Although not shown in signaling diagram 1400, AMF reallocation can be performed to activate the desired network slice, and existing PDU session information is transferred to the new AMF.

[0130] Once registration is complete and the desired network slice is activated at UE 110, in 1425, UE 110 transmits a PDU session modification request to AMF 205 to transfer the PDU session to the desired network slice. Although not shown in signaling diagram 1400, SMF reallocation can be performed to activate the desired network slice, and existing PDU session information is transferred to the new SMF.

[0131] In step 1430, AMF 205 transmits a registration acceptance message to UE 110. The registration acceptance message can be configured to include an information element indicating a change in PDU session association from a first network slice to a second different network slice.

[0132] In 1435, the same PDU session continues on a second, different network slice (e.g., S-NSSAI-B). As mentioned above, different network slices can have different QoS parameters. Therefore, before the modification process, the PDU session may undergo a first set of one or more QoS parameters, and after a successful PDU session modification process, the same PDU session may undergo a second, different set of one or more QoS parameters.

[0133] Example

[0134] In a first embodiment, the processor of the user equipment (UE) is configured to perform operations including establishing a packet data unit (PDU) session on a first network slice, determining to perform a PDU session transfer from the first network slice to a second different network slice, and continuing the PDU session on the second different network slice.

[0135] In the second embodiment, the processor of the first embodiment further includes initiating a registration process for activating a second different network slice prior to the PDU session transfer.

[0136] In the third embodiment, the processor of the second embodiment is used, wherein the registration process is triggered in response to an instruction received from a remote server.

[0137] In the fourth embodiment, the processor of the second embodiment is used, wherein the registration process is triggered in response to user input at the UE.

[0138] In the fifth embodiment, the processor of the second embodiment is used, wherein the registration process is initiated by a configuration update command received from the Service Access and Mobility Management Function (AMF).

[0139] In a sixth embodiment, the user equipment (UE) includes a transceiver and a processor configured to communicate with a network. The processor is communicatively coupled to the transceiver and configured to perform operations including transmitting a first registration request to the network, receiving a registration acceptance message in response to the first registration request, including a rejected network slice and an indication of a rejection reason corresponding to the rejected network slice, and transmitting a second registration request to the network including a requested network slice, wherein the requested network slice and the rejected network slice are the same network slice.

[0140] In the seventh embodiment, the user equipment (UE) includes a transceiver and a processor configured to communicate with a network, the transceiver being communicatively coupled to the transceiver and configured to perform operations including establishing a packet data unit (PDU) session on a first network slice, determining to perform a PDU session transfer from the first network slice to a second different network slice, and continuing the PDU session on the second different network slice.

[0141] 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.

[0142] 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.

[0143] 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.

[0144] 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), the method comprising: Transmit the first registration request to the Mobility Management Function (AMF) of the 5G network; Receive a registration acceptance message in response to the first registration request, the registration acceptance message including a rejected network slice and an indication of a rejection reason corresponding to the rejected network slice, the indication indicating that the rejected network slice is not allowed in a first tracking area of ​​the registration area; Initiate a Mobility Registration Update (MRU) based on the registration acceptance message; as well as After initiating the MRU, a second registration request including the requested network slice is transmitted from the second tracking area of ​​the registration area to the AMF, wherein the requested network slice and the rejected network slice are the same network slice.

2. The method according to claim 1, wherein the UE is deployed in the same registration area when receiving the registration acceptance message and transmitting the second registration request.

3. The method of claim 1, wherein the rejection reason is specific to the first tracking region of the registration region.

4. The method of claim 3, wherein the reason for rejection is indicated by the extended rejected network slice selection auxiliary information NSSAI information element.

5. The method according to claim 1, further comprising: Before transmitting the second registration request, an indication is received for one or more Tracking Region Identity (TAI) entries that allow the rejected network slice within the registration area.

6. The method of claim 1, wherein the denial reason is specific to the Access and Mobility Management Function (AMF).

7. The method according to claim 1, further comprising: Before transmitting the second registration request, receive an indication of the network slices allowed for each AMF within the Access and Mobility Management Function (AMF) pool.

8. A method performed by a network function, the method comprising: Receive the first registration request from the user equipment (UE); Transmit a first registration acceptance message in response to the first registration request, the first registration acceptance message including a rejected network slice and an indication of a rejection reason corresponding to the rejected network slice, the indication indicating that the rejected network slice is not allowed in a first tracking area of ​​the registration area; When the UE is in the second tracking area of ​​the registration area, as part of the UE-initiated Mobility Registration Update (MRU), the UE receives a second registration request from the UE. The second registration request includes a requested network slice, wherein the requested network slice and the rejected network slice are the same network slice. as well as Transmit a second registration acceptance message in response to the second registration request.

9. The method of claim 8, wherein the UE is deployed within the same registration area when receiving the registration acceptance message and transmitting the second registration request.

10. The method of claim 8, wherein the rejection reason is specific to the first tracking region of the registration region.

11. The method of claim 10, wherein the reason for rejection is indicated by the extended rejected network slice selection auxiliary information NSSAI information element.

12. The method according to claim 8, further comprising: Before receiving the second registration request, an indication is transmitted for one or more Tracking Region Identity (TAI) entries that are allowed in the registration area for the rejected network slice.

13. The method of claim 8, wherein the network function is an Access and Mobility Management Function (AMF), and the denial reason is specific to the AMF.

14. The method of claim 8, further comprising: Before receiving the second registration request, an indication is transmitted of the network slices allowed for each AMF within the Access and Mobility Management Function (AMF) pool.

15. The method of claim 8, further comprising: In response to the second registration request, an AMF reallocation process is initiated to the AMFs within the Access and Mobility Management Function (AMF) pool.

16. A user equipment (UE), comprising: A transceiver is configured to communicate with a network; as well as A processor, communicatively coupled to the transceiver, is configured to perform the following operations: Generate the first registration request for use in the Mobility Management Function (AMF) transmitted to the 5G network; Receive a registration acceptance message in response to the first registration request, the registration acceptance message including a rejected network slice and an indication of a rejection reason corresponding to the rejected network slice, the indication indicating that the rejected network slice is not allowed in a first tracking area of ​​the registration area; Initiate a Mobility Registration Update (MRU) based on the registration acceptance message; as well as A second registration request is generated, including the requested network slice, for transmission to the AMF, wherein the requested network slice and the rejected network slice are the same network slice.

17. The UE of claim 16, wherein the UE is deployed within the same registration area when receiving the registration acceptance message and transmitting the second registration request.

18. The UE of claim 16, wherein the rejection reason is specific to the first tracking region of the registration region.

19. The UE of claim 18, wherein the reason for rejection is indicated by the extended rejected network slice selection assistance information NSSAI information element.

20. The UE according to claim 16, further comprising: Before transmitting the second registration request, an indication is received for one or more Tracking Region Identity (TAI) entries that allow the rejected network slice within the registration area.

Images