Frequency Range Driven Network Slicing

Abstract

Network slice selection assistance information (NSSAI) may be signaled between a user equipment (UE) and a network. The NSSAI sent from the network to the UE may include, for example, the operating frequency band (OFB) of each single-NSSAI (S-NSSAI) within the NSSAI as well as a radio access technology (RAT) frequency selection preference (RFSP) index, which the network configures as part of the UE access and mobility subscription during the UE registration procedure. RAT restriction may be extended to indicate to the UE that a particular slice is not accessible via a particular RAT. The UE may be provided by the network with alternative NSSAIs and corresponding OFBs for each S-NSSAI, thereby indicating to the UE that these S-NSSAIs are allowed, if requested. The UE may select an alternative allowed NSSAI and send a registration update request to the network.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of priority to U.S. Provisional Patent Application No. S / N62 / 956,441, filed January 2, 2020, and entitled "Frequency range driven network slicing," U.S. Provisional Patent Application No. S / N62 / 972,212, filed February 10, 2020, and entitled "Frequency range driven network slicing," and U.S. Provisional Patent Application No. S / N63 / 057,996, filed July 29, 2020, and entitled "Frequency range driven network slicing," the contents of which are incorporated herein by reference in their entireties. [Background technology]

[0002] This disclosure may incorporate, but is not limited to, 3rd Generation Partnership Project (3GPP) TS 23.501, System Architecture for the 5G System, Stage 2, v16.1.0, Release 16, 2019-06, 3GPP TS 23.502, Procedures for the 5G System, Stage 2, v16.1.1, Release 15, 2019-06, GSMA NG.116 Generic Slice Template, Version 1.0, 23 May 2019, 3GPP TS 38.101-1 User Equipment (UE) radio transmission and reception, Part 1 - Range 1 Standalone, V16.1.0 (2019-09), and 3GPP TS 38.101-2 User Equipment (UE) radio transmission and reception, Part 2 - Range 2 Standalone, V16.1.0 (2019-09), and 3GPP TS 23.503, Policy and Charging Control Framework for the 5G System (5GS), Stage 2 (Release 16), etc. Summary of the Invention

[0003] When a User Equipment (UE) needs to access network slices that are available in different 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 may be achieved by various mechanisms.

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

[0005] The RAT restriction may be extended to indicate to the UE that a particular slice is not accessible via a particular RAT.

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

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

[0008] The extended UE Route Selection Policy (URSP) rules may include indication of 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.

[0009] The network may send a Radio Resource Control (RRC) message to the UE to indicate which particular S-NSSAIs within the allowed NSSAIs are accessible on the UE's current frequency band and which particular S-NSSAIs within the allowed NSSAIs are inaccessible.

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

[0011] Other challenges to be addressed include, for example, that UEs may not be allowed to access certain slices simultaneously, and that certain slices may only be available to UEs in certain locations, e.g., geographic regions and / or tracking areas. To address such scenarios, several approaches may be taken.

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

[0013] A UE may be allowed to register with multiple S-NSSAIs, and the UE may be restricted from having simultaneous Packet Data Unit (PDU) sessions with more than one slice based on configured Simultaneous Slice Access Policies (SSAPs). For example, the Access and Mobility Management Function (AMF) may reject a PDU session establishment request with a cause code detailing that slice B is not accessible along with slice A. The UE receives this cause code, and depending on its urgency or requirement, the UE may terminate the session with slice A and retry the PDU session establishment request with slice B.

[0014] The UE may be configured to know which S-NSSAIs are or are not available in a geographic region. Location information may be provided to the UE in the S-NSSAI information. Additionally, a NULL Slice / Service Type (SST) value may be used by the network to indicate to the UE, for example, that the network has recognized an S-NSSAI but that the S-NSSAI is not available in a particular geographic region and / or PLMN.

[0015] An extended registration procedure may be used, in which the UE is configured with information about which geographic regions the slices can be accessed from. The UE may then use this information when selecting a route for uplink data. For example, the UE may use this information to select a lower priority route when the slices are not available.

[0016] An enhanced PLMN selection or reselection mechanism may be used for UEs that take into account the availability of network slices in each PLMN when determining whether to register with the PLMN.

[0017] The UE may trigger PLMN reselection when the UE evaluates the URSP rules and identifies that traffic cannot be routed because the desired S-NSSAI is not available at the UE's current location in the PLMN.

[0018] A further challenge is that the UE may only have access to network slices that are all available in the UE's current OFB. Several solutions are available.

[0019] For example, a UE may inform a network (e.g., a Radio Access Network (RAN) and / or a 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.

[0020] Based on the UE's supported OFBs, the requested network slice, and the OFBs in which the requested slices are available, the network may, for example, direct the UE to switch to a different OFB in which all or most of the requested slices are available.

[0021] The UE may use the received OFB information to retransmit the UE registration request to the network, taking into account the cause code communicated by the network and ensuring that the allowed NSSAI is updated until the handover is complete. In the new OFB, the UE may receive a set of allowed slices once the registration is accepted.

[0022] The UE may send an indicator to the network during the registration update request process to inform the network that the UE wishes to update its allowed NSSAI only if the network can grant all of the requested slices within the UE's current operating band. If the network cannot grant all of the requested slices, the UE may continue to function with its current allowed NSSAI.

[0023] The UE may receive a list of Tracking Area / Registration Areas (TA / RA) to which all slices within the UE's allowed NSSAI are available during a successful UE registration procedure. Because the UE may be a mobile device, it may be appropriate for the UE to have knowledge of such TA / RA to which the UE can be gracefully handed over.

[0024] The UE may send a Non-Access Stratum (NAS) message to the network to request a list of TAs / RAs where all slices within the UE's allowed NSSAI are available. This request may be triggered by some UE context, such as time, TA change, and / or direction.

[0025] Both the UE-OFB policy and the simultaneous slice access policy (SSAP) can be applied as restrictions on simultaneous access of two or more slices during the UE registration procedure. Based on these policies, the UE can change the OFB for simultaneous access of slices.

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

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

[0028] During a PDU session with a slice in the network, the UE may include S-NSSAI information of the desired slice in an 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 UE's current OFB, the RAN may allow further PDU session establishment process to proceed or may otherwise instruct the UE to change the OFB before continuing the PDU session establishment procedure.

[0029] For a mobile UE with multiple ongoing PDU sessions, the RAN node may assist the UE in switching OFBs, and the UE may continue existing PDU sessions. Based on the OFBs supported by the UE and slice, the RAN may facilitate a new cell / OFB for the UE while continuing all PDU sessions, some PDU sessions, or none of the ongoing PDU sessions.

[0030] This Summary is provided to introduce a selection of concepts in a simplified form, which are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages noted anywhere in this disclosure. [Brief explanation of the drawings]

[0031] A more detailed understanding may be had from the following detailed description, given by way of example in conjunction with the accompanying drawings in which: [Figure 1] FIG. 1 is a block diagram of an example 5G system service-based architecture. [Figure 2] FIG. 1 is a block diagram of an example non-roaming 5G system architecture in reference point representation. [Figure 3]1 illustrates an example of a core network presenting multiple network slices. [Figure 4] 10 is a call flow of an example of NSSAI and operating band information delivery during registration. [Figure 5A] 10 illustrates an example call flow for providing an alternative slice and corresponding frequency band to a UE. [Figure 5B] 10 illustrates an example call flow for providing an alternative slice and corresponding frequency band to a UE. [Figure 6A] 1 illustrates an example call flow for frequency band redirection using RRC messaging. [Figure 6B] 1 illustrates an example call flow for frequency band redirection using RRC messaging. [Figure 7] 1 illustrates an example of a Graphical User Interface (GUI) of a UE with NSSAI and OFB and extended URSP rules. [Figure 8A] 1 illustrates an example of a communication system in which the methods and apparatus described and claimed herein may be implemented. [Figure 8B] 1 is a block diagram of an example of an apparatus or device configured for wireless communication. [Figure 8C] FIG. 1 is a system diagram of an example radio access network (RAN) and core network. [Figure 8D] FIG. 1 is a system diagram of another example RAN and core network. [Figure 8E] FIG. 1 is a system diagram of another example RAN and core network. [Figure 8F] FIG. 1 is a block diagram of an example computing system. [Figure 8G] FIG. 2 is a block diagram of another example communication system. [Figure 9] 10 illustrates an example of an S-NSSAI information element. [Figure 10] 10 illustrates an example of an extended S-NSSAI information element with OFB. [Figure 11]10 is an example call flow for delivering a simultaneous slice access policy indicator to a UE. [Figure 12] 10 is an example call flow for a UE re-registering to a desired slice after rejection due to a simultaneous slice access policy. [Figure 13] 10 is an example call flow for handling a PDU session request with concurrent slice access restrictions. [Figure 14] 1 is an example call flow of a UE with restricted access to a network slice based on a geographic region. [Figure 15] 10 is an example call flow for configuring slice location restriction information via access and mobility subscriptions. [Figure 16] 1 illustrates an example of a UE graphical user interface (GUI) showing support for simultaneous slice access restrictions, slice access service area restrictions, and support capabilities. [Figure 17] 1 is a call flow of an example of an operating frequency band handover during a registration procedure. [Figure 18] 10 is a call flow of an example of a registration update with allowed slices in the UE's current OFB. [Figure 19] 10 is an example call flow for a UE receiving TA / RA information from the network, where all slices are available in all OFBs. [Figure 20] 1 is a call flow of an example UE registration procedure using SSAP and UE OFB policy. [Figure 21] 1 is an example call flow for handling UE-OFB policy and concurrency restrictions by SSAP. [Figure 22] 10 is an example call flow of a UE sending an S-NSSAI in an RRC message during a PDU session establishment request. [Figure 23] 1 is a call flow of an example of a RAN proposing OFB for PDU session continuity. DETAILED DESCRIPTION OF THE INVENTION

[0032] term Table 14 in the Appendix contains many of the abbreviations used herein. The following are terms and neologisms used by the inventors herein:

[0033] Tracking Area (TA) - A TA is a set of cells. TAs can be grouped into a Tracking Area List (TA List), which can be configured on the User Equipment (UE). TAs are used for UE access control, location registration, paging, and mobility management.

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

[0035] Service Area Restriction - The service area restriction can be set to include one or more TAs or be unlimited, e.g., to include all TAs in a public mobile network (PLMN). The UE's subscription data in Unified Data Management (UDM) can include the service area restriction, e.g., using explicit TA identifiers to specify which TAs are allowed areas and / or which TAs are not allowed areas. Additionally or alternatively, the service area restriction can use geographic information such as longitude / latitude, zip code, etc. to identify allowed and / or not allowed TAs.

[0036] Alternate Network Slice Selection Assistance Information (NSSAI) - The NSSAI may be provided in an "Alternate NSSAI" that contains a set of one or more Single Network Slice Selection Assistance Information (S-NSSAI) that the UE is allowed to access if it selects to access them.

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

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

[0039] Network Function Service - An NF service is a type of capability that is exposed by a first NF (NF service producer) to another authorized NF (NF service consumer) via a service-based interface. An NF may expose one or more NF services. For example, an AMF may provide a Namf_EventExposure service, allowing the AMF to send notifications to NFs that subscribe to certain mobility management-related events.

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

[0041] Network slice—A network slice is a logical network that provides specific network capabilities and network characteristics.

[0042] Network slice instance—A network slice instance is a set of an NF instance and the necessary resources (e.g., computational resources, storage resources, and network resources) that form a deployed network slice.

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

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

[0045] PC5 (Interface) - PC5 refers to the reference point at which a user equipment communicates with another user equipment over a direct channel.

[0046] 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 "Index to RAT / Frequency Selection Priority" (RFSP index) to the eNodeB over S1. The RFSP index is mapped by the eNodeB to a locally defined configuration to apply a specific Radio Resource Management (RRM) strategy. The RFSP index is UE-specific and applies to all radio bearers. This parameter can be used by the E-UTRAN to derive a UE-specific cell reselection priority for controlling idle mode camping 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 it to a locally defined configuration in the gNodeB to apply a specific RRM strategy.

[0047] Simultaneous Slice Access Policy (SSAP) - The term SSAP is used herein to refer to a set of policies that control 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 to access and / or be accessing a URLLC slice.

[0048] Simultaneous Slice Access Capability (SSAC) - The term SSAC is used herein to refer to a 3GPP Rel-17 or subsequent system capability whereby the network may need to impose a restriction on a UE accessing more than one slice simultaneously. This restriction may be imposed by a Mobile Network Operator (MNO) in the core network based on SSAP. The core network provides the UE with an SSAC indicator that defines the nature of the simultaneous access. The UE may need to support such a policy. A UE that supports SSAP is known to have simultaneous slice access capability. The UE signals support for the SSAC indicator via the SSAC Support Indicator (SSI).

[0049] UE-OFB Policy—The term UE-OFB policy herein refers to a policy that allows a UE to access only 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, a request to access all slices is rejected with an OFB handover proposal in which all requested slices are available.

[0050] Uu (interface) - The air interface between the 5G RAN and the user equipment.

[0051] 5G Network Architecture Example Figure 1 shows an example non-roaming reference architecture with service-based interfaces in the Control Plane (CP). See 3GPP TS 23.501, System Architecture for the 5G System; Stage 2, v16.1.0, Release 16, 2019-06.

[0052] Figure 2 shows an example of a 5G system architecture for the non-roaming case, using a reference point representation showing how the various network functions interact with each other. See TS 23.501.

[0053] Mobility management and session management functions (SMF) are separated. A single N1 NAS connection is used for both registration and connection management, as well as for UE messages and procedures related to session management (SM). A single N1 termination point is located in the AMF. The AMF forwards 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.

[0054] Network Features The 5G architecture provides support for data connectivity and enables deployments using technologies such as network function virtualization and software-defined networking. The 5G system architecture enables service-based interactions between control planes (CPs) and network functions (NFs) to be leveraged, where identified.

[0055] An NF is a processing function within a network, with defined functional behavior and defined interfaces. An NF can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on a suitable platform, for example on a cloud infrastructure.

[0056] Network Slicing in 5GC A network slice is a logical network that provides specific network capabilities and characteristics. A network slice in a PLMN includes a Core Network (CN) control plane (CP) and user plane network functions. A network slice instance is a set of NF instances and the necessary resources (e.g., computational, storage, and network resources) that form a deployed network slice.

[0057] Network slices may differ in terms of supported features and network function optimization, in which case such network slices may be of different SSTs. An operator may deploy multiple network slice instances delivering the same features, but for different groups of UEs, for example, when they deliver different committed services and / or because they are customer-specific, in which case such network slices may be of the same SST but distinguished through different slice identifiers.

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

[0059] Network slice identification and selection, S-NSSAI and NSSAI A network slice is identified by an S-NSSAI and may include a slice / service type (SST) and a slice suffix (SD). The SST indicates the expected network slice behavior in terms of features and services. The slice suffix (SD) is optional information that complements the SST to distinguish between multiple network slices of the same SST.

[0060] An S-NSSAI can have a standard value (e.g., such an S-NSSAI consists only of an SST with a standardized SST value and does not include an SD), or a non-standard value (e.g., such an S-NSSAI consists either of both an SST and an SD, or of only an SST without a standardized SST value and does not include an SD). An S-NSSAI with a non-standard value identifies a single network slice within the PLMN to which it is associated. An S-NSSAI with a non-standard value shall not be used by the UE in Access Stratum (AS) procedures for any PLMN other than the PLMN to which the S-NSSAI is associated. Table 1 in the Appendix shows the standardized SST values.

[0061] The NSSAI is a collection of S-NSSAIs. The NSSAI may be a configured NSSAI, a requested NSSAI, or an authorized NSSAI. There can be up to eight S-NSSAIs among the authorized NSSAIs and requested NSSAIs sent in a signaling message between the UE and the network. The requested NSSAI signaled by the UE to the network enables the network to select the serving AMF, network slice, and network slice instance for this UE.

[0062] Based on the operational or deployment needs of an operator, a network slice instance can be associated with one or more S-NSSAIs, and an S-NSSAI can be associated with one or more network slice instances. Multiple network slice instances associated with the same S-NSSAI can 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., be common to) two or more network slice instances associated with this S-NSSAI.

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

[0064] The RAN may use the requested NSSAI in access stratum (AS) signaling to address UE CP connection before 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 requests to resume the RRC connection and is in CM-CONNECTED in the RRC inactive state, the UE shall not include the requested NSSAI in the RRC resume.

[0065] Once the UE is successfully registered to an access type, the CN notifies the RAN by providing the authorized NSSAI for the corresponding access type.

[0066] Standardized SST values ​​provide slicing with a way to ensure global interoperability, allowing PLMNs to more efficiently support roaming use cases for the most commonly used SSTs.

[0067] The standardized SST is given in Table 1 below in the appendix to this specification. See TS 23.501.

[0068] NSSAI composed A configured NSSAI is an NSSAI provisioned to a UE that is applicable to one or more PLMNs. A configured NSSAI is configured by and may apply to a serving PLMN. There is at most one configured NSSAI per PLMN.

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

[0070] Requested NSSAI The Requested NSSAI is the NSSAI provided by the UE to the serving PLMN during registration. The S-NSSAI in the Requested NSSAI selected from the Configured NSSAI is applicable to this PLMN if it is available. If the Configured NSSAI for the PLMN is not available, the S-NSSAI in the Requested NSSAI is selected from the Default Configured NSSAI if it is configured in the UE.

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

[0072] Authorized NSSAI The allowed NSSAI is an NSSAI provided by the serving PLMN during the registration procedure and indicates the S-NSSAI value for which the UE is not registered in the serving PLMN of the current registration area. Upon successful completion of the UE registration procedure across an access type, the UE obtains from the AMF the allowed NSSAI for this access type, including one or more S-NSSAIs and, if necessary, a mapping of one or more S-NSSAIs to the HPLMN S-NSSAI. These S-NSSAIs are valid for the current registration area and access type and can be used simultaneously by the UE.

[0073] Authorized NSSAI mapping The allowed NSSAI mapping is the mapping of each S-NSSAI of the allowed NSSAIs for the serving PLMN to an HPLMN S-NSSAI.

[0074] Configured NSSAI mapping The configured NSSAI mapping is the mapping of each S-NSSAI of the configured NSSAI for the serving PLMN to an HPLMN S-NSSAI.

[0075] S-NSSAI encoding The purpose of the S-NSSAI information element is to identify the network slice. The S-NSSAI information element is encoded as shown in Figure 9 and Table 8 in the appendix of this specification, as described in 9.11.2.8 of 3GPP TS 24.501 Non-Access-Stratum (NAS) protocol for a 5G system.

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

[0077] URSP Rules The UE Route Selection Policy (URSP) contains a prioritized list of URSP rules. See 3GPP TS 23.503 Policy and Charging Control Framework for 5G system; Stage 2 (Release 16). See also Table 2 in the appendix hereto, which shows the URSP. The structure of the URSP rules is described in Tables 3 and 4 in the appendix hereto.

[0078] Network Slicing Extensions The 3GPP SA2 study, Feasibility Study on Enhancement of Network Slicing Phase 2 (S2-1908583), concerns new enhancements to network slicing. This study was undertaken as a result of a request received from the GSMA 5GJA to further investigate and incorporate recommended features based on the Generic Slice Template (GST) concept published in GSMA NG.116 Generic Slice Template, Version 1.0, 23 May 2019. The main objective of this study is to identify support for GST parameters in 5G system procedures in SA2-owned TSs and to investigate potential solutions that could address these gaps.

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

[0080] This means that a specific frequency band can be used to access a specific network slice. For example, eMBB slices can be supported at 2.6 GHz and 4.9 GHz, but URLLC slices can only be supported at 4.9 GHz. In some other deployment scenarios, lower frequency bands can be used for IoT while higher frequency bands are used for eMBB services. In other words, the combination of spectrum bands and network slices can be a good tool for service providers that require service separation as well as efficient use of 5G spectrum bands.

[0081] Radio Spectrum 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 terms of how often they are used. Table 6 in the appendix to this specification provides a summary of the radio spectrum attributes.

[0082] This attribute defines which frequencies can be used to access a network slice. NR is designed to operate in the FR1 and FR2 operating bands. The symbols n1, n77, and n38 in Table 6 represent examples of NR operating bands within the FR1 frequency range designation. Table 5.2.1 of TS 23.101 defines the relationship between the frequency range designations FR1 and FR2 (Table 5) and the NR operating bands. For example, the n1 NR operating band represents the uplink (UL) operating band between 1920 MHz and 1980 MHz, which UEs use for transmission and base stations use for reception, and the downlink (DL) operating band between 2110 MHz and 2170 MHz, which UEs use for reception and base stations use for transmission, operating in FDD (Frequency Division Duplex) duplex mode.

[0083] It should also be noted that radio spectrum attributes have scalability attribute tags. Tags are used as labels attached to attributes to give additional information about the nature of each attribute. GSMA NG.116 defines that there are two types of attributes: character attributes and scalability attributes. An attribute cannot fall into both categories.

[0084] A literal attribute characterizes a slice, for example, the throughput, latency, and / or application programming interface (API) that the slice provides. It is independent of the network slice consumer (NSC) and the network slice provider (NSP). A 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 consumer (NSC) and the network slice provider (NSP).

[0085] Service Area NG.116 also defines a service area attribute, which specifies the area in which a terminal can access a particular network slice. Thus, the attribute specifies a list of countries in which the service will be provided.

[0086] The list is specific to the Network Slice Provider (NSP) and their roaming agreements. If the list contains more than one entry, a roaming agreement between the HPLMN and the visited public mobile network (VPLMN) is required. Table 9 in the Appendix to this specification provides attribute details.

[0087] Regional specifications For every country listed in the service area attribute, it MUST be indicated whether the service is provided throughout the country or only in part of the country. If a Network Slice Consumer (NSC) requires a specific location, this attribute can be used to specify the region of the country in which the service is provided. It MUST be completed for every country listed in the area of ​​service attribute.

[0088] The list of regions is specific to each country, and the way to define these regions is to determine the network slice consumer (NSC) and network slice provider (NSP). Table 10 in the appendix to this specification provides attribute details.

[0089] The service area may also depend on the base station location and its coverage, cells, etc. In addition, the GSMA NST116 document describes geographical partitioning. This approach involves partitioning a geographical region into a set of zones / grids, which consists of defining a regular set of zones of predetermined dimensions for better resource utilization.

[0090] Radio Resource Management Function To support radio resource management in the RAN, the AMF provides the parameter "Radio Access Frequency (RAT) / Frequency Selection Priority (RFSP Index)" to the Radio Access Network (RAN) over N2. See TS 23.501. The RFSP Index is mapped to a locally defined configuration by the RAN to apply a specific Radio Resource Management (RRM) strategy, taking into account any available information in the RAN. The RFSP Index is UE-specific and applies to all radio bearers. This parameter can be used by the RAN to derive a UE-specific cell reselection priority to control idle mode camping, and can also be used to decide to redirect active mode UEs to a different frequency layer or RAT.

[0091] 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 a non-roaming subscriber, the AMF selects the RFSP index in use according to one of the following procedures, depending on the operator's configuration: The RFSP index in use may be identical to the subscribed RFSP index, or the AMF may select the RFSP index in use based on UE-related context information available in the AMF, including the subscribed RFSP index, locally configured operator policies, allowed NSSAIs, and, if received during the registration procedure, the UE's usage settings (see 3GPP TS 23.502, Procedures for the 5G System; Stage 2, v16.1.1, Release 15, 2019-06).

[0092] For roaming subscribers, the AMF may select the RFSP index in use based on the accessed 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 used for all roamers regardless of the HPLMN).

[0093] The RFSP index in use is also transferred from the source to the target RAN node when Xn or N2 is used for intra-NG-RAN handover.

[0094] The AMF stores the received subscribed RFSP index values ​​and the RFSP index value in use. During the registration procedure, the AMF may update the RFSP index value in use (e.g., the AMF may need to update the RFSP index value in use if UE-related context information in the AMF changes). Upon changing the RFSP index value in use, the AMF immediately provides the updated RFSP index value in use to the NG-RAN node by modifying an existing UE context, or by establishing a new UE context in the RAN, or by configuring the inclusion of the updated RFSP index value in use in a Next Generation Application Protocol (NGAP) downlink NAS transport message if user plane establishment is not required.

[0095] Access and mobility-related policy control The Access and Mobility Policy Control function encompasses the management of service area restrictions, management of RFSP functionality, and management of UE Aggregate Maximum Bit Rate (UE-AMBR) and SMF selection. This clause defines the management of service area restrictions and RFSP index for UEs registered over 3GPP access.

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

[0097] The AMF may report the subscribed service area restrictions received from the UDM during the registration procedure or when the AMF is changed. The condition for reporting requires that the local policy in the AMF indicates that access and mobility control is enabled. The AMF also reports the subscribed service area restrictions to the PCF when the policy control request trigger for service area restrictions is changed, as described in 6.1.2.5 of 3GPP TS 23.503, Policy and Charging Control Framework for the 5G System (5GS); Stage 2 (Release 16). The AMF receives the modified service area restrictions from the PCF. The AMF stores them and uses them to determine the UE's mobility restrictions. The PCF can indicate to the AMF that an unrestricted service area exists.

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

[0099] The RFSP index management allows the PCF to modify the RFSP index used by the AMF to perform radio resource management functions, as described in TS 23.501 clause 5.3.4. The PCF modifies the RFSP index based on operator policies that take into account, for example, cumulative usage, load level information per network slice instance, etc. The subscribed RFSP index can be further adjusted by the PCF at any time based on operator policies.

[0100] For radio resource management, the AMF may report the subscribed RFSP index received from the UDM during the registration procedure or when the AMF is changed. The condition for reporting requires that the local policy in the AMF indicates that access and mobility control is enabled. The AMF reports the subscribed RFSP index to the PCF when the subscription to the RFSP index change to the PCF is satisfied. The AMF receives the modified RFSP index from the PCF.

[0101] UE-AMBR management allows the PCF to provide UE-AMBR information to the AMF based on the serving network policy. The AMF may report the subscribed UE-AMBR received from the UDM. The condition for reporting requires that the PCF has provided a policy control request trigger to the AMF to report the subscriber UE-AMBR change. The AMF receives the modified UE-AMBR from the PCF. The AMF provides the serving network's UE-AMBR value to the RAN as specified in TS 23.501 clause 5.7.2.6.

[0102] Example assignment An MNO may offer multiple network slices. Each network slice may be designed and configured to offer specific slice characteristics to a UE, such as desired QoS, security capabilities, and network capabilities. Four standard slice / service types are defined in TS 23.501, Rel 16. See Table 1 in the appendix hereto. A network operator may want to plan their network so that certain slices are only available over certain frequency bands.

[0103] Figure 3 shows a core network that can present four different types of network slices: URLLC, V2X, eMBB, and Massive Internet-of-Things (MIoT). These network slices can be operated in different frequency bands, which can be assigned to slice types based on factors such as QoS, NF, and / or geographic region.

[0104] When a UE accesses a particular slice, the network may need to restrict the UE from accessing other slices, 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. For example, this may be desirable in a scenario where an enterprise deploys slices and wants to prevent a UE from accessing a slice while simultaneously accessing one or more other slices belonging to another enterprise.

[0105] Another network slicing scenario to consider relates to roaming. When a UE is roaming, a roaming agreement between the UE's HPLMN and VPLMN specifies the slices that the UE is allowed to access via the VPLMN. Furthermore, the roaming agreement may be negotiated such 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 may be done in scenarios where an enterprise does not want its slices to be accessed from certain countries or regions, or in scenarios where local regulations dictate that certain slice types should not be accessed.

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

[0107] Based on the type of application used in the UE and the target network slice, the UE must be able to steer itself to a predefined, pre-allocated frequency band corresponding to the frequency band of the slice. Currently, 5GS does not provide a mechanism for a UE to steer itself to a specific frequency band assigned to a specific network slice without registering and deregistering.

[0108] A UE must be configured with a set of policies to navigate itself between frequency bands assigned to network slices. 5GS must define such policies. While an MNO allocates frequency bands to network slices, a UE may require frequency band information to successfully navigate to the correct network slice. Therefore, information about the relationship between frequency bands and network slices must be provided to the UE. Current 5GS does not describe a mechanism for configuring or distributing such frequency band and corresponding network slice information to a UE.

[0109] The UE must have a policy to correctly navigate to the target network slice via the correct operating frequency band using information received from the core network. Such a policy may be pre-configured in the UE or delivered by the core network. Current 5GS does not define such a policy for the UE. Furthermore, the policy needs to be defined in the UE so that the UE can successfully navigate to the correct frequency.

[0110] To allow the network to restrict a UE from accessing any other slice, restrict a UE from accessing other slices with the same SST value, or restrict a UE from accessing other slices with the same SD value, the following questions need to be answered:

[0111] First, how does 5GS make the UE aware of these restrictions? In other words, how does the network make the UE aware that these restrictions are in place?

[0112] Second, how does the UE handle the case where new application layer activity accesses a slice, which would typically trigger the UE to attempt to send traffic on a currently restricted slice?

[0113] Third, what will the network do when the UE attempts to violate the restrictions? In other words, what will 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 will need to apply these restrictions to legacy (Rel-15 and Rel-16) UEs as well.

[0114] To address the case where a UE is only allowed to access certain slices in a particular PLMN when the UE is roaming, the following questions need to be addressed:

[0115] First, how does the network communicate to the UE that a certain slice cannot be accessed in a certain PLMN when the UE is roaming? In other words, how does the network communicate to the UE that a slice cannot be accessed via a given VPLMN when the UE is in a particular country or region?

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

[0117] Third, if a 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?

[0118] Fourth, the answers to the questions considered herein should take into account the need for networks to apply these restrictions to legacy (Rel-15 and Rel-16) UEs.

[0119] Furthermore, when a UE is restricted to access a network slice based on the OFB in which the slice is available, multiple slice access scenarios may arise. For example, the UE may be allowed to access only slices that are available in the UE's current OFB. In such a configuration, the following questions may need to be addressed:

[0120] How does the UE communicate to the network about the OFBs it supports so that the network can assist the UE in selecting the slices it can access?

[0121] What happens when a 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?

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

[0123] How does 5GS manage a UE's request to establish a PDU session to a slice if the slice does not exist in the UE's current OFB? How does 5GS deal with PDU session continuity scenarios when the UE moves to a new OFB / cell? The answers to this question should also take into account that the network will need to apply these restrictions to legacy (Rel-15 and Rel-16) UEs.

[0124] Solutions based on frequency band configuration in UE Operating bands, which align with specific UL and DL frequency ranges, 3GPP TS 38.101 (including Part 1 and Part 2, and TS 38.101-1 and TS 38.101-2) User Equipment (UE) radio transmission and reception V16.1.0(2019-09), may be predefined and assigned to network slices. The allocation and configuration of these operating bands to corresponding network slices may depend on the MNO's local policy. Figure 4 shows an example of how the operating bands for each slice are distributed to UEs.

[0125] In step 0 of Figure 4, the MNO may allocate operating bands (e.g., n1, n7, n12, etc.) and assign them to S-NSSAI(s) as part of UE Access and Mobility Subscription at the UDM / UDR, as defined in 3GPP TS 38.101-1 User Equipment (UE) radio transmission and reception; Parts 1&2, V16.1.0 (2019-09), and assign them to S-NSSAI(s) as part of UE Access and Mobility Subscription at the UDM / UDR, which may include RFSP index configuration.

[0126] In step 1, the UE sends a registration request to the AMF via the access network. The request includes the requested NSSAIs. In the case of initial registration or mobility registration update, the UE includes a mapping of the requested NSSAIs (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-NSSAIs in the allowed NSSAIs are allowed based on the subscribed S-NSSAIs. The UE includes a default configured NSSAI indication if the UE is using a default configured NSSAI.

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

[0128] 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 a UE context request indicating that a UE context needs to be set up in the NG-RAN, including the selected PLMN ID or PLMN ID and network identifier (NID), location information and cell identity information related to the cell on which the UE is camped, and security information.

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

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

[0131] Mobility restrictions consist of RAT restrictions, forbidden areas, service area restrictions, core network type restrictions, and closed access group information as described in TS 23.501 clause 5.3.4.1, where RAT restrictions define the 3GPP RATs that a UE is not allowed to access in a PLMN. For a restricted RAT, a UE based on a subscription is not allowed to access the network of this PLMN. RAT restrictions can be extended so that RAT restrictions are indicated per S-NSSAI, in other words, a certain slice may not be accessible via a certain RAT.

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

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

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

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

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

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

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

[0139] Extended S-NSSAI information element with OFB In the solution described with reference to FIG. 4, upon successful registration, the AMF sends the UE an authorized NSSAI with operating frequency band information attached to each S-NSSAI. The S-NSSAI information element is described in Section 9.11.2.8 of TS 24.501. FIG. 10 shows an S-NSSAI information element extended with two octets of operating frequency band (OFB) information. It defines the operating frequency band that the S-NSSAI should be available to the UE. FIG. 10 shows the OFB that may be included in octets 11 to 12. Two octets have been 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 limit of octets (e.g., the current S-NSSAI IE size). Additionally, multiple operating frequency band information elements may be provided to the UE, and each OFB information element may be associated with location information (in the PLMN associated with the S-NSSAI) where the OFB information should be considered valid. Examples of location information are registration area, tracking area, and cell identifier.

[0140] The UE may use the OFB information element to determine which operating frequency band to use based on the service the UE wishes 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 and secondary cells to connect to.

[0141] Table 11 in the appendix hereto provides details about the S-NSSAI information element updated with operating frequency band information.

[0142] Operating frequency band handover of available slices For a UE camped in a cell, the allowed NSSAIs received by the UE in the registration accept message shall include only a set of S-NSSAIs that are all available in the current operating frequency band. A scheme in which a UE can access a network slice only if the slice is available in the UE's current OFB can be referred to as a UE-OFB policy. However, there may be scenarios in which the UE may request a slice that may not be available in the UE's current OFB. In such cases, the registration request may be rejected by the network (e.g., by the AMF) with a cause code. The cause code in the registration reject message may provide the UE or RAN node with further information about the reason for the rejection and the OFB, but triggers the UE to move to a different operating band where all requested slices are available and all S-NSSAIs from the requested NSSAI are available. OFB handover during the registration procedure is illustrated in Figure 17.

[0143] 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 the UE access and mobility subscription in UDM / UDR, which may include the RFSP index configuration.

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

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

[0146] Firstly, V2X operating bands for V2X OFB, V2X preferred OFB, and simultaneous Uu & PC5 based operation.

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

[0148] Third, OFB for intra-band carrier aggregation operation, UE's preferred OFB for intra-band carrier aggregation operation.

[0149] Fourth, OFB for dual connectivity operation, the UE's preferred OFB for dual connectivity operation.

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

[0151] Sixth, S-NSSAI preference in priority order: The UE may indicate which S-NSSAI is essential for the current OFB to assist the AMF in accepting or rejecting the registration request.

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

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

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

[0155] Mobility restrictions consist of RAT restrictions, prohibited areas, service area restrictions, core network type restrictions, and closed access group information, as described in TS 23.501 clause 5.3.4.1 [1]. RAT restrictions define the 3GPP radio access technologies that a UE is not allowed to access in a PLMN. For restricted RATs, a UE is not allowed to access the network of this PLMN depending on the UE subscription. For example, the UE subscription is used by the network to determine whether the UE is allowed or not allowed access. RAT restrictions can be extended to be indicated per S-NSSAI; in other words, a certain slice may not be accessible via a certain RAT. This solution assumes that a mapping between S-NSSAI and OFB or OFB options is maintained in the core network, as described herein. For example, an AMF core network uses OFB information received from the UE as input for selecting an S-NSSAI and determining RAT restrictions. Furthermore, in alternative embodiments, the RAT restriction may be extended to be indicated for each combination of S-NSSAI and OFB, and the OFB indication may include any OFB indication option described herein, including a V2X-related OFB indication option, for example, a CA carrier aggregation (CA) OFB option or a dual connectivity OFB option.

[0156] In step 3, the AMF applies 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 from within the requested NSSAI that may be accessible via the UE's current OFB, it may identify that not all S-NSSAIs within the requested NSSAI are available in the UE's current operating frequency band.

[0157] In addition, the AMF may be able to identify one or more OFBs including an OFB option as described herein in which all of the S-NSSAIs from the requested NSSAI are accessible by the UE. In such a case, the AMF may reject the registration request from the UE with a cause code and indicate to the UE an OFB in which all of the S-NSSAIs from the requested NSSAI are accessible by the UE.

[0158] In step 4, the AMF may return a registration rejection message to the UE with a cause code. The cause code may indicate to the UE that the registration request was rejected because the requested slices are not necessarily available in the UE's current OFB. In addition, it may also contain an OFB supported by the UE or an OFB including OFB options as described herein, from which all requested slices are accessible, and may suggest to the UE to resend the registration request from another OFB.

[0159] If the UE supports multiple OFBs but the requested slice is not necessarily available in any of the OFBs supported by the UE, the AMF rejects the UE registration request or registration update request with a cause code indicating that the requested slice is not available in any of the OFBs. The cause code may request the 5GS to adapt to the following cases:

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

[0161] In case 2, the cause code may include a suggestion that most S-NSSAIs from the requested NSSAI may be accessible. For example, the UE may support three OFBs (e.g., OFB1, OFB2, and OFB3). The AMF may discover that only four of eight S-NSSAIs are accessible in the UE's current OFB (e.g., OFB1), and that OFB2 and OFB3 support six and seven S-NSSAIs, respectively, and may suggest to the UE to choose whether it wants to resend the registration in another OFB.

[0162] In Case 3, the cause code may include an OFB proposal in which all slices are available based on the slice priorities for that UE. The rank of the slices may be defined based on the frequency range (FR), OFB, UE type, slice, slice type, and the services provided by the slice type. For example, there may be different types of UEs (e.g., mobile phones, autonomous vehicles, connected-only vehicles, fixed IoT devices, etc.). These UEs may have different services that they typically require, which may require, for example, 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 slice priorities for each UE may be different from other UEs. For example, an autonomous vehicle UE may have a URLLC slice at the top of its list, an eMBB slice second, and an IoT slice third. The priorities may not be the same for a mobile phone, which may have eMBB at the top of its list and a URLLC slice second. In addition, FR and the corresponding OFB may be more suitable for one type of traffic (e.g., lowest latency traffic). When the AMF sends a registration rejection message, the cause code may include OFBs ranked based on the UE's slice priorities, but all slices are available in that OFB. This allows the UE to select a more appropriate OFB to retransmit the registration request. This case may also be preferable when the AMF can suggest a UE with an OFB where most of the slices are available. For example, if an eMBB slice is not available in an OFB but a URLLC is available in another OFB, or vice versa, the UE may choose to send its registration request to the OFB based on its own service / slice priority.

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

[0164] In another alternative, if none of the OFBs supports all UE-requested slices, but the UE's current OFB supports some of the requested slices, the AMF may respond with a registration accept message using an allowed NSSAI that may include only certain slices supported in the UE's current OFB, and may include the remainder of the S-NSSAI in the rejected NSSAI using a cause code that indicates that the slice was rejected because it is not supported in the current OFB. The cause code may also indicate the OFB in which each slice is available.

[0165] In step 5, based on the information in the cause code received from the network, the UE may select a proposed OFB. The UE may initiate a new registration request using the new proposed OFB. This may involve sending the request via a different RAN node than the UE's initial registration request in step 1. The AMF may assist the RAN node and the UE to make the registration request at the different RAN node. The AMF knows the OFB in which 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 node, the AMF may send a cause code indicating a change of OFB, and therefore of 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) that supports the requested NSSAI and is in the UE's location / TA.

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

[0167] Note that the UE may not be allowed to update its authorized NSSAI until it has successfully switched to a new operating band.

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

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

[0170] Registration renewal by authorized NSSAI The general registration or registration update request may be extended such that the UE may send an indicator to the network to indicate that it wishes to update its allowed NSSAI only if all of the slices in the request will be allowed within the UE's current operating band. Otherwise, the UE may prefer to retain its current allowed NSSAI. This scenario is depicted in Figure 18 as follows:

[0171] In step 1, the UE sends a registration or registration update request, which may include a requested NSSAI. In the request message, the UE may also include an indicator called an all-slice indicator, which informs the network about the UE's desire to update the allowed NSSAIs only if all S-NSSAIs in the request will be allowed in the current operating band; otherwise, the UE does not want to update the allowed NSSAIs.

[0172] Alternatively, the all-slice indicator may represent the UE's desire to remain in the current OFB only if no other OFB supports all the requested slices.

[0173] In step 2, the AMF applies the UE-OFB policy and checks whether all requested slices are available in the UE's current OFB. In addition, the AMF also considers the all-slice indicator from the UE. The AMF may have two alternative decisions based on the results of the UE-OFB policy and the all-slice indicator.

[0174] In step 3-a, if the AMF encounters that one or more of the requested slices in the registration update request are not available in the UE's current OFB and in addition detects the all slices indicator from the UE, the AMF will return a registration update accept message without updating the allowed NSSAIs, and the registration update accept message will include a cause code or some other indication to indicate to the UE that the UE should not update its allowed NSSAIs. The cause code or indication may indicate that the all slices indicator was not satisfied. This registration update may update all but the allowed NSSAIs or may reject the registration update request.

[0175] In step 3-b, if the AMF encounters that the slices of the requested NSSAI are all available in the UE's current OFB and detects an all slices indicator from the UE, the AMF will return a registration update accept message with a new set of allowed NSSAIs.

[0176] Instead of including the all slice indicator in the registration request, the UE may include the current allowed NSSAI in the registration request. The presence of the allowed NSSAI in the registration request may serve the all slice indicator.

[0177] Tracking / registration area with slices available in all cells If a UE can access all slices in any of its OFBs, it may be convenient for the UE to have prior knowledge of the TA / RA in which all slices in the UE's allowed NSSAI may be available. This information may facilitate smooth UE movement as the UE passes through various TA / RA. Information regarding where such TA / RA are available may be configured in the network, and the network may deliver the information to the UE during registration, registration update process, or UE configuration update process, as shown in FIG. 19.

[0178] In step 0-A, an Operations, Administration and Maintenance (OAM) entity may configure the PCF with a UE-OFB policy that allows all slices to be accessed via all cells in the tracking / registration area. This UE-OFB policy may be sent to the AMF for later application. Additionally, the OFB-to-slice relationship may be sent to the RAN node along with RAN resource allocation information such as RFSP index.

[0179] In step 0-B, the UDM / UDR may be configured with a list of TA / RA information for the UE, which specifies the Tracking Area Identifier (TAID) for each TA, and the UE may have access to authorized Slices in all OFBs.

[0180] 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 that the UE supports, including the OFBs that the UE is currently using.

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

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

[0183] In step 3, the AMF checks the requested NSSAI, the OFBs supported by the UE, and all available slices in all cells of the TA / RA including the current TA / RA, identifies the allowed NSSAIs of the UE, identifies the TAs / RAs where the OFBs supported by the UE are available, and determines the allowed NSSAIs together with a list of TAs / RAs where all slices of the allowed NSSAI are available.

[0184] In step 4, the AMF sends a registration acceptance message with the allowed NSSAIs and rejected NSSAIs, if any. In addition, the AMF also distributes a list of TAIDs for all TAs within the RA for which all slices of the allowed NSSAIs are available.

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

[0186] In another alternative, a request for a TA / RA list in which all slices within the allowed NSSAI are available in all its cells may be included in a NAS message such as a new service request.

[0187] In yet another alternative, a list of TA / RAs for which all slices in the allowed NSSAI are available in all cells may be delivered to the UE based on UE mobility information the network obtains from the UE. For example, if the UE is moving in a particular direction at a certain speed, the network may be able to detect the UE's movement, and using the NWDAF, the network may be able to predict the probability of the UE changing its TA / RA in a geographical region where the UE may be headed. This may trigger the network to send a registration update, a UE configuration update, or simply a NAS message, which may include a list of TA / RAs for which the allowed NSSAI is available in all cells.

[0188] Solution based on alternative NSSAI provisioning in the UE The example solution shown in Figures 5A and 5B relies on the network to detect that the UE has requested to register on a slice that is not available in the same frequency band. The network (AMF) then determines which slice should be prioritized and included in the authorized NSSAI because the UE may have immediate access to the slice received as the authorized NSSAI with the current OFB. Also, although the UE may be authorized to access the network slice, slices with lower priority may not be included in the authorized NSSAI because the UE may only access certain OFBs at a time. Furthermore, the AMF provides one or more alternative NSSAIs to the UE, if requested, as a way to indicate to the UE which other NSSAIs are authorized. The UE can then determine to request a different NSSAI if it determines that the S-NSSAI provided by the network in the NSSAI is not the highest priority.

[0189] 5A and 5B illustrate providing an alternative slice and corresponding frequency band to a UE. In step 0-A of FIG. 5A, the UE may have a configured NSSAI for a PLMN and an allowed NSSAI for the PLMN. The UE can then request registration targeting a specific slice within the NSSAI.

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

[0191] In step 1, the UE sends a registration request to the network (AMF) via the RAN. The UE registration request may provide the network in the AS layer and NAS layer with a requested NSSAI, including an S-NSSAI corresponding to the slice to which the UE wants to register.

[0192] The requested NSSAI may be one or more S-NSSAIs from the authorized NSSAIs for the access type for which the requested NSSAI is being sent, or a subset thereof, plus any NSSAIs not yet authorized within the authorized NSSAIs for the access type.

[0193] The registration request may further indicate to the AMF the capabilities of the UE, including an indication of which operating frequency bands the UE can operate in and whether the UE can operate in two or more frequency bands simultaneously.

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

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

[0196] The call flow in Figure 5A continues in Figure 5B. Steps 4 to 7 in Figures 5A and 5B are similar to steps 4 to 7 in Figure 4.

[0197] In step 8 of Figure 5B, the AMF may evaluate the registration request. The AMF may find that the UE is attempting to register to a network slice with a different OFB. Therefore, the AMF may not be able to redirect the UE to a frequency that serves all S-NSSAIs in the NSSAI.

[0198] The network may be able to serve connections in diverse frequency bands that direct the UE to different network slices, but may only allow some of the S-NSSAIs within the allowed NSSAIs.

[0199] Therefore, the AMF may be able to select an S-NSSAI and corresponding operating frequency band of a higher priority network slice from the requested NSSAI and return it to the UE as an allowed NSSAI. In addition, the AMF may send an alternative allowed NSSAI containing other combinations of S-NSSAIs that would be allowed if requested by the UE. The presence of an alternative allowed NSSAI is an indication to the UE that the network did not include all S-NSSAIs from the requested NSSAI in the allowed NSSAI because the UE cannot allow simultaneous connection to all of the S-NSSAIs in the requested NSSAI, and the network determines whether the S-NSSAIs in the requested NSSAI should be prioritized. The AMF may also provide an indication of the reason why an S-NSSAI from the requested NSSAI was not present in the allowed NSSAI (e.g., because some S-NSSAIs cannot be accessed simultaneously because only some S-NSSAIs are available only in mutually exclusive frequencies). The allowed S-NSSAI and the alternative allowed NSSAI may further indicate the operating frequency band of the (each) S-NSSAI.

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

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

[0202] In step 11, the UE may choose to send a registration update request using the allowed NSSAI or with a new requested NSSAI formed based on the information provided in the registration accept message of step 10 (e.g., an alternative NSSAI).

[0203] URSP Rules Extension As discussed, the UE may receive the allowed NSSAIs and OFBs for each S-NSSAI. Alternatively, or additionally, the URSP rules may be extended to guide the UE toward the appropriate S-NSSAI / frequency band combination. The registration accept message also provides the RAN node with several important pieces of information, such as the RFSP index, RAT restrictions, prohibited areas, service area restrictions, core network type restrictions, and closed access group information. The RFSP index and corresponding frequency spectrum information enable the RAN to manage resources appropriate for the UE. The RAN node also provisions the UE with operating frequency band information upon receiving the RFSP index.

[0204] When a UE attempts to connect to a slice in a network, different network slices may only be accessible via specific OFBs. Therefore, the UE must ensure that it uses the correct frequency band to connect to the network slice. In addition, the UE may need to be camped on an appropriate PLMN, for which frequency bands and corresponding slices accessible through those bands are configured to allow the UE to have access. Therefore, the UE route selection policy may be extended to indicate the relationship between the PLMN on which the UE is camped, the slices the UE can access, and the operating frequency bands the UE needs to use to reach the network slice.

[0205] This information may be configured in the URSP rule. Thus, the Route Selection Descriptor (RSD) portion of the URSP rule presented in Appendix Table 4 may be extended by including the operating frequency band and PLMN information shown in Appendix Table 7. In particular, Table 4 is updated with two new RSD information elements, PLMN ID and OFB. Alternatively, the information may be included as part of the route selection verification criteria so that the UE will not attempt to establish a route unless it is camped within the indicated PLMN and on the indicated frequency.

[0206] Having the PLMN ID and OFB information along with the network slice information forms the relationship between these three components of the RSD. Having the PLMN ID and operating frequency band in the route selection component can ensure that the UE moves to the desired PLMN / frequency band combination. Having the PLMN ID and OFB in the route selection verification criteria can be used to configure the UE to only attempt to establish a route if the UE is already camped in the PLMN and using the frequency band.

[0207] Frequency Band Redirection Using RRC Reconfiguration When a UE attempts to register on a set of slices, the network (AMF) may detect that the UE is attempting to register on a slice that cannot be used on the same frequency. Therefore, the AMF cannot redirect the UE to a single frequency that works for all of the S-NSSAIs within the NSSAI. In other words, there is no single RFSP index that can be used to access all of the S-NSSAIs. In this solution, the AMF considers a UE registered on all of the required S-NSSAIs, provides multiple RFSP indexes to the RAN, and tells the RAN which S-NSSAIs can be used with each RFSP index. The UE and RAN nodes then use RRC messaging to coordinate movement between frequency bands depending on which S-NSSAI needs to be accessed.

[0208] 6A and 6B illustrate frequency band redirection using RRC messaging. In step 0-A of FIG. 6A, the UE may have a configured NSSAI for a PLMN and an allowed NSSAI for the PLMN. Thus, the UE can request registration targeting a specific slice within the NSSAI.

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

[0210] In step 1, the UE sends a registration request to the network (AMF) via the RAN. The UE registration request may provide the network at the access stratum (AS) layer and the NAS layer with a requested NSSAI, including an S-NSSAI corresponding to the slice to which the UE wants to register.

[0211] The requested NSSAI may be one or more S-NSSAIs from the authorized NSSAIs for the access type for which the requested NSSAI is being sent, or a subset thereof, plus any NSSAIs not yet authorized within the authorized NSSAIs for the access type.

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

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

[0214] Steps 4 to 7 in FIG. 6A are similar to steps 4 to 7 in FIG.

[0215] In step 8, the AMF may evaluate the registration request. The AMF may find that the UE is attempting to register to 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., extract the RFSP index).

[0216] The AMF response to the RAN node can be extended to include multiple RFSP indices and the S-NSSAI within the NSSAI that will function with each index.

[0217] The call flow of Figure 6A continues in Figure 6B. In step 9 of Figure 6B, the AMF provides the RAN with multiple RFSP indices and an S-NSSAI that can be accessed using each RFSP index.

[0218] In addition, the AMF may provide the access stratum connection NSSAI inclusion mode parameter to the UE via the RAN in the registration accept message to indicate whether and when the UE should include NSSAI information in the RRC connection establishment.

[0219] In step 10, the RAN node forwards a registration accept message. To control idle mode camping, the registration accept message may include multiple sets of UE-specific cell reselection priorities in an RRC message to the UE. Each set of priorities is associated with one or more S-NSSAIs.

[0220] The message may indicate that the S-NSSAI within the allowed NSSAI is accessible in the frequency band that the UE is currently using.

[0221] The message may indicate that the S-NSSAI within the allowed NSSAI is not accessible in the frequency band that the UE is currently using.

[0222] In step 11, the UE sends an RRC message to the RAN node to indicate that it wishes to access an S-NSSAI that is not accessible in the frequency band that the UE is currently using.

[0223] In step 12, the RAN node responds with an RRC message instructing the UE with an OFB change command to switch to a frequency that the UE can use to access the S-NSSAI.

[0224] Handling DL traffic in a second network slice with an ongoing session in a first network slice In some of the solutions described herein, the UE is permitted to register with slices 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 UE's network in a slice (S-NSSAI) accessible only via frequency band #2. The network may address this scenario by sending a NAS notification to the UE, including the OFB to which the UE should switch to receive DL data. Alternatively, the NAS notification may indicate the S-NSSAI or PDU session ID for which DL data is available, and the UE may derive the associated OFB based on previously configured information. How the UE is configured with this information is described with reference to FIG. 4.

[0225] 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, and the allowed PDU sessions may be reactivated in the frequency band according to the UE policy and whether the S-NSSAI of these PDU sessions is within the allowed NSSAI of the 3GPP access.

[0226] As described herein, before a UE connects to a different frequency band, the UE may send an RRC message to a RAN node to indicate that the UE desires to access an S-NSSAI that is not accessible in the currently used frequency band. The RAN node may respond with an RRC message instructing the UE with an OFB change command to switch to a frequency that the UE can use to access the S-NSSAI.

[0227] Limit concurrent network slice access during registration A UE is configured with one or more configured NSSAIs, where one of the configured NSSAIs may be a default NSSAI. For each S-NSSAI in the configured NSSAI, the configuration may include a simultaneous 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 can be used with any network slice, with any other network slice, only with network slices having the same SST value, but not with network slices having the same SST value, only with network slices having the same SD value, but not with network slices having the same SD value, and / or only with network slices in the same network slice group (NSG).

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

[0229] When a UE registers with a network, it may indicate to the network whether it supports (e.g., understands) the SSAC indicator using an SSAC support indicator (SSI). The network may use the SSI to determine whether SSAC information should be included in the configured NSSAI.

[0230] Figure 11 illustrates how a UE may indicate support for SSAC and how the network may deliver the SSAC indicator to the UE, focusing on an extension of the UE registration procedure described in TS 23.502.

[0231] In step 0-A, as described with reference to FIG. 11, the OAM system may be used to configure network functions (NFs), such as the AMF, UDM / UDR, and PCF, with the SSAC indicator for each S-NSSAI. The OAM may configure the SSAC indicator for each S-NSSAI in the UE subscription that includes the subscribed NSSAI, and the PCF may be configured or updated with a UE policy that may include the SSAC indicator for each S-NSSAI, or the AMF may be configured or receive the SSAC indicator for the S-NSSAI from the UDM or PCF. Furthermore, the SSAC indicator may be provisioned per S-NSSAI per UE. For example, per-UE configuration may be desirable in a scenario where it is desirable to restrict only some UEs from accessing a slice and not other UEs.

[0232] In step 0-B, as described with reference to FIG. 11, the UE may be configured with one or more configured NSSAIs, and each S-NSSAI within each configured NSSAI may include an SSAC indicator.

[0233] 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 a default configured NSSAI indication. The UE includes a default configured NSSAI indication if the UE is using a default configured NSSAI as defined in TS 23.501. The UE may indicate that it supports an SSAC indicator using an SSAI in the registration message. The SSI may be a single-bit indication, or the UE may indicate its support by including a configured SSAC indicator for each S-NSSAI in the requested NSSAI.

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

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

[0236] Step 4 is similar to steps 8 to 19 in Figure 4.2.2.2.2-1 of TS 23.502.

[0237] In step 5, the AMF may send a registration accept message to the UE via the RAN. In the registration accept message, the AMF may include the allowed NSSAIs, the allowed NSSAI mappings, the configured NSSAIs for the serving PLMN, the configured NSSAI mappings, and the rejected S-NSSAIs. For each S-NSSAI of the configured NSSAIs for the serving PLMN, the AMF may include an SSAC indicator. Optionally, the SSAC indicator may also be included in the allowed NSSAIs, the allowed NSSAI mappings, and the configured NSSAI mappings for each S-NSSAI. The absence of the SSAC indicator may serve as a sign that there are no restrictions associated with the S-NSSAI regarding simultaneous use with other network slices. Each rejected S-NSSAI may be associated with a cause value. The AMF may set the cause value to indicate to the UE that the S-NSSAI is rejected because the SSAC configuration associated with the S-NSSAI does not match one of the S-NSSAIs in the allowed S-NSSAIs. If the UE does not indicate 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 did not indicate support for SSAC, the cause code associated with each rejected S-NSSAI may be a general cause code, such as cause #62 - no network slice available.

[0238] As described in FIG. 11, the AMF may inform the UE in a registration accept message that the S-NSSAI (S-NSSAI#1) has been rejected because the SSAC of S-NSSAI#1 is incompatible with the SSAC of a second S-NSSAI (S-NSSAI#2) within the allowed NSSAIs. When this occurs, the UE may subsequently determine that it will register to S-NSSAI#1 rather than S-NSSAI#2. In such a scenario, the UE may subsequently send a second registration request message that includes S-NSSAI#1 within the requested NSSAIs and does not include S-NSSAI#2 within the requested NSSAIs. The subsequent registration accept message may include S-NSSAI#2 within the allowed NSSAIs and may not include S-NSSAI#1 within the allowed NSSAIs. This procedure is depicted in FIG. 12.

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

[0240] In step 2, the AMF may apply SSAC-related policies to handle the UE's slice access request. The AMF identifies that S-NSSAI#1 and S-NSSAI#2 cannot both be accessed by the UE. Therefore, the AMF selects S-NSSAI#2 of the allowed NSSAIs and rejects S-NSSAI#1.

[0241] In step 3, the AMF sends a registration accept message to the UE with an allowed NSSAI having S-NSSAI#2 and a rejected NSSAI having S-NSSAI#1, and a rejection reason code indicating simultaneous access incompatibility of S-NSSAI#1 with S-NSSAI#2.

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

[0243] In step 5a, the UE sends a registration update request in a subsequent request with S-NSSAI#1 in its requested NSSAI.

[0244] In step 5b, alternatively, the UE may indicate a preference by including S-NSSAI#1 within the requested NSSAI in the registration complete message returned to the AMF after receiving the registration accept message.

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

[0246] Implementing both SSAP and UE-OFB policies during the registration procedure The AMF may implement SSAP to check whether two or more slices are simultaneously accessible by the UE. However, the UE-OFB policy may also act as a constraint on the UE's simultaneous access of two or more slices. The UE-OFB policy ensures that all requested slices are available in a common operating band. In addition, the common frequency band must be the UE's current operating frequency band. The AMF may implement SSAP together with the UE-OFB policy, as illustrated in the example of Figure 20.

[0247] Steps 0-2 in FIG. 20 involve the same steps as steps 0 to 2 in FIG.

[0248] In step 3, the AMF may check two different policies: First, the AMF checks the UE-OFB policy to see if all slices in the requested NSSAI are available in the UE's current OFB; Second, the AMF performs SSAP to see if two or more slices are simultaneously accessible based on the SSAP.

[0249] In step 4a, if all slices are accessible via the UE's current OFB, the AMF checks whether two or more slices are simultaneously accessible based on SSAPs. If two or more slices are not simultaneously accessible based on SSAPs, the AMF selects one S-NSSAI from the allowed NSSAIs, combines the other non-compatible S-NSSAIs into a set of rejected S-NSSAIs, and includes a cause code indicating the reason for rejecting the rejected NSSAI in the registration accept message. The registration accept message is then sent to the UE.

[0250] In step 4b, if one or more requested slices are not available in the UE's current OFB based on the UE-OFB policy, the procedure described in Figure 17 may be applicable, and the AMF instructs the UE to move to an operating band where all slices are accessible.

[0251] If all the requested S-NSSAIs are not available in the UE's current OFB, the AMF does not check the SSAPs for the requested NSSAIs. In other words, if one of the S-NSSAIs in the requested NSSAIs is not available in the UE's current OFB, the UE cannot simultaneously access all slices in its operating band.

[0252] However, if the UE is successfully handed over to a different OFB where all slices are available, the AMF may apply the SSAP before determining the registration accept message.

[0253] When the UE is handed over to a new OFB where all slices are available, the AMF applies 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 in the allowed NSSAI. For example, if the SSAP identifies that the requested NSSAI has eight slices, all of which are available in the UE's current OFB, and two of them were not simultaneously accessible, the allowed NSSAI will have seven S-NSSAIs, which may be delivered to the UE via the registration accept message, and one S-NSSAI delivered to the rejected NSSAI.

[0254] Alternatively, the AMF may be configured in the UE-OFB policy to not allow slices that are not available in the UE's current OFB without instructing the UE to change the OFB. In other words, the AMF may send the slices available in the UE's current OFB in the allowed NSSAI and include other slices that are not available in the UE's current OFB in the 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 the SSAP. If no SSAP-incompatible slice is found, it is included in the list of rejected slices, and the remaining slices may be returned to the UE as allowed NSSAIs in the registration accept message. Within this alternative, the UE-OFB policy may be configured to instruct the UE to change the OFB where most of the slices are available. Once the UE changes the OFB and finds accessible slices, SSAPs may be implemented for those slices.

[0255] Alternatively, the AMF may apply the SSAP and UE-OFB policies in the reverse order, i.e., the SSAP is applied 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 applies 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 instructs the UE to handover its registration request to an OFB where all slices are accessible.

[0256] However, if the SSAP policy finds that one or more of the slices cannot be authorized in the first location, the inaccessible slices are considered rejected slices, and the rest of the slices pass through the UE-OFB policy. If the UE-OFB policy identifies that one of the slices cannot be accessed through the UE's current OFB, the procedure described in Figure 17 may be applicable, and the AMF instructs the UE to handover its registration request to an OFB where all slices are accessible. Otherwise, the S-NSSAIs of these slices are placed in the authorized NSSAIs and returned to the UE as a registration accept message. Note that in return for checking the UE-OFB policy, slices rejected due to SSAP are not included. Again, if the AMF directs the UE to a different OFB, the SSAP application may be repeated. In other words, the AMF may check the SSAP policy again before determining and sending the registration accept message to the UE.

[0257] Steps 5 to 7 are the same as steps 5 to 7 in Figure 17 and are only applied if step 4b is true. In this case, the UE-OFB policy applies, so the AMF directs the UE handover to another OFB where all slices are available.

[0258] Limiting simultaneous network slice access during PDU session establishment Restrictions on the simultaneous use of network slices may be applied during PDU session establishment, i.e., a UE may be allowed to register with a network slice but may be restricted to only having simultaneous PDU sessions in the restricted slice.

[0259] Restrictions on concurrent access of slices can be applied during the PDU session establishment process by implementing the concurrent slice validation criteria field in the route selection validation criteria of the URSP rule. The extended URSP rule with the concurrent slice validation criteria field is shown in Table 7 in the appendix to this specification.

[0260] Figure 13 shows an alternative that describes the case where the UE attempts to establish a PDU session in a slice from the allowed list of S-NSSAI, but is unable to establish the PDU session because the core network restricts simultaneous access to a particular slice.

[0261] In step 1, a PDU session is previously established in a slice (Slice A).

[0262] In step 2, the simultaneous slice access policy (SSAP) is distributed to the applicable AMF.

[0263] In step 3, the UE may attempt to establish a second PDU session establishment request for another slice (slice B) in the network. This request may include an SSI that 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 understands the SSAC rejection cause code and configuration information.

[0264] In step 4, the AMF identifies that slice B is not simultaneously accessible to slice A for the UE.

[0265] In step 5, the AMF shall reject the PDU session establishment request if the PDU session establishment request is for an S-NSSAI that cannot be used simultaneously with an S-NSSAI with which the UE already has an established PDU session. If the UE has indicated the ability to understand SSAC information, the AMF may reject the request with a cause code detailing that slice B is not accessible together with slice A. The UE may receive this cause code and, depending on its urgency or requirements, may terminate the session with slice A and retry the PDU session establishment request with slice B.

[0266] Alternatively, if a session is ongoing for slice A, the AMF may indicate to the UE in the rejection cause code that the UE may attempt a PDU session establishment request as soon as the session with slice A is terminated.

[0267] Alternatively, if an ongoing PDU session with slice A has expired, the AMF may terminate the session and accept the PDU session establishment request for slice B.

[0268] Another alternative is that if the UE has some information about the UE's slice priority (e.g., an emergency situation) and slice B is of higher priority than slice A, the UE may terminate the PDU session with slice A and send a PDU session establishment request for slice B.

[0269] Handling of simultaneous slice access restrictions by UE-OFB policy and SSAP during PDU session establishment procedure The restriction on simultaneous access of two or more slices may also be based on the OFB in which the slices are available. This restriction may be applied during the PDU session establishment procedure. In this case, it is assumed that slices available in different frequency bands are authorized and delivered to the authorized NSSAI during the general UE registration or registration update procedure. However, the UE-OFB policy may also be applied during 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 an existing PDU session. In other words, if two PDU sessions are established for two different network slices in the network, both must be available under the same OFB, and the OFB must be the UE's current OFB. This procedure also assumes that the UE has already submitted its supported OFB to the network during the general registration procedure. In some cases, the UE-OFB policy may also be applied with the SSAP, as illustrated in the example of Figure 21.

[0270] In step 1 of Figure 21, the SSAP and UE-OFB policies are delivered or configured in the AMF.

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

[0272] In step 3, the UE may initiate a new PDU session in a second network slice (slice B) available in a different OFB, where the AMF may apply both the UE-OFB policy and the SSAP.

[0273] The AMF may first apply the UE-OFB policy and then the SSAP policy, or vice versa. If a second PDU session is requested for a slice that is not available in the UE's current OFB, 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 in which all slices may be available for the PDU session (e.g., 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 was rejected because the slice was not available in the UE's current OFB. In addition, the cause code may transmit information about an OFB in which both slices are available and a PDU session can be established in both slices simultaneously. Alternatively, the cause code may transmit information about which OFB can be used to establish the requested PDU session. If the AMF did not find an OFB in which two slices are available, the cause code only indicates the reason for the rejection, stating a violation of the UE-OFB policy. In this case, SSAP policy enforcement has two options:

[0274] In option 1, the AMF may apply an SSAP policy to ensure the compatibility of the two slices. If they do not match, the incompatibility information due to the SSAP may be sent to the UE via a cause code in the PDU session request reject message. Note that this rejection information may also help the UE to later decide whether to stay in the current allowed NSSAI or move to a completely different OFB.

[0275] If both the UE-OFB policy and SSAP checks are unsuccessful, it is ensured that the UE cannot access both slices in any of the OFBs, and thus the AMF may send a rejection message with an indicating cause code.

[0276] In option 2, the AMF cannot apply the SSAP policy and only sends a rejection message based on the UE-OFB policy.

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

[0278] 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 are successful, 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 with a cause code to the PDU session. The cause code indicates the failure of a slice in the UE's current OFB and may recommend an OFB where both slices (Slice A and Slice B) may be accessible, or an OFB where slice B is accessible. If the rejection is due to an SSAP violation, the cause code indicates that the slices (Slice A and Slice B) are not suitable for simultaneous access.

[0279] In step 5-A, if the UE obtains a PDU session rejection message with a cause code based on the UE-OFB policy, the UE may choose to keep the ongoing PDU session in slice A and refrain from the PDU session establishment request for slice B. In other words, the UE may ignore the AMF recommendation to use another OFB that may be available for both slices. If the rejection is due to a violation of both the UE-OFB policy and the SSAP, the UE may not change the OFB, refrain from the PDU session establishment request, and simply continue the ongoing PDU session in slice A.

[0280] In step 5-B, if the PDU session is rejected with a cause code indicating a change of OFB, the UE may choose to request a new allowed NSSAI in a 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 teardown of the ongoing PDU session in slice A. Once the PDU session teardown is complete, the UE will need to send a registration update request toward the OFB recommended by the AMF in the previous step. If the registration is successful via the new OFB, the UE may re-establish the previously torn-down PDU session and continue the PDU session. The UE may also request a new PDU session establishment request in slice B using the new OFB. Alternatively, when the UE changes the OFB, the existing session may simply be handed over to the new OFB.

[0281] Alternatively, since the UE has information about which slices are available in which OFB (cell) based on the OFB in which the UE is currently located, the UE may simply initiate the PDU session establishment process only on the slices available in the UE's current OFB. In this way, there is no obstacle to establishing a PDU session and waiting for the AMF to determine whether the PDU session can be established based on the UE-OFB policy. Once the PDU session is established, the AMF may apply only the SSAP to implement the adaptation of two or more slices for that UE.

[0282] RAN-assisted UE handover based on slice availability Each S-NSSAI may be associated with its available OFB. This information (e.g., the S-NSSAI and the corresponding OFB) is conveyed to the RAN node during a successful registration procedure. When a UE requests to establish a PDU session with a slice in the network, the UE may include desired slice information in an 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 UE's current OFB, the RAN may allow the PDU session establishment process to proceed; otherwise, the RAN may instruct the UE to change the OFB before continuing the PDU session establishment procedure. This process is illustrated in Figure 22.

[0283] In step 0, the AMF may retrieve access and mobility subscription data in which S-NSSAI to OFB related information exists. This information may be conveyed to the RAN during the UE registration procedure.

[0284] 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 in the RRC message the S-NSSAI of the requested slice for which the UE wants to establish a PDU session. Note that this S-NSSAI information is added to the slice information sent to the AMF.

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

[0286] First, V2X operating bands for V2X OFB, V2X-preferred OFB, simultaneous Uu and PC5-based operation.

[0287] Second, the OFB for in-band carrier aggregation operation. The UE's preferred OFB for in-band carrier aggregation operation.

[0288] Third, an OFB for intra-band carrier aggregation operation, the UE's preferred OFB for intra-band carrier aggregation operation.

[0289] Fourth, OFB for dual connectivity operation, the UE's preferred OFB for dual connectivity operation.

[0290] Fifth, OFB of UL MIMO, preferred OFB of UL MIMO UE.

[0291] Sixth, S-NSSAI preference in priority order: The UE may indicate which S-NSSAI is essential for the current OFB to assist the AMF in accepting or rejecting the registration request.

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

[0293] Based on the identification, the RAN does one of the following:

[0294] Case 1: In step 3, the RAN identifies that the requested slice is accessible in the UE's current OFB, and therefore forwards the PDU session establishment request towards the AMF.

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

[0296] In step 5, the AMF sends an NAS message to the RAN, which indicates an N2 PDU session request. AN-specific resources are set up between the UE and the RAN, which indicates acceptance of the PDU session establishment request. The RAN then returns an N2 PDU session response to the AMF.

[0297] Case 2: In step 3, the RAN identifies that the requested slice is not accessible in the UE's current OFB, and in addition, the RAN identifies an OFB in which the requested slice is available and returns a NAS message to the UE to suggest an OFB in which the slice may be accessible.

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

[0299] In step 5, the PDU session establishment request is accepted by the network and the UE may begin transmitting PDUs toward the desired slice in the network.

[0300] Handling of PDU sessions when the UE moves to a new cell 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 assist the UE in switching OFBs, and the UE can continue existing PDU sessions. If the network cannot support all slices in the OFB, the RAN may notify the UE with a cause code. Figure 23 describes the procedure.

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

[0302] In step 1, the UE may move to a new cell, continue with any ongoing PDU sessions, and send a message to the RAN indicating that it wishes to leave a cell that has a PDU session with the network.

[0303] In step 2, the RAN identifies slices and OFBs for which slices with PDU sessions may be available, for which the UE can continue its existing PDU session in the slice. The UE's current RAN node may coordinate with other RAN nodes about the UE's desired OFBs and the slices that these OFBs support, either via the core network or directly between RAN nodes.

[0304] 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 returns a positive response indicating such support for all slices in the new OFB. The RAN node can then facilitate a smooth OFB handover for the UE and continue the PDU session.

[0305] In step 3-B, the RAN node may identify that the new cell does not support all UE slices and may identify other cells within the UE's reach where more slices may be supported. In this case, the RAN may propose to the UE to continue the PDU session in an OFB where a larger number of slices are supported. In addition, it may indicate to the UE an S-NSSAI that is not supported in the proposed OFB. The RAN may then facilitate a graceful OFB handover of the UE to a supported slice and continue the PDU session.

[0306] 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 other cells within the UE's range cannot support those slices. In this case, the RAN returns a response to the UE with a cause code stating that the OFB cannot support the requested slices. In this case, the RAN cannot continue the PDU session, and therefore all PDU sessions may be terminated.

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

[0308] In step 4, the UE switches to the new OFB. When the UE switches to the new OFB, the core network is notified about this. If there are any updates in the policy, the PCF sends the policy to the AMF and RAN nodes before the AMF fully accepts the transition to the new OFB. After the handover is successful, the UE continues the PDU session.

[0309] Configure slice location restriction information in NSSAI When the UE is in a particular PLMN in a particular country, it may be that a particular network slice is not available to the UE. Note that the PLMN ID includes the mobile country code (MCC), and thus any information configured in the UE on a PLMN ID basis is already configured per country.

[0310] During registration or configuration update, the network may send the UE a "configured NSSAI mapping" for the serving PLMN. When this information is sent to the UE, each S-NSSAI is encoded as described with reference to FIG. 9.

[0311] It should be noted that when the coding shown in Figure 9 and Table 8 in the Appendix hereto is used, at least the mapped SST is provided to the UE.

[0312] The encoding of the SST and SD fields is as described in section 28.4.2 of 3GPP TS 23.003, Numbering, Addressing and Identification. As described in TS 23.003, the S-NSSAI may contain both the SST and SD fields (in which case the S-NSSAI length is a total of 32 bits), or the S-NSSAI may contain only the SST field (in which case the S-NSSAI length is only 8 bits).

[0313] The SST field can have standardized and non-standardized values: values ​​0 to 127 belong to the standardized SST range, which is defined in 3GPP TS 23.501; values ​​128 to 255 belong to the operator-specific range.

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

[0315] TS 23.501, section 5.15.2.2 explains that four SST values ​​are standardized to characterize network slices (eMBB, URLLC, MIoT, and V2X).

[0316] To cover cases where the network needs to convey to the UE that a particular PLMN (e.g., not available for a particular PLMN ID) is not available in a particular country, a new SST value can be standardized to represent the NULL or unsupported case. When this value is provided in the SST field, it indicates to the UE that the S-NSSAI associated with the S-NSSAI in the HPLMN map does not map and that the UE is not restricted from accessing the services of the S-NSSAI in the HPLMN when attached to the PLMN. Table 12 in the appendix to this specification shows the standardized SST values ​​from TS 23.501. This table has been updated to show how the SST value can be modified to indicate to the UE that no SST value or slice maps to the S-NSSAI in the PLMN.

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

[0318] Another alternative way to convey to the UE that there is no SNSSAI mapped in the PLMN is via the S-NSSAI information element. The S-NSSAI IE may contain only the SST or the SST and SD in the mapped configured NSSAI. The UE may interpret the indicated SST or the SST and SD as meaning that it is an HPLMN configured NSSAI with no mapping in the VPLMN.

[0319] Another alternative approach to indicating to the UE that there is no S-NSSAI mapped in the PLMN is to define a new encoding of the "S-NSSAI Content Length" field that indicates the status to the UE. For example, an encoding of 00001001 may indicate that the information element carries only the mapped HPLM SST value, an encoding of 00001010 may indicate that the information element carries only the mapped HPLMN SD value, and an encoding of 00001011 may indicate that the information element carries the mapped HPLM SST value and the mapped HPLMN SD value. The absence of SST and SD values ​​for the VPLMN would be an indication to the UE that the HPLMN S-NSSAI has no mapping in the PLMN.

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

[0321] When a UE is roaming, a particular slice (e.g., S-NSSAI) may not be available in the VPLMN or in a particular region within the VPLMN. In this case, the region where the S-NSSAI is available (or not) may be indicated to the UE as part of the "Configured NSSAI Mapping" information element and coded as described herein.

[0322] Table 13 in the Appendix hereto shows how the S-NSSAI information element encoding can be updated to convey the above information. When the UE registers with the network, the UE may 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 encodings and rejection cause codes.

[0323] When a UE attempts to access an S-NSSAI from a region where access to the S-NSSAI is restricted in the PLMN, the network may reject the S-NSSAI and provide a cause code with the rejected S-NSSAI, indicating that the S-NSSAI is rejected because access is not permitted at the UE's current location. The cause code may further indicate to the UE where access is permitted or not permitted. Furthermore, 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 a new permitted NSSAI. The permitted NSSAI will differ from the permitted NSSAI previously sent to the UE because the new permitted NSSAI will lack the currently restricted S-NSSAI due to the UE's current location. Figure 14 describes the process by which a UE is denied access based on a geographic region.

[0324] In step 1, the UE initiates a UE registration procedure with an 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 a default configured NSSAI indication, among other information. One of the S-NSSAIs in the requested NSSAI may be restricted in the geographic region, and the UE may not recognize this restriction. In addition, the UE may or may not include an indicator indicating that it supports geographical S-NSSAI restriction.

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

[0326] In step 3, the AMF may send a registration accept message to the UE with the allowed NSSAI and the rejected S-NSSAI with a rejection cause code, which may indicate that the S-NSSAI mapping was unavailable (NULL) in the VPLMN in the UE's current region.

[0327] Configuring slice location restriction information via access and mobility subscriptions A service area restriction consists of either an authorized area or an unauthorized area. In particular, it may include a limited tracking area, or alternatively, it may include all tracking areas (TAs) in the PLMN. A UE may be restricted to access one or more network slices based on the service area. To address scenarios where a particular slice may be available in an authorized area but not in an unauthorized area, a new field indicating the availability of a network slice in a service area, such as a field called slice availability area restriction, may be used. This field specifies the availability or unavailability of each S-NSSAI of a configured NSSAI in that 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 TS 23.502 (UE subscription data types). During the UE registration process, slice availability area restriction information may be sent to the AMF along with the UE subscription data and applied there.

[0328] Alternatively, the slice availability region restriction information may be delivered to the UE along with the registration accept message and evaluated at the UE.

[0329] Yet another alternative is to pre-configure the UE with slice region availability restriction information for each S-NSSAI when configuring the configured NSSAI in the UE.

[0330] Figure 15 describes the process by which slice availability region restriction information is conveyed to the AMF in the network, or alternatively, to the UE.

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

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

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

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

[0335] In step 4-a, the AMF sends a registration accept message to the UE. In the registration accept message, the AMF includes the allowed NSSAIs, the mapping of the allowed NSSAIs, the configured NSSAIs, the mapping of the configured NSSAIs, and the rejected NSSAIs. The rejected NSSAIs include the rejected S-NSSAIs at that location and the slice availability region restrictions associated with each S-NSSAI, so that the UE knows that the slice has been rejected for its current location, and the UE can use this information to consider when attempting to register with the slice again.

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

[0337] In step 5, if the UE receives slice availability region restriction information from the network together with the registration accept message (step 4-b), when application traffic is generated in the UE, the slice availability region restriction information can be taken into account when the URSP rule is evaluated. In other words, this information can be used to bypass the restricted slice and select a lower priority route in the network when the RSD is evaluated.

[0338] Using slice location restriction information during PLMN selection The procedure described with reference to Figure 15 illustrates how the network can configure a UE with information about which PLMN slices (e.g., S-NSSAI) are available and about the regions within the PLMN where the slices are available. This information can also be configured in the UE, for example, in the UE's SIM card or via an eSIM protocol. Once the UE is aware of the availability of slices within a PLMN, the UE can take this information into account during PLMN selection and PLMN reselection. PLMN selection and PLMN reselection are specified in TS 23.122.

[0339] PLMN selection at switch-on or recovery from lack of coverage in automatic network selection mode is specified in Section 4.4.3.1.1 of TS 23.122. This procedure may be extended to consider the availability of network slices (S-NSSAIs) in each PLMN when determining whether to attempt to register with a PLMN. For example, if an S-NSSAI is not available in a PLMN at the UE's current location, the PLMN may be considered a lower priority, meaning that the UE will first attempt to register with PLMNs for which all or more S-NSSAIs are available. In addition to the PLMN ID and the power level of the strongest cell on each frequency, the AS may also be extended to provide a tracking area (TA) code and / or cell ID to inform the NAS of the UE's location within the PLMN and enable slice-aware PLMN selection. The UE may only consider the availability of its configured NSSAI or an S-NSSAI that is part of the mapped configured NSSAI associated with the PLMN.

[0340] In addition to the PLMN ID and power level of the strongest cell for each frequency, the AS can be extended to provide the TA code, cell ID, and / or RAN area ID to inform the UE location within the PLMN via the NAS to enable slice-aware PLMN selection.

[0341] Additionally, two different network slices may be available in two different PLMNs, and S-NSSAI mappings for both S-NSSAIs may be available. In such a case, the UE may use a predefined slice priority to select a slice and thus may select the PLMN in which it is available.

[0342] PLMN selection at switch-on and recovery from lack of coverage in manual network selection mode are specified in section 4.4.3.1.2 of TS 23.122. This procedure can be extended to take into account the availability of network slices (S-NSSAI) in each PLMN when the UE determines which PLMNs are present. For example, when some S-NSSAIs are not available in the PLMN at the UE's current location, this information can be displayed to the user. For example, the display can indicate that services are limited, the display can indicate which services are available, the display can indicate which services are not available, etc. Additionally, the display can indicate why and where services are not available in the PLMN.

[0343] PLMN reselection in automatic network selection mode is specified in section 4.4.3.2.1 of TS 23.122. PLMN reselection may be extended to consider the availability of network slices (S-NSSAI) in each PLMN, as described herein in proposed extensions to the PLMN selection procedure. Furthermore, a UE may be permitted to trigger PLMN reselection when the UE evaluates the URSP rules and finds that it cannot establish a route for traffic because the desired S-NSSAI is not available at the UE's current location within the PLMN.

[0344] Figure 7 shows a GUI for a UE that coordinates with the RAN and core network to maintain the allowed NSSAIs and corresponding OFBs per S-NSSAI, alternative allowed NSSAIs and OFBs, extended URSP rules, and frequency band steering capabilities.

[0345] FIG. 16 shows a UE GUI including UE configuration to support simultaneous slice access restriction, support for slice access restriction due to service area including geographical region location information, and extended URSP rules to support simultaneous slice access validation criteria.

[0346] Example Environment The Third Generation Partnership Project (3GPP) develops technical standards for mobile communication network technologies, including radio access, core transport networks, and service capabilities, including work on coding, 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. 3GPP has begun standardization of the next generation of cellular technology, called New Radio (NR), also known as "5G." 3GPP NR standard development is expected to include the definition of Next Generation Radio Access Technologies (New RATs), which are expected to include new flexible radio access provisions below 6 GHz and new ultra-mobile broadband radio access provisions above 6 GHz. Flexible radio access is expected to consist of new, non-backward compatible radio access in new spectrum below 6 GHz, including different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with divergent requirements. Ultra Mobile Broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra mobile broadband access, for example, for indoor applications and hotspots. In particular, Ultra Mobile Broadband is expected to share a common design framework with sub-6 GHz Flexible Wireless Access, with centimeter wave and millimeter wave specific design optimizations.

[0347] 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 may include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high speed indoor broadband access, broadband access in the cloud, 50 Mbps or greater everywhere, ultra-low cost broadband access, mobile broadband in cars), critical communications, large-scale machine-type communications, network operations (e.g., network slicing, routing, migration and interaction, and energy conservation), vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and enhanced vehicle-to-everything (eV2X) communications, which may include any of the following: 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, wireless cloud-based office, first responder connectivity, ecall for automobiles, disaster warning, real-time gaming, multi-person video calling, autonomous driving, augmented reality, touch internet, and virtual reality, to name a few. All of these use cases and more are contemplated herein.

[0348] 8A illustrates one embodiment of an example communications system 100 in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be referred to generally or collectively as WTRUs 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and 102g may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, 102g is represented in Figures 1A-1E as a handheld wireless communication device, it should be understood that in the wide variety of use cases contemplated for 5G wireless communication, each WTRU may comprise or be embodied in any type of apparatus or device 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 smartphone, a laptop, a tablet, 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 or e-health device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane, etc.

[0349] The communications 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 communications networks, such as the core networks 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, the TRPs (transmission and reception points) 119a, 119b, and / or the RSUs (roadside units) 120a and 120b to facilitate access to one or more communications networks, such as the core networks 106 / 107 / 109, the Internet 110, the other networks 112, and / or the V2X server (or ProSe function and server) 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 networks 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 networks 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 networks 106 / 107 / 109, the Internet 110, and / or other networks 112, and / or the V2X server (or ProSe function and server) 113.By way of example, the base stations 114a, 114b may be a base transceiver station (BTS), a Node-B, an eNode-B, a Home Node-B, a Home eNode-B, a site controller, an access point (AP), a wireless router, etc. Although the base stations 114a, 114b are each shown as a single element, it will be understood that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

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

[0351] 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, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0352] 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 (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0353] The RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over the 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 radio access technology (RAT).

[0354] The WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g may communicate with one another over air interfaces 115d / 116d / 117d (not shown), 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 interfaces 115d / 116d / 117d may be established using any suitable radio access technology (RAT).

[0355] The communications 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, and so on. For example, the base station 114a of the RAN 103 / 104 / 105 and the RRHs 118a, 118b, TRPs 119a, 119b, and RSUs 120a, 120b of the RANs 103b / 104b / 105b, and the WTRUs 102c, 102d, 102e, 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS), Terrestrial Radio Access (UTRA), etc., which may establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively, using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+), which may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

[0357] In one embodiment, the base station 114a of the RAN 103 / 104 / 105 and the RRHs 118a, 118b, TRPs 119a, 119b, and / or RSUs 120a, 120b of the RAN 103b / 104b / 105b and the WTRUs 102c, 102d, 102e, 102f are configured to support a wireless LAN standard 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), GSM Evolution (Enhanced Data rates for Wireless technologies such as GSM Evolution (EDGE), GSM EDGE (GERAN), etc. may be implemented.

[0358] The base station 114c of FIG. 8A may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point and may utilize any suitable RAT for facilitating wireless connectivity in a local area, such as a business, home, vehicle, campus, etc. In an embodiment, the base station 114c and the WTRU 102e may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an 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 establish a picocell or femtocell utilizing a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.). As shown in FIG. 8A, 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.

[0359] The RANs 103 / 104 / 105 and RANs 103b / 104b / 105b may communicate with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, application, 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, prepaid calling, Internet connectivity, video streaming, etc., and / or perform high-level security functions such as user authentication.

[0360] 8A, it will be understood that the radio access networks (RANs) 103 / 104 / 105 and / or RANs 103b / 104b / 105b and / or core networks 106 / 107 / 109 may communicate directly or indirectly with other RANs employing the same radio access technology (RAT) as the RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, or a different RAT. For example, in addition to being connected to the RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, which may utilize E-UTRA radio technology, the core networks 106 / 107 / 109 may also communicate with another RAN (not shown) using GSM radio technology.

[0361] The core network 106 / 107 / 109 may also serve as a gateway for the wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, and 102e to access the public switched telephone network (PSTN) 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a public switched telephone network providing plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the transmission control protocol (TCP), user datagram protocol (UDP), and 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 network 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, or a different RAT.

[0362] Some or all of the wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and 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 over different wireless links. For example, the WTRU 102e shown in FIG. 8A may be configured to communicate with a base station 114a, which may employ a cellular-based wireless technology, and a base station 114c, which may employ an IEEE 802.11 wireless technology.

[0363] 8B is a block diagram of an example apparatus or device configured for wireless communication in accordance with embodiments illustrated herein, such as, for example, a WTRU 102. As shown in FIG. 8B, 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, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with an embodiment. Embodiments also contemplate that the base stations 114a and 114b, and / or the like, which may represent, but are not limited to, a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home Node-B, an evolved home Node-B (eNodeB), a home evolved Node-B (HeNB), a home evolved Node-B gateway, and a proxy node, may include some or all of the elements shown in FIG. 8B and described herein.

[0364] The processor 118 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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. While FIG. 8B depicts the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0365] The transmit / receive element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 115 / 116 / 117. For example, in one embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. In one embodiment, the transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0366] 8B 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.

[0367] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and 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 RATs, such as UTRA and IEEE 802.11.

[0368] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a Liquid Crystal Display (LCD) unit or an Organic Light-Emitting Diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. Furthermore, the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), 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, etc. In an 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 home computer (not shown).

[0369] 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 providing power to the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0370] The processor 118 may also be coupled to a 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 instead of 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 being received from two or more nearby base stations. It will be understood that the WTRU 102 may obtain location information by way of any suitable location-determination method while remaining consistent with an embodiment.

[0371] The processor 118 may further be coupled to other peripherals 138 and may include one or more software 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 an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a Universal Serial Bus (USB) port or other interconnection interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a Frequency Modulated (FM) radio unit, a digital music player, a media player, a video game player module, etc.

[0372] The wireless transmit / receive unit (WTRU) 102 may be embodied in other apparatus or devices, such as a sensor, a consumer electronics appliance, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, industrial equipment, a drone, or a vehicle such as a car, truck, train, or aircraft. The WTRU 102 may connect to other components, modules, or systems of such an apparatus or device via one or more interconnection interfaces, such as an interconnection interface that may include one of the peripherals 138.

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

[0374] As shown in FIG. 8C, Node-Bs 140a, 140b may communicate with RNC 142a. Additionally, Node-B 140c may communicate with RNC 142b. Node-Bs 140a, 140b, and 140c may communicate with their respective RNCs 142a, 142b via an Iub interface. RNCs 142a, 142b may communicate with each other via an Iur interface. Each of RNCs 142a, 142b may be configured to control its respective Node-B 140a, 140b, and 140c. Additionally, each of RNCs 142a, 142b may be configured to perform or support other functions such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0375] The core network 106 shown in Figure 8C 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 will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0376] The RNC 142a in the RAN 103 may be connected to an MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to an MGW 144. The MSC 146 and 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 landline communication devices.

[0377] The RNC 142a in the RAN 103 may also be connected to an SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to a GGSN 150. The SGSN 148 and 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.

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

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

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

[0381] Each of the eNode-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, etc. in the uplink and / or downlink. As shown in FIG. 8D, the eNode-Bs 160a, 160b, 160c may communicate with one another via an X2 interface.

[0382] The core network 107 shown in Figure 8D may include a mobility management entity (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the foregoing elements is depicted as part of the core network 107, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0383] A mobility management entity (MME) 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may function 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 initial attach of the wireless transit / receiving 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 and / or WCDMA.

[0384] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, 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 perform other functions such as anchoring the user plane during inter-eNode 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, etc.

[0385] The serving gateway 164 may be connected to a PDN gateway 166, which 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.

[0386] The core network 107 may facilitate communication 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 communication between the WTRUs 102a, 102b, 102c and traditional landline communication devices. For example, the core network 107 may include or communicate 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 other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0387] 8E is a system diagram of a radio access network (RAN) 105 and a core network 109, according to an 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 different functional entities of the WTRUs 102a, 102b, 102c, the RAN 105, and the core network 109 may be defined as reference points.

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

[0389] 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. Additionally, 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 that may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0390] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point that includes protocols for facilitating WTRU handovers and the 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 that may include protocols for facilitating mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0391] As shown in Figure 8E, 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, including protocols for facilitating data transfer and mobility management capabilities, for example. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, and accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of the core network 109, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator.

[0392] 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 transit / receiving networks (WTRUs) 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for supporting user authentication and 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 other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0393] 8E, it will be 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 and may include protocols for coordinating 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, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0394] The core network entities described herein and illustrated in Figures 1A, 1C, 1D, and 1E are identified by names given to those entities in certain existing Third Generation Partnership Project (3GPP) specifications, although it is understood that in the future, those entities and functions may be identified by other names and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP New Radio (NR) specifications. Thus, it is understood that the specific network entities and functions described and illustrated in Figures 1A, 1B, 1C, 1D, and 1E are provided by way of example only, and 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.

[0395] 8F is a block diagram of an exemplary computing system 90 in which one or more devices of the communications networks illustrated in FIGS. 1A, 1C, 1D, and 1E may be embodied, such as a particular node or functional entity within the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, or other networks 112. The computing system 90 may comprise a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, or wherever or by whatever means such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to function. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple 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, or the like. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communications network. The coprocessor 81 is an optional processor distinct from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

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

[0397] The memories coupled to the system bus 80 include random access memory (RAM) 82 and read-only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROM 93 generally contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 may be controlled by a memory controller 92. The memory controller 92 may provide an address translation function that converts virtual addresses to physical addresses when instructions are executed. The memory controller 92 may also provide a memory protection function that separates processes within the system and separates system processes from user processes. Thus, a program executing in the first mode can only access memory mapped by its own process virtual address space and cannot access memory in another process's virtual address space unless memory sharing between processes is configured.

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

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

[0400] Additionally, computing system 90 may include communications circuitry, such as, for example, network adapter 97, that may be used to connect computing system 90 to external communications networks, such as RANs 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, or other networks 112 of Figures 1A, 1B, 1C, 1D, and 1E, to enable computing system 90 to communicate with other nodes or functional entities of those networks. The communications circuitry may be used alone or in combination with processor 91 to perform the transmitting and receiving steps of particular devices, nodes, or functional entities described herein.

[0401] 8G illustrates one embodiment of an example communication system 111 in which the methods and apparatus described and claimed herein may be implemented. As shown, the example communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, and F, a base station, a V2X server, and RSUs A and B, although it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One or some of WTRUs A, B, C, D, and E may be outside the range of the network (e.g., outside the cell coverage boundary shown as a dashed line in the figure). WTRUs A, B, and C form a V2X group, with WTRU A being the group lead and WTRUs B and C being group members. WTRUs A, B, C, D, E, and F may communicate over a Uu interface or a sidelink (PC5) interface.

[0402] It is understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which instructions, when executed by a processor, such as processor 118 or 91, cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may 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-transitory (e.g., tangible or physical) method or technology for storage of information, although such computer-readable storage media do not include signals. Computer-readable storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computing system.

[0403] appendix

[0404] [Table 1]

[0405] [Table 2]

[0406] [Table 3]

[0407] [Table 4]

[0408] [Table 5]

[0409] [Table 6]

[0410] [Table 7]

[0411] [Table 8]

[0412] [Table 9]

[0413] [Table 10] * Depending on the use case, this attribute can also be a scalability attribute.

[0414] [Table 11]

[0415] [Table 12]

[0416] [Table 13]

[0417] Table 14-1

[0418] Table 14-2

Claims

1. 1. A wireless transmit / receive unit (WTRU) comprising a processor, a memory, and communication circuitry for communicating with a network, the memory including computer-executable instructions; The computer-executable instructions, when executed by the processor, cause the WTRU to: sending a request to the network, the request indicating a requested network slice selection assistance information (NSSAI), the request further indicating that the WTRU is capable of receiving simultaneous slice access capability (SSAC) information; receiving, from the network, a message including information about a registration group and an indication that an NSSAI is associated with the registration group, the message further including SSAC information of one or more single NSSAIs (S-NSSAIs), the SSAC information indicating that a first S-NSSAI cannot be used with a network slice that is not part of the registration group; Controlling access to the network slice according to the message; A wireless transmit / receive unit (WTRU) that causes the WTRU to perform operations including:

2. The WTRU of claim 1 , wherein the SSAC information indicates that a first S-NSSAI cannot be used with any other network slice.

3. The WTRU of claim 1, wherein the SSAC information indicates that the second S-NSSAI can be used only with network slices having the same slice / service type (SST) value.

4. The WTRU of claim 1, wherein the SSAC information indicates that a second S-NSSAI cannot be used with a network slice having the same SST value.

5. The WTRU of claim 1, wherein the SSAC information indicates that the second S-NASSAI can be used only with network slices having the same slice division numerator (SD) value.

6. The WTRU of claim 1 , wherein the SSAC information indicates that a second S-NSSAI cannot be used with a network slice having the same SD value.

7. The WTRU of claim 1, wherein the SSAC information indicates that a first S-NSSAI is to be used only with network slices in the same registration group.

8. The WTRU of claim 1 , wherein the SSAC information constrains which of the one or more S-NSSAIs are simultaneously provided to the WTRU in the NSSAI.

9. 1. A method implemented by a wireless transmit / receive unit (WTRU), comprising: sending a request to a network, the request indicating a requested network slice selection assistance information (NSSAI), the request further indicating that the WTRU is capable of receiving simultaneous slice access capability (SSAC) information; receiving, from the network, a message including information about a registration group and an indication that an NSSAI is associated with the registration group, the message further including SSAC information of one or more single NSSAIs (S-NSSAIs), the SSAC information indicating that a first S-NSSAI cannot be used with a network slice that is not part of the registration group; Controlling access to the network slice according to the message; A method comprising:

10. 10. The method of claim 9, wherein the SSAC information indicates that the first S-NSSAI cannot be used with any other network slice.

11. 10. The method of claim 9, wherein the SSAC information indicates that the second S-NSSAI can be used only with network slices having the same slice / service type (SST) value.

12. The method of claim 9, wherein the SSAC information indicates that a second S-NSSAI cannot be used with a network slice having the same SST value.

13. The method of claim 9, wherein the SSAC information indicates that the second S-NASSAI can be used only with network slices having the same slice division numerator (SD) value.

14. The method of claim 9, wherein the SSAC information indicates that a second S-NSSAI cannot be used with a network slice having the same SD value.

15. The method of claim 9, wherein the SSAC information indicates that the first S-NSSAI is used only with network slices in the same registration group.

16. The method of claim 9, wherein the SSAC information constrains which of the one or more S-NSSAIs are simultaneously provided to the WTRU in the NSSAI.

Images