Frequency range driven network slicing

Abstract

The invention discloses a frequency range driven network slicing. Network slice selection assistance information (NSSAI) may be signaled between a user equipment (UE) and a network. An NSSAI sent from a network to a UE may include, for example, an operating band (OFB) for each single NSSAI (S-NSSAI) in the NSSAI, and a Radio Access Technology (RAT) Frequency Selection Priority (RFSP) index, the network being configured as part of UE access and mobility subscription during a UE registration procedure. The RAT restriction may be enhanced to indicate to the UE that certain slices are not accessible via certain RATs. The network may provide the UE with an alternative NSSAI and a corresponding OFB for each S-NSSAI, indicating to the UE that these S-NSSAIs will be allowed if these S-NSSAIs were requested. The UE may be able to select an alternative allowed NSSAI and send a registration update request to the network.

Description

[0001] This application is a divisional application of the invention patent application with application date of December 31, 2020, application number 202080095519.6, and invention name “Frequency range driven network slicing”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to U.S. Provisional Patent Application S / N 62 / 956,441 filed on January 2, 2020, U.S. Provisional Patent Application S / N 62 / 972,212 filed on February 10, 2020, and U.S. Provisional Patent Application S / N 63 / 057,996 filed on July 29, 2020, all of which are titled “Frequency range driven network slicing,” the contents of which are incorporated herein by reference in their entirety. Background Art

[0004] The present disclosure relates to systems, methods and apparatus or wireless networking, such as, but not limited to: in 3rd Generation Partnership Project (3GPP) TS 23.501, System Architecture for 5G Systems, Stage 2, V16.1.0, Release 16, 2019-06; 3GPP TS 23.502, Procedures for 5G Systems, Stage 2, V16.1.1, Release 15, 2019-06; GSMA NG.116 Generic Slice Template, Version 1.0, May 23, 2019; 3GPP TS 38.101-1 User Equipment (UE) Radio Transmission and Reception, Part 1 - Scope 1 Standalone, V16.1.0 (2019-09); 3GPP TS 38.101-2 User Equipment (UE) Radio Transmission and Reception, Part 2 - Scope 2 Standalone, V16.1.0 (2019-09); and 3GPP The techniques described in TS 23.503, Policy and Charging Control Framework for 5G Systems (5GS), Stage 2 (Release 16). Summary of the invention

[0005] When a user equipment (UE) needs to access a network slice available on various frequency bands, the UE may need to select a frequency band and connect to the network, disconnect / disable the connection, or switch between different frequency bands. These goals can be achieved through various mechanisms.

[0006] The UE may receive the allowed Network Slice Selection Assistance Information (NSSAI) and the operating frequency band (OFB) for each Single Network Slice Selection Assistance Information (S-NSSAI) in the NSSAI and its Radio Access Technology (RAT) Frequency Selection Priority (RFSP) index from the network, which the network configures as part of the UE access and mobility subscription during the UE registration procedure.

[0007] RAT restrictions may be enforced to indicate to the UE that certain slices cannot be accessed via certain RATs.

[0008] The network may provide the UE with alternative NSSAIs and the corresponding OFB for each S-NSSAI, thereby indicating to the UE that these S-NSSAIs would be allowed if requested.

[0009] The UE may be able to select an alternative allowed NSSAI and send a registration update request to the network.

[0010] Enhanced UE Routing Policy (URSP) rules may include an indication of a public land mobile network (PLMN) identifier (ID) and / or OFB selection information, so that the UE may be able to steer itself to the intended slice by selecting an operating frequency band.

[0011] The network may send a radio resource control (RRC) message to the UE to indicate a specific S-NSSAI among the allowed NSSAIs that is accessible and inaccessible with the UE's current frequency band.

[0012] The UE may indicate in an RRC message that it wishes to access an S-NSSAI that may not be accessible with the UE's current frequency band, and the network may redirect the UE with a handover command so that the UE may switch to the correct frequency band to access the desired S-NSSAI.

[0013] Other challenges to be addressed include, for example, that a UE may not be allowed to access certain slices simultaneously, and that certain slices may only be available to a UE in certain locations (e.g., geographic areas and / or tracking areas). Many approaches can be taken to address such situations.

[0014] In order to control simultaneous access to network slices, the UE may indicate its Synchronous Slice Access Capability (SSAC) to the network, for example during the UE registration procedure, and by including an SSAC indicator in each S-NSSAI of configured NSSAI, allowed NSSAI and / or denied S-NSSAI, the network may be able to convey to the UE whether a slice is accessible simultaneously with other network slices.

[0015] A UE may be allowed to register multiple S-NSSAIs, where the UE may be restricted from having simultaneous packet data unit (PDU) sessions with two or more slices based on a configured Synchronous Slice Access Policy (SSAP). For example, an access and mobility management function (AMF) may reject a PDU session establishment request with a reason code detailing that slice A cannot access slice B. The UE may receive the reason code, and depending on its urgency or requirement, the UE may end the session with slice A and retry the PDU session establishment request with slice B.

[0016] The UE may be configured to know which S-NSSAI is available or not available in a geographic area. The location information may be provided to the UE in the S-NSSAI information. In addition, for example, the network may use a NULL slice / service type (SST) value to indicate to the UE that the network recognizes the S-NSSAI, but the S-NSSAI is not available in a particular geographic area and / or PLMN.

[0017] An enhanced registration procedure may be used, where the UE is configured with information about the geographical areas from which it is accessible. The UE may then use this information when selecting a route for uplink data. For example, when a slice is not available, the UE may use this information to select a lower priority route.

[0018] An enhanced PLMN selection or reselection mechanism may be used, in which the UE considers the availability of network slices in each PLMN when determining whether to register with the PLMN.

[0019] When the UE evaluates the URSP rules and identifies that a route cannot be established for the service because the desired S-NSSAI is not available in the UE's current location in the PLMN, the UE may trigger PLMN reselection.

[0020] Another challenge is that a UE may sometimes only have access to all available network slices in the UE's current OFB. Many solutions are available.

[0021] For example, the UE may inform the network (e.g., radio access network (RAN) and / or core network) about the operating frequency bands (OFBs) that the UE can support. This information may be utilized by the network to identify and facilitate the UE's requested slices.

[0022] Based on the UE's supported OFBs, the requested network slices, and the OFBs where the requested slices are available, the network can guide the UE to switch to a different OFB where, for example, all or most of the requested slices are available.

[0023] The UE may consider the cause code conveyed by the network and resend the UE Registration Request to the network using the received OFB information while ensuring that the allowed NSSAI is not updated until the handover is completed. In the new OFB, once the registration is accepted, the UE may receive a set of allowed slices.

[0024] During the registration update request procedure, the UE may send an indicator to the network to inform the network that the UE desires to update the allowed NSSAI, as long as the network can allow all slices in the request in the UE's current operating band. If the network cannot allow all requested slices, the UE may continue to operate with its currently allowed NSSAI.

[0025] The UE may receive a list of Tracking Areas / Registration Areas (TA / RA) where all slices in the UE's allowed NSSAI are available during a successful UE registration procedure. Since the UE may be a mobile device, it may be applicable for the UE to know such TA / RA where the UE may be gracefully handed over.

[0026] The UE may send a non-access stratum (NAS) message to the network requesting a TA / RA list where all slices in the UE's allowed NSSAI are available. The request may be triggered by some UE context, such as time, TA change, and / or direction.

[0027] Both UE-OFB policy and Synchronous Slice Access Policy (SSAP) can be applied as constraints for accessing two or more slices simultaneously during the UE registration procedure. Based on the policy, the UE can change OFB to access slices simultaneously.

[0028] During PDU session establishment, UE-OFB policy and SSAP can be applied simultaneously. Based on the decision given by the network, the UE can request a registration update by switching its OFB and continue the PDU session. Alternatively, the UE can decide to continue the existing PDU session without registration update and OFB switching.

[0029] The UE may initiate a PDU session establishment request indicating only those slices that are available in the UE's current OFB.

[0030] During a PDU session with a slice in the network, the UE may include S-NSSAI information for the desired slice in the RRC message directed to the RAN. The RAN may identify the requested slice and the OFB associated with the requested slice, and based on the requested slice and the current OFB of the UE, the RAN may allow further PDU session establishment procedures, otherwise it may guide the UE to change the OFB before continuing the PDU session establishment procedure.

[0031] For a mobile UE with multiple ongoing PDU sessions, the RAN node may assist in switching the UE's OFB, where the UE may continue the existing PDU sessions. Based on the OFB supported by the UE and the slice, the RAN may facilitate the UE's new cell / OFB with continuation of all PDU sessions, some PDU sessions, or no ongoing PDU sessions.

[0032] The purpose of providing this summary is to introduce selected concepts in a simplified form, which are further described in the following detailed description. This summary is neither intended to identify the key or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings.

[0034] Figure 1 is a block diagram of an exemplary 5G system service-based architecture.

[0035] Figure 2 is a block diagram of an exemplary non-roaming 5G system architecture in reference point representation.

[0036] Figure 3 An exemplary core network providing multiple network slices is shown.

[0037] Figure 4 is a call flow for an example of NSSAI and operating band information passing during registration.

[0038] Figure 5A and Figure 5B An example call flow for providing alternative slices and corresponding frequency bands to a UE is shown.

[0039] Fig. 6A and Figure 6B An example call flow for band redirection using RRC messaging is shown.

[0040] Figure 7 An exemplary graphical user interface (GUI) of a UE with NSSAI and OFB and enhanced URSP rules is shown.

[0041] Fig. 8A An exemplary communication system is presented in which the methods and apparatus described and claimed herein may be embodied.

[0042] Figure 8B is a block diagram of an exemplary apparatus or device configured for wireless communication.

[0043] Figure 8C is a system diagram of an exemplary radio access network (RAN) and core network.

[0044] Fig.8D is a system diagram of another exemplary RAN and core network.

[0045] Fig. 8E is a system diagram of another exemplary RAN and core network.

[0046] Fig.8F is a block diagram of an exemplary computing system.

[0047] Figure 8G is a block diagram of another exemplary communication system.

[0048] Fig. 9 An exemplary S-NSSAI information element is shown.

[0049] Fig.10 An exemplary enhanced S-NSSAI information element with OFB is shown.

[0050] Fig.11 is an example call flow for delivering a synchronization slice access policy indicator to a UE.

[0051] Fig.12 This is a call flow for an example of a UE re-registering to a desired slice after being rejected due to synchronized slice access policy.

[0052] Fig.13 This is an example call flow for handling a PDU session request with synchronous slice access restriction.

[0053] Fig.14 is an example call flow for a UE with restricted access to network slices based on geographic area.

[0054] Fig.15 This is an example call flow for configuring slice location restriction information via access and mobility subscription.

[0055] Fig.16 An exemplary graphical user interface (GUI) of a UE is shown, indicating support for synchronized slice access restriction, areas of service restriction for slice access, and supported capabilities.

[0056] Fig.17 is a call flow for an example of operating a band switch during the registration procedure.

[0057] Fig.18 Here is an example call flow for a registration update with allowed slices in the UE’s current OFB.

[0058] Fig.19This is an example call flow for UE to receive TA / RA information from the network, where all slices are available in all OFBs.

[0059] Fig. 20 is a call flow of an example of UE registration procedure with SSAP and UE OFB policy.

[0060] Fig.21 is a call flow of an example that handles synchronization restrictions due to UE-OFB policy and SSAP.

[0061] Fig. 22 is an example call flow for a UE sending S-NSSAI in an RRC message during a PDU Session Establishment Request.

[0062] Fig.23 is an example call flow showing RAN of OFB for PDU session continuity. DETAILED DESCRIPTION

[0063] Special terms

[0064] Table 14 of the Appendix includes many of the abbreviations used herein. The following are terms and neologisms used by the inventors herein.

[0065] Tracking Area (TA) - A TA is a group of cells. A TA can be grouped into a list of tracking areas (TA list) which can be configured on a user equipment (UE). A TA is used for access control, location registration, paging and mobility management of the UE.

[0066] Registration Area (RA) - A Registration Area is an area in which a UE can roam without performing location registration, which is a NAS procedure.

[0067] Service area restrictions - A service area restriction may include one or more TAs, or be set to be unrestricted, for example, including all TAs of a public land mobile network (PLMN). The subscription data of the UE in the unified data management (UDM) may include a service area restriction, for example, which specifies which TAs are allowed areas and / or which TAs are not allowed areas using explicit TA identifiers. Additionally or alternatively, the service area restriction identifies allowed and / or not allowed TAs using geographic information (such as longitude / latitude, postal code, etc.).

[0068] Alternative Network Slice Selection Assistance Information (NSSAI) - NSSAI may be provided in "Alternative NSSAI" comprising a set of one or more Single Network Slice Selection Assistance Information (S-NSSAI) that the UE is allowed to access if the UE chooses to do so.

[0069] Network Function (NF) - A NF is a processing function in a network with defined functional behavior and defined interfaces. A NF can be implemented as a network element on dedicated hardware, a software instance running on dedicated hardware, or a virtualized function instantiated on an appropriate platform (such as on a cloud infrastructure).

[0070] NF Instance - A NF instance is an identifiable instance of a NF.

[0071] Network Function Service - NF Service is a capability reserved by a first NF (NF Service Producer) to another authorized NF (NF Service Client) through a service-based interface. NF can expose one or more NF Services. For example, AMF can provide Namf_EventExposure service, which enables AMF to send notifications to NFs that subscribe to certain mobility management related events.

[0072] NF Service Instance - An NF Service Instance is an identifiable instance of an NF Service.

[0073] Network Slicing - A network slice is a logical network that provides specific network capabilities and network characteristics.

[0074] Network Slice Instance - A network slice instance is a set of NF instances and the required resources (e.g., compute, storage, and network resources) that constitute a deployed network slice.

[0075] Network Capabilities - Network capabilities are transport network features that the core network implements and provides to its users (e.g., UEs and application servers). Examples of network capabilities include background data transfer and event monitoring. Network capabilities may be enabled by one or more NF services of one or more NFs.

[0076] Operating Frequency Band (OFB) - OFB or operating frequency band is the frequency range for data transmission or reception between UE and RAN node. In this document, "OFB" and "operating frequency band" are used interchangeably.

[0077] PC5 (Interface)-PC5 refers to the reference point where a user equipment communicates with another user equipment through a direct channel.

[0078] Radio Access Technology / Frequency Selection Priority (RFSP) Index - In Long Term Evolution (LTE), to support Radio Resource Management in E-UTRAN, the Mobility Management Entity (MME) provides the parameter 'RAT Index / Frequency Selection Priority' (RFSP Index) to the evolved NodeB across S1. To apply specific Radio Resource Management (RRM) policies, the evolved NodeB maps the RFSP Index to a locally defined configuration. The RFSP Index is UE specific and applies to all radio bearers. The E-UTRAN can use this parameter to derive UE specific cell reselection priorities to control idle mode, or to decide to redirect an active mode UE to a different frequency layer or RAT. Similarly, in 5GS, the AMF receives the subscribed RFSP Index from the UDM / Unified Data Repository (UDR) and maps to the gNodeB to a locally defined configuration to apply specific RRM policies.

[0079] Synchronous Slice Access Policy (SSAP) - The term SSAP refers herein to a set of policies that govern a UE's simultaneous access to two or more network slices at a time. For example, a UE may be able to access an Ultra-Reliable Low Latency Communication (URLLC) slice, but may be denied access to an enhanced Mobile Broadband (eMBB) slice, while the UE is allowed access to and / or has access to a URLLC slice.

[0080] Synchronous Slice Access Capability (SSAC) - The term SSAC refers in this document to a system capability in 3GPP Rel-17 or higher, whereby the network may have to impose restrictions on a UE accessing two or more slices simultaneously. This capability restriction may be placed by a mobile network operator (MNO) in the core network and based on SSAP. The core network provides the UE with SSAC indicators that define the nature of synchronous access. The UE may need to support such policies. A UE that supports SSAP is known to have synchronous slice access capability. The UE communicates its support for the SSAC indicator via the SSAC Support Indicator (SSI).

[0081] UE-OFB Policy - The term UE-OFB policy in this document refers to the policy that allows the UE to access only those slices that are available in the UE's current operating frequency band (OFB). If at least one slice in a set of requested slices is not available in the UE's current OFB, the request to access all slices is denied and an OFB handover is proposed where all requested slices are available.

[0082] Uu (interface) - the radio interface between 5G RAN and user equipment.

[0083] Exemplary 5G Network Architecture

[0084] Figure 1An exemplary non-roaming reference architecture with a service-based interface within the control plane (CP) is shown. See 3GPP TS 23.501, System Architecture for 5G Systems; Stage 2, V16.1.0, Release 16, 2019-06.

[0085] Figure 2 Depicts an exemplary 5G system architecture for a non-roaming scenario represented using reference points, showing how the various network functions interact with each other. See TS 23.501.

[0086] The mobility management and session management functions (SMF) are separate. A single N1 NAS connection is used for both registration management and connection management, and for session management (SM) related messages and procedures for the UE. The single N1 termination point is located in the AMF. The AMF forwards the SM related NAS information to the SMF. The AMF handles the registration management and connection management parts of the NAS signaling exchanged with the UE. The SMF handles the SM part of the NAS signaling exchanged with the UE.

[0087] Network Features

[0088] 5G architecture supports data connectivity and services, enabling deployments to use technologies such as network function virtualization and software-defined networking. 5G system architecture allows service-based interactions between network functions (NFs) utilizing an identified control plane (CP).

[0089] NF is a processing function in a network with defined functional behavior and defined interfaces. NF can be implemented as a network element on dedicated hardware, or as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform (e.g., on a cloud infrastructure).

[0090] Network Slicing in 5GC

[0091] A network slice is a logical network that provides specific network capabilities and network characteristics. A network slice within a PLMN includes the core network (CN) control plane (CP) and user plane network functions. A network slice instance is a set of NF instances and the required resources (e.g., computing, storage, and network resources) that constitute a deployed network slice.

[0092] Network slices may differ with respect to supported features and network function optimizations, in which case such network slices may have different SSTs. An operator may deploy multiple network slice instances that deliver the same features, but for different groups of UEs, for example, because they deliver different promised services and / or because they are dedicated to customers, in which case such network slices may have the same SST, but be differentiated by different slice differentiators.

[0093] The network may simultaneously serve a single UE with one or more network slice instances via the 5G-AN and be associated with a total of up to eight different S-NSSAIs, regardless of the access type (e.g., 3GPP access and / or N3GPP access) on which the UE is registered. The AMF instance serving the UE logically belongs to each network slice instance serving the UE, for example, the AMF instance is common to the network slice instance serving the UE.

[0094] Identification and selection of network slices: S-NSSAI and NSSAI

[0095] A network slice is identified by S-NSSAI, which may include a slice / service type (SST) and a slice differentiator (SD). SST refers to the expected network slice behavior in terms of features and services. Slice differentiator (SD) is optional information that supplements SST to distinguish between multiple network slices of the same SST.

[0096] The S-NSSAI may have a standard value (e.g., such S-NSSAI consists only of SST with a standard SST value and no SD) or a non-standard value (e.g., such S-NSSAI consists of either both SST and SD, or consists only of SST without a standard SST value and no SD). The S-NSSAI with a non-standard value identifies a single network slice associated with it within a PLMN. The S-NSSAI with a non-standard value should not be used by the UE in access stratum (AS) procedures in any PLMN, except the PLMN associated with the S-NSSAI. Table 1 of the Appendix shows standard SST values.

[0097] NSSAI is a set of S-NSSAIs. NSSAI can be a configured NSSAI, a requested NSSAI, or an allowed NSSAI. There can be up to eight S-NSSAIs in the allowed and requested NSSAIs sent in the signaling messages between the UE and the network. The requested NSSAI signaled by the UE to the network allows the network to select a serving AMF, network slice, and network slice instance for the UE.

[0098] Based on the operator's operational or deployment requirements, a network slice instance may be associated with one or more S-NSSAIs, and an S-NSSAI may be associated with one or more network slice instances. Multiple network slice instances associated with the same S-NSSAI may be deployed in the same or different tracking areas (TAs). When multiple network slice instances associated with the same S-NSSAI are deployed in the same TA, the AMF instance serving the UE may logically belong to (e.g., jointly belong to) more than one network slice instance associated with the S-NSSAI.

[0099] Based on the requested NSSAI (if any) and subscription information, the 5G Core (5GC) is responsible for selecting a network slice instance to serve the UE, including the 5GC control plane (CP) and user plane network functions (NFs) corresponding to that network slice instance.

[0100] The RAN may use the requested NSSAI in access stratum (AS) signaling to handle the UE CP connection before the 5GC notifies the RAN of the allowed NSSAI. The requested NSSAI is used by the RAN for AMF selection as described in clause 6.3.5. When the UE asks to resume the RRC connection and is connected to an RRC inactive CM, the UE shall not include the requested NSSAI in the RRC resumption.

[0101] When the UE successfully registers with an access type, the CN informs the RAN by providing the allowed NSSAI for the corresponding access type.

[0102] Standardized SST values ​​provide a means to establish global interoperability of slices so that PLMNs can more efficiently support roaming use cases for the most commonly used SSTs.

[0103] The standardized SST is in Table 1 below in the Appendix to this document. See TS 23.501.

[0104] Configured NSSAI

[0105] The configured NSSAI is the NSSAI provided in the UE and applicable to one or more PLMNs. The configured NSSAI can be configured by the serving PLMN and applied to the serving PLMN. Each PLMN is configured with at most one NSSAI.

[0106] NSSAI with default configuration

[0107] The default configured NSSAI is configured by the Home Public Land Mobile Network (HPLMN) and applies to any PLMN for which no specific configured NSSAI is provided to the UE. The value used in the default configured NSSAI is expected to be determined normally by all roaming partners. If the default configured NSSAI is configured in the UE, it is used by the UE in the serving PLMN only if the UE does not have an NSSAI configured for the serving PLMN. The UE may be pre-configured with a default configured NSSAI.

[0108] Requested by NSSAI

[0109] The requested NSSAI is the NSSAI provided by the UE to the serving PLMN during registration. The S-NSSAI in the requested NSSAI is selected from the configured NSSAI applicable to that PLMN (when available). If no configured NSSAI for the PLMN is available, the S-NSSAI in the requested NSSAI is selected from the default configured NSSAI, if configured in the UE.

[0110] The requested NSSAI signaled by the UE to the network allows the network to select a serving AMF, network slice and network slice instance for the UE. Based on the requested NSSAI (if any) and subscription information, the 5GC is responsible for selecting a network slice instance to serve the UE, including the 5GC control plane and user plane network functions corresponding to the network slice instance.

[0111] Permitted NSSAI

[0112] The allowed NSSAI is the NSSAI provided by the serving PLMN during the registration procedure, indicating that the UE is not registered to the S-NSSAI value in the serving PLMN of the current registration area. When the UE registration procedure is successfully completed by access type, the UE obtains the allowed NSSAI for that access type from the AMF, which includes one or more S-NSSAIs and (if necessary) their mapping to the HPLMN S-NSSAI. These S-NSSAIs are valid for the current registration area and access type and can be used by the UE simultaneously.

[0113] Allowed NSSAI mappings

[0114] The mapping of allowed NSSAIs is a mapping of each S-NSSAI of the allowed NSSAIs of the serving PLMN to the HPLMN S-NSSAI.

[0115] Configure NSSAI mapping

[0116] The mapping of configured NSSAI is a mapping of each S-NSSAI of the configured NSSAI of the serving PLMN to the HPLMN S-NSSAI.

[0117] S-NSSAI Coding

[0118] The purpose of the S-NSSAI information element is to identify the network slice. The encoding of the S-NSSAI information element is as shown in the Appendix of this document. Fig. 9 and Table 8, as described in 9.11.2.8 of 3GPP TS24.501 non-access stratum (NAS) protocol for 5G systems.

[0119] S-NSSAI is a Type 4 information element with a minimum length of 3 octets and a maximum length of 10 octets.

[0120] URSP Rules

[0121] The UE's routing policy (URSP) includes a prioritized list of URSP rules. See 3GPP TS 23.503, Policy and Charging Control Framework for 5G Systems; Stage 2 (Release 16). See also Table 2 of the Appendix herein, which shows the URSP. The structure of the URSP rules is as described in Tables 3 and 4 of the Appendix herein.

[0122] Enhancements in Network Slicing

[0123] 3GPP SA2 study, Feasibility Study on Enhancements to Network Slicing Phase 2 (S2-1908583) deals with new enhancements in network slicing. The study was conducted as a result of a request received from the GSMA 5GJA to further investigate and incorporate recommended features based on the concepts of the Generic Slicing Template (GST) published in GSMA NG.116 Generic Slicing Template, Version 1.0, 23 May 2019. The main objectives of the study are to identify 5G system procedures in the SA2 owned TS to support the GST parameters and to investigate potential solutions that could address these gaps.

[0124] Among the many relevant attributes that are featured in NG.116, one of them deals with the radio spectrum supported by the network slice. Each network slice may support or operate in a different radio frequency range based on the type of service it provides. The frequency ranges in which the New Radio (NR) may operate are identified as described in Table 5.1-1 in TS 38.101. See Table 5 of the Appendix to this document.

[0125] This means that specific frequency bands can be used to access specific network slices. For example, eMBB slices can be supported at 2.6GHz and 4.9GHz, while URLLC slices can only be supported at 4.9GHz. In some other deployment scenarios, lower frequency bands can be used for IoT while using higher frequency bands for eMBB services. That said, the combination of spectrum bands and network slices is a great tool for service providers who need service isolation as well as efficient use of 5G spectrum bands.

[0126] Radio spectrum

[0127] NG.116 defines an attribute called radio spectrum to address a specific frequency range. In NG.116, this attribute defines the radio spectrum supported by the network slice. This is important information because some terminals may be restricted in the frequency they can use. Table 6 of the Appendix to this document depicts a description of the radio spectrum attribute.

[0128] This attribute defines the frequencies that can be used to access the network slice. NR is designed to operate in FR1 and FR2 operating bands. The symbols n1, n77, n38 in Table 6 represent examples of NR operating bands within the FR1 frequency range name. Table 5.2.-1 of TS23.101 defines the relationship between the frequency range names FR1 and FR2 (Table 5) and the NR operating bands. For example, the n1 NR operating band represents an uplink (UL) operating band between 1920MHz–1980MHz for UE to transmit and base station to receive, and a downlink (DL) operating band between 2110MHz–2170MHz for UE to receive and base station to transmit, and operates in FDD (frequency division duplex) duplex mode.

[0129] It can also be noted that the Radio Spectrum attribute has an extensible attribute tag. Tags are used as labels attached to attributes to give additional information about the nature of each attribute. GSMA NG.116 defines two types of attributes, character attributes and extensible attributes. An attribute cannot fall into two categories.

[0130] The character attribute characterizes the slice, such as the throughput, latency and / or application programming interface (API) it provides. It is independent of the network slice customer (NSC) and the network slice provider (NSP). The scalability attribute provides attribute information about the scalability of the slice; for example, the number of terminals allowed in the slice. This type of attribute is specific to the network slice customer (NSC) and the network slice provider (NSP).

[0131] Service Area

[0132] NG.116 also defines a service area attribute. This attribute specifies the area in which a terminal can access a specific network slice. Thus, the attribute specifies a list of countries where the service will be provided.

[0133] The list is specific to the Network Slice Provider (NSP) and its roaming agreement. In case the list includes more than one entry, a roaming agreement between the HPLMN and the Visited Public Land Mobile Network (VPLMN) is required. Table 9 of the Appendix to this document describes the attribute details.

[0134] Regional regulations

[0135] For each country listed in the Regions of the service attributes, it is necessary to indicate whether the service will be provided in the entire country or only in a part of the country. If a network slice customer (NSC) requires a specific location, this attribute can be used to specify the region of the country where the service will be provided. This needs to be completed for each country listed in the Regions of the service attributes.

[0136] The list of regions is specific to each country and the way these regions are defined is the decision of the Network Slice Customer (NSC) and the Network Slice Provider (NSP). Table 10 of the Appendix to this document describes the attribute details.

[0137] The service area may also depend on the base station location and its coverage, cells, etc. In addition, the GSMA NST 116 document describes geographical partitioning. This approach requires partitioning the geographical area into a set of regions / grids, which include areas of a set of predetermined dimensions that define rules for better resource utilization.

[0138] Radio resource management function

[0139] To support radio resource management in the RAN, the AMF provides the parameter "Radio Access Frequency (RAT) / Frequency Selection Priority Index" (RFSP Index) to the Radio Access Network (RAN) across N2. See TS23.501. Taking into account any available information in the RAN, the RAN maps the RFSP index to a locally defined configuration in order to apply a specific Radio Resource Management (RRM) policy. The RFSP index is UE-specific and applies to all radio bearers. The RAN can use this parameter to derive UE-specific cell reselection priorities to control idle mode and can also be used to decide to redirect an active mode UE to a different frequency layer or RAT.

[0140] The HPLMN may set the RFSP index taking into account the subscribed S-NSSAI. The AMF receives the subscribed RFSP index from the UDM (e.g., during the registration procedure). For non-roaming subscribers, the AMF selects the RFSP index in use according to one of the following procedures based on the operator's configuration. The RFSP index in use may be the same as the subscribed RFSP index, or the AMF may select the RFSP index in use based on the subscribed RFSP index, locally configured operator policies, allowed NSSAIs, and UE-related context information available at the AMF (including the UE's usage settings, if received during the registration procedure) (see 3GPP TS 23.502, Procedures for 5G Systems; Stage 2, V16.1.1, Release 15, 2019-06).

[0141] For roaming subscribers, the AMF may select the RFSP index in use based on the visited network policy, but may take into account input from the HPLMN (e.g., a pre-configured RFSP index value per HPLMN, or a single RFSP index value for all roamers independent of the HPLMN).

[0142] When Xn or N2 is used for intra-NG-RAN handover, the RFSP index in use is also forwarded from the source RAN node to the target RAN node.

[0143] The AMF stores the received subscribed RFSP index value and the RFSP index value in use. During the registration procedure, the AMF may update the RFSP index value in use (for example, if the UE-related context information in the AMF has changed, the AMF may need to update the RFSP index value in use). When the RFSP index value in use changes, if no user plane needs to be established, the AMF immediately provides the NG-RAN node with the updated RFSP index value in use by modifying the existing UE context, or by establishing a new UE context in the RAN, or by configuring it to include the updated RFSP index value in use in the Next Generation Application Protocol (NGAP) downlink NAS transport message.

[0144] Access and mobility related policy control

[0145] The access and mobility policy control functions include the management of service area restrictions, management of RFSP functionality and UE aggregate maximum bit rate (UE-AMBR), and management of SMF selection. This clause defines the management of service area restrictions and RFSP index for UEs registered through 3GPP access.

[0146] The subscription of a UE may contain a service area restriction, which may be further modified by a Policy Control Function (PCF) at any time based on operator defined policies, either by extending the list of allowed Tracking Area Identifiers (TAIs), by reducing the number of not allowed TAIs, or by increasing the maximum number of allowed TAIs. Operator defined policies in the PCF may depend on input data such as UE location, time of day, and information provided by other NFs.

[0147] The AMF may report subscribed service area restrictions received from the UDM during the registration procedure or when the AMF changes. The conditions for the report require local policy indications in the AMF to enable access and mobility control. The AMF also reports the subscribed service area restrictions to the PCF when the policy control request trigger for the service area restriction changes, as described in clause 6.1.2.5 of 3GPP TS23.503, Policy and Charging Control Framework for 5G Systems (5GS); Stage 2 (Release 16) is met. The AMF receives modified service area restrictions from the PCF. The AMF stores them and then uses them to determine the mobility restrictions for the UE. The PCF may indicate to the AMF that there is an unrestricted service area.

[0148] The service area restriction consists of a list of allowed TAIs or a list of disallowed TAIs, and optionally a maximum number of allowed TAIs.

[0149] Management of RFSP indexes enables the PCF to modify the RFSP indexes used by the AMF to perform radio resource management functions as described in TS23.501 clause 5.3.4. The PCF modifies the RFSP indexes based on operator policy, which takes into account the accumulated usage, load level information for each network slice instance, etc. The subscribed RSFP index can be further adjusted by the PCF at any time based on operator policy.

[0150] For radio resource management, AMF may report the subscribed RFSP index received from UDM during the registration procedure or when AMF changes. The conditions for reporting require local policy indication in AMF to enable access and mobility control. When the subscription to the RFSP index change of PCF is met, AMF reports the subscribed RFSP index to PCF. AMF receives the modified RFSP index from PCF.

[0151] Management of UE-AMBR enables PCF to provide UE-AMBR information to AMF based on serving network policy. AMF may report the subscribed UE-AMBR received from UDM. The conditions for reporting require PCF to provide a policy control request trigger to AMF to report the subscriber UE-AMBR change. AMF receives the modified UE-AMBR from PCF. AMF provides the UE-AMBR value of the serving network to RAN as specified in clause 5.7.2.6 of TS23.501.

[0152] Example Challenge

[0153] An MNO may provide multiple network slices. Each network slice may be designed and configured to provide specific slice characteristics to the UE, such as desired QoS, security features, and network functions. Four standard slice / service types are defined in TS 23.501, Rel 16. See Table 1 of the Appendix to this document. A network operator may wish to plan its network so that certain slices are only available via certain frequency bands.

[0154] Figure 3 A core network is shown that can provide four different types of network slices. Namely, URLLC, V2X, eMBB, and Massive Internet of Things (MIoT). These network slices can operate in different frequency bands, and these frequency bands can be assigned to slice types based on factors such as QoS, NFs, and / or geographic regions.

[0155] When a UE accesses a specific slice, the network may need to restrict the UE from accessing any other slices, thereby restricting the UE from accessing other slices with the same SST value, or restricting the UE from accessing other slices with the same SD value. This may be desirable, for example, in a scenario where an enterprise has deployed a slice and wishes to prevent the UE from accessing the slice when the UE is simultaneously accessing other slices or slices belonging to another enterprise.

[0156] Another network slicing scenario that should be considered involves roaming. When the UE is roaming, the roaming agreement between the UE's HPLMN and the VPLMN indicates which slices the UE is allowed to access via the VPLMN. In addition, the roaming agreement can be arranged so that the VPLMN allows the UE to access certain slices in some countries or regions, but not in other countries or regions. For example, this can be done in a scenario where an enterprise does not want its slices to be accessed from a certain country or region, or does not want to access its slices in a scenario where local regulations dictate that certain slice types should not be accessed.

[0157] In reference Figure 3 In the described scenario, when the UE needs to access a slice that is only available on a single frequency band, the UE may need to select a frequency band, disconnect / disable the connection to another frequency band, or switch between different frequency bands.

[0158] Based on the type of UE and the applications used in the target network slice, the UE must be able to steer itself to a predefined and pre-allocated frequency band corresponding to the frequency band of the slice. The current 5GS does not provide a mechanism for steering the UE to a specific frequency band allocated for a specific network slice without registration and deregistration.

[0159] The UE must be configured with a set of policies to navigate itself between the frequency bands allocated for the network slices. The 5GS must define such policies. The MNO allocates frequency bands for the network slices, but the UE may need the frequency band information in order to successfully steer to the correct network slice. Therefore, the UE must be provided with information about the relationship between frequency bands and network slices. Currently, the 5GS does not describe a mechanism to configure or communicate such frequency band and corresponding network slice information to the UE.

[0160] The UE must have a strategy using the information received from the core network to correctly steer itself to the target network slice via the correct operating band. Such a strategy may be pre-configured in the UE or may be delivered by the core network. Currently 5GS does not define such a strategy for the UE. In addition, a strategy needs to be defined in the UE so that it can successfully steer to the correct frequency.

[0161] In order to allow the network to restrict the UE from accessing any other slice, restrict the UE from accessing other slices with the same SST value, or restrict the UE from accessing other slices with the same SD value, the following issues need to be addressed.

[0162] First, how does 5GS make the UE aware of these limitations? In other words, how does the network make the UE aware that these limitations exist?

[0163] Second, how does the UE handle the situation where the UE is accessing a slice where new application layer activity would normally trigger the UE to attempt to send traffic on the currently restricted slice?

[0164] Third, what does the network do when the UE attempts to violate the restrictions? In other words, what does the network do when the UE attempts to simultaneously access two slices that are not allowed to be accessed simultaneously? The answer to this question should take into account that the network needs to enforce these restrictions for legacy (Rel-15 and Rel-16) UEs as well.

[0165] In order to handle the situation where the UE is only allowed to access certain slices in certain PLMNs when the UE is roaming, the following problem needs to be solved.

[0166] First, when the UE is roaming, how does the network communicate to the UE that some slices are not accessible in certain PLMNs? In other words, when the UE is located in a certain country or region, how does the network tell the UE that a slice is not accessible via a given VPLMN?

[0167] Second, how does the current location and slice that the UE may want to visit affect the PLMN selection?

[0168] Third, if the UE attempts to access a slice via a PLMN that does not allow access to the slice and is rejected, should the UE attempt to switch to a different PLMN?

[0169] Fourth, the answers to the questions discussed in this article should take into account that the network needs to enforce these restrictions for legacy (Rel-15 and Rel-16) UEs as well.

[0170] In addition, once the UE is restricted to access network slices based on the OFB of available slices, multiple scenarios of slice access may occur. For example, the UE is only allowed to access the slices available in the UE's current OFB. In this setting, the following issues may need to be addressed:

[0171] How does the UE communicate its supported OFB to the network so that the network can help the UE select a slice accessible to the UE?

[0172] What happens when the UE wants to access a slice that is not available in the UE's current OFB? How does the network facilitate the UE's access to the slice?

[0173] When OFB becomes a constraint on accessing a slice, how does it affect the constraint on simultaneous access of two or more slices by UE?

[0174] How does the 5GS manage the UE's request to establish a PDU session for a slice if the slice is not in the UE's current OFB? How does the 5GS handle the scenario of PDU session continuity when the UE moves to a new OFB / cell? The answer to this question should also take into account the network's need to enforce these restrictions for legacy (Rel-15 and Rel-16) UEs.

[0175] UE-based frequency band configuration solution

[0176] The network slices may be predefined and allocated operating bands, which translate to specific UL and DL frequency ranges, 3GPP TS 38.101 (including Part 1 and Part 2, TS 38.101-1 and TS 38.101-2) User Equipment (UE) Radio Transmission and Reception V16.1.0 (2019-09). The allocation and configuration of these operating bands and corresponding network slices may depend on the local policy of the MNO. Figure 4 An exemplary method is shown by which the operating band of each slice is communicated to the UE.

[0177] exist Figure 4 In step 0 of , the MNO may allocate operating bands (e.g., n1, n7, n12, etc.) as defined in 3GPP TS 38.101-1 User Equipment (UE) Radio Transmission and Reception; Parts 1 and 2, V16.1.0 (2019-09) and assign them to the S-NSSAI as part of the UE access and mobility subscription at the UDM / UDR. This may include RFSP index configuration.

[0178] In step 1, the UE sends a registration request to the AMF via the access network. The request includes the requested NSSAI. In case of initial registration or mobility registration update, the UE includes a mapping of the requested NSSAI (if available) which is a mapping of each S-NSSAI of the requested NSSAI to the HPLMN S-NSSAI to ensure that the network can verify whether the S-NSSAI in the requested NSSAI is permitted based on the subscribed S-NSSAI. If the UE is using the default configured NSSAI, the UE includes a default configured NSSAI indication.

[0179] In step 2, the RAN selects an AMF as described in TS 23.501 clause 6.3.5.

[0180] In step 3, the RAN sends an N2 message (N2 parameters, registration request and UE policy container) to the AMF. The N2 parameters may include: the selected PLMN ID or PLMN ID and network identifier (NID); location information and cell identity related to the cell where the UE is camped; and a UE context request indicating that a UE context including security information needs to be set up at the NG-RAN.

[0181] In step 4, the AMF may retrieve access and mobility subscription data using Nudm_SDM_Get. This requires the UDM to retrieve this information from the UDR via Nudr_DM_Query. This includes the operating band and the corresponding S-NSSAI relationship and RFSP index information.

[0182] After obtaining access and mobility subscription data from UDM, AMF creates a UE context for the UE.

[0183] As described in TS23.501 Section 5.3.4.1, mobility restrictions consist of RAT restrictions, restricted areas, service area restrictions, core network type restrictions, and closed access group information, where RAT restrictions define the 3GPP RATs that UEs are not allowed to access in the PLMN. In restricted RATs, subscription-based UEs are not allowed to access the network of the PLMN. RAT restrictions can be enhanced so that they are indicated by S-NSSAI; in other words, some slices may not be accessible via certain RATs.

[0184] In step 5, the AMF may report the RAT restriction, subscribed service area restriction, subscribed RFSP index and subscribed UE-AMBR received from the UDM for further evaluation to the PCF.

[0185] In step 6, the PCF may modify the RFSP index, RAT restriction, service area restriction and subscribed UE-AMBR based on the operator policy.

[0186] In step 7, the AMF may receive a modified RFSP index, a modified RAT restriction, a modified service area restriction, and a modified UE-AMBR from the PCF.

[0187] The modified RFSP index, the modified RAT restriction, the modified service area restriction and the modified UE-AMBR may replace the subscribed RFSP index, the RAT restriction, the service area restriction and the UE-AMBR.

[0188] In step 8, the AMF sends a registration accept message to the UE via the RAN node. The AMF may send the RFSP index, RAT restriction, service area restriction, and UE-AMBR in the registration accept message to the RAN node in the N2 message.

[0189] In step 9, the RAN node may forward a registration acceptance to the UE. The registration acceptance may include an allowed NSSAI with information for each S-NSSAI and its corresponding operating band, a mapping of allowed NSSAIs with each S-NSSAI and its corresponding operating band, a configured NSSAI for the serving PLMN with each S-NSSAI and its corresponding operating band, and a mapping of configured NSSAIs with each S-NSSAI and its corresponding operating band. The registration acceptance also includes mobility restrictions including RAT restrictions. The RAT restrictions have been enhanced to include restrictions indicated according to the S-NSSAI; in other words, certain slices may not be accessible via certain RATs.

[0190] The UE may display the RAT restrictions and allowed frequency ranges associated with each S-NSSAI on the GUI. The user may view the GUI from within the "Settings" GUI.

[0191] Enhanced S-NSSAI Information Element with OFB

[0192] In reference Figure 4 In the described solution, upon successful registration, the AMF sends the allowed NSSAI to the UE with operating band information appended for each S-NSSAI. The S-NSSAI information element is described in section 9.11.2.8 of TS24.501. Fig.10 The S-NSSAI information element is shown with two octets for the operating frequency band (OFB) information. It defines the operating frequency band for which the S-NSSAI should be available for the UE. Fig.10 Depicts the OFB that may be included from octet 11 to octet 12. Two octets are added to encode the uplink and downlink operating bands in the S-NSSAI information element (IE). However, alternatively, the operating band information may be encoded by sharing the existing octet limitations (e.g., the current S-NSSAI IE size). In addition, multiple operating band information elements may be provided to the UE, and each OFB information element may be associated with location information, where the OFB information should be considered valid (in the PLMN associated with the S-NSSAI). Examples of location information are registration areas, tracking areas, and cell identifiers.

[0193] The UE may use the OFB information element to determine the operating band to use based on the service it wants to access. For example, if the UE is not using dual connectivity, it may use this information to determine which cell to connect to. If the UE is using dual connectivity, it may use this information to determine which primary cell and which secondary cell to connect to.

[0194] Table 11 of the Appendix of this document depicts details about the S-NSSAI information element updated with the operating band information.

[0195] Operation band switching for available slices

[0196] For UEs camped in a cell, the allowed NSSAIs received by the UE in the Registration Accept message shall contain only a set of S-NSSAIs that are all available in the current operating band. The scheme where the UE can only access network slices if the slices are available in the UE's current OFB may be referred to as the UE-OFB policy. However, there may be scenarios where the UE may request slices that may not all be available in the UE's current OFB. In this case, the registration request may be rejected by the network (e.g., by the AMF) with a reason code. The reason code in the Registration Reject message may provide the UE or RAN node with the reason for the rejection and further information about the OFB where all requested slices are available, thereby triggering the UE to move to a different operating band where all S-NSSAIs from the requested NSSAI are available. Fig.17 OFB switching during the registration procedure is described.

[0197] In step 0, the MNO may allocate operating bands (e.g., n1, n7, n12, etc.) as defined in TS 38.101-1 and 38.101-2 and assign them to the S-NSSAI as part of UE access and mobility subscription at the UDM / UDR. This may include RFSP index configuration.

[0198] In step 1, the UE sends a registration request to the AMF via the access network. The request includes the requested NSSAI. In case of initial registration or mobility registration update, the UE includes a mapping of the requested NSSAI (if available) which is a mapping of each S-NSSAI of the requested NSSAI to the HPLMN S-NSSAI to ensure that the network can verify whether the S-NSSAI in the requested NSSAI is permitted based on the subscribed S-NSSAI. If the UE is using the default configured NSSAI, the UE includes a default configured NSSAI indication.

[0199] In addition, the UE may also indicate to the AMF the OFBs it supports. This includes the OFB that the UE is currently using. The UE may also include in the request a slice priority with the registration request message. In addition, such indication may include an indication of its OFB preference, for example, its preferred OFB among the OFBs communicating with the AMF. The UE may also indicate to the AMF one or more of the following:

[0200] First, V2X OFB, V2X preferred OFB, V2X operating band, is used for simultaneous Uu&PC5 based operations.

[0201] Second, OFB for intra-band carrier aggregation operation; UE's preferred OFB for intra-band carrier aggregation operation.

[0202] Third, OFB for inter-band carrier aggregation operation; UE's preferred OFB for inter-band carrier aggregation operation.

[0203] Fourth, OFB for dual connectivity operation; UE's preferred OFB for dual connectivity operation.

[0204] Fifth, OFB for UL Multiple-Input Multiple-Output (MIMO); UE's preferred OFB for UL MIMO.

[0205] Sixth, S-NSSAI priority order preference; the UE can indicate which S-NSSAI are mandatory for the current OFB to help the AMF accept or reject the registration request.

[0206] Alternatively, when the RAN node forwards the registration request to the AMF in the N2 message, the RAN node may indicate to the AMF the operating band that the UE is using. The indication will be included as part of the N2 message. In addition, the indication may include any of the OFB indication options described herein (e.g., if the OFB indication is sent to the RAN node in the RRC message).

[0207] In step 2, the AMF may retrieve access and mobility subscription data using Nudm_SDM_Get. This requires the UDM to retrieve this information from the UDR via Nudr_DM_Query. This includes the operating band and the corresponding S-NSSAI relationship and RFSP index information.

[0208] After obtaining access and mobility subscription data from UDM, AMF creates a UE context for the UE.

[0209] As described in TS23.501 Section 5.3.4.1[1], mobility restrictions consist of RAT restrictions, restricted areas, service area restrictions, core network type restrictions and closed access group information, where RAT restrictions define the 3GPP radio access technologies that the UE is not allowed to access in the PLMN. In the restricted RAT, the UE is not allowed to access the network for the PLMN based on the UE subscription, for example, the network uses the UE's subscription to determine whether the UE is allowed to access. The RAT restrictions can be enhanced so that they are indicated by the S-NSSAI, in other words, certain slices may not be accessible via certain RATs. In this solution, it is assumed that a mapping is maintained between S-NSSAI and OFB or OFB options in the core network, as described in this document. For example, the core network for AMF uses OFB information received from the UE as input for selecting S-NSSAI and RAT restrictions. Furthermore, in an alternative embodiment, the RAT restriction may be enhanced so as to be indicated based on a combination of S-NSSAI and OFB, wherein the OFB indication may include the OFB indication options described herein, including V2X-related OFB indication options, such as a CA carrier aggregation (CA) OFB option or a dual connectivity OFB option.

[0210] In step 3, the AMF implements the UE-OFB policy. Based on the UE subscription information, the OFB or OFB options supported by the UE (received in step 1), and the number of S-NSSAIs accessible via the UE's current OFB from the requested NSSAI, the AMF may recognize that not all S-NSSAIs in the requested NSSAI are available in the UE's current operating band.

[0211] In addition, the AMF may be able to identify an OFB or an OFB including the OFB option described herein, where the UE is able to access all S-NSSAIs from the requested NSSAI. In this case, the AMF may reject the registration request from the UE with a cause code and indicate to the UE an OFB, where the UE is able to access all S-NSSAIs from the requested NSSAI.

[0212] In step 4, the AMF may send a Registration Reject message back to the UE with a reason code. The reason code may indicate to the UE that the registration request was rejected because not all requested slices are available in the current OFB of the UE. In addition, it may also include an OFB supported by the UE or an OFB including the OFB option described herein, where all requested slices are accessible, suggesting that the UE resend the registration request from another OFB.

[0213] If the UE supports multiple OFBs but the requested slice is not available in any OFB supported by the UE, the AMF rejects the UE Registration Request or Registration Update Request with a cause code. The cause code indicates that the requested slice is not available in any OFB. The cause code may require the 5GS to adapt to the following situations.

[0214] In case 1, the cause code may list the OFB where the UE can access most of the S-NSSAIs from the requested NSSAI. In addition, the cause code may also indicate the number of allowed S-NSSAIs that the AMF may send in the allowed NSSAI.

[0215] In case 2, the cause code may include a suggestion that most of the S-NSSAIs from the requested NSSAI are accessible. For example, the UE may support three OFBs (e.g., OFB1, OFB2, and OFB3). The AMF may find that only 4 of the 8 S-NSSAIs are accessible in the UE's current OFB (e.g., OFB1), and may also find that OFB2 and OFB3 support 6 and 7 S-NSSAIs, respectively, and suggest the UE to select if it wants to resend the registration in another OFB.

[0216] In case 3, the cause code may include an OFB recommendation where all slices are available based on the priority of the slices for that UE. The ordering of slices may be defined based on frequency range (FR), OFB, UE type, services provided by the slice, slice type, etc. For example, there may be different types of UEs (e.g., mobile phones, autonomous vehicles, connected cars only, fixed IoT devices, etc.). These UEs may have different services that they typically require, such as requiring certain uplink or downlink data rates and QoS, and may have an SLA with the MNO. If some of these UEs have access to multiple slices, the priority of the slices may be different for each UE than for other UEs. For example, in the list, an autonomous vehicle UE may have a URLLC slice on the top, an eMBB slice second, and an IoT slice third. For a mobile phone, the priority may not be the same, which may have an eMBB at the top of its list and a URLLC slice as the second. In addition, the FR and the corresponding OFB may be more suitable for one form of service (e.g., the lowest latency service). When the AMF sends a registration reject message, the cause code may include an OFB based on the priority ordering of the slices for the UE, even though all slices are available in that OFB. This allows the UE to select a more appropriate OFB to resend the Registration Request. This situation may also be appropriate when the AMF may suggest the UE to use OFB, where most slices are available. For example, in the case when eMBB slices are not available in OFB, but URLLC is in another OFB, and vice versa, the UE may choose to send its Registration Request to OFB based on its own service / slice priority.

[0217] If the UE indicates only a limited number of OFBs when submitting its supported OFBs (step 1), or if the network supports only a limited number of OFBs out of all OFBs that the UE has submitted (step 1), and if not all S-NSSAI in the requested NSSAI are available in the UE's current frequency band, the network may send a registration reject message back to the UE with a cause code indicating that not all slices are available in the UE's OFB.

[0218] In another alternative, if no OFB supports all the slices requested by the UE, but the UE's current OFB supports some of the requested slices, the AMF may respond with a Registration Accept message with an Allowed NSSAI, which may contain only the slices supported in the UE's current OFB, and include the remaining S-NSSAI in a Rejected NSSAI with a reason code. The reason code indicates that the slices are rejected because they are not supported in the current OFB. The reason code may also indicate the OFB that each slice is available for.

[0219] In step 5, based on the information in the cause code received from the network, the UE may select a suggested OFB. The UE may initiate a new registration request using the new suggested OFB. This may involve sending a request via a different RAN node than the UE's initial registration request in step 1. The AMF may help the RAN node and the UE make registration requests in different RAN nodes. The AMF is aware of the OFB where the requested slice is available. Based on the supported UE OFB submitted in step 1, and the AMF's knowledge of the OFBs supported by the RAN nodes, the AMF may send a cause code indicating a change of OFB, and therefore the RAN node. Alternatively, the first RAN node (RAN node 1) may trigger an inter-frequency cell change to a second RAN node (RAN node 2), which supports the requested NSSAI and is in the UE's location / TA.

[0220] In step 6, based on the UE subscription information, the UE's indication of its supported OFB (received in step 1), the UE's current OFB, and the number and priority of S-NSSAIs within the requested NSSAI, the AMF may identify that the S-NSSAIs in the requested NSSAI are all available in the UE's current operating band.

[0221] Note that the UE may not be allowed to update its allowed NSSAI until successfully switched to the new operating band.

[0222] In step 7, the AMF sends a registration accept / reject message to the UE via the RAN. The registration accept may include an allowed NSSAI with each S-NSSAI and its corresponding operating band information, and a mapping of allowed NSSAI with each S-NSSAI and its corresponding operating band. The S-NSSAI in the allowed NSSAI and the S-NSSAI in the mapping of the allowed NSSAI are both available in the current operating band of the UE.

[0223] Note that during the registration update procedure, the UE may only wish to update its allowed NSSAI if all slices in the request would be allowed in the UE's current operating band. The UE may indicate in the registration request that it only wishes to update its allowed NSSAI if all S-NSSAIs in the requested NSSAI are allowed.

[0224] Registration renewal with permitted NSSAI

[0225] A general registration or registration update request may be enhanced where the UE may send an indicator to the network to inform it that it wishes to update its allowed NSSAI, as long as all slices in the request will be allowed in the UE's current operating band. If not, the UE may similarly maintain its currently allowed NSSAI. As follows Fig.18 This scenario is described in .

[0226] In step 1, the UE sends a registration or registration update request, in which it may include the requested NSSAI. In the request message, the UE may also include an indicator called the all slice indicator, which informs the network about the UE's desire to update its allowed NSSAI as long as all S-NSSAIs in the request are allowed in the current operating band, and if not, the UE does not wish to update the allowed NSSAI.

[0227] Alternatively, the all slices indicator may indicate the UE's desire to stay in the current OFB as long as other OFBs do not support all requested slices.

[0228] In step 2, the AMF implements the UE-OFB policy, where it checks whether all requested slices are available in the current OFB of the UE. In addition, the AMF also considers all slice indicators from the UE. Based on the results of the UE-OFB policy and all slice indicators, the AMF may have two alternative decisions.

[0229] In step 3-a, if the AMF encounters that one or more requested slices in the Registration Update Request are not available in the UE's current OFB, and in addition, all slice indicators are detected from the UE, the AMF will send back a Registration Update Accept message without updating the allowed NSSAI, and the Registration Update Accept message will include a reason code or some other indication to indicate to the UE that the UE should not update its allowed NSSAI. The reason code or indication may indicate that all slice indicators are not met. The Registration Update may update everything except the allowed NSSAI, or it may reject the Registration Update Request.

[0230] In step 3-b, if the AMF encounters that slices in the requested NSSAI are all available in the UE's current OFB and detects all slice indicators from the UE, the AMF shall send back a Registration Update Accept message with a new set of allowed NSSAIs.

[0231] Instead of including all slice indicators in the Registration Request, the UE may include its currently allowed NSSAI in the Registration Request. The presence of allowed NSSAI in the Registration Request may serve all slice indicators.

[0232] Tracking areas / registration areas with available slices in all cells

[0233] In the case where the UE has access to all slices in any of its OFBs, the UE may conveniently know in advance the TA / RA where all slices in the UE's allowed NSSAI may be available. This information may facilitate smooth movement of the UE through various TA / RAs. Information about the available locations of such TA / RAs may be configured at the network, and the network may deliver this information to the UE during registration, registration update procedures, or UE configuration update procedures, such as Fig.19 shown.

[0234] In step 0-A, the Operation, Administration and Maintenance (OAM) entity may configure the PCF with a UE-OFB policy that allows access to all slices via all cells of the tracking area / registration area. This UE-OFB policy may be sent to the AMF where it is later implemented. Additionally, the OFB to slice relationship may be sent to the RAN node along with RAN resource allocation information such as RFSP index.

[0235] In step 0-B, the UDM / UDR may be configured with a list of TA / RA information for the UE.

[0236] The list of TA / RA information specifies the Tracking Area Identifier (TAID) for each TA, where

[0237] The UE can access allowed slices in all OFBs.

[0238] In step 1, the UE sends a registration or registration update request to the network via the RAN. In addition, the UE may also indicate to the AMF the OFBs supported by the UE. This includes the OFB currently being used by the UE.

[0239] In step 2, the AMF may retrieve access and mobility subscription data using Nudm_SDM_Get. This requires the UDM to retrieve this information from the UDR via Nudr_DM_Query. This includes the operating band and the corresponding S-NSSAI relationship and RFSP index information.

[0240] After obtaining access and mobility subscription data from UDM, AMF creates a UE context for the UE.

[0241] In step 3, the AMF checks the requested NSSAI, the OFB supported by the UE, all available slices in all cells of the TA / RA (including the current TA / RA), identifies the allowed NSSAI of the UE, identifies the TA / RA available for the OFB supported by the UE, and determines the list of TA / RAs available for all slices of the allowed NSSAI and the allowed NSSAI.

[0242] In step 4, the AMF sends a Registration Accept message with the allowed NSSAI and rejected NSSAI (if any). In addition, the AMF also delivers a list of TAIDs for all TAs in the RA where all slices in the allowed NSSAI are available.

[0243] Alternatively, the UE may send a NAS message to the network requesting a list of TA / RAs in which all slices in the allowed NSSAI are available in all cells of that TA / RA. The NAS message request may be triggered by a change in the UE's state (e.g., the UE's location), such as some point in time when it starts moving or a point at which the UE changes its TA.

[0244] In another alternative, a request for a list of TA / RAs available in all cells for all slices in the allowed NSSAI may be included in a NAS message, such as a new service request.

[0245] In yet another alternative, a list of TA / RAs in which all slices in the allowed NSSAI are available in all cells may be delivered to the UE based on the UE mobility information obtained by the network from the UE. For example, if the UE moves in a certain direction at a certain speed, the network may be able to detect the movement of the UE, and using NWDAF, the network may be able to predict the possibility of the UE changing the TA / RA of the UE in the geographical area where the UE may move forward. This may trigger the network to send a registration update, UE configuration update, or a simple NAS message, which may contain a list of TA / RAs in which the allowed NSSAI is available in all cells.

[0246] Based on providing an alternative solution to NSSAI at the UE

[0247] Figure 5A and Figure 5B The exemplary solution shown in relies on the network to detect that the UE has requested to register to a slice that is not available in the same frequency band. The network (AMF) then determines which slices take priority and should be included in the allowed NSSAI because the UE has immediate access to slices received as allowed NSSAIs with the current OFB. And, although the UE may be authorized to access network slices, network slices with lower priority may not be included in the allowed NSSAI because the UE can only access certain OFBs at a time. In addition, the AMF provides one or more alternative NSSAIs to the UE to indicate to the UE which other NSSAIs would be allowed if requested. If the UE decides that the network provided in the S-NSSAI is not the highest priority, it may determine to request a different NSSAI.

[0248] Figure 5A and Figure 5BA UE providing an alternative slice and a corresponding frequency band is shown. Figure 5A In step 0-A of , the UE may have a configured NSSAI for the PLMN and an allowed NSSAI for the PLMN. Therefore, the UE is able to request registration for a specific slice in the NSSAI.

[0249] In step 0-B, the MNO may allocate operating bands (e.g., n1, n7, n12, etc.), as defined in TS 38.101-1, and assign them to the S-NSSAI as part of UE access and mobility subscription at the UDM / UDR. This may include RFSP index configuration.

[0250] In step 1, the UE sends a registration request to the network (AMF) via the RAN. The UE registration request may provide the requested NSSAI to the network in the AS and NAS layers, which contains the S-NSSAI corresponding to the slice that the UE wishes to register with.

[0251] The requested NSSAI may be the allowed NSSAIs for the access type for which the requested NSSAI is sent, or a subset thereof, plus one or more S-NSSAIs from the configured NSSAIs that are not already in the allowed NSSAIs for the access type.

[0252] The registration request may further indicate the UE capabilities to the AMF, including indicating in which frequency bands the UE is capable of operating, and indicating whether the UE is capable of operating in more than one frequency band simultaneously.

[0253] In step 2, the RAN selects an AMF as described in TS 23.501 clause 6.3.5.

[0254] In step 3, the RAN sends an N2 message (N2 parameters, registration request and UE policy container) to the AMF. The N2 parameters include the selected PLMN ID (or PLMN ID and NID), location information and cell identity related to the cell where the UE is camped, and a UE context request indicating that a UE context including security information needs to be set up at the NG-RAN.

[0255] Figure 5A The call flow is Figure 5B Continue in. Figure 5A and 5B Steps 4-7 are similar to Figure 4 Follow steps 4-7 in the tutorial.

[0256] exist Figure 5BIn step 8 of , the AMF may evaluate the registration request. The AMF may find that the UE is trying to register to a network slice with a different OFB. Therefore, the AMF may not be able to redirect the UE to the frequency used for all S-NSSAIs in the NSSAI.

[0257] Although the network may be able to serve connections in various bands directing UEs to different network slices, it may only allow some S-NSSAIs out of the allowed NSSAIs.

[0258] Thus, the AMF may be able to select the S-NSSAI and corresponding operating band of the network slice with a higher priority from the requested NSSAI and send it back to the UE as the allowed NSSAI. In addition, the AMF may send an alternative allowed NSSAI containing other combinations of S-NSSAIs that would be allowed if they were requested by the UE. The presence of the alternative allowed NSSAI indicates to the UE that the network does not include all S-NSSAIs from the requested NSSAI in the allowed NSSAI because it cannot allow the UE to connect to all S-NSSAIs in the requested NSSAI at the same time, and indicates that the network determines which S-NSSAIs in the requested NSSAI should be prioritized. The AMF may also indicate why the S-NSSAI from the requested NSSAI does not exist in the allowed NSSAI (for example, because some S-NSSAIs are only available on mutually exclusive frequencies, because some S-NSSAIs do not allow simultaneous access, etc.). The allowed S-NSSAI and the alternative allowed NSSAI may further indicate the operating band for (each) S-NSSAI.

[0259] exist Figure 5B In step 9 of , the AMF sends a registration accept message to the UE via the RAN node. The AMF may send an allowed NSSAI with a corresponding operating band for (each) S-NSSAI, and an alternative allowed NSSAI with a corresponding operating band for each S-NSSAI. The message may include the corresponding RFSP index, RAT restriction, service area restriction, and UE-AMBR in the registration accept message for the RAN node in the N2 message.

[0260] In step 10, the RAN node may forward a registration accept message to the UE, which includes the allowed NSSAI and the corresponding operating band. It also includes alternative allowed NSSAI and operating band information for each S-NSSAI in the NSSAI.

[0261] In step 11, the UE may choose to use the allowed NSSAI, or send a registration update request with a new requested NSSAI (eg, a replacement NSSAI) formed based on the information provided in the registration accept message of step 10.

[0262] URSP rule enhancement

[0263] As discussed, the UE may receive the allowed NSSAI and OFB for each S-NSSAI. Alternatively or additionally, the URSP rules may be enhanced to guide the UE towards the appropriate S-NSSAI / band combination. Through the registration accept message, the RAN node is also provided with several important information, such as RFSP index, RAT restrictions, restricted areas, service area restrictions, core network type restrictions, and closed access group information. The RFSP index and the corresponding spectrum information allow the RAN to manage resources suitable for the UE. The RAN node provides the operating band information to the UE based on the received RFSP index.

[0264] When a UE attempts to connect to a slice in a network, different network slices can only be accessed via a specific OFB. Therefore, the UE must ensure that the correct frequency band is used to connect to the network slice. In addition, the UE may need to reside on an appropriate PLMN for which the frequency bands and corresponding slices accessible via these bands are configured so that the UE can access them. Therefore, the UE routing policy can be enhanced to indicate the relationship between the PLMN on which the UE resides, the slices that the UE can access, and the operating frequency bands that the UE needs to use to reach the network slice.

[0265] This information may be configured in the URSP rules. Therefore, the routing descriptor (RSD) portion of the URSP rules shown in Table 4 of the Appendix may be enhanced by including the operating band and PLMN information shown in Table 7 of the Appendix. In particular, Table 4 is updated with two new RSD information elements, PLMN ID and OFB. Alternatively, this information may be included as part of the routing validation criteria so that the UE will not attempt to establish a route unless the UE is camped in the indicated PLMN and on the indicated frequency.

[0266] Having the PLMN ID and OFB information along with the network slice information forms a relationship between these three components of the RSD. Having the PLMN ID and operating band in the routing component ensures that the UE moves to the desired PLMN / band combination. Having the PLMN ID and OFB in the routing validation criteria can be used to configure the UE so that it attempts to establish a route only if the UE is already camped in the PLMN and using the band.

[0267] Band redirection using RRC reconfiguration

[0268] When the UE attempts to register a set of slices, the network (AMF) can detect that the UE is trying to register a slice that cannot be used on the same frequency. Therefore, the AMF cannot redirect the UE to a single frequency that will work for all S-NSSAIs in the NSSAI. In other words, there is no single RFSP index that can be used to access all S-NSSAIs. In this solution, the AMF considers that the UE is registered to all requested S-NSSAIs and gives the RAN multiple RFSP indications and tells the RAN which S-NSSAIs can be used with each RFSP index. The UE and the RAN node then use RRC messages to coordinate movement between frequency bands based on the S-NSSAI that needs to be accessed.

[0269] Fig. 6A and Figure 6B Band redirection using RRC messaging is demonstrated. Fig. 6A In step 0-A of , the UE may have a configured NSSAI for the PLMN and an allowed NSSAI for the PLMN. Therefore, the UE is able to request registration for a specific slice in the NSSAI.

[0270] In step 0-B, the MNO may allocate operating bands (e.g., n1, n7, n12, etc.), as defined in TS 38.101-1, and assign them to the S-NSSAI as part of UE access and mobility subscription at the UDM / UDR. This may include RFSP index configuration.

[0271] In step 1, the UE sends a registration request to the network (AMF) via the RAN. The UE registration request may provide the requested NSSAI to the network in the access stratum (AS) and NAS layers, which contains the S-NSSAI corresponding to the slice that the UE wishes to register with.

[0272] The requested NSSAI may be the allowed NSSAIs for the access type for which the requested NSSAI is sent, or a subset thereof, plus one or more S-NSSAIs from the configured NSSAIs that are not already in the allowed NSSAIs for the access type.

[0273] In step 2, the RAN selects an AMF as described in TS 23.501 clause 6.3.5.

[0274] In step 3, the RAN sends an N2 message (N2 parameters, registration request and UE policy container) to the AMF. The N2 parameters include the selected PLMN ID (or PLMN ID and NID), location information and cell identity related to the cell where the UE is camped, and a UE context request indicating that a UE context including security information needs to be set up at the NG-RAN.

[0275] Fig. 6A Steps 4-7 are similar to Figure 4 Follow steps 4-7 in the tutorial.

[0276] In step 8, the AMF may evaluate the registration request. The AMF may find that the UE is trying to register a network slice with a different OFB. Therefore, the AMF may not be able to redirect the UE to a frequency that works for all S-NSSAIs in the NSSAI (e.g., select an RFSP index).

[0277] The AMF response to the RAN node may be enhanced to include multiple RFSP indices and S-NSSAI in the NSSAI to work with each index.

[0278] Fig. 6A The call flow is Figure 6B Continue in Figure 6B In step 9, the AMF provides multiple RFSP indexes and S-NSSAI, which can access the RAN with each RFSP index.

[0279] In addition, the AMF may provide the Access Stratum Connection Establishment NSSAI Inclusion Mode parameter to the UE via the RAN in the Registration Accept message, which indicates whether and when the UE should include NSSAI information in the RRC connection establishment.

[0280] In step 10, the RAN node forwards the registration accept message. In the RRC message to the UE, it may include multiple groups of UE-specific cell reselection priorities to control idle mode residence. Each group of priorities is associated with one or more S-NSSAIs.

[0281] This message may indicate which S-NSSAIs among the allowed NSSAIs are accessible in the frequency band currently being used by the UE.

[0282] This message may indicate which S-NSSAIs among the allowed NSSAIs cannot be accessed in the frequency band currently being used by the UE.

[0283] In step 11, the UE sends an RRC message to the RAN node to indicate that it wants to access the S-NSSAI which is not accessible in the frequency band currently being used by the UE.

[0284] In step 12, the RAN node replies with an RRC message directing the UE with an OFB change command so that the UE will switch to a frequency that can be used to access the S-NSSAI.

[0285] Process DL services in the second network slice and handle ongoing sessions in the first network slice

[0286] In some solutions described herein, a UE is allowed to register slices that are accessible only via different frequency bands, and the UE is further configured with information to know which frequency band each slice is accessible from. The UE may also be connected to the network via frequency band #1, and downlink (DL) data arrives at the network at a slice (S-NSSAI) that is accessible only via frequency band #2. The network may handle this scenario by sending a NAS notification to the UE, which includes the OFB to which the UE should switch in order to receive the DL data. Alternatively, the NAS notification may indicate the S-NSSAI or PDU Session ID that the DL data is available, and the UE may derive the associated OFB based on the previously configured information. Reference Figure 4 Describe how to configure the UE with this information.

[0287] When the UE receives a NAS notification indicating that the UE needs to switch to a different frequency band to receive downlink data, the UE may connect to the network via the different frequency band and send a UE-triggered service request to the network with a list of allowed PDU sessions that may be reactivated in the frequency band based on the UE policy and whether the S-NSSAI of these PDU sessions is within the allowed NSSAI of the 3GPP access.

[0288] As described herein, before the UE connects to a different frequency band, the UE may send an RRC message to the RAN node to indicate that it wants to access an S-NSSAI that is not accessible in the frequency band that the UE is currently using. The RAN node replies with an RRC message that directs the UE with an OFB change command so that the UE will switch to a frequency that can be used to access the S-NSSAI.

[0289] Limit simultaneous network slice access during registration

[0290] The UE is configured with one or more configured NSSAIs; one of the configured NSSAIs may be a default NSSAI. For each S-NSSAI in the configured NSSAIs, the configuration may include a synchronization slice access capability (SSAC) indicator. The SSAC indicator may indicate how the S-NSSAI is used. For example, the SSAC indicator may indicate that the S-NSSAI may be used for: any network slice: any other network slice; only for network slices with the same SST value; not for network slices with the same SST value; only for network slices with the same SD value; not for network slices with the same SD value; and / or only for network slices in the same network slice group (NSG).

[0291] The SSAC indicator associated with each S-NSSAI may be configured by network functions such as AMF, UDM / UDR, and PCF via the OAM system.

[0292] When a UE registers with a network, it may use an SSAC Support Indicator (SSI) to indicate to the network whether it supports (eg, understands) the SSAC indicator. The network may use the SSI to determine whether SSAC information should be included in the configured NSSAI.

[0293] Fig.11 It is shown how the UE can indicate its support for SSAC and how the network can communicate the SSAC indicator to the UE. Fig.11 Enhancements to the UE registration procedure described in TS 23.502 are highlighted.

[0294] In step 0-A, as shown in reference Fig.11 As described, the OAM system may be used to configure a network function (NF), such as an AMF, UDM / UDR, and PCF, with an SSAC indicator for each S-NSSAI. The OAM may configure an SSAC indicator for each S-NSSAI within a UE subscription, including the subscribed NSSAI, the PCF may be configured or updated with a policy of the available UE, which may include an allowed NSSAI with an SSAC indicator for each S-NSSAI, or the AMF may be configured, or the SSAC indicator for the S-NSSAI may be received from the UDM or PCF. In addition, the SSAC indicator may be provided based on each S-NSSAI of each UE. For example, per-UE configuration may be desirable in the case where it is desired to restrict access to only some UEs without restricting other UEs when accessing a slice.

[0295] In step 0-B, as shown in reference Fig.11 As described, a UE may be configured with one or more configured NSSAIs, and each S-NSSAI in each configured NSSAI may include an SSAC indicator.

[0296] In step 1, the UE sends a registration request to the network. The registration request may include a requested NSSAI, a mapping of the requested NSSAI, and an indication of the default configured NSSAI. If the UE is using the default configured NSSAI, the UE includes the default configured NSSAI indication as defined in TS 23.501. The UE may use the SSAI in the registration message to indicate that it supports the SSAC indicator. The SSI may be a single bit indication, or the UE may indicate its support by including its configured SSAC indicator for each S-NSSAI in the requested NSSAI.

[0297] In step 2, the RAN selects an AMF as described in TS 23.501 clause 6.3.5.

[0298] In step 3, the RAN sends an N2 message (N2 parameters, registration request and UE policy container) to the AMF. The N2 parameters include the selected PLMN ID (or PLMN ID and NID), location information and cell identity related to the cell where the UE is camped, and a UE context request indicating that a UE context including security information needs to be set up at the NG-RAN.

[0299] Step 4 is similar to TS23.502 Figure 4 .Steps 8-19 of 2.2.2.2-1.

[0300] In step 5, the AMF sends a registration accept message to the UE via the RAN. In the registration accept message, the AMF may include the allowed NSSAI, the mapping of the allowed NSSAI, the configured NSSAI for the serving PLMN, the mapping of the configured NSSAI, and the rejected S-NSSAI. For each S-NSSAI in the configured NSSAI for the serving PLMN, the AMF may include an SSAC indicator. Optionally, an SSAC indicator may also be included for each S-NSSAI in the allowed NSSAI, the mapping of the allowed NSSAI, and the mapping of the configured NSSAI. The absence of the SSAC indicator may indicate that the S-NSSAI has no restrictions on simultaneous use with other network slices. In terms of simultaneous use with other network slices, the absence of the SSAC indicator may be used as a symbol that there are no restrictions associated with the S-NSSAI. Each rejected S-NSSAI may be associated with a cause value. The AMF may set the cause value so that it indicates to the UE that the S-NSSAI is rejected because the SSAC configuration associated with the S-NSSAI is incompatible with one of the allowed S-NSSAIs. If the UE does not indicate its support for SSAC in the Registration Request message, the AMF may not provide any SSAC indicator to the UE. If the network rejects any S-NSSAI due to simultaneous usage restrictions and the UE does not indicate support for SSAC, the cause code associated with each rejected S-NSSAI may be a generic cause code such as cause #62 – No network slice available.

[0301] like Fig.11As described, the AMF may inform the UE in a Registration Accept message that the S-NSSAI (S-NSSAI#1) is rejected because the SSAC of S-NSSAI#1 is incompatible with the SSAC of a second S-NSSAI (S-NSSAI#2) in the allowed NSSAIs. When this occurs, the UE may then determine that it will register to S-NSSAI#1 instead of S-NSSAI#2. In this scenario, the UE may then send a second Registration Request message that includes S-NSSAI#1 in the requested NSSAI and does not include S-NSSAI#2 in the requested NSSAI. A subsequent Registration Accept message may include S-NSSAI#2 in the allowed NSSAIs and not include S-NSSAI#1 in the allowed NSSAIs. This procedure is described in Fig.12 Depicted in.

[0302] In step 1, the UE sends a registration request to the network with a requested NSSAI. The requested NSSAI may include at least two S-NSSAIs, S-NSSAI#1 and S-NSSAI#2.

[0303] In step 2, the AMF may implement SSAC-related policies to resolve the UE's slice access request. The AMF recognizes that S-NSSAI#1 and S-NSSAI#2 may not be accessed together by the UE. Therefore, the AMF selects S-NSSAI#2 for the allowed NSSAI and rejects S-NSSAI#1.

[0304] In step 3, the AMF sends a Registration Accept message to the UE with an Allowed NSSAI with S-NSSAI #2 and a Rejected NSSAI with S-NSSAI #1 and a Reject Cause Code indicating that simultaneous access of S-NSSAI #1 is incompatible with S-NSSAI #2.

[0305] In step 4, the UE identifies the rejection cause code for S-NSSAI #1. However, the UE chooses to access S-NSSAI #1.

[0306] In step 5a, in a subsequent request, the UE sends a Registration Update Request with S-NSSAI #1 in its requested NSSAI.

[0307] In step 5b, the UE may alternatively indicate a preference by including S-NSSAI#1 in the requested NSSAI in the Registration Complete message returned to the AMF after receiving the Registration Accept message.

[0308] In step 6, the AMF accepts the registration request for S-NSSAI#1. At this time, S-NSSAI#2 is deregistered for the UE.

[0309] Implement SSAP and UE-OFB policies together during the registration process

[0310] The AMF may implement SSAP to check whether the UE can access two or more slices simultaneously. However, the UE-OFB policy may also act as a constraint for the UE to access two or more slices simultaneously. The UE-OFB policy ensures that all requested slices are available in the common operating band. In addition, the common band must be the current operating band of the UE. The AMF may implement SSAP together with the UE-OFB policy, as in Fig. 20 is shown in the example.

[0311] Fig. 20 Steps 0-2 involve Fig.17 Follow the same steps as steps 0-2 in .

[0312] In step 3, the AMF may check two different policies. First, the AMF checks the UE-OFB policy, which checks whether all slices in the requested NSSAI are available in the current OFB of the UE. Second, the AMF performs SSAP, which checks whether two or more slices can be accessed simultaneously based on the SSAP.

[0313] In step 4a, if all slices are accessible via the current OFB of the UE, the AMF checks whether two or more slices are simultaneously accessible based on the SSAP. If two or more slices are not simultaneously accessible based on the SSAP, the AMF selects one S-NSSAI for the allowed NSSAI and puts the other incompatible S-NSSAIs into a set of rejected S-NSSAIs and includes a reason code indicating the reason for rejecting the rejected NSSAI in the Registration Accept message. The Registration Accept message is then sent to the UE.

[0314] In step 4b, if one or more requested slices are not available in the UE's current OFB based on the UE-OFB policy, then Fig.17 The procedure described in is applicable, where the AMF directs the UE to move to an operating band accessible to all slices.

[0315] If all requested S-NSSAIs are not available in the UE's current OFB, the AMF will not check the SSAP for the requested NSSAI. In other words, if one of the S-NSSAIs in the requested NSSAI is not available in the UE's current OFB, the UE may not access all slices in the working band at the same time.

[0316] However, if the UE is successfully handed over to a different OFB where all slices are available, the AMF may implement SSAP before deciding on the Registration Accept message.

[0317] Assuming that the UE is handed over to a new OFB where all slices are available, the AMF implements the SSAP. If the SSAP determines that two slices are not simultaneously accessible, one of them is placed in the rejected NSSAI and the other is placed in the allowed NSSAI. For example, if there are 8 slices in the requested NSSAI, if all slices are available in the UE's current OFB, and if the SSAP identifies that two of them are not simultaneously accessible, the allowed NSSAI will have 7 S-NSSAIs, which can be delivered to the UE via the Registration Accept message, and one S-NSSAI is delivered as the rejected NSSAI.

[0318] Alternatively, the AMF may be configured with a UE-OFB policy to not allow slices that are not available in the UE's current OFB without directing the UE to change OFB. In other words, the AMF may send allowed NSSAIs in those slices that are available in the UE's current OFB, and put other slices that are not available in the UE's current OFB into a list of rejected slices. After the UE implements the UE-OFB policy for the slices allowed in the UE's current OFB, the AMF checks whether these slices are simultaneously accessible based on SSAP. If any SSAP-incompatible slices are found, they are placed in the list of rejected slices, and the remaining slices may be sent back to the UE as allowed NSSAIs in the registration accept message. Within this alternative, the UE-OFB policy may be configured to direct the UE to change the OFB where most of the slices are available. Once the UE changes OFB and finds accessible slices, SSAPs may be implemented for those slices.

[0319] On the other hand, the AMF may implement the SSAP and UE-OFB policies in reverse order. That is, the SSAP is implemented before the UE-OFB policy. In this case, the UE first checks the SSAP policy for simultaneous access. If the SSAP allows the UE to access all slices simultaneously, the AMF then implements the UE-OFB policy. If the UE-OFB policy identifies that one of the slices is not available in the UE's current OFB, the AMF directs the UE to switch its registration request to OFB, where all slices are accessible.

[0320] However, if the SSAP policy finds that one or more slices are not allowed in the first place, the inaccessible slices are treated as denied slices and the remaining slices are passed through the UE-OFB policy. If the UE-OFB policy identifies that one of the slices may not be accessible via the UE's current OFB, then Fig.17The procedure described in may apply, where the AMF directs the UE to switch its Registration Request to OFB where all slices are accessible. Otherwise, the S-NSSAI of these slices are put into the allowed NSSAI and sent back to the UE as a Registration Accept message. Note that slices rejected due to SSAP are not included when checking the UE-OFB policy. Again, the SSAP implementation may be repeated if the AMF directs the UE to a different OFB. In other words, the AMF may check the SSAP policy again before deciding on the Registration Accept message and sending it to the UE.

[0321] Steps 5-7 and Fig.17 Steps 5-7 in are the same as in and are only applied if step 4b becomes true. In this case, the UE-OFB policy is applied and therefore, the AMF directs the UE to hand over to another OFB where all slices are available.

[0322] Limiting simultaneous network slice access during PDU session establishment

[0323] During PDU session establishment, restrictions on simultaneous use of network slices may be enforced. In other words, a UE may be allowed to register a network slice, but only if it simultaneously has a PDU session in a restricted slice.

[0324] By implementing the Sync Slice Validation Criteria field in the Routing Validation Criteria of the URSP rules, restrictions on simultaneous access to slices can be enforced during PDU session establishment. The enhanced URSP rules with the Sync Slice Validation Criteria field are depicted in Table 7 of the Appendix of this document.

[0325] Fig.13 An alternative scenario is depicted which describes a situation where the UE attempts to establish a PDU session in a slice in the allowed list of the S-NSSAI but finds that the PDU session cannot be established because the core network restricts simultaneous access to certain slices.

[0326] In step 1, a PDU session has been previously established in a slice (Slice A).

[0327] In step 2, the Synchronized Slice Access Policies (SSAPs) have been delivered to the AMF where they are implemented.

[0328] In step 3, the UE may attempt to establish a second PDU session establishment request for another slice (slice B) in the network. The request may include an SSI, which may indicate to the network whether the UE supports (e.g., understands) the SSAC indicator. The network may use the SSI to determine whether the UE will understand the SSAC rejection cause code and configuration information.

[0329] In step 4, the AMF identifies slice B which is not accessible simultaneously with slice A for the UE.

[0330] In step 5, if the PDU session establishment request is for an S-NSSAI that cannot be used simultaneously with the S-NSSAI for which the UE has established a PDU session, the AMF shall reject the PDU session establishment. If the UE indicates that it can understand the SSAC information, the AMF may reject the request with a reason code detailing that slice A cannot access slice B. The UE may receive this reason code and, depending on its urgency or requirements, it may end the session with slice A and retry the PDU session establishment request with slice B.

[0331] Alternatively, and assuming that a session for slice A is ongoing, the AMF may indicate to the UE in the rejection cause code that once the session with slice A ends, the UE may be able to attempt a PDU session establishment request.

[0332] Alternatively, and if the ongoing PDU session with slice A has expired, the AMF may end that session and accept the PDU session establishment request for slice B.

[0333] Another alternative could be that if the UE carries some information about slice priority for the UE (e.g., emergency situation), and if slice B has a higher priority than slice A, the UE may end the PDU session with slice A and send a PDU session establishment request for slice B.

[0334] Handling of synchronous slice access restrictions due to UE-OFB policy and SSAP during PDU session establishment procedure

[0335] Restriction on simultaneous access to two or more slices may also be based on the OFB available for the slices. Such restriction may be implemented during the PDU session establishment procedure. In this case, it is assumed that during the general UE registration procedure or the registration update procedure, slices available in different frequency bands may be allowed and delivered in the allowed NSSAI. However, the UE-OFB policy may be applied during the PDU session establishment. In addition, the UE-OFB policy may be implemented when the UE changes cell or TA / RA and the UE needs to continue the existing PDU session. In other words, when two PDU sessions are established towards two different network slices in the network, both must be available under the same OFB and the OFB must be the current OFB of the UE. The procedure also assumes that the UE has submitted its supported OFB to the network during the general registration procedure. In some cases, the UE-OFB policy may be implemented together with the SSAP, such as Fig.21 as shown in the example.

[0336] exist Fig.21 In step 1 of , the SSAP and UE-OFB policy have been delivered or configured at the AMF.

[0337] In step 2, the UE establishes a PDU session in the slice (Slice A).

[0338] In step 3, the UE may initiate a new PDU session for a second network slice (Slice B) that is available in a different OFB. Here, the AMF may implement the UE-OFB policy and SSAP together.

[0339] The AMF may implement the UE-OFB policy first and the SSAP policy second, or vice versa. If a second PDU session is requested towards a slice that is not available in the current OFB of the UE, the AMF may identify this scenario through the UE-OFB policy. Therefore, the PDU session request may be rejected. In addition, the AMF may also identify an OFB where all slices are available for the PDU session (for example, for both slice A and slice B). The AMF may send a PDU session rejection response to the UE with a cause code. The cause code may indicate that the PDU session is rejected because the slice is not available in the current OFB of the UE. In addition, the cause code may send information about an OFB where both slices are available and a PDU session can be established in both slices at the same time. Alternatively, the cause code may send information about which OFBs can be used to establish the requested PDU session. If the AMF does not find any OFB with two slices available, the cause code will only indicate the reason for the rejection, mentioning the violation of the UE-OFB policy. For this case, the SSAP policy implementation may take the following two options:

[0340] In option 1, the AMF may enforce the SSAP policy to ensure compatibility of the two slices. If they are not compatible, the incompatibility information due to SSAP may be sent to the UE via the cause code in the PDU Session Request Reject message. Note that this rejection information may also help the UE to decide later whether to keep the currently allowed NSSAI or move to a different OFB completely.

[0341] If both the UE-OFB policy and the SSAP check fail, the UE is guaranteed not to have access to both slices in any OFB. Therefore, the AMF may send a reject message and cause a code indicating the same.

[0342] In option 2, the AMF may not enforce the SSAP policy and send a reject message based only on the UE-OFB policy.

[0343] However, if the second PDU session establishment request for a slice (e.g., slice B) is available in the same OFB as the PDU session established in slice A, and the OFB is the current OFB of the UE, the AMF implements SSAP. If the two slices are compatible with each other, the PDU session establishment for the second slice will succeed. If slice B is not compatible with slice A, the PDU session request is rejected with a reason code.

[0344] In step 4, the AMF may send a UE PDU session accept or reject message. If both the UE-OFB policy check and the SSAP check pass, the UE shall establish a PDU session in slice B. If the PDU session is rejected due to a UE-OFB policy failure, the AMF sends a reject message to the PDU session with a reason code. The reason code indicates a failure of the slice in the UE's current OFB, and may recommend an OFB accessible to both slices (slice A and slice B) or an OFB accessible to slice B. If the rejection is due to a violation of the SSAP, the reason code indicates that the slices (slice A and slice B) are incompatible for synchronous access.

[0345] In step 5-A, if the UE obtains a PDU session rejection message with a reason code based on the UE-OFB policy, the UE may choose to keep the ongoing PDU session in slice A and block the PDU session establishment request for slice B. In other words, the UE may ignore the AMF's suggestion to use other OFB if ​​both slices are available. If the rejection is due to violation of the UE-OFB policy and SSAP, the UE may not change the OFB and block the PDU session establishment request, and continue the ongoing PDU session only in slice A.

[0346] In step 5-B, assuming that the PDU session is rejected with a reason code indicating a change of OFB, the UE may choose to request a new allowed NSSAI in the new OFB where both slices are available. If the UE selects this option, the UE may first need to save the state of the ongoing PDU session and request a PDU session disconnect for the ongoing PDU session in slice A. Once the PDU session disconnect is complete, the UE will need to send a registration update request to the OFB, which was suggested by the AMF in the previous step. Once the registration is successful via the new OFB, the UE can re-establish the previously disconnected PDU session and continue the PDU session. The UE can also request a new PDU session establishment request in slice B using the new OFB. Alternatively, when the UE changes OFB, the existing session can simply be handed over to the new OFB.

[0347] In an alternative solution, since the UE has information about which slices are available in which OFB, based on the OFB (cell) the UE is currently in, the UE can start the PDU session establishment procedure only on the slices available in the UE's current OFB. In this way, there is no obstacle in establishing a PDU session and waiting for the AMF to decide whether the PDU session can be established based on the UE-OFB policy. When establishing a PDU session, the AMF can only implement SSAP to implement compatibility of two or more slices for the UE.

[0348] RAN-assisted UE handover based on slice availability

[0349] Each S-NSSAI may be associated with its available OFB. During a successful registration procedure, this information (e.g., S-NSSAI and corresponding OFB) is delivered to the RAN node. When the UE requests to establish a PDU session with a slice in the network, the UE may include the desired slice information in the RRC message directed to the RAN. The RAN may identify the requested slice and the OFB associated with the requested slice. If the requested slice is in the current OFB of the UE, the RAN may further allow the PDU session establishment procedure, otherwise the RAN may direct the UE to change the OFB before continuing the PDU session establishment procedure. This procedure is performed in Fig. 22 Depicted in.

[0350] In step 0, the AMF may retrieve the access and mobility subscription data where the S-NSSAI to OFB association information is present. This information may be delivered to the RAN during the UE registration procedure.

[0351] In step 1, the UE sends a PDU session establishment request to the network via the RAN. In this request, the UE may also include the S-NSSAI of the slice requested in the RRC message, where the UE wants to establish a PDU session. Note that this S-NSSAI information is in addition to the slice information sent to the AMF.

[0352] In addition, the UE may also include a slice priority. In addition, the UE may include an indication of its OFB preference. The UE may also indicate to the RAN one or more of the following:

[0353] First, V2X OFB, V2X preferred OFB, V2X operating band, for simultaneous Uu and PC5 based operations.

[0354] Second, OFB for intra-band carrier aggregation operation; UE's preferred OFB for intra-band carrier aggregation operation.

[0355] Third, OFB for inter-band carrier aggregation operation; UE's preferred OFB for inter-band carrier aggregation operation.

[0356] Fourth, OFB for dual connectivity operation; UE's preferred OFB for dual connectivity operation.

[0357] Fifth, OFB for UL MIMO; UE's preferred OFB for UL MIMO.

[0358] Sixth, S-NSSAI priority order preference; the UE can indicate which S-NSSAI are mandatory for the current OFB to help the AMF accept or reject the registration request.

[0359] In step 2, since the RAN has received the S-NSSAI to OFB relationship information from the core network, the RAN identifies the OFB associated with the requested S-NSSAI and confirms that the UE can access it in the UE's current OFB.

[0360] Based on the identification, the RAN performs one of the following.

[0361] Case 1 :

[0362] In step 3, the RAN identifies that the requested slice is accessible in the current OFB of the UE and therefore forwards the PDU session establishment request towards the AMF.

[0363] In step 4, the relevant network functions may participate in the PDU session establishment setup procedure as described in clause 4.3.2.2.1 of TS 23.501 [2].

[0364] In step 5, the AMF sends a NAS message to the RAN, where it indicates an N2 PDU Session Request. AN-specific resources are set up between the UE and the RAN, which indicates that the PDU Session Establishment Request is accepted, and then the RAN sends an N2 PDU Session Response back to the AMF.

[0365] Case 2 :

[0366] In step 3, the RAN identifies that the requested slice is not accessible in the current OFB of the UE. In addition, the RAN identifies an OFB where the requested slice is available and sends a NAS message back to the UE, suggesting the OFB via which the slice can be accessed.

[0367] In step 4, the UE may direct itself to the OFB suggested by the RAN and may send a PDU session establishment request to the network. Since the slice is available in the OFB, the RAN node forwards the request to the network.

[0368] In step 5, the network accepts the PDU session establishment request and the UE can start sending PDUs to the desired slice in the network.

[0369] When the UE moves to a new cell, it handles the PDU session

[0370] The UE may have multiple ongoing PDU sessions in multiple network slices in an OFB (cell). The UE may be mobile and may want to move to a new OFB. Based on the available OFBs supported by the UE, the RAN may help the UE switch OFBs where the UE may continue with the existing PDU sessions. If the network cannot support all slices in the OFB supported by the UE, the RAN may inform the UE in the cause code. Fig.23 Describes the procedure.

[0371] In step 0, the UE may have ongoing PDU sessions in multiple slices in the network.

[0372] In step 1, the UE may send a message to the RAN indicating that it wants to move to a new cell and continue the ongoing PDU session and leave the cell in which it has a PDU session with the network.

[0373] In step 2, the RAN identifies the slices and OFBs, where a slice with a PDU session may be available and the UE may continue the existing PDU session in the slice. The UE's current RAN node may coordinate with other RAN nodes via the core network or directly in the RAN node about the OFB desired by the UE and the slices supported by these OFBs.

[0374] In step 3-A, if the RAN node identifies that the new cell also supports all slices for which the UE has an ongoing PDU session, it sends back a confirmation message indicating that it supports all slices in the new OFB. The RAN node can then facilitate a good OFB handover for the UE and continue the PDU session.

[0375] In step 3-B, the RAN node may identify that the new cell does not support all of the UE's slices, and identify other cells within reach of the UE where more slices may be supported. In this case, the RAN may suggest that the UE continue the PDU session in OFB where a greater number of slices are supported. Additionally, it may indicate to the UE that the S-NSSAI will not be supported in the suggested OFB. The RAN may then facilitate a good OFB handover of the UE for supported slices and continue the PDU session.

[0376] In step 3-C, the RAN node may identify that the new cell does not support any of the UE's slices, and may further identify that no other cells within reach of the UE can support those slices. In this case, the RAN sends a response back to the UE with a cause code indicating that no OFB can support the requested slices. In this case, the RAN cannot continue the PDU session, and therefore, all PDU sessions can end.

[0377] Alternatively, the network may support a default slice in the new cell, and the RAN node may indicate the information in the response. The UE may establish a PDU session in the default slice, and the UE may continue one or more PDU sessions in the default slice if allowed.

[0378] In step 4, the UE switches to the new OFB. When the UE switches to the new OFB, the core network is informed about this. If there is any policy update, the PCF sends the policy to the AMF and RAN nodes before the AMF fully accepts the transition to the new OFB. After a successful switch, the UE continues the PDU session.

[0379] Configuring Slice Location Restriction Information in NSSAI

[0380] When the UE is in certain PLMNs in certain countries, it may be the case that certain network slices are not available for the UE. Note that the PLMN ID includes the Mobile Country Code (MCC), so any information configured in the UE based on the PLMN ID is already configured in each country.

[0381] During registration or configuration update, the network may send the UE a "Mapping of Configured NSSAIs" for the serving PLMN. When sending this information to the UE, each S-NSSAI is encoded as shown in Fig. 9 described.

[0382] Note that when using the appendix to this article Fig. 9 When encoded as depicted in Table 8, at least the mapped SST is provided to the UE.

[0383] The encoding of the SST and SD fields is as described in Section 28.4.2, Numbering, Addressing and Identification of 3GPP TS 23.003. As explained in TS 23.003, "The S-NSSAI may include both the SST and SD fields (in which case the S-NSSAI is 32 bits long in total), or the S-NSSAI may include only the SST field (in which case the S-NSSAI is only 8 bits long).

[0384] The SST field can have standardized and non-standardized values. Values ​​0 to 127 belong to the standardized SST range and they are defined in 3GPP TS 23.501. Values ​​128 to 255 belong to the operator specific range.

[0385] The SD field has a reserved value "SD value not associated with an SST", which is defined as hexadecimal FFFFFF. In some protocols, the SD field is not included to indicate that no SD value is associated with an SST."

[0386] TS23.501, Section 5.15.2.2 explains that 4SST values ​​are standardized to indicate the characteristics of network slices (eMBB, URLLC, MIoT and V2X).

[0387] In order to cover the situation where the network needs to deliver slices to the UE that are not available in a certain country for a certain PLMN (for example, a certain PLMN ID is not available), a new SST value can be standardized to indicate the NULL or unsupported situation. When this value is provided in the SST field, it indicates to the UE that there is no S-NSSAI associated with the S-NSSAI mapped to the HPLMN, and the UE is restricted from accessing the services of the S-NSSAI of the HPLMN when connected to the PLMN. Table 12 of the Appendix to this document shows the standardized SST values ​​from TS23.501. The table has been updated to show how to modify the SST value to indicate to the UE that there is no SST value or no slices mapped to the S-NSSAI in the PLMN.

[0388] Alternatively, a new SD value may be defined to indicate to the UE that there is no S-NSSAI mapped for a network slice in the PLMN. Alternatively, the indication may be conveyed in new information carried in the S-NSSAI Information Element (IE) or inside a different information element.

[0389] Another alternative method of delivering S-NSSAI that is not mapped in the PLMN to the UE is via the S-NSSAI information element. The S-NSSAI IE may include only the SST or SST and SD within the mapped configured NSSAI. The UE may interpret this as indicating that the indicated SST or SST and SD is the HPLMN configured NSSAI that is not mapped in the VPLMN.

[0390] Another alternative method to indicate to the UE that there is no S-NSSAI mapped in the PLMN is to define a new coding for the "Length of S-NSSAI Content" field to indicate the condition to the UE. For example, coding 00001001 may indicate that the information element carries only mapped HPLM SST values, coding 00001010 may indicate that the information element carries only mapped HPLMN SD values, and coding 00001011 may indicate that the information element carries only mapped HPLM SST and mapped HPLMN SD values. The absence of SST and SD values ​​for the VPLMN will indicate to the UE that the HPLMN S-NSSAI is not mapped in the PLMN.

[0391] It may be the case that the slices in the configured NSSAI are only available in specific areas within the HPLMN. When this is the case, the network needs to convey to the UE the areas where the slices are accessible. During registration or configuration update, the network may send the "Configured NSSAI" to the UE. When this information is sent to the UE, the encoding of each S-NSSAI is as described in Section 9.11.2.8 of TS24.501 and as shown in Figure 8 and Table 11 of the Appendix. The network may indicate the geographic area in which the UE S-NSSAI is available in the S-NSSAI information element. For example, the "length of the S-NSSAI content" encoding may be modified so that the network may indicate to the UE that the information element indicates that location information is present in the information element. For example, a value of 10000001 may indicate to the UE that the SST and geographic information (e.g., service area) are included in the S-NSSAI content. In addition, the geographic information may be encoded so that the encoding indicates the format of the geographic information to the UE. Exemplary formats include registration area (e.g., service area list) area, tracking area identification list, cell identifier, country, city, and GPS coordinates. If the geographical area is not included in the information element, the UE may assume that the S-NSSAI is available in the entire PLMN. Alternatively, the geographical area may indicate to the UE locations where access to the S-NSSAI is restricted.

[0392] It may also be the case that certain slices (e.g., S-NSSAI) are not available in the VPLMN or in certain areas within the VPLMN when the UE is roaming. When this is the case, the areas where the S-NSSAI is available (or not) may be indicated to the UE as part of the "Mapping of configured NSSAI" information element and encoded as described herein.

[0393] Table 13 of the Appendix shows how the S-NSSAI information element coding can be updated to convey the above information. When the UE registers with the network, it can indicate to the network that it supports receiving geographical S-NSSAI restrictions so that the network knows that the UE will understand the new information element coding and rejection cause code.

[0394] When the UE attempts to access the S-NSSAI from an area in the PLMN where access to the S-NSSAI is restricted, the network may reject the S-NSSAI and provide a reason code with the rejected S-NSSAI and indicate that the S-NSSAI is rejected because the UE's current location does not allow access. The reason code may further indicate to the UE that access is allowed or indicate a location where access is not allowed. In addition, if the UE moves to a location where access to one of its S-NSSAIs is restricted, the network may send a UE configuration update message to the UE with the new allowed NSSAI. The allowed NSSAI will be different from the allowed NSSAI previously sent to the UE because the new allowed NSSAI will lack the S-NSSAI, which is now restricted due to the UE's current location. Fig.14 Describes the process of denying UE access based on geographic region.

[0395] In step 1, the UE initiates a UE registration procedure with the AMF in a VPLMN in a different geographic region (e.g., a country). The registration request may include a requested NSSAI, a mapping of the requested NSSAI, and an indication of a default configured NSSAI among other information. One of the S-NSSAIs in the requested NSSAI may be restricted in the geographic region, and the UE may not be aware of the restriction. In addition, the UE may or may not include an indicator indicating that it supports geographic S-NSSAI restrictions.

[0396] In step 2, the AMF may identify the restricted slices for the UE in the visited geographical area. See Table 12 of the Appendix. The mapping of S-NSSAI in the configured NSSAI and the mapping of S-NSSAI in the allowed NSSAI may be set to NULL, for example, to indicate that there is no corresponding mapping of the home network slice to any network slice in the visited network. Therefore, the visitor access and mobility management function (V-AMF) may reject certain requested S-NSSAIs.

[0397] In step 3, the AMF may send a Registration Accept message to the UE with an allowed NSSAI and a rejected S-NSSAI with a reject cause code. The reject is because the code may indicate that the S-NSSAI mapping is not available (NULL) at the VPLMN in the current area of ​​the UE.

[0398] Slice location restriction information configured via access and mobility subscription

[0399] The service area restriction consists of an allowed area or a disallowed area. In particular, it may contain limited tracking areas and, alternatively, may contain all tracking areas (TAs) in a PLMN. The UE may be restricted to access one or more network slices based on the service area. In order to address scenarios where certain slices are available in allowed areas or unavailable in disallowed areas, a new field indicating the availability of network slices in a service area may be used, for example, called slice availability area restriction. This field specifies the availability or unavailability of each S-NSSAI of the configured NSSAI in the area. This information may be stored in the UDM as part of the Access and Mobility Subscription Data Type, defined in Table 5.2.3.3.1-1 of TS23.502 (UE Subscription Data Type). During the UE registration process, the slice availability area restriction information may be sent to the AMF using UE subscription data, where it may be implemented.

[0400] Alternatively, the slice availability area restriction information may be delivered to the UE in a registration accept message and evaluated in the UE.

[0401] Another alternative is to pre-configure the UE with slice area availability restriction information for each S-NSSAI when the configured NSSAI is configured in the UE.

[0402] Fig.15 A process is described for delivering slice availability area restriction information to the AMF in the network and alternatively to the UE.

[0403] In step 0, the slice availability area restriction field in the access and mobility subscription data is configured for the UE.

[0404] In step 1, the UE initiates a general UE registration procedure to the AMF via a RAN node. The request may include the requested NSSAI.

[0405] In step 2, for the UE, the AMF can use Nudm_SDM_Get to retrieve the UE subscription information, which may include access and mobility subscription data, SMF selection subscription data, UE context in SMF data, etc. This requires the UDM to retrieve this information from the UDR via Nudr_DM_Query fields in the UE subscription.

[0406] In step 3, the AMF identifies the slice availability area restriction field in the access and mobility subscription data and configures restricted slices for the service area.

[0407] In step 4-a, the AMF sends a registration accept message to the UE. In the registration accept message, the AMF includes the allowed NSSAI, the mapping of the allowed NSSAI, the configured NSSAI and the mapping of the configured NSSAI, and the rejected NSSAI. The rejected NSSAI includes the S-NSSAI rejected at the location and the slice availability area restriction associated with each S-NSSAI, so that the UE knows that the slice is rejected at the current location, and the UE can use this information to consider when to try to register to the slice again.

[0408] In step 4-b, the AMF sends a registration accept message to the UE. In the registration accept message, the AMF includes the allowed NSSAI, the mapping of the allowed NSSAI, the configured NSSAI and the mapping of the configured NSSAI, and the slice availability area restriction associated with each S-NSSAI in the allowed NSSAI and the configured NSSAI, and delivers the mapping of the allowed NSSAI to the UE. In this option, the UE is allowed to register to the slice even if the slice is restricted in the current area. The UE is responsible for applying the restriction by not allowing slice activity in the restricted area (e.g., not starting / allowing PDU session establishment), and the network will implement the restriction by not allowing any slice activity in the restricted area (e.g., not allowing PDU session establishment).

[0409] In step 5, if the UE receives slice availability area restriction information from the network through a registration accept message (step 4-b), the slice availability area restriction information may be considered when evaluating URSP rules when generating application traffic in the UE. In other words, when evaluating RSD, this information may be used to bypass restricted slices and select a lower priority route in the network.

[0410] Use of slice location restriction information during PLMN selection

[0411] refer to Fig.15 The described procedures show how the network can configure the UE with information about what PLMN slices (e.g., S-NSSAI) are available in the PLMN and the areas within the PLMN in which the slices are available. This information may also be configured in the UE, for example, in the UE's SIM card or via the eSIM protocol. Once the UE knows the availability of slices within the PLMN, the UE may take this information into account during PLMN selection and PLMN reselection. PLMN selection and PLMN reselection are specified in TS 23.122.

[0412] Section 4.4.3.1.1 of TS23.122 specifies PLMN selection when connecting or recovering from lack of coverage in automatic network selection mode. The procedure can be enhanced so that the availability of network slices (S-NSSAI) in each PLMN will be considered when determining whether to attempt to register a PLMN. For example, if the S-NSSAI is not available in the PLMN at the UE's current location, the PLMN may be considered to be a lower priority in the sense that the UE will first attempt to register a PLMN where all or more S-NSSAI are available. In addition to the PLMN ID and power level of the strongest cell on each frequency, the AS may be enhanced to provide a tracking area (TA) code and / or cell ID to inform the NAS of the UE's location within the PLMN, thereby enabling slice-aware PLMN selection. The UE may only consider the availability of the S-NSSAI as part of its configured NSSAI or a mapped configured NSSAI associated with the PLMN.

[0413] The AS can be enhanced to provide TA code, cell ID and / or RAN area ID in addition to the PLMN ID and power level of the strongest cell on each frequency to inform the UE location within the PLMN via NAS, thereby enabling slice-aware PLMN selection.

[0414] In addition, two different network slices may be available in two different PLMNs, and the mapping of S-NSSAI for the two S-NSSAIs may be available. In this case, the UE may use a predefined slice priority to select a slice and, therefore, an available PLMN.

[0415] Section 4.4.3.1.2 of TS23.122 specifies PLMN selection when connecting or recovering from lack of coverage in manual network selection mode. The procedure can be enhanced so that the availability of network slices (S-NSSAI) in each PLMN is taken into account when the UE determines which PLMNs to present. For example, when some S-NSSAI are not available in the PLMN in the UE's current location, this information can be displayed to the user. For example, the display may indicate that the service is limited, the display may indicate which services are available, the display may indicate which services are unavailable, etc. In addition, the display may indicate why and where the service is unavailable in the PLMN.

[0416] PLMN reselection in automatic network selection mode is specified in section 4.4.3.2.1 of TS23.122. PLMN reselection may be enhanced to take into account the availability of network slices (S-NSSAI) in each PLMN as described herein in the proposed enhancements to the PLMN selection procedure. In addition, UE-triggered PLMN reselection may be performed when the UE evaluates the URSP rules and finds that a route cannot be established for the traffic because the desired S-NSSAI is not available in the current location of the UE in the PLMN.

[0417] Figure 7 A GUI for a UE is shown that maintains the allowed NSSAI and corresponding OFB for each S-NSSAI, alternative allowed NSSAI and OFB, enhanced URSP rules, and band steering capabilities coordinated with the RAN and core network.

[0418] Fig.16 A GUI for a UE is shown, which includes configuration of the UE to support simultaneous slice access restriction, support for slice access restriction due to service area (including geographic area location information), and enhanced URSP rules to support simultaneous slice access verification criteria.

[0419] Example Environment

[0420] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities, including research on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE Advanced standards. 3GPP has begun to work on the standardization of the next generation cellular technology (also known as "5G") called New Radio (NR). The development of the 3GPP NR standard is expected to include the definition of the next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. The flexible radio access is expected to include new non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes, which can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different needs. It is expected that ultra-mobile broadband includes centimeter wave and millimeter wave spectrum, which will provide opportunities for ultra-mobile broadband access such as indoor applications and hotspots. In particular, ultra mobile broadband is expected to share a common design framework with sub-6 GHz flexible radio access, while having centimeter-wave and millimeter-wave specific design optimizations.

[0421] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowded places, 50+Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles); critical communications; massive machine-type communications; network operations (e.g., network slicing, routing, migration and interworking, energy saving); and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle-to-other-entity communications. Specific services and applications in these categories include, for example: surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, car e-calling, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, tactile Internet, and virtual reality, among others. All of these use cases and others are considered in this article.

[0422] Fig. 8A An embodiment of an example communication system 100 is shown in which the methods and apparatus described and claimed herein may be embodied. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be generally or collectively referred to as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, other networks 112, and V2X servers (or ProSe functions and servers) 113, although it should be understood that the embodiments disclosed herein contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. FIG. 8A to FIG. 8EAlthough depicted as a handheld wireless communication device, it should be understood that in the context of the wide variety of use cases envisioned for 5G wireless communications, each WTRU may include or may be embodied as any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic device, a wearable device (such as a smart watch or smart clothing), a medical device or e-health device, a robot, an industrial equipment, a drone, a vehicle (such as a car, truck, train or airplane, etc.).

[0423] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, other networks 112, and / or a V2X server (or ProSe function and server) 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTS), Node Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, etc. Although the base stations 114a, 114b are each depicted as a single element, it will be appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0424] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a may be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired signals and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, a cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In one embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.

[0425] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c over an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0426] The base station 114b may communicate with one or more of the RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b, which may be any suitable wired communication link (e.g., cable, optical fiber, etc.) or a wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0427] The RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115c / 116c / 117c may be established using any suitable RAT.

[0428] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another via an air interface 115d / 116d / 117d (not shown in the figures), which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

[0429] The communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or the RRHs 118a, 118b, the TRPs 119a, 119b and the RSUs 120a, 120b and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0430] In one embodiment, the base station 114a and the WTRUs 102a, 102b, 102c or RRHs 118a, 118b, TRPs 119a, 119b and / or RSUs 120a, 120b, and WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use Long Term Evolution (LTE) and / or LTE Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communications, etc.). 3GPP NR technologies include NR V2X technologies and interfaces (such as sidelink communications, etc.).

[0431] In one embodiment, the base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c or RRHs 118a, 118b, the TRPs 119a, 119b and / or the RSUs 120a, 120b, and the WTRUs 102c, 102d, 102e, 102f in the RAN 103b / 104b / 105b may implement a radio technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), GSM Evolution (GERAN), etc.

[0432] Fig. 8AThe base station 114c in the WTRU 102d may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area (such as a business district, a home, a vehicle, a train, etc.). In one embodiment, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114c and the WTRU 102d may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or a femtocell. Fig. 8A As shown, the base station 114b may have a direct connection to the Internet 110. Therefore, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0433] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

[0434] Although not in Fig. 8A 105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same radio access technology (RAT) as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may be utilizing an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.

[0435] The core network 106 / 107 / 109 may also serve as a gateway for the wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e to access the public switched telephone network (PSTN) 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may use the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT.

[0436] Some or all of the wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig. 8A The illustrated WTRU 102e may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0437] Figure 8B 1 is a block diagram of an example apparatus or device, such as WTRU 102, configured for wireless communication according to an embodiment presented herein. Figure 8B As shown, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements while being consistent with an embodiment. In addition, embodiments contemplate that the base stations 114a and 114b and / or nodes that the base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTS), node Bs, site controllers, access points (APs), home node Bs, evolved home node Bs (eNodeBs), home evolved node Bs (HeNBs), home evolved node B gateways, and proxy nodes, etc.) may include Figure 8BSome or all of the elements depicted in and as described herein.

[0438] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Figure 8B The processor 118 and the transceiver 120 are depicted as separate components, but it is understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0439] Transmit / receive element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. For example, in one embodiment, transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive IR, UV or visible light signals. In another embodiment, transmit / receive element 122 can be configured to transmit and receive both RF signals and optical signals. It should be understood that transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0440] Furthermore, although the transmit / receive element 122 is Figure 8B 1 as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in one embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0441] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. The wireless transmit / receive unit (WTRU) 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple radio access technologies (RATs), such as UTRA and IEEE 802.11, for example.

[0442] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data from the foregoing components. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, or the like. In one embodiment, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0443] The processor 118 may receive power from the power source 134 and may be configured to distribute and / or control the power to other components in the wireless transmit / receive unit (WTRU) 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0444] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or in lieu of the information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by any suitable location-determination method while remaining consistent with an embodiment.

[0445] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, and more.

[0446] The wireless transmit / receive unit (WTRU) 102 may be embodied in other devices or equipment, such as sensors, consumer electronic devices, wearable devices (such as smart watches or smart clothing), medical or e-health equipment, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains, or airplanes). The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface that may include one of the peripheral devices 138.

[0447] Figure 8C 1 is a system diagram of a radio access network (RAN) 103 and a core network 106 according to one embodiment. The RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. Figure 8C As shown, the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while remaining consistent with an embodiment.

[0448] like Figure 8CAs shown, Node B 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each of RNC 142a, 142b can be configured to control the corresponding Node B 140a, 140b, 140c to which it is connected. In addition, each of RNC 142a, 142b can be configured to perform or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0449] Figure 8C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0450] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0451] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0452] The core network 106 may also be connected to networks 112, which may include other wired networks or wireless networks owned and / or operated by other service providers.

[0453] Fig.8D1 is a system diagram of the RAN 104 and the core network 107 according to one embodiment. The RAN 104 may employ E-UTRA radio technology to communicate with the wireless transmit / receive units (WTRUs) 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0454] The radio access network (RAN) 104 may include evolved Node-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of evolved Node-Bs while remaining consistent with an embodiment. The evolved Node-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In one embodiment, the evolved Node-Bs 160a, 160b, 160c may implement MIMO technology. Thus, the evolved Node-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0455] Each of the evolved Node Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Fig.8D As shown, the evolved nodes 160a, 160b, and 160c may communicate with each other via an X2 interface.

[0456] Fig.8D The illustrated core network 107 may include a mobility management entity (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements are depicted as being part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than a core network operator.

[0457] A mobility management entity (MME) 162 may be connected to each of the evolved Node-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the wireless transmit / receive units (WTRUs) 102a, 102b, 102c, etc. The MME 162 may also provide a control plane function for switching between the radio access network (RAN) 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0458] The serving gateway 164 may be connected to each of the evolved Node-Bs 160a, 160b, and 160c in the radio access network (RAN) 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to / from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring a user plane during inter-evolved Node-B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and storing the context of the WTRUs 102a, 102b, 102c, and the like.

[0459] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0460] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the Public Switched Telephone Network (PSTN) 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the core network 107 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0461] Fig. 8E is a system diagram of a radio access network (RAN) 105 and a core network 109 according to one embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with wireless transmit / receive units (WTRUs) 102a, 102b, and 102c over an air interface 117. The communication links between the different functional entities WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

[0462] like Fig. 8EAs shown, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it should be understood that the radio access network (RAN) 105 may include any number of base stations and ASN gateways while remaining consistent with the embodiment. The base stations 180a, 180b, 180c may each be associated with a specific cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In one embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, the base station 180a, for example, may use multiple antennas to transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, service classification, quality of service (QoS) policy implementation, and the like. Access service network (ASN) gateway 182 may serve as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to core network 109, and the like.

[0463] The air interface 117 between the wireless transmit / receive units (WTRUs) 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0464] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols for facilitating WTRU handovers and transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the access service network (ASN) gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0465] like Fig. 8EAs shown, a radio access network (RAN) 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the foregoing elements is depicted as part of the core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0466] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the wireless transmit / receive networks (WTRUs) 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the public switched telephone network (PSTN) 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional landline communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0467] although Fig. 8E Not shown, but it is understood that the RAN 105 may be connected to other access service networks (ASNs), and the core network 109 may be connected to other core networks. The communication link between the radio access network (RAN) 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the wireless transmit / receive units (WTRUs) 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0468] This article and Fig. 8A , Figure 8C , Fig.8D and Fig. 8EThe core network entities shown in are identified by the names given to these entities in certain existing 3rd Generation Partnership Project (3GPP) specifications, but it should be understood that these entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP New Radio (NR) specifications. Fig. 8A , Figure 8B , Figure 8C , Fig.8D and Fig. 8E The specific network entities and functionality described and illustrated in the present disclosure are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or defined in the future.

[0469] Figure 8F is a block diagram of an example computing system 90, in which Fig. 8A , Figure 8C , Fig.8D and Fig. 8E 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to operate. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, and the like. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a communication network. Coprocessor 81 is an optional processor distinct from main processor 91 that may perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0470] In operation, processor 91 fetches, decodes and executes instructions, and transfers information to and from other resources via the computing system's main data transfer path (system bus 80). Such a system bus connects components in computing system 90 and defines a medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0471] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes a circuit system that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. The data stored in RAM 82 can be read or changed by a processor 91 or other hardware device. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address as an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; unless memory sharing between processes has been set, it cannot access memory within the virtual address space of another process.

[0472] In addition, computing system 90 may include a peripheral device controller 83 responsible for passing instructions from processor 91 to peripheral devices such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

[0473] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output can be provided in the form of a graphical user interface (GUI). The display 86 can be implemented with a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch pad. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0474] Further, computing system 90 may include communications circuitry such as, for example, network adapter 97, which may be used to connect computing system 90 to an external communications network, such as Fig. 8A , 8B, RAN 103 / 104 / 105 of 8C, 8D and 8E, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112 to enable computing system 90 to communicate with other nodes or functional entities of these networks. Communication circuit systems alone or in combination with processor 91 can be used to perform the transmission and reception steps of certain devices, nodes or functional entities described herein.

[0475] Figure 8G An embodiment of an exemplary communication system 111 is shown in which the methods and apparatus described and claimed herein may be embodied. As shown, the exemplary communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, base stations, V2X servers, and RSUs A and B, but it should be understood that the embodiments disclosed herein contemplate any number of WTRUs, base stations, networks, and / or network elements. One or several or all of the WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundary as shown by the dashed line in the figure). WTRUs A, B, C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

[0476] It should be understood that any or all of the devices, systems, methods, and processes described herein can be implemented in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), causes the processor to execute and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein can be implemented in the form of such computer executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-transient (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage media do not include signals. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical disk storage, cassettes, tapes, disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store the desired information and can be accessed by a computing system.

[0477]

[0478]

[0479]

[0480]

[0481]

[0482]

[0483]

[0484]

[0485]

[0486]

[0487]

[0488]

[0489]

[0490]

[0491]

[0492]

[0493]

[0494]

[0495]

[0496]

[0497]

[0498]

[0499]

[0500]

[0501]

Claims

1. A user equipment (UE) comprising a processor, a memory, and a communication circuit system for communicating with a network, wherein the memory comprises computer executable instructions, and when the computer executable instructions are executed by the processor, the UE performs operations, the operations comprising: sending a first request to the network, the first request indicating first requested network slice selection assistance information (NSSAI), the first request further indicating that the UE is capable of receiving operating frequency band information; as well as A response including allowed NSSAIs is received from the network, the response also including allowed operating band information for one or more single NSSAIs (S-NSSAIs) among the allowed NSSAIs.

2. The UE of claim 1 , wherein the operations further comprise displaying allowed operating band information for one or more S-NSSAIs via a graphical user interface.

3. The UE of claim 1, wherein the operations further comprise determining a second requested NSSAI using the allowed operating band information.

4. The UE of claim 1, wherein the response further comprises an indication that one or more of the S-NSSAIs in the allowed NSSAIs cannot be accessed simultaneously. 5 . The UE of claim 1 , wherein the operations further comprise receiving the operating frequency band information in a non-access stratum (NAS) message. 6 . The UE of claim 1 , wherein the allowed operating frequency band information is associated with location information indicating one or more regions where the one or more operating frequency bands are to be considered valid. The UE according to claim 6 , wherein the location information comprises a registration area, a tracking area or a cell identifier.

8. The UE of claim 1, wherein the operations further comprise receiving the allowed operating band information in a radio resource control (RRC) message.

9. The UE of claim 1, wherein the allowed operating band information comprises a cell reselection priority associated with at least one S-NSSAI, the cell reselection priority being related to idle mode camping.

10. The UE of claim 1, wherein the operations further comprise: sending a second request to the network, the second request being a radio resource control (RRC) message indicating that the UE wants to access a selected S-NSSAI in the allowed NSSAI, the selected S-NSSAI being inaccessible in a frequency band currently being used by the UE; as well as A redirection of a frequency band that can be used to access the selected S-NSSAI is received from the network.

11. A user equipment (UE) comprising a processor, a memory, and a communication circuit system for communicating with a network, the memory comprising computer executable instructions, the computer executable instructions when executed by the processor causing the UE to perform operations comprising: sending a first request to the network, the first request indicating first requested network slice selection assistance information (NSSAI), the first request further indicating that the UE is capable of receiving synchronization slice access capability (SSAC) information; as well as A first response including allowed NSSAIs is received from the network, and the first response also includes SSAC information for one or more S-NSSAIs of the allowed NSSAIs.

12. The UE according to claim 11, wherein the SSAC information indicates: First, S-NSSAI cannot be used with any other network slice; The first S-NSSAI can only be used with network slices having the same slice / service type (SST) value; The first S-NSSAI cannot be used with a network slice having the same SST value; The first S-NAS SAI can only be used with network slices having the same slice distinguisher (SD) value; or The first S-NSSAI cannot be used with a network slice having the same SD value.

13. The UE according to claim 11, wherein: The operations also include receiving an indication that the first S-NSSAI is associated with a group; and The SSAC information indicates that S-NSSAI cannot be used with slices that are not part of the group.

14. A user equipment (UE) comprising a processor, a memory, and a network circuit system connected to a network, the memory comprising computer executable instructions, the computer executable instructions when executed by the processor causing the UE to perform operations comprising: Sending a first registration request to a network, the first registration request including first requested network slice selection assistance information (NSSAI), the NSSAI including a first single NSSAI (S-NSSAI) and a second S-NSSAI; receiving a first registration response from the network, the first registration response comprising a first allowed NSSAI, the first allowed NSSAI comprising the first S-NSSAI; a rejected NSSAI, the rejected NSSAI comprising the second S-NSSAI; and a cause code indicating that the second S-NSSAI is incompatible with the first S-NSSAI; sending a second registration request to the network, the second registration request including a second requested NSSAI, the second requested NSSAI including the second S-NSSAI, the second registration request omitting the first S-NSSAI; and A second registration response is received from the network, the second registration response comprising a second allowed NSSAI, the second allowed NSSAI comprising the second S-NSSAI.

15. A user equipment (UE), comprising a processor, a memory and a communication circuit system for communicating with a network, wherein the memory comprises computer executable instructions, and when the computer executable instructions are executed by the processor, the UE performs operations, wherein the operations comprise: sending a registration request to the network, the registration request comprising requested network slice selection assistance information (NSSAI), the NSSAI comprising at least a first single NSSAI (S-NSSAI) and a second S-NSSAI; receiving a registration response from the network, the registration response comprising allowed NSSAIs, the allowed NSSAIs comprising the first S-NSSAI and the second S-NSSAI; establishing a first packet data unit (PDU) session using the first S-NSSAI; sending a first PDU session establishment request related to establishing a second PDU session to the network, the second PDU session using the second S-NSSAI; receiving a PDU session establishment response, the PDU session establishment response comprising a reason code indicating that the second PDU session cannot be established because the PDU sessions with the first S-NSSAI and the second S-NSSAI cannot be maintained simultaneously; Ending the first PDU session with the first S-NSSAI; Sending a second PDU session establishment request to the network to establish the second PDU session; as well as A second PDU session establishment response is received indicating successful establishment of the second PDU session.

Images