Frequency range driven network slicing

Abstract

Access network slices available across various frequency bands. [Solution] Network slice selection assistance information (NSSAI) transmitted from the network to the UE includes not only the operating frequency band (OFB) of each individual NSSAI (S-NSSAI) within the NSSAI, but also the radio access technology (RAT) frequency selection priority (RFSP) index, which the network configures as part of the UE access and mobility subscription during the UE registration procedure. RAT restrictions are extended to indicate to the UE that a particular slice is not accessible through a particular RAT, and the network provides the UE with alternative NSSAIs and the corresponding OFBs for each S-NSSAI, indicating to the UE that these S-NSSAIs are permitted if requested. The UE selects an alternative permitted NSSAI and sends a registration renewal request to the network.

Description

Technical Field

[0001] (Cross - reference to related applications) This application claims the benefit of priority of U.S. Provisional Patent Application No. 62 / 956,441, filed on January 2, 2020, and entitled "Frequency range driven network slicing", U.S. Provisional Patent Application No. 62 / 972,212, filed on February 10, 2020, and entitled "Frequency range driven network slicing", and U.S. Provisional Patent Application No. 63 / 057,996, filed on July 29, 2020, and entitled "Frequency range driven network slicing", the contents of which are hereby incorporated by reference in their entirety.

Background Art

[0002] This disclosure is not limited to, but includes, 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. This relates to systems, methods, and apparatus or wireless networks, including technologies described in (2019-09), and 3GPP TS 23.503, Policy and Charging Control Framework for the 5G System (5GS), Stage 2 (Release 16), etc. [Overview of the project]

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

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

[0005] RAT restrictions can be extended to indicate to the UE that a particular slice is not accessible through a particular RAT.

[0006] The UE may be provided with alternative NSSAIs and corresponding OFBs for each S-NSSAI via the network, thereby indicating to the UE that these S-NSSAIs are permitted when requested.

[0007] The UE may select an alternative authorized NSSAI and send the registration renewal request to the network.

[0008] Extended UE Route Selection Policy (URSP) rules may include instructions for Public Land Mobile Network (PLMN) identifiers (IDs) and / or OFB selection information, so that a UE can guide itself to its intended slice by selecting an operating frequency band.

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

[0010] A UE may indicate in an RRC message that it wishes to access an S-NSSAI that may be inaccessible in the UE's current frequency band, and the network may redirect the UE using 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 permitted to access certain slices simultaneously, and that certain slices may only be available to UEs in certain locations, such as geographical regions and / or tracking areas. Several approaches can be taken to address such scenarios.

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

[0013] A UE may be permitted to register with multiple S-NSSAIs, and may be restricted from having simultaneous Packet Data Unit (PDU) sessions with two or more slices 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 together with slice A. Upon receiving this cause code, the UE may, depending on its urgency or requirements, 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 available or unavailable in a geographical area. Location information may be provided to the UE within the S-NSSAI information. Furthermore, 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 geographical area and / or PLMN.

[0015] An extended registration procedure may be used, in which the UE consists of information about the geographical regions from which the slice can be accessed. The UE may then use this information when selecting a route for the uplink data. For example, the UE may use this information to select a lower-priority route when the slice is unavailable.

[0016] In UEs that consider the availability of network slices in each PLMN when deciding whether to register with a PLMN, an extended PLMN selection or re-selection mechanism may be used.

[0017] The UE may trigger PLMN reselection when it evaluates the URSP rule and identifies that it cannot establish a route for traffic 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 can only access network slices that are all available within the UE's current OFB. Several solutions are available.

[0019] For example, a UE may inform the network (e.g., a Radio Access Network (RAN) and / or core network) about the operating frequency bands (OFB) that the UE can support. This information may be used by the network to identify and facilitate the slice requested by the UE.

[0020] Based on the OFBs supported by the UE, the requested network slice, and the OFBs on which the requested slice is available, the network may, for example, guide the UE to switch to a different OFB where all or most of the requested slice is 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 transmitted by the network and ensuring that the authorized NSSAI is updated until the handover is complete. With the new OFB, the UE may receive a set of authorized slices once the registration is accepted.

[0022] During the registration update request process, the UE may send an indicator to the network to notify it that it wishes to update its permitted NSSAI only if the network can allow all slices of the request within the UE's current operating bandwidth. If the network cannot allow all slices of the request, the UE may continue to operate with its currently permitted NSSAI.

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

[0024] The UE may send a Non-Access Stratum (NAS) message to the network to request a list of TA / RAs where all slices within the UE's permitted 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) may be applied as constraints regarding simultaneous access to two or more slices during the UE registration procedure. Based on these policies, the UE may change the OFB for simultaneous access to slices.

[0026] During PDU session establishment, the UE-OFB policy and SSAP may be applied simultaneously. Based on the 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 indicating only the slices available in the UE's current OFB.

[0028] Between the PDU session and the slice within the network, the UE may include the S-NSSAI information of the desired slice in the RRC message directed to the RAN. The RAN may identify the requested slice and the OFB associated with the requested slice, and based on the requested slice and the UE's current OFB, the RAN may permit the further progress of the PDU session establishment process or, otherwise, may instruct the UE to change the OFB before continuing the PDU session establishment procedure.

[0029] In the case of a mobile UE having multiple ongoing PDU sessions, the RAN node may assist in switching the UE's OFB and the UE may continue the existing PDU sessions. Based on the OFBs supported by the UE and the slice, the RAN may facilitate the UE's new cell / OFB while continuing all PDU sessions, while continuing some PDU sessions, or without continuing any of the ongoing PDU sessions.

[0030] This summary is provided to introduce a selection of concepts in a simplified form, which will be further described below in the "Detailed Description of the Invention". This summary is not intended to identify the 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. Further, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages described in any part of this disclosure.

Brief Description of the Drawings

[0031] A more detailed understanding can be obtained from the following detailed description, given by way of example in conjunction with the accompanying drawings. [Figure 1] It is a block diagram of an example of a 5G system service-based architecture. [Figure 2] It is a block diagram of an example of a non-roaming 5G system architecture in reference point representation. [Figure 3]An example of a core network that presents multiple network slices is provided. [Figure 4] This is an example call flow for NSSAI and operating bandwidth information distribution during registration. [Figure 5A] This shows an example call flow for providing an alternative slice and the corresponding frequency band to the UE. [Figure 5B] This shows an example call flow for providing an alternative slice and the corresponding frequency band to the UE. [Figure 6A] This shows an example call flow for frequency band redirection using RRC messaging. [Figure 6B] This shows an example call flow for frequency band redirection using RRC messaging. [Figure 7] This document provides an example of a graphical user interface (GUI) for a UE with NSSAI, OFB, and extended URSP rules. [Figure 8A] Examples of communication systems in which the methods and apparatus described and claimed herein may be embodied are illustrated below. [Figure 8B] This is a block diagram of an example of a device or apparatus configured for wireless communication. [Figure 8C] This is a system diagram of an example of a wireless access network (RAN) and core network. [Figure 8D] This is a system diagram of another example of a RAN and core network. [Figure 8E] This is a system diagram of another example of a RAN and core network. [Figure 8F] This is a block diagram of an example computing system. [Figure 8G] This is a block diagram of another communication system example. [Figure 9] An example of an S-NSSAI information element is shown below. [Figure 10] An example of an extended S-NSSAI information element with OFB is provided. [Figure 11]This is an example call flow for delivering a concurrent slice access policy indicator to the UE. [Figure 12] This is an example call flow for a UE that re-registers for a desired slice after being denied access due to a concurrent slice access policy. [Figure 13] This is an example call flow for handling PDU session requests with simultaneous slice access restrictions. [Figure 14] This is an example call flow for a UE where access to network slices is restricted based on geographical location. [Figure 15] This is an example call flow for configuring slice location restriction information via access and mobility subscriptions. [Figure 16] This section provides an example of a UE's graphical user interface (GUI) that demonstrates support for simultaneous slice access limits, slice access service area limits, and support capabilities. [Figure 17] This is an example call flow for a handover of the operating frequency band during the registration procedure. [Figure 18] This is an example call flow for a registration update using allowed slices in the current OFB of the UE. [Figure 19] This is an example call flow for a UE receiving TA / RA information from the network, where all slices are available for all OFBs. [Figure 20] This is an example call flow for a UE registration procedure using SSAP and UE OFB policies. [Figure 21] This is an example call flow that handles UE-OFB policies and concurrent restrictions imposed by SSAP. [Figure 22] This is an example call flow for a UE that sends S-NSSAI in an RRC message during a PDU session establishment request. [Figure 23] This is an example call flow from RAN proposing OFB for PDU session continuity. [Modes for carrying out the invention]

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

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

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

[0035] Service Area Restrictions - Service area restrictions can be set to include one or more TAs, or unlimitedly, for example, to include all TAs in a public mobile network (PLMN). UE subscription data in Unified Data Management (UDM) may include service area restrictions, for example, using explicit TA identifiers to specify which TAs are permitted and / or which are not permitted. Additionally or alternatively, service area restrictions may use geographical information such as longitude / latitude and zip code to identify permitted and / or unpermitted TAs.

[0036] Alternate Network Slice Selection Information (NSSAI) - NSSAI may be provided in an "alternate NSSAI" which includes a set of one or more single network slice selection information (S-NSSAI) that the UE is permitted to access if the UE chooses to access it.

[0037] Network Function (NF) - An NF is a processing function within a network that has 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 an appropriate platform such as a cloud infrastructure.

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

[0039] Network Functional Services (NF services) are a type of capability presented by one authorized NF (NF service consumer) through a service-based interface. An NF may present one or more NF services. For example, an AMF may provide the 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 Instances - Network slice instances are a set of NF instances and the necessary resources (e.g., compute resources, storage resources, and network resources) that form the deployed network slice.

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

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

[0045] PC5 (Interface) - PC5 refers to the reference point through which user equipment communicates directly with other user equipment via a channel.

[0046] In Radio Access Technology / Frequency Selection Priority (RFSP) Index - 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 in order 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 E-UTRAN to derive UE-specific cell reselection priorities to control idle mode camping or to decide whether to redirect active mode UEs to a different frequency layer or RAT. Similarly, in 5GS, the AMF receives subscribed RFSP indices from the UDM / Unified Data Repository (UDR) and maps them to the gNodeB to a locally defined configuration in order 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 a UE may be permitted to access and / or have access to a URLLC slice.

[0048] Simultaneous Slice Access Capability (SSAC) - The term SSAC is used herein to refer to the 3GPP Rel-17 or subsequent system capability, thereby requiring the network to impose restrictions on UEs accessing more than two slices simultaneously. This capability restriction may be imposed by a Mobile Network Operator (MNO) within the core network based on SSAP. The core network provides UEs with SSAC indicators that define the nature of simultaneous access. UEs may be required to support such policies. UEs that support SSAP are known to have simultaneous slice access capability. UEs communicate support for SSAC indicators via SSAC Support Indicators (SSIs).

[0049] UE-OFB Policy – ​​In this specification, the term UE-OFB policy refers to a policy that allows a UE to access only slices available in the UE's current operating frequency band (OFB). If at least one slice in a set of requested slices is not available in the UE's current OFB, the request to access all slices is rejected along with a proposal for an OFB handover in which all requested slices are available.

[0050] Uu (Interface) - A wireless interface between the 5G RAN and user equipment.

[0051] Examples of 5G network architectures Figure 1 shows an exemplary non-roaming-based architecture with a service-based interface within 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 illustrates an example of a 5G system architecture in the non-roaming case, using a reference point representation that shows how various network functions interact with each other. See TS 23.501.

[0053] The Mobility Management and Session Management Functions (SMF) are separated. A single N1 NAS connection is used for both registration management and connection management, as well as for UE messages and procedures related to Session Management (SM). The single N1 termination point is located within the AMF. The AMF forwards SM-related NAS information to the SMF. The AMF handles the registration management and connection management portions of the NAS signaling exchanged with the UE. The SMF handles the SM portion of the NAS signaling exchanged with the UE.

[0054] Network Function The 5G architecture supports data connectivity and enables deployment by using technologies such as network function virtualization and software-defined networking. The 5G system architecture allows for the utilization of service-based interactions between control plane (CP) and network functions (NF), where identified.

[0055] An NF (Network Function) is a processing function within a network, possessing 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. Within a PLMN, network slices include 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., compute resources, storage resources, and network resources) to form the deployed network slice.

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

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

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

[0060] An S-NSSAI can have standard values ​​(for example, such an S-NSSAI consists only of SSTs with standardized SST values ​​and does not include SDs) or non-standard values ​​(for example, such an S-NSSAI consists of both SSTs and SDs, or consists only of SSTs that do not have standardized SST values ​​and does not include SDs). An S-NSSAI with non-standard values ​​identifies a single network slice within the PLMN to which it is associated. An S-NSSAI with non-standard values ​​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] An NSSAI is a collection of S-NSSAIs. An NSSAI can be a configured NSSAI, a requested NSSAI, or an authorized NSSAI. Up to eight S-NSSAIs can exist within authorized and requested NSSAIs transmitted in signaling messages between the UE and the network. A requested NSSAI signaled to the network by the UE allows the network to select the serving AMF, network slice, and network slice instance of that UE.

[0062] Based on the operator's operational or deployment needs, 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 may be deployed in the same or different tracking areas (TAs). When multiple network slice instances associated with the same S-NSSAI are deployed in the same TA, an 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 instances to serve the UE, including the 5GC control plane (CP) and user plane network functions (NF) corresponding to this network slice instance.

[0064] The RAN may use the requested NSSAI in Access Layer (AS) signaling to address the UE CP connection before notifying the RAN of the authorized NSSAI for 5GC. The requested NSSAI will be used by the RAN for AMF selection as described in Clause 6.3.5. When the UE requests the resumption of the RRC connection and is CM-CONNECTED in an RRC inactive state, the UE shall not include the requested NSSAI in the RRC resume.

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

[0066] Because standardized SST values ​​provide a way for slicing to establish global interoperability, PLMN can more efficiently support roaming use cases for the most commonly used SSTs.

[0067] The standardized SSTs are shown in Table 1 below in the appendix of this specification. See TS 23.501.

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

[0069] NSSAI configured by default 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 is not provided to the UE. The values ​​used in the default configured NSSAI are expected to be determined in common by all roaming partners. If configured at the UE, the default configured NSSAI will only be used by the UE in a serving PLMN if the UE does not have a configured NSSAI for that PLMN. The UE may be pre-configured with the default configured NSSAI.

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

[0071] The requested NSSAI, signaled to the network by the UE, 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, 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 authorized NSSAIs are those provided by the Serving PLMN during the registration procedure, indicating S-NSSAI values ​​that the UE has not registered in the Serving PLMN for the current registration area. Upon successful completion of the UE registration procedure across the access type, the UE obtains the authorized NSSAIs for this access type from the AMF, including one or more S-NSSAIs and, if necessary, one or more S-NSSAI mappings to HPLMN S-NSSAIs. These S-NSSAIs are valid for the current registration area and access type and can be used simultaneously by the UE.

[0073] Allowed NSSAI mapping The mapping of permitted NSSAIs is the mapping of each S-NSSAI of the permitted NSSAIs related to the serving PLMN to the HPLMN S-NSSAI.

[0074] The configured NSSAI mapping The mapping of the configured NSSAI is the mapping of each S-NSSAI of the configured NSSAI with respect to the serving PLMN to the 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 of the Appendix to this specification, as described in 9.11.2.8 of the 3GPP TS 24.501 Non-Access-Stratum (NAS) protocol for a 5G system.

[0076] 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's Route Selection Policy (URSP) includes a prioritized list of URSP rules. See 3GPP TS 23.503 Policy and Charging Control Framework for 5G system; Stage 2 (Release 16). Also see Table 2 in the appendix of this specification, which shows the URSP. The structure of the URSP rules is described in Tables 3 and 4 in the appendix of this specification.

[0078] Network slicing extension The 3GPP SA2 study, Feasibility Study on Enhancement of Network Slicing Phase 2 (S2-1908583), concerns a new enhancement of network slicing. This study was conducted as a result of a request received from GSMA 5GJA to further investigate and incorporate recommended features based on the concept of the Generic Slice Template (GST) 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 at SA2-owned TSs and to study potential solutions that can address these gaps.

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

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

[0081] Radio spectrum NG.116 defines an attribute called radio spectrum to address specific frequency ranges. In NG.116, this attribute defines the radio spectrum supported by a network slice. This is important information because some terminals may be limited in terms of how often they are used. Table 6 in the appendix of this specification provides a summary of the radio spectrum attributes.

[0082] This attribute defines which frequencies can be used to access the network slice. NR is designed to operate within 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 used by the UE for transmission and the base station for reception between 1920MHz and 1980MHz, and the downlink (DL) operating band used by the UE for reception and the base station for transmission between 2110MHz and 2170MHz, operating in FDD (Frequency Division Duplex) duplex mode.

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

[0084] Character attributes characterize a slice, for example, the throughput, latency, and / or application programming interface (API) it provides. They are independent of the Network Slice Consumer (NSC) and Network Slice Provider (NSP). Scalability attributes provide attribute information about the scalability of a slice, for example, the number of terminals allowed in the slice. This type of attribute is specific to the Network Slice Consumer (NSC) and Network Slice Provider (NSP).

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

[0086] The list is specific to network slice providers (NSPs) and their roaming agreements. If a list contains two or more entries, a roaming agreement between the HPLMN and the accessed public mobile network (VPLMN) is required. Table 9 in Appendix to this specification provides attribute details.

[0087] Regional specifications For all countries listed in the service area attribute, it must be indicated whether the service is provided nationwide or only in a portion of the country. If a Network Slice Consumer (NSC) requires a specific location, this attribute can be used to define the geographical area of ​​the country where the service is provided. This must be completed for all countries listed in the service area attribute.

[0088] The list of regions is specific to each country, and the way these regions are defined is by determining the network slice consumers (NSCs) and network slice providers (NSPs). Table 10 in the appendix of 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 method requires partitioning a geographical area into a set of zones / grids, which consists of defining a regular set of zones of a given size for better resource utilization.

[0090] Wireless resource management function To support radio resource management in the RAN, AMF provides the parameter "Radio Access Frequency (RAT) / Frequency Selection Priority (RFSP Index)" to the Radio Access Network (RAN) across N2. See TS 23.501. The RFSP Index is mapped by the RAN to a locally defined configuration in order 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 may be used by the RAN to derive UE-specific cell reselection priorities to control idle mode camping, and may also be used to decide whether to redirect active mode UEs to a different frequency layer or RAT.

[0091] HPLMN may configure the RFSP index considering the subscribed S-NSSAI. AMF receives the subscribed RFSP index from UDM (for example, during the registration procedure). For non-roaming subscribers, AMF selects the RFSP index to use according to one of the following procedures, depending on the operator configuration. The RFSP index to use may be the same as the subscribed RFSP index, or AMF may select the RFSP index to use based on the subscribed RFSP index, locally configured operator policies, permitted NSSAI, and UE-related context information available to AMF, including UE usage settings, if received during the registration procedure (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 also consider input from HPLMN (e.g., pre-configured RFSP index values ​​for each HPLMN, or a single RFSP index value used for all roamers regardless of 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 an NG-RAN handover.

[0094] The AMF stores the received subscribed RFSP index values ​​and the RFSP index values ​​in use. During the registration procedure, the AMF may update the RFSP index values ​​in use (for example, the AMF may need to update the RFSP index values ​​in use if UE-related context information in the AMF changes). When the RFSP index values ​​in use are changed, the AMF immediately provides the updated RFSP index values ​​in use to the NG-RAN nodes by modifying the existing UE context, establishing a new UE context in the RAN, or, if user plane establishment is not required, by configuring the AMF to include the updated RFSP index values ​​in use in the Next Generation Application Protocol (NGAP) downlink NAS transport message.

[0095] Access and mobility-related policy control The access and mobility policy control functions include managing service area limits, RFSP functionality, and UE Aggregate Maximum Bit Rate (UE-AMBR) and SMF selection. This clause defines the management of service area limits and RFSP indices for UEs registered across 3GPP access.

[0096] UE subscriptions may include service area limitations and may be further modified at any time by a Policy Control Function (PCF) based on operator-defined policies, by expanding the list of permitted Tracking Area Identifiers (TAIs), reducing the number of unpermitted TAIs, or increasing the maximum number of permitted TAIs. Operator-defined policies in the PCF may depend on input data such as UE location, time, and information provided by other NFs.

[0097] The AMF may report subscribed service area limits received from the UDM during the registration procedure or when the AMF is modified. The condition for reporting is that the local policy in the AMF indicates that access and mobility controls are enabled. The AMF also reports subscribed service area limits to the PCF when the policy control request trigger for service area limits is modified, 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 limits from the PCF. The AMF stores them and uses them to determine the mobility limits of the UE. The PCF may indicate to the AMF that unlimited service area exists.

[0098] Service area limits consist of a list of permitted TAIs or a list of prohibited TAIs, and the maximum number of optionally permitted TAIs.

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

[0100] For wireless resource management, the AMF may report subscribed RFSP indices received from the UDM during the registration procedure or when the AMF is modified. The condition for reporting is that a local policy in the AMF indicates that access and mobility controls are enabled. The AMF reports the subscribed RFSP indices to the PCF once the subscription for RFSP indice changes to the PCF is fulfilled. The AMF then receives the corrected RFSP indices from the PCF.

[0101] UE-AMBR management enables the PCF to provide UE-AMBR information to the AMF based on the serving network policy. The AMF can report subscribed UE-AMBRs received from the UDM. The condition for reporting is that the PCF has provided the AMF with a policy control request trigger to report subscriber UE-AMBR changes. The AMF receives the corrected UE-AMBRs from the PCF. The AMF provides the UE-AMBR values ​​for the serving network to the RAN as specified in TS 23.501 Clause 5.7.2.6.

[0102] Examples of problems An MNO may offer multiple network slices. Each network slice may be designed and configured to offer specific slice characteristics to the UE, such as desired QoS, security features, and network functions. Four standard slice / service types are defined in TS 23.501, Rel 16. See Table 1 in the appendix of this specification. A network operator may wish to plan their network so that a particular slice is available only through a particular frequency band.

[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 operate in different frequency bands, and these frequency bands can be assigned to slice types based on factors such as QoS, NF, and / or geographical area.

[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 might be desirable in a scenario where a company deploys slices and wants to prevent a UE from accessing a slice when it is simultaneously accessing one or more other slices belonging to another company.

[0105] Another network slicing scenario to consider concerns roaming. When a UE is roaming, the roaming agreement between the UE's HPLMN and VPLMN specifies which slices the UE is permitted to access via the VPLMN. Furthermore, the roaming agreement may stipulate that the VPLMN permits the UE to access certain slices in some countries or regions but not in others. For example, this may be done in scenarios where a company does not want its slices to be accessed from certain countries or regions, or where local regulations stipulate that certain slice types should not be accessed.

[0106] In the scenario described with reference to Figure 3, when a UE needs to access a slice that is only available on a different frequency band, the UE may need to select a frequency band, disconnect / disable connections to another frequency band or different frequency bands, 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 direct itself to a predefined, pre-allocated frequency band corresponding to the slice's frequency bandwidth. The current 5GS does not provide a mechanism for the UE to direct itself to a specific frequency band assigned to a particular network slice without registration and deregistration.

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

[0109] The UE must have a policy to correctly guide the target network slice through 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. The current 5GS does not define such a policy for the UE. Furthermore, the policy needs to be defined in the UE so that it can successfully guide to the correct frequency.

[0110] In order for the network to allow a UE to restrict access to any other slice, restrict access to other slices with the same SST value, or restrict access to other slices with the same SD value, the following questions must be answered.

[0111] Firstly, how does 5GS make the UE aware of these limitations? In other words, how does the network make the UE aware that these limitations are being enforced?

[0112] Secondly, how does the UE handle situations where new application layer activity attempts to access a slice, which would typically trigger the UE to try sending traffic over a slice that is currently restricted?

[0113] Thirdly, what does the network do when a UE attempts to violate the restrictions? In other words, what does the network do when a UE attempts to access two slices simultaneously that are not permitted to be accessed at the same time? The answer to this question should be that the network must also consider that these restrictions must be applied to legacy (Rel-15 and Rel-16) UEs.

[0114] To address the situation where a UE is only allowed to access a specific slice in a particular PLMN while roaming, the following questions need to be addressed:

[0115] Firstly, how does the network communicate to a UE that a particular slice is inaccessible in a particular PLMN while the UE is roaming? In other words, how does the network communicate to a UE that a slice is inaccessible via a given VPLMN when the UE is in a particular country or region?

[0116] Secondly, how do the current locations and slices that the UE might want to access influence the PLMN selection?

[0117] Thirdly, if the UE attempts to access a slice via a PLMN that does not grant access and is denied, should the UE attempt to switch to a different PLMN?

[0118] Fourth, the answers to the questions discussed herein should take into account that the network must apply these limitations to legacy (Rel-15 and Rel-16) UEs.

[0119] Furthermore, if the UE is restricted to accessing network slices based on which OFB the slice is available, several slice access scenarios can arise. For example, the UE may only be allowed access to 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 help the UE select 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 on accessing a slice, how does it affect the UE's constraint on simultaneous access to 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 within the UE's current OFB? How does 5GS handle PDU session continuity scenarios when a UE moves to a new OFB / cell? The answer to this question should also consider that the network needs to apply these limitations to legacy (Rel-15 and Rel-16) UEs.

[0124] Solutions based on frequency band configuration in UE Operating bandwidths that translate to specific UL and DL frequency ranges, 3GPP TS38.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), can be predefined and allocated to network slices. Allocating and configuring these operating bandwidths to the corresponding network slices may depend on the MNO's local policy. Figure 4 shows an example of how the operating bandwidths for each slice are delivered to the UEs.

[0125] In step 0 of Figure 4, the MNO can allocate operating bandwidths (e.g., n1, n7, n12, etc.) 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, and assign them to S-NSSAI(s) as part of UE Access and Mobility Subscription at the UDM / UDR. This 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 NSSAI. For initial registration or mobility registration renewal, the UE includes a mapping of the requested NSSAI (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 within the permitted NSSAI is permitted based on the subscribed S-NSSAI. The UE also includes a default configured NSSAI instruction if the UE is using the default configured NSSAI.

[0127] In step 2, RAN selects 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, including the selected PLMN ID or the PLMN ID and network identifier (NID), location information and cell identification information related to the cell where the UE will camp, and security information, needs to be set up in the NG-RAN.

[0129] In step 4, the AMF can use Nudm_SDM_Get to retrieve access and mobility subscription data. This requires that the UDM can retrieve this information from the UDR using Nudr_DM_Query. This includes operating bandwidth and corresponding S-NSSAI relationships and RFSP index information.

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

[0131] 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. RAT restrictions define 3GPP RATs that UEs are not permitted to access in PLMNs. In restricted RATs, UEs based on subscriptions are not permitted to access the network of that PLMN. RAT restrictions can be extended as RAT restrictions are shown per S-NSSAI; in other words, a particular slice cannot be accessed through a particular RAT.

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

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

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

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

[0136] In step 8, the AMF sends a registration acceptance message to the UE via the RAN node. In the N2 message, within the registration acceptance message to the RAN node, the AMF may send the RFSP index, RAT limit, service area limit, and UE-AMBR.

[0137] In step 9, the RAN node may forward the registration acceptance to the UE. The registration acceptance may include mappings of authorized NSSAIs with each S-NSSAI and its corresponding operating bandwidth information, configured NSSAIs for each S-NSSAI and its corresponding serving PLMN, configured NSSAIs for each S-NSSAI and its corresponding serving PLMN, and mapped configured NSSAIs for each S-NSSAI and its corresponding operating bandwidth. The registration acceptance also includes mobility restrictions, including RAT restrictions. RAT restrictions have been extended to include restrictions indicated for each S-NSSAI, in other words, a particular slice may not be accessible through a particular RAT.

[0138] The UE can display the RAT limits and permitted frequency ranges associated with each S-NSSAI on its GUI. Users can view the GUI from within the "Settings" GUI.

[0139] Extended S-NSSAI information element with OFB In the solution described with reference to Figure 4, upon successful registration, the AMF transmits to the UE an authorized NSSAI containing 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. Figure 10 shows the 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. Figure 10 shows the OFB that may be contained in octets 11 and 12. The two octets are added to encode the uplink and downlink operating bands within the S-NSSAI Information Element (IE). However, alternatively, the operating band information may be encoded by sharing existing octet limits (e.g., the current S-NSSAI IE size). In addition, multiple operating frequency band information elements can be provided to the UE, and each OFB information element can be associated with location information where the OFB information should be considered valid (in the PLMN associated with S-NSSAI). Examples of location information include registration areas, tracking areas, and cell identifiers.

[0140] The UE may use OFB information elements to determine which operating frequency band to use based on the services 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 of this specification provides details about the S-NSSAI information elements updated with operating frequency band information.

[0142] Available slice operating frequency bandwidth handover For a UE camped in a cell, the authorized NSSAI received by the UE during the registration acceptance message shall include only a set of S-NSSAI that are all available in the current operating frequency band. A scheme that allows a UE to access a network slice only if the slice is available in the UE's current OFB can be called a UE-OFB policy. However, there may be scenarios in which a UE requests a slice that could not possibly 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) using a cause code. The cause code in the registration rejection message may provide the UE or RAN node with further information about the reason for rejection and the OFB, provided that all requested slices are available, triggering the UE to move to a different operating band, and all S-NSSAI from the requested NSSAI are available. OFB handover during the registration procedure is shown in Figure 17.

[0143] In Step 0, the MNO may allocate operating bandwidth (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 the UDM / UDR. This may include 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. For initial registration or mobility registration renewal, 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 permitted based on the subscribed S-NSSAI. The UE also includes the default configured NSSAI instruction if the UE is using the default configured NSSAI.

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

[0146] Firstly, V2X OFB, V2X-prioritized OFB, and V2X operating bandwidth for simultaneous Uu & PC5-based operation.

[0147] Secondly, the preferred OFB for in-band carrier aggregation operation, and the preferred OFB for the UE for in-band carrier aggregation operation.

[0148] Thirdly, the preferred OFB for in-band carrier aggregation operation and the preferred OFB for the UE for in-band carrier aggregation operation.

[0149] Fourth, OFB for dual connectivity operation, and preferred OFB for UE for dual connectivity operation.

[0150] Fifth, OFB for UL Multiple-Input Multiple-Output (MIMO), and UE preference OFB for UL MIMO.

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

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

[0153] In step 2, the AMF can use Nudm_SDM_Get to retrieve access and mobility subscription data. This requires that the UDM can retrieve this information from the UDR using Nudr_DM_Query. This includes operating bandwidth and corresponding S-NSSAI relationships and RFSP index information.

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

[0155] Mobility restrictions, as described in TS 23.501 Clause 5.3.4.1[1], consist of RAT restrictions, restricted areas, service area restrictions, core network type restrictions, and closed access group information, where RAT restrictions define 3GPP radio access technologies that a UE is not permitted to access in a PLMN. In a restricted RAT, a UE is not permitted to access the network in that PLMN, depending on the UE subscription, for example, the UE's subscription is used by the network to determine whether the UE is permitted or not. RAT restrictions may be extended as shown for each S-NSSAI, in other words, a particular slice may not be accessible through a particular 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, the core network of the AMF uses OFB information received from the UE as input for S-NSSAI selection and RAT restriction determination. Furthermore, in alternative embodiments, the RAT limit may be extended as shown for each combination of S-NSSAI and OFB, and the OFB instruction may include the OFB instruction options described herein, including V2X-related OFB instruction options, e.g., CA carrier aggregation (CA) OFB option or dual connection 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, may identify that not all S-NSSAIs within the requested NSSAI are available in the UE's current operating frequency band.

[0157] In addition, AMF may identify one or more OFBs, including OFB options as described herein, in which all S-NSSAIs from the requested NSSAI are accessible to the UE. In such cases, AMF may reject the registration request from the UE using a cause code and indicate to the UE that all S-NSSAIs from the requested NSSAI are accessible to the UE.

[0158] In step 4, the AMF may return a registration rejection message to the UE using 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 include an OFB supported by the UE or an OFB option as described herein, from which all requested slices are accessible and which may suggest to the UE resubmit the registration request from a different OFB.

[0159] If a UE supports multiple OFBs, but the requested slice is not necessarily available in all OFBs supported by the UE, the AMF will reject the UE registration request or registration renewal request using a cause code. The cause code indicates that the requested slice is not available in any of the OFBs. The cause code may require 5GS to adapt to the following cases:

[0160] In Case 1, the cause code may list OFBs that are accessible by the UE for the majority of S-NSSAIs from the requested NSSAI. In addition, the cause code may also indicate the number of authorized S-NSSAIs that the AMF can send with the authorized NSSAIs.

[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 the 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 whether they wish to resubmit the registration in a different OFB.

[0162] In Case 3, the cause code may include a proposed OFB where all slices are available based on the slice priority of that UE. Slice rank may be defined based on frequency range (FR), OFB, UE type, slice, slice type, etc., the services provided by the slice type, etc. For example, there may be different types of UEs (e.g., cellular, autonomous vehicles, connected-only vehicles, fixed IoT devices, etc.). These UEs may have different services that they typically require, which may, for example, require a certain uplink or downlink data rate and QoS and have an SLA with an MNO. If some of these UEs have access to multiple slices, the slice priority for each UE may differ from that of the other UEs. For example, an autonomous vehicle UE may have URLLC slices at the top of its list, eMBB slices second, and IoT slices third. The priority may not be the same for cellular, which may have eMBB at the top of its list and URLLC slices second. In addition, the FR and corresponding OFB may be more preferred for one form of traffic (e.g., lowest latency traffic). When the AMF sends a registration rejection message, the cause code may include an OFB ranked based on the UE's slice priority, but all slices are available in that OFB. This allows the UE to select a more appropriate OFB to resubmit the registration request. This case may also be preferable when the AMF can suggest a UE with an OFB where the majority of slices are available. For example, if an eMBB slice is not available in an OFB, but a URLLC is available in another OFB, and vice versa, the UE may choose to submit its registration request to that OFB based on its own service / slice priority.

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

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

[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 through a different RAN node than the UE's initial registration request in step 1. The AMF may assist the RAN node and the UE in making the registration request at a different RAN node. The AMF is aware of the OFBs on which the requested slice is available. Based on the AMF's knowledge of the supported UE OFB submitted in step 1 and the OFBs supported by the RAN node, the AMF may send a cause code indicating a change in OFB, and therefore in the RAN node. Alternatively, the first RAN node (RAN node-1) may support the requested NSSAI and trigger an inter-frequency cell change to a second RAN node (RAN node-2) located at the UE's location / TA.

[0166] In step 6, based on the UE subscription information, the UE's instructions (received in step 1) regarding 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 all S-NSSAIs within the requested NSSAI are available within the UE's current operating bandwidth.

[0167] Please note that the UE may not be permitted to update its authorized NSSAI until it has successfully switched to the new operating bandwidth.

[0168] In step 7, the AMF sends an acceptance / rejection message to the UE via the RAN. Acceptance may include an authorized NSSAI with each S-NSSAI and its corresponding operating bandwidth information, and a mapping of each authorized NSSAI with each S-NSSAI and its corresponding operating bandwidth. All S-NSSAIs within an authorized NSSAI and S-NSSAIs within the mapping of an authorized NSSAI are available in the UE's current operating frequency band.

[0169] Please note that during the registration renewal procedure, the UE may only wish to renew its permitted NSSAI if all requested slices are permitted within the UE's current operating bandwidth. In a registration request, the UE may indicate that it only wishes to renew its permitted NSSAI if all S-NSSAIs within the requested NSSAI are permitted.

[0170] Registration renewal by authorized NSSAI A general registration or registration renewal request may be expanded, and the UE may send an indicator to the network to signal that it wishes to renew its permitted NSSAI only if all slices in the request would be permitted within the UE's current operating bandwidth. Otherwise, the UE may prefer to retain its current permitted NSSAI. This scenario is illustrated in Figure 18 below.

[0171] In Step 1, the UE sends a registration or registration renewal request, which may include the requested NSSAI. In the request message, the UE may also include an indicator called an all-slice indicator, which notifies the network of the UE's desire to renew the permitted NSSAI only if all S-NSSAI in the request would be permitted in the current operating bandwidth; otherwise, the UE does not wish to renew the permitted NSSAI.

[0172] Alternatively, the all-slice indicator could indicate the UE's desire to remain on the current OFB only if other OFBs do not support all requested slices.

[0173] In Step 2, the AMF applies the UE-OFB policy and verifies 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. Based on the results of the UE-OFB policy and the all-slice indicator, the AMF may have two alternative decisions.

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

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

[0176] Instead of including the all-slice indicator in the registration request, the UE may include the currently authorized NSSAI in the registration request. The presence of the authorized NSSAI in the registration request allows the all-slice indicator to be provided as a service.

[0177] Tracking area / registration area with available slices in all cells If a UE can access all slices in any of its OFBs, it may be useful for the UE to have prior knowledge of the TA / RAs where all slices of the UE's authorized NSSAIs may be available. This information can facilitate the UE's smooth movement as it navigates through various TAs / RAs. Information about where such TAs / RAs are available may be configured in the network, and the network may distribute this information to the UE during registration, registration update, or UE configuration update processes, as shown in Figure 19.

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

[0179] In step 0-B, the UDM / UDR may be constructed using a list of UE's TA / RA information. The list of TA / RA information defines 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 renewal request to the network via the RAN. In addition, the UE may also inform the AMF about the OFBs that the UE supports. This includes the OFBs currently in use by the UE.

[0181] In step 2, the AMF can use Nudm_SDM_Get to retrieve access and mobility subscription data. This requires that the UDM can retrieve this information from the UDR using Nudr_DM_Query. This includes operating bandwidth and corresponding S-NSSAI relationships and RFSP index information.

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

[0183] In step 3, the AMF examines all available slices in all cells of the TA / RA, including the requested NSSAI, OFBs supported by the UE, and the current TA / RA, identifies the UE's permitted NSSAI, identifies the TA / RAs in which OFBs supported by the UE are available, and determines the permitted NSSAI along with a list of TA / RAs in which all slices of the permitted NSSAI are available.

[0184] In step 4, AMF sends a registration acceptance message containing the approved NSSAIs and any rejected NSSAIs. In addition, AMF also delivers a list of TAIDs for all TAs in the RA, for which all slices of the approved NSSAIs are available.

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

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

[0187] In yet another alternative, a list of TA / RAs in which all slices within an authorized NSSAI are available in all cells may be delivered to the UE based on UE mobility information obtained by the network from the UE. For example, if a UE is moving at a certain speed in a certain direction, the network may be able to detect the UE's movement, and using NWDAF, the network may be able to predict the probability that the UE will change its TA / RA in the geographical area it may be heading towards. This may include a list of TA / RAs in which all cells are available in an authorized NSSAI, which may trigger the network to perform a registration update, a UE configuration update, or simply send a NAS message.

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

[0189] Figures 5A and 5B illustrate the provision of alternative slices and corresponding frequency bands to the UE. In step 0-A of Figure 5A, the UE may have a configured NSSAI for the PLMN and an authorized NSSAI for the PLMN. Therefore, the UE can request registration targeting a specific slice within the NSSAI.

[0190] In step 0-B, the MNO may allocate the operating bandwidth defined in TS 38.101-1 (e.g., n1, n7, n12, etc.) to the S-NSSAI as part of the UE access and mobility subscription in the UDM / UDR. This may include 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 and NAS layers with the requested NSSAI, including the S-NSSAI corresponding to the slice that the UE wishes to register.

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

[0193] The registration request may further indicate to the AMF the capabilities of the UE, including instructions on 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, RAN selects 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 must be set up in the NG-RAN, which includes the selected PLMN ID (or PLMN ID and NID), location and cell identification information related to the cell where the UE is camping, and security information.

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

[0197] In step 8 of Figure 5B, the AMF may evaluate the registration request. The AMF may discover that the UE is attempting to register with a network slice that has a different OFB. Therefore, the AMF cannot redirect the UE to a frequency that functions for all S-NSSAIs within the NSSAI.

[0198] The network may be able to provide connectivity across a variety of frequency bands, directing UEs to different network slices, but may only allow some of the S-NSSAIs within the permitted NSSAI.

[0199] Therefore, the AMF may select S-NSSAIs and corresponding operating frequency bands for higher-priority network slices from the requested NSSAIs and return them to the UE as authorized NSSAIs. In addition, the AMF may send alternative authorized NSSAIs, including other combinations of S-NSSAIs that would be authorized if requested by the UE. The presence of alternative authorized NSSAIs is an instruction to the UE that the network did not include all S-NSSAIs from the requested NSSAIs in the authorized NSSAIs because the UE could not allow simultaneous connection to all S-NSSAIs in the requested NSSAIs, and is an instruction for the network to determine whether the S-NSSAIs in the requested NSSAIs should take precedence. The AMF may also provide instructions on why S-NSSAIs from the requested NSSAIs were not present in the authorized NSSAIs (e.g., some S-NSSAIs are only available on mutually exclusive frequencies, so some S-NSSAIs cannot be accessed simultaneously). The authorized S-NSSAI and alternative authorized NSSAI may further indicate the operating frequency bandwidth of each S-NSSAI.

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

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

[0202] In step 11, the UE may choose to use an authorized NSSAI or to submit a registration renewal request with a new requested NSSAI formed based on the information provided in the registration acceptance message in step 10 (e.g., an alternative NSSAI).

[0203] URSP Rule Extension As considered, the UE can receive the permitted NSSAI and OFB for each S-NSSAI. Alternatively, or additionally, the URSP rules can be extended to guide the UE toward the appropriate S-NSSAI / frequency band combination. The registration acceptance message also provides the RAN node with several important pieces of information, including the RFSP index, RAT limit, restricted area, service area limit, core network type limit, and closed access group information. The RFSP index and corresponding frequency spectrum information enable the RAN to manage resources suitable for the UE. The RAN node provisions operating frequency band information to the UE in conjunction with receiving the RFSP index.

[0204] When a UE attempts to connect to a slice within a network, different network slices may only be accessible via specific OFs. Therefore, the UE must ensure it uses the correct frequency band to connect to the network slice. In addition, the UE may need to be camped on the appropriate PLMN, and for the appropriate PLMN, the frequency bands and corresponding slices accessible through those bands are configured so that the UE has access to them. Thus, 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 must use to reach the network slices.

[0205] This information may be incorporated into 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 will be updated with two new RSD information elements: PLMN ID and OFB. Alternatively, the information may be included as part of a route selection validation criterion to ensure that the UE does not attempt to establish a route unless it is camping within the indicated PLMN and at the indicated frequency.

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

[0207] Frequency band redirection using RRC reconstruction When a UE attempts to register with a set of slices, the Network Network (AMF) may detect that the UE is attempting to register with slices that are not available on the same frequency. Therefore, the AMF cannot redirect a UE to a single frequency that works for all S-NSSAIs within an NSSAI. In other words, there is no single RFSP index that can be used to access all S-NSSAIs. In this solution, the AMF considers UEs registered with all requested S-NSSAIs and provides the RAN with multiple RFSP indices, informing the RAN which S-NSSAIs are available with each RFSP index. The UE and RAN nodes then use RRC messaging to coordinate movement between frequency bands depending on which S-NSSAIs they need to access.

[0208] Figures 6A and 6B illustrate frequency band redirection using RRC messaging. In step 0-A of Figure 6A, the UE may have a configured NSSAI for the PLMN and an authorized 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 the operating bandwidth defined in TS 38.101-1 (e.g., n1, n7, n12, etc.) to the S-NSSAI as part of the UE access and mobility subscription in the UDM / UDR. This may include 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 layer (AS) and NAS layers with the requested NSSAI, which includes the S-NSSAI corresponding to the slice that the UE wishes to register.

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

[0212] In step 2, RAN selects 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 containing the selected PLMN ID (or PLMN ID and NID), location information, cell identification information related to the cell where the UE is camping, and security information needs to be set up in the NG-RAN.

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

[0215] In step 8, the AMF may evaluate the registration request. The AMF may discover that the UE is attempting to register with a network slice that has a different OFB. Therefore, the AMF cannot redirect the UE to a frequency that functions for all S-NSSAIs within the NSSAI (e.g., retrieving the RFSP index).

[0216] The AMF response to RAN nodes can be extended to include multiple RFSP indices and S-NSSAI within NSSAI, which will function using each index.

[0217] The call flow in 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 indice.

[0218] In addition, the AMF may provide the UE with an access layer connection NSSAI inclusion mode parameter via RAN in the registration acceptance message, indicating whether and when the UE should include NSSAI information in the RRC connection establishment.

[0219] In step 10, the RAN node forwards a registration acceptance message. To control idle mode camping, the registration acceptance message may include multiple sets of UE-specific cell reselection priorities in the 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 authorized NSSAI is accessible in the frequency band currently being used by the UE.

[0221] The message may indicate that the S-NSSAI within the authorized NSSAI is not accessible in the frequency band currently being used by the UE.

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

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

[0224] Handling DL traffic in the second network slice using ongoing sessions in the 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 from which frequency bands each slice is accessible. The UE may also be connected to the network via frequency band #1, and downlink (DL) data reaches 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 containing an OFB that the UE should switch to in order to receive the DL data. Alternatively, the NAS notification may indicate an S-NSSAI or PDU session ID from 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 Figure 4.

[0225] When a UE receives a NAS notification indicating that it 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 using a list of authorized PDU sessions. The authorized PDU sessions may then be reactivated in the frequency band according to the UE policy and whether the S-NSSAI of these PDU sessions is within the authorized NSSAI for 3GPP access.

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

[0227] Restrict simultaneous network slice access for registered users. A UE consists of one or more configured NSSAIs, one of which may be the default NSSAI. For each S-NSSAI within a configured NSSAI, the configuration may include a Concurrent 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, any other network slice, only with network slices that have the same SST value, not with network slices that have the same SST value, only with network slices that have the same SD value, not with network slices that have the same SD value, and / or only with network slices within the same Network Slice Group (NSG).

[0228] Each S-NSSAI associated with an SSAC indicator may be configured via the OAM system through network functions such as AMF, UDM / UDR, and PCF.

[0229] When a UE registers with the network, it may use an SSAC Support Indicator (SSI) to indicate to the network whether it supports (e.g., understands) SSAC indicators. 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 can indicate SSAC support and how the network can deliver SSAC indicators to the UE. Figure 11 focuses on extensions to the UE registration procedure described in TS 23.502.

[0231] In step 0-A, as described with reference to Figure 11, the OAM system may be used to configure network functions (NFs) such as AMF, UDM / UDR, and PCF using the SSAC indicator of each S-NSSAI. The OAM may configure the SSAC indicator of each S-NSSAI within a UE subscription that contains the subscribed NSSAIs, the PCF may be configured or updated using a UE policy that may include the SSAC indicator of each S-NSSAI, or the AMF may be configured or receive the SSAC indicator of 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 scenarios where it is desirable to restrict only certain UEs when they access a slice, without restricting other UEs.

[0232] In step 0-B, as described with reference to Figure 11, the UE may consist of 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 the requested NSSAI, the mapping of the requested NSSAI, and the default configured NSSAI instruction. The UE includes the default configured NSSAI instruction if the UE is using the default configured NSSAI as defined in TS 23.501. The UE may use the SSAI in the registration message to indicate that the UE supports the SSAC indicator. The SSI may be a single-bit instruction, or the UE may indicate this support by including the configured SSAC indicator for each S-NSSAI in the requested NSSAI.

[0234] In step 2, 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 must be set up in the NG-RAN, which includes the selected PLMN ID (or PLMN ID and NID), location information, and cell identification information and security information related to the cell the UE is canning.

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

[0237] In step 5, the AMF may send a registration acceptance message to the UE via the RAN. In the registration acceptance message, the AMF may include the allowed NSSAI, the mapping of the allowed NSSAI, the configured NSSAI for the serving PLMN, the mapping of the configured NSSAI, and the rejected S-NSSAI. For each S-NSSAI of the configured NSSAI for the serving PLMN, the AMF may include an SSAC indicator. Optionally, the SSAC indicator may also be included for each S-NSSAI in the allowed NSSAI, the mapping of the allowed NSSAI, and the mapping of the configured NSSAI. The absence of an SSAC indicator may serve as a sign that there are no restrictions associated with the S-NSSAI regarding concurrent use with other network slices. Each rejected S-NSSAI may be associated with a cause value. The AMF may set a cause value to indicate to the UE that the S-NSSAI was rejected because the SSAC configuration associated with the S-NSSAI does not match one of the S-NSSAIs in the allowed S-NSSAI. If the UE does not indicate SSAC support in the registration request message, the AMF cannot provide the UE with any SSAC indicators. If the network rejects any S-NSSAI due to concurrent usage limits and the UE does not indicate SSAC support, the cause code associated with each rejected S-NSSAI may be a general cause code such as Cause #62 - No network slices available.

[0238] As shown in Figure 11, the AMF may notify the UE in the registration acceptance message that 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 authorized NSSAI. When this occurs, the UE may then determine that it will subsequently register with S-NSSAI#1 rather than S-NSSAI#2. In such a scenario, the UE may then send a second registration request message that includes S-NSSAI#1 within the requested NSSAI but does not include S-NSSAI#2. A subsequent registration acceptance message may include S-NSSAI#2 within the authorized NSSAI but not S-NSSAI#1. This procedure is illustrated in Figure 12.

[0239] In step 1, the UE sends the registration request to the network with the requested NSSAI. The requested NSSAI 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 address the UE's slice access request. The AMF identifies that both S-NSSAI#1 and S-NSSAI#2 cannot be accessed by the UE. Therefore, the AMF selects S-NSSAI#2 as the permitted NSSAI and rejects S-NSSAI#1.

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

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

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

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

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

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

[0247] Steps 0-2 in Figure 20 involve the same steps as steps 0-2 in Figure 17.

[0248] In step 3, AMF may examine two different policies. First, AMF examines the UE-OFB policy to determine if all slices within the requested NSSAI are available in the UE's current OFB. Second, AMF runs SSAP to determine if two or more slices are accessible simultaneously based on 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 the SSAP. If two or more slices are not simultaneously accessible based on the SSAP, the AMF selects one S-NSSAI of the permitted NSSAIs, combines the other non-conforming S-NSSAIs into a set of rejected S-NSSAIs, and includes a cause code indicating the reason for rejecting the rejected NSSAIs in the registration acceptance message. The registration acceptance 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 all slices to an operating bandwidth where they are accessible.

[0251] If not all requested S-NSSAIs are available in the UE's current OFB, the AMF will not check the SSAP for the requested NSSAIs. In other words, if one of the S-NSSAIs within a requested NSSAI is not available in the UE's current OFB, the UE will not be able to access all slices simultaneously in its operating bandwidth.

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

[0253] If a UE is handed over to a new OFB where all slices are available, the AMF applies SSAP. If SSAP determines that two slices are not accessible at the same time, one of them is placed in the rejected NSSAI and the other in the permitted NSSAI. For example, if the requested NSSAI has eight slices and SSAP identifies that all of them are available in the UE's current OFB, and two of them were not accessible at the same time, the permitted NSSAI will have seven S-NSSAIs, which may be delivered to the UE via the registration acceptance message, and one S-NSSAI will be delivered to the rejected NSSAI.

[0254] Alternatively, the AMF may configure a UE-OFB policy to not allow slices that are not available in the UE's current OFB without instructing the UE to modify the OFB. In other words, the AMF may send an allowed NSSAI for slices available in the UE's current OFB and include other slices that are not available in the UE's current OFB in a list of rejected slices. After the UE implements the UE-OFB policy regarding 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 non-compliant slices are found, it is included in the list of rejected slices, and the remainder of the slice may be returned to the UE as an allowed NSSAI in the registration acceptance message. Within this alternative, the UE-OFB policy may be configured to instruct the UE to modify the OFB in which the majority of slices are available. Once the UE modifies the OFB and finds accessible slices, the SSAP may be implemented for those slices.

[0255] On the other hand, AMF may apply SSAP and UE-OFB policies in the reverse order; that is, SSAP is applied before the UE-OFB policy. In this case, the UE first checks the SSAP policy for concurrent access. If SSAP allows the UE to access all slices simultaneously, 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, AMF instructs the UE to hand over 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 allowed 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 accessible through the UE's current OFB, the procedure described in Figure 17 may be applicable, and the AMF instructs the UE to hand over its registration request to an OFB in which all slices are accessible. Otherwise, the S-NSSAI for these slices is placed in an permitted NSSAI and returned to the UE as a registration acceptance message. Note that in exchange for checking the UE-OFB policy, slices rejected due to the 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 deciding on a registration acceptance message and sending it to the UE.

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

[0258] Restricting concurrent network slice access during PDU session establishment. Restrictions on the concurrent use of network slices can be applied during PDU session establishment. In other words, the UE may be permitted to register to a network slice, but only the concurrent possession of PDU sessions in restricted slices may be restricted.

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

[0260] Figure 13 depicts an alternative form where the UE attempts to establish a PDU session in a slice from the permitted list of S-NSSAIs, but the core network cannot establish the PDU session to restrict the concurrent access to a certain slice.

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

[0262] In step 2, the concurrent 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) within the network. This request may include an SSI that can 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 cannot access slice A of the UE concurrently.

[0265] In step 5, the AMF will reject the PDU session establishment if the PDU session establishment request is for an S-NSSAI that cannot be used simultaneously with the S-NSSAI for which the UE already has an established PDU session. If the UE demonstrates 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 in progress with respect to slice A, the AMF may indicate to the UE in the rejection cause code that the UE may be able to attempt the PDU session establishment request as soon as the session with slice A ends.

[0267] Alternatively, if the 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 priorities (e.g., emergency situation) and slice B has a 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 Restrictions on simultaneous access to two or more slices may also be based on the OFB on 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 permitted and can be delivered to NSSAI permitted during the general UE registration or registration renewal 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 a cell or TA / RA and the UE needs to continue an existing PDU session. In other words, if two PDU sessions are established to 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 supporting OFB to the network during the general registration procedure. In some cases, the UE-OFB policy may also be applied with SSAP, as illustrated in the example in 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 slice (slice A).

[0272] In step 3, the UE may initiate a new PDU session on a second network slice (slice B) available in a different OFB. Here, 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 OFBs where all slices are 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 send information about OFBs where both slices are available and the PDU session can be established on both slices simultaneously. Alternatively, the cause code may send information about which OFBs can be used to establish the requested PDU session. If the AMF does not find an OFB where both slices are available, the cause code will only indicate a reason for rejection stating a violation of the UE-OFB policy. In this case, there are two possible options for applying the SSAP policy:

[0274] In Option 1, the AMF may apply an SSAP policy to ensure the conformity of the two slices. If they do not conform, nonconformity information attributable to the SSAP may be sent to the UE via a cause code in the PDU session request rejection message. Note that this rejection information may also help the UE later decide whether to remain in the currently permitted NSSAI or move to a completely different OFB.

[0275] If both the UE-OFB policy and SSAP verification fail, it is guaranteed that the UE will not be able to access either slice in any of the OFBs. In this case, the AMF may send a rejection message and a cause code indicating it.

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

[0277] However, if a second PDU session establishment request directed to a slice (e.g., slice B) is available in the same OFB as the established PDU session in slice A, and that OFB is the UE's current OFB, then 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 message to accept or reject the UE PDU session. 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 failure of the UE-OFB policy, the AMF sends a rejection message with a cause code to the PDU session. The cause code indicates a failure of the slice in the UE's current OFB and may recommend an OFB that both slices (slice A and slice B) may be able to access, or an OFB that slice B may be able to access. If the rejection is due to a violation of SSAP, the cause code indicates that the slices (slice A and slice B) are unsuitable for concurrent access.

[0279] In Step 5-A, if the UE receives a PDU session rejection message with a cause code based on the UE-OFB policy, the UE may choose to retain the ongoing PDU session in slice A and refrain from requesting a PDU session establishment for slice B. In other words, the UE may disregard 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 cannot change the OFB and will simply refrain from requesting a PDU session establishment, continuing the ongoing PDU session in slice A.

[0280] In step 5-B, if a PDU session is rejected with a cause code indicating a change in the OFB, the UE may choose to request a new authorized NSSAI on the new OFB where both slices are available. If the UE chooses this option, it may first need to save the state of the ongoing PDU session and request a PDU teardown of the ongoing PDU session on slice A. Once the PDU session teardown is complete, the UE will need to send a registration update request to the OFB recommended by the AMF in the previous step. If registration is successful through the new OFB, the UE may re-establish the previously teardown PDU session and continue the PDU session. The UE may also request a new PDU session establishment request on slice B using the new OFB. Alternatively, if the UE changes the OFB, existing sessions may simply be handed over to the new OFB.

[0281] In the alternative configuration, the UE has information about which slices are available in which OFB (cell) based on the OFB (cell) the UE is currently in, so the UE can simply initiate the PDU session establishment process only on 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 it can establish a PDU session based on the UE-OFB policy. Once the PDU session is established, the AMF can only apply SSAP to implement the conformance of two or more slices of that UE.

[0282] RAN-assisted UE handover based on slice availability Each S-NSSAI can be associated with its available OFB. This information (e.g., S-NSSAI and corresponding OFB) is transmitted to the RAN node during a successful registration procedure. When the UE requests to establish a PDU session with a slice within the network, the UE may include the desired slice information in an RRC message directed to the RAN. The RAN can identify the requested slice and the OFB associated with the requested slice. If the requested slice is within the UE's current OFB, the RAN may permit 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 described in Figure 22.

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

[0284] In step 1, the UE transmits a PDU session establishment request to the network via the RAN. In this request, the UE may also include the S-NSSAI of the requested slice for which the UE desires to establish a PDU session in the RRC message. Note that this S-NSSAI information is added to the slice information transmitted to the AMF.

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

[0286] First, the V2X OFB, the OFB preferred by V2X, and the V2X operating band for simultaneous Uu and PC5-based operations.

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

[0288] Thirdly, the OFB for in-band carrier aggregation operation, and the preferred OFB for the UE for in-band carrier aggregation operation.

[0289] Fourth, OFB for dual connectivity operation, and preferred OFB for UE for dual connectivity operation.

[0290] Fifth, the preferred OFB for UL MIMO and UE for UL MIMO.

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

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

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

[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 to the AMF.

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

[0296] In step 5, the AMF sends a NAS message to the RAN, which indicates an N2 PDU session request. An AN-specific resource is set up between the UE and the RAN, which indicates acceptance of the PDU session establishment request, and the RAN then replies to the AMF with an N2 PDU session response.

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

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

[0299] In step 5, the PDU session establishment request is accepted by the network, and the UE may begin sending the PDU to the desired slice within the network.

[0300] Handling of PDU sessions when a UE moves to a new cell. A UE may have multiple ongoing PDU sessions within multiple network slices in an OFB (cell). A UE may be mobile and may wish to move to a new OFB. Based on the available OFBs that the UE supports, the RAN may assist the UE in switching OFBs, allowing the UE to continue existing PDU sessions. If the network cannot support all slices in an OFB, the RAN may notify the UE with a cause code. Figure 23 illustrates the procedure.

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

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

[0303] In step 2, the RAN identifies slices and OFBs where slices with PDU sessions may be available, allowing the UE to continue existing PDU sessions within the slices. The UE's current RAN node may coordinate with other RAN nodes regarding 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 all slices with ongoing PDU sessions in the UE also support the new cell, it returns an acknowledgment indicating that support for all slices in the new OFB. The RAN node then facilitates a smooth OFB handover for the UE, allowing the PDU sessions to continue.

[0305] In step 3-B, the RAN node may identify that the new cell does not support all of the UE's slices and may identify other cells within the UE's reach that can support more slices. In this case, the RAN may suggest to the UE that the PDU session continue in an OFB that supports a greater number of slices. In addition, it may indicate to the UE any S-NSSAIs that are not supported in the proposed OFB. The RAN can then facilitate a smooth OFB handover for the UE to supported slices 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 no other cells within the UE's reach can support those slices. In this case, the RAN sends a response to the UE with a cause code stating that the OFB cannot support the requested slice. 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 within a new cell, and therefore the RAN node may indicate this information in its response. A UE may establish a PDU session in the default slice if authorized UEs are able to maintain one or more PDU sessions in the default slice.

[0308] In step 4, the UE switches to the new OFB. The core network is notified when the UE switches to the new OFB. 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] This constitutes slice location restriction information in NSSAI. When a UE is within a specific PLMN in a particular country, a particular network slice may not be available to the UE. Note that the PLMN ID includes the mobile country code (MCC), and thus any information configured in the UE based on the PLMN ID is already configured on a country-by-country basis.

[0310] During registration or configuration update, the network may send a “configured NSSAI mapping” for the serving PLMN to the UE. When this information is sent to the UE, each S-NSSAI is encoded as shown in Figure 9.

[0311] Note that when the encodings shown in Figure 9 and Table 8 of the Appendix to this specification are 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 32 bits in total), or the S-NSSAI may contain only the SST field (in which case the S-NSSAI length is 8 bits in total).

[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," defined as hexadecimal FFFFFF. In certain protocols, the SD field is omitted to indicate that the SD value is not 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 situations where a network needs to communicate to a UE that a particular PLMN (e.g., not available for a particular PLMN ID) is unavailable in a particular country, a new SST value may be standardized to represent NULL or unsupported. When this value is provided in the SST field, it is an instruction 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 HPLMN's S-NSSAI service when connected to the PLMN. Table 12 in the appendix of this specification shows the standardized SST values ​​from TS 23.501. This table has been updated to show how SST values ​​can be modified to indicate to the UE that there is no SST value or slice that maps to an S-NSSAI in the PLMN.

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

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

[0319] Another alternative way to indicate to the UE that there is no mapped S-NSSAI within the PLMN is to define a new encoding for the "Length of S-NSSAI Content" field to indicate the state to the UE. For example, encoding 00001001 could indicate that the information element carries only the mapped HPLM SST value, encoding 00001010 could indicate that the information element carries only the mapped HPLMN SD value, and encoding 00001011 could indicate that the information element carries both the mapped HPLM SST value and the mapped HPLMN SD value. The absence of SST and SD values ​​for VPLMN would be an instruction to the UE that the HPLMN S-NSSAI does not have a mapping in the PLMN.

[0320] A slice within a configured NSSAI may be available only in a specific region within the HPLMN. In this case, the network needs to communicate to the UE the regions in which the slice is accessible. During registration or configuration updates, 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 of the Appendix. The network may indicate the geographical regions in which the UE S-NSSAI is available within the S-NSSAI information elements. For example, the “S-NSSAI content length” encoding may be modified so that the network can indicate to the UE that the information element indicates that location information is present within the information element. For example, a value of 10000001 can indicate to the UE that the SST and geographical information (e.g., service area) are included in the S-NSSAI content. Furthermore, geographical information may be encoded so that the encoding indicates to the UE the format of the geographical information. An example format includes registration area (e.g., service area list), tracking area identification information list, cell identifier, country, citile, and GPS coordinates. If the geographic area is not included in the information element, the UE may assume that S-NSSAI is available throughout the PLMN. Alternatively, the geographic area may indicate to the UE locations where access to S-NSSAI is restricted.

[0321] If the 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 regions where S-NSSAI is available (or unavailable) are indicated to the UE as part of the "Configured NSSAI Mapping" information element and may be encoded as described herein.

[0322] Table 13 in the appendix of this specification shows how the S-NSSAI information element coding can be updated to convey the information described above. When a 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 coding 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, provide a cause code 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 denied. Furthermore, if the UE moves to a location where access to one of its S-NSSAIs is restricted, the network may send the UE a configuration update message with a new permitted NSSAI. The permitted NSSAI will be different from the previously sent permitted NSSAI to the UE because the new permitted NSSAI will lack the S-NSSAI that is currently restricted due to the UE's current location. Figure 14 illustrates the process by which a UE is denied access based on its geographical location.

[0324] In Step 1, the UE initiates the UE registration procedure using the AMF in the VPLMN within different geographical regions (e.g., countries). The registration request may include the requested NSSAI, the mapping of the requested NSSAI, and, among other information, the default configured NSSAI directives. One of the S-NSSAIs within the requested NSSAI may be geographically restricted, and the UE may not be aware of this restriction. In addition, the UE may or may not include an indicator showing support for geographical S-NSSAI restrictions.

[0325] In step 2, the AMF may identify restricted slices of UEs in the accessed geographical area. See Table 12 in the Appendix. The S-NSSAI mappings of configured NSSAIs and S-NSSAI mappings of permitted NSSAIs may be set to NULL, for example, to indicate that there is no corresponding mapping of a home network slice for any network slice within the accessed network. Therefore, the accessed access and mobility management function (V-AMF) may reject a particular requested S-NSSAI.

[0326] In step 3, the AMF may send a registration acceptance message to the UE along with the approved NSSAIs and the rejected S-NSSAIs with rejection reason codes, because the rejection reason code may indicate that the S-NSSAI mapping was unavailable (NULL) in the VPLMN within the UE's current region.

[0327] Configure slice location restriction information via access and mobility subscriptions. Service area restrictions consist of either permitted or denied areas. In particular, they may include limited tracking areas, or alternatively, all tracking areas (TAs) in the PLMN. A UE may be restricted to access one or more network slices based on its service area. To address scenarios where a particular slice may be available in a permitted area or not available in a denied area, a new field indicating the availability of a network slice in the service area may be used, for example, a field called slice availability area restriction. This field specifies the availability or unavailability of each S-NSSAI in the configured NSSAI within that area. This information may be stored in the UDM as part of the access and mobility subscription data types 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, where it may be applied.

[0328] Alternatively, slice availability limit information can be delivered to the UE along with the registration acceptance message and evaluated by the UE.

[0329] Another alternative is to pre-configure the UE using slice area availability limitation information for each S-NSSAI when configuring the configured NSSAI.

[0330] Figure 15 illustrates the process by which slice availability limit information is transmitted to the AMF, or alternatively, the UE, within the network.

[0331] In Step 0, the slice availability area limit 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 toward the AMF via the RAN node. The request may include the requested NSSAI.

[0333] In Step 2, for UE, AMF can use Nudm_SDM_Get to retrieve UE subscription information, which may include access and mobility subscription data, SMF selection subscription data, and UE context within SMF data. This requires UDM to be able to retrieve this information from UDR using Nudr_DM_Query fields within the UE subscription.

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

[0335] In step 4-a, the AMF sends a registration acceptance message to the UE. In the registration acceptance message, the AMF includes the allowed NSSAIs, the mappings of the allowed NSSAIs, the configured NSSAIs, and the mappings of the configured NSSAIs, as well as the rejected NSSAIs. The rejected NSSAIs include the S-NSSAIs that were rejected at that location and the slice availability area limits associated with each S-NSSAI, so that the UE can recognize that the slice has been rejected for its current location and can use this information to consider when it will attempt to register the slice again.

[0336] In step 4-b, the AMF sends a registration acceptance message to the UE. In the registration acceptance message, the AMF includes the allowed NSSAIs, the mapping of the allowed NSSAIs, the configured NSSAIs, and the mapping of the configured NSSAIs, along with the slice availability area limits associated with each S-NSSAI within the allowed NSSAIs, and the mapping of the configured NSSAIs, which are delivered to the UE. This option allows the UE to register for a slice even if the slice is restricted in its current area. The UE is responsible for enforcing this restriction by not allowing slice activity in the restricted area (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 area (e.g., not allowing PDU session establishment).

[0337] In step 5, if the UE receives slice availability limit information from the network along with the registration acceptance message (step 4-b), the slice availability limit information may be considered when the URSP rule is evaluated as application traffic is generated at the UE. In other words, this information may be used to bypass restricted slices and select lower priority routes in the network when the RSD is evaluated.

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

[0339] PLMN selection upon switch-on, or recovery from coverage deficiencies 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-NSSAI) 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 the UE will first attempt to register with a PLMN in 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 location within the PLMN and enable slice-aware PLMN selection. The UE may only consider the availability of S-NSSAI that are part of its configured NSSAI or a mapped and configured NSSAI associated with the PLMN.

[0340] In addition to the PLMN ID and power level of the strongest cell at each frequency, the AS may be extended to provide the TA code, cell ID, and / or RAN area ID to notify the UE location within the PLMN via the NAS, enabling slice-recognized PLMN selection.

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

[0342] Recovery from coverage deficiencies in PLMN selection during switch-on and in manual network selection mode is specified in section 4.4.3.1.2 of TS 23.122. This procedure may be extended so that when the UE determines which PLMNs are present, the availability of network slices (S-NSSAI) in each PLMN is considered. For example, if some S-NSSAIs are not available in a PLMN at the UE's current location, this information may be displayed to the user. For example, the display may indicate that services are limited, which services are available, which services are unavailable, and so on. In addition, the display may indicate the reason and location where services are unavailable in a 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 take into account 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 it evaluates a URSP rule 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 the GUI of the UE that, in coordination with the RAN and core network, holds the authorized NSSAI and corresponding OFB for each S-NSSAI, alternative authorized NSSAI and OFB, extended URSP rules, and frequency band guidance capability.

[0345] Figure 16 shows the UE GUI, including the UE configuration for supporting simultaneous slice access restrictions, support for slice access restrictions based on service areas including geographical location information, and extended URSP rules for supporting simultaneous slice access validation criteria.

[0346] Examples of environments 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 service coding, security, and quality. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun working on the standardization of the next generation of cellular technology called New Radio (NR), also known as "5G." 3GPP NR standard development is expected to include a definition of next-generation radio access technology (New RAT), which is expected to include the provision of new flexible radio access below 6 GHz and new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in the new spectrum below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with branching requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectra, for example, providing opportunities for ultra-mobile broadband access for indoor applications and hotspots. In particular, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 6 GHz, utilizing centimeter-wave and millimeter-wave specific design optimizations.

[0347] 3GPP identifies the various use cases that NR is expected to support, resulting in a wide range of user experience requirements for data transfer speed, latency, and mobility. Use cases may include enhanced vehicle-to-everything (eV2X) communications, which may include any of the following common categories: enhanced mobile broadband (e.g., broadband access in congested areas, ultra-high-speed indoor broadband access, broadband access in the cloud, 50Mbps or more everywhere, ultra-low-cost broadband access, mobile broadband in vehicles), critical communications, large-scale machine-type communications, network operations (e.g., network slicing, routing, migration and interaction, as well as energy saving), vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), network communications (V2N), vehicle-to-pedestrian communication (V2P), and vehicle-to-infrastructure communications with other entities. Specific services and applications in these categories include, to name a few, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster warning, real-time gaming, multi-person video calls, autonomous driving, augmented reality, touch internet, and virtual reality. All of these use cases are contemplated herein.

[0348] Figure 8A illustrates one embodiment of a communication system 100 in which the methods and apparatus described and claimed herein may be embodied. As shown, an example of a communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be generally or collectively referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone network (PSTN) 108, the internet 110, other networks 112, and a V2X server (or ProSe function and server) 113, but it will be understood that the disclosed embodiments may envision any number of WTRUs, base stations, networks, and / or network elements. Each of WTRU102a, 102b, 102c, 102d, 102e, 102f, and 102g may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Each WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g is represented in Figures 1A to 1E as a handheld wireless communication device. However, in the diverse use cases envisioned for 5G wireless communication, each WTRU may comprise or be embodied in any type of device or apparatus configured to transmit and / or receive wireless signals, including, but are not limited to, user equipment (UEs), mobile stations, fixed or mobile subscriber units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, tablets, netbooks, notebook computers, personal computers, wireless sensors, consumer electronics, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, cars, trucks, trains, or airplanes.

[0349] The communication system 100 may also include base stations 114a and 114b. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. Base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of RRHs (remote radio heads) 118a, 118b, TRPs (transmit and receive points) 119a, 119b, and / or RSUs (roadside units) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. RRH118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRU102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. TRP119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. RSU120a, 120b may be any type of device configured to wirelessly interface with at least one of the WTRU102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112, and / or V2X server (or ProSe function and server) 113.For example, base stations 114a and 114b may be a base transceiver station (BTS), Node-B, eNode B, home Node B, home eNode B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are shown as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0351] Base station 114a may communicate with one or more WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117, where air interfaces 115 / 116 / 117 may be any suitable radio communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). Air interfaces 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0352] Base station 114b may communicate with one or more of the RRH 118a, 118b, TRP 119a, 119b, and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b, the wired or air interfaces 115b / 116b / 117b 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.). Air interfaces 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0353] RRH118a, 118b, TRP119a, 119b, and / or RSU120a, 120b may communicate with one or more WTRU102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which may be any suitable radio communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

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

[0355] The communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a of RAN103 / 104 / 105, and WTRU102a, 102b, 102c, or RRH118a, 118b, TRP119a, 119b, and RSU120a, 120b of RAN103b / 104b / 105b, as well as WTRU102c, 102d, 102e, 102f, can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) and Terrestrial Radio Access (UTRA), which can establish air interfaces 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 Advanced HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

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

[0357] In one embodiment, base stations 114a of RAN103 / 104 / 105, and WTRU102a, 102b, 102c, or RRH118a, 118b, TRP119a, 119b, and / or RSU120a, 120b of RAN103b / 104b / 105b, as well as WTRU102c, 102d, 102e, 102f, are IEEE802.16 (for example, WiMAX (Worldwide Interoperability for Microwave Access), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile communications (GSM), GSM Evolution (Enhanced Data rates for It can implement wireless technologies such as GSM Evolution (EDGE) and GSM EDGE (GERAN).

[0358] The base station 114c in Figure 8A may be, for example, a wireless router, home Node B, home eNode B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as offices, homes, vehicles, and campuses. In embodiments, the base station 114c and WTRU 102e may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, the base station 114c and WTRU 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114c and WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell. As shown in Figure 8A, the base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not need to access the internet 110 via the core network 106 / 107 / 109.

[0359] RAN103 / 104 / 105 and RAN103b / 104b / 105b may communicate with core networks 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. For example, core networks 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video streaming, etc., and / or implement high-level security functions such as user authentication.

[0360] Although not shown in Figure 8A, it will be understood that 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 RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, or different RATs. For example, in addition to connecting to RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, which may utilize E-UTRA radio technology, core networks 106 / 107 / 109 may also communicate with another RAN (not shown) using GSM radio technology.

[0361] Core networks 106 / 107 / 109 may also function as gateways for Wireless Transmit / Receive Units (WTRUs) 102a, 102b, 102c, 102d, 102e to access the Public Switched Telephone Network (PSTN) 108, the Internet 110, and / or other networks 112. 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 using common communication protocols such as the transmission control protocol (TCP), the datagram protocol (UDP), and the Internet protocol (IP) in the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs that may employ the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, or a different RAT.

[0362] Some or all of the radio transmit / receive units (WTRUs) 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability. For example, WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different radio networks via different radio links. For example, WTRU 102e shown in Figure 8A may be configured to communicate with base station 114a, which may employ cellular-based radio technology, and base station 114c, which may employ IEEE 802 radio technology.

[0363] Figure 8B is a block diagram of an example of an apparatus or device configured for wireless communication according to embodiments illustrated herein, such as WTRU102. As shown in Figure 8B, an example of WTRU102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripherals 138. It will be understood that WTRU102 may include any partial combination of the aforementioned elements while maintaining consistency with one embodiment. Furthermore, the embodiments are intended to include base stations 114a and 114b, and / or, but are not limited to, base stations 114a and 114b, which may represent transceiver stations (BTS), Node-B, site controllers, access points (AP), home Node-B, evolved home Node-B (eNodeB), home evolved Node-B (HeNB), home evolved Node-B gateways, and proxy nodes, etc., as shown in Figure 8B and may include some or all of the elements described herein.

[0364] The processor 118 may be a general-purpose processor, a dedicated 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 functions that enable WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 which can be coupled to a transmit / receive element 122. Although Figure 8B shows the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and 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 air interfaces 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, for example, IR, UV, or visible light signals. In yet another embodiment, the transmit / receive element 122 may be configured to transmit and / or receive both RF signals and optical signals. It will be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of radio signals.

[0366] In addition, although the transmit / receive element 122 is represented as a single element in Figure 8B, 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., multiplex antennas) for transmitting and receiving radio signals via the air interfaces 115 / 116 / 117.

[0367] The transceiver 120 may be configured to modulate the signal transmitted by the transmit / receive element 122 and demodulate the signal received by the transmit / receive element 122. The radio transmit / receive unit (WTRU) 102 may have multimode capability. 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 WTRU102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a Liquid Crystal Display (LCD) unit or an Organic Light-Emitting Diode (OLED) display unit) and may receive user input data from them. 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 any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data in such memory. 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, and the like. In the embodiment, the processor 118 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data in that memory.

[0369] The processor 118 may receive power from the power supply 134 and be configured to distribute and / or control power to other components in the wireless transmit / receive unit (WTRU) 102. The power supply 134 may be any suitable device for supplying power to the WTRU 102. For example, the power supply 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) about the current location of the WTRU 102. In addition to or instead of the information from the GPS chipset 136, the WTRU 102 may determine its location by receiving location information from base stations (e.g., base stations 114a, 114b) via air interfaces 115 / 116 / 117 and / or based on the timing of signals received from two or more nearby base stations. It will be understood that the WTRU 102 may acquire location information by any preferred location determination method, while maintaining consistency with one embodiment.

[0371] The processor 118 may be further coupled to other peripherals 138 and may include one or more software modules and / or hardware modules that provide additional features, functions, 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 photography or video), 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, or a video game player module.

[0372] The wireless transmitter / receiver unit (WTRU) 102 may be embodied in other devices or equipment such as sensors, home appliances, wearable devices such as smartwatches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, cars, trucks, trains, or aircraft. The WTRU 102 may be connected to other components, modules, or systems of such devices or equipment via one or more interconnect interfaces, such as an interconnect interface which may include one of the peripheral devices 138.

[0373] Figure 8C is a system diagram of a radio access network (RAN) 103 and a core network 106 according to an embodiment. RAN 103 may communicate with WTRU 102a, 102b, and 102c via an air interface 115, employing UTRA radio technology. RAN 103 may also communicate with the core network 106. As shown in Figure 8C, RAN 103 may include Node-B 140a, 140b, and 140c, each of which may include one or more transceivers for communication with WTRU 102a, 102b, and 102c via the air interface 115. Node-B 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNC 142a and 142b. It will be understood that RAN 103 may include any number of Node-B and RNC while maintaining consistency with one embodiment.

[0374] As shown in Figure 8C, Node-B 140a and 140b can communicate with RNC142a. In addition, Node-B 140c can communicate with RNC142b. Node-B140a, 140b, and 140c can communicate with their respective RNC142a and 142b via the Iub interface. RNC142a and 142b can communicate with each other via the Iur interface. Each of RNC142a and 142b can be configured to control each of the Node-B140a, 140b, and 140c to which it is connected. In addition, each of RNC142a and 142b can be configured to perform or support other functions such as external loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, and data encryption.

[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 aforementioned elements is represented 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] RNC142a in RAN103 may be connected to MSC146 in core network 106 via the IuCS interface. MSC146 may be connected to MGW144. MSC146 and MGW144 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional terrestrial line communication devices.

[0377] RNC142a within RAN103 may also be connected to SGSN148 in core network 106 via an IuPS interface. SGSN148 may be connected to GGSN150. SGSN148 and GGSN150 may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

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

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

[0380] The Radio Access Network (RAN) 104 may include eNode-B 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of the eNode-B 160a, 160b, and 160c may include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B 160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B 160a can, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0381] Each of the eNode-B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc., on the uplink and / or downlink. As shown in Figure 8D, the eNode-B 160a, 160b, and 160c may communicate with each other via the 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 aforementioned elements is represented 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] The Mobility Management Entity (MME) 162 may be connected to each of the eNode-B 160a, 160b, and 160c within the RAN 104 via the S1 interface and may function as a control node. For example, MME 162 may perform roles such as authenticating users of WTRU 102a, 102b, and 102c, bearer activation / deactivation, and selecting a specific serving gateway during the initial attachment of radio transit / receiving units (WTRUs) 102a, 102b, and 102c. MME 162 may also provide control plane functionality for switching between the Radio Access Network (RAN) 104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0384] The serving gateway 164 may be connected to each of the eNode-B 160a, 160b, and 160c in the radio access network (RAN) 104 via the S1 interface. The serving gateway 164 can generally route and forward user data packets to and from WTRU 102a, 102b, and 102c. The serving gateway 164 may perform other functions, such as anchoring the user plane during eNode-B handover, triggering paging when downlink data is available to WTRU 102a, 102b, and 102c, and managing and remembering the context of WTRU 102a, 102b, and 102c.

[0385] Serving gateway 164 may be connected to PDN gateway 166, which may provide WTRU 102a, 102b, and 102c with access to a packet-switched network, such as the Internet 110, in order to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0386] The core network 107 may facilitate communication with other networks. For example, the core network 107 may provide WTRU 102a, 102b, and 102c with access to circuit-switched networks, such as the Public Switched Telephone Network (PSTN) 108, thereby facilitating communication between WTRU 102a, 102b, and 102c and conventional fixed-line 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 functions as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide WTRU 102a, 102b, and 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] Figure 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) employing IEEE 802.16 radio technology to communicate with radio transmit / receive units (WTRUs) 102a, 102b, and 102c via an air interface 117. 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] As shown in Figure 8E, RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, but it will be understood that the Radio Access Network (RAN) 105 may include any number of base stations and ASN gateways, while maintaining consistency with the embodiment. Each of the base stations 180a, 180b, and 180c may be associated with a specific cell within RAN 105 and may include one or more transceivers for communicating with WTRU 102a, 102b, and 102c via the air interface 117. In one embodiment, the base stations 180a, 180b, and 180c may implement MIMO technology. Thus, base station 180a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. Base stations 180a, 180b, and 180c can also provide mobility management functions such as handoff triggering, tunnel establishment, radio resource management, traffic classification, and quality of service (QoS) policy enforcement. The Access Service Network (ASN) gateway 182 may function as a traffic aggregation point and may perform roles such as paging, subscriber profile caching, and routing to the core network 109.

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

[0390] The communication links between base stations 180a, 180b, and 180c may be defined as R8 reference points, which include protocols to facilitate WTRU handover and data transfer between base stations. The communication links between base stations 180a, 180b, and 180c and the Access Services Network (ASN) gateway 182 may be defined as R6 reference points. R6 reference points may include protocols to facilitate mobility management based on mobility events associated with each of WTRU 102a, 102b, and 102c.

[0391] As shown in Figure 8E, the Radio Access Network (RAN) 105 may be connected to the Core Network 109. The communication link between the RAN 105 and the Core Network 109 may be defined as an R3 reference point, for example, including protocols to facilitate data transfer and mobility management capabilities. 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. Although each of the aforementioned elements is represented 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] MIP-HA may play a role in IP address management and may enable WTRU102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA184 may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between the radio transit / receiving networks (WTRUs) 102a, 102b, and 102c and IP-enabled devices. AAA server 186 may play a role in supporting user authentication and user services. Gateway 188 may facilitate interaction with other networks. For example, gateway 188 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as the Public Switched Telephone Network (PSTN) 108 to facilitate communication between the WTRU102a, 102b, and 102c and conventional fixed-line communication devices. In addition, gateway 188 may provide WTRU 102a, 102b, and 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] Although not shown in Figure 8E, it will be understood that RAN 105 may be connected to other access service networks (ASNs), and core network 109 may be connected to other core networks. The communication link between the radio access network (RAN) 105 and other ASNs may be defined as an R4 reference point and may include protocols for coordinating the mobility of radio transmit / receive units (WTRUs) 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks may be defined as an R5 reference point and may include protocols for facilitating interaction between the home core network and the accessed core network.

[0394] The core network entities described herein and illustrated in Figures 1A, 1C, 1D, and 1E are identified by the names given to them in certain existing Third Generation Partnership Project (3GPP) specifications, but it is understood that in the future, these entities and functions may be identified by other names, and 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 only as examples, and the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or hereafter defined.

[0395] Figure 8F is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks illustrated in Figures 1A, 1C, 1D, and 1E may be embodied, such as RAN 103 / 104 / 105, core networks 106 / 107 / 109, PSTN 108, the Internet 110, or a particular node or functional entity within another network 112. The computing system 90 may be equipped with a computer or server, may be controlled primarily by computer-readable instructions, may be in the form of software, or such software may be stored or accessed anywhere or by any means. Such computer-readable instructions may be executed within a processor 91 to make the computing system 90 function. The processor 91 may be a general-purpose processor, a dedicated 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, and the like. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other functions that enable the computing system 90 to operate on a communication 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 coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0396] During operation, the processor 91 fetches, decodes, and executes instructions, and transmits information to other resources via the main data transfer path of the computing system, the system bus 80. Such a system bus connects the components within the computing system 90 and defines the medium for data exchange. The 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 the PCI (Peripheral Component Interconnect) bus.

[0397] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that enables 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 modified by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide address translation functionality that translates virtual addresses to physical addresses when an instruction is executed. The memory controller 92 can also provide memory protection functionality that isolates processes within the system and separates system processes from user processes. Thus, a program running 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 inter-process memory sharing is configured.

[0398] In addition, the computing system 90 may include a peripheral device controller 83 that plays a role in communicating commands from the 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 includes the electronic components necessary to generate the video signal transmitted to the display 86.

[0400] Furthermore, the computing system 90 may include communication circuits, such as a network adapter 97, which can be used to connect the computing system 90 to an external communication network such as RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, the Internet 110, or other network 112 in Figures 1A, 1B, 1C, 1D, and 1E, enabling the computing system 90 to communicate with other nodes or functional entities in those networks. The communication circuits may be used alone or in combination with the processor 91 to perform the transmission and reception steps of the specific devices, nodes, or functional entities described herein.

[0401] Figure 8G illustrates one embodiment of an example of a communication system 111 in which the methods and apparatus described herein and claimed may be embodied. As shown, an example of a communication system 111 may include radio transmission / receiving units (WTRUs) A, B, C, D, E, F, base stations, V2X servers, and RSUs A and B, but it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. One or more WTRUs A, B, C, D, E may be outside the network (e.g., outside the cell coverage boundary shown as dashed lines in the figure). WTRUs A, B, C form a V2X group, where WTRU A is the group lead and WTRUs B and C are group members. WTRUs A, B, C, D, E, F can communicate via a Uu interface or a sidelink (PC5) interface.

[0402] Any or all of the apparatus, 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, and it is understood that when such instructions are executed by a processor, such as processor 118 or 91, the processor will carry out 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 that are executed on a processor of an apparatus or computing system configured for wireless and / or wired network communication. Computer-readable storage mediums include volatile and non-volatile, removable and non-removable media that are implemented by any non-temporary (e.g., tangible or physical) method or technique for storing information, but such computer-readable storage mediums do not contain signals. Computer-readable storage media include RAM, ROM, EEPROM, flash memory, or other memory technologies; CD-ROM, digital versatile disks (DVDs), or other optical disk storage; magnetic cassettes, magnetic tapes, magnetic disk storage devices, or other magnetic storage devices; or any other tangible or physical media that can be used to store desired information and 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

[0414] Table 11

[0415] Table 12

[0416] Table 13

[0417] Table 14-1

[0418] Table 14-2

Claims

1. A user device (UE) comprising a processor, memory, and a communication circuit for communicating with a network, wherein the memory contains computer executable instructions, and when the computer executable instructions are executed by the processor, the UE receives Transmitting a first request to the network, wherein the first request indicates a first requested network slice selection assistance information (NSSAI), and the first request further indicates that the UE is capable of receiving operating bandwidth information. User equipment (UE) that causes the network to perform an operation including receiving a response from the network that includes an authorized NSSAI, wherein the response further includes authorized operating bandwidth information for one or more single NSSAIs (S-NSSAIs) within the authorized NSSAI.

2. The UE according to the claim, further comprising the operation of displaying permitted operating bandwidth information for one or more S-NSSAIs via a graphical user interface.

3. The UE according to claim 1, further comprising determining a second requested NSSAI using the permitted operating bandwidth information for determination.

4. The UE according to claim 1, further comprising an instruction that the response cannot access one or more of the S-NSSAIs within the permitted NSSAI simultaneously.

5. The UE according to claim 1, further comprising receiving the operational bandwidth information in a non-access layer (NAS) message.

6. The UE according to claim 1, wherein the permitted operating bandwidth information is associated with location information, and the location information indicates one or more regions where one or more operating bandwidths are deemed to be active.

7. The UE according to claim 6, wherein the location information includes a registration area, a tracking area, or a cell identifier.

8. The UE according to claim 1, further comprising receiving the permitted operating bandwidth information in a radio resource control (RRC) message.

9. The UE according to claim 1, wherein the permitted operating bandwidth information includes a cell reselection priority associated with at least one S-NSSAI, and the cell reselection priority is related to idle mode camping.

10. The aforementioned operation, Transmitting a second request to the network, the second request being a radio resource control (RRC) message indicating that the UE desires to access a selected S-NSSAI within the authorized NSSAI that is inaccessible to the UE in the frequency band currently being used by the UE; The UE according to claim 1, further comprising receiving a redirection from the network to a frequency band that can be used to access the selected S-NSSAI.

11. A user device (UE) comprising a processor, memory, and a communication circuit for communicating with a network, wherein the memory contains computer executable instructions, and when the computer executable instructions are executed by the processor, the UE receives Transmitting a first request to the network, wherein the first request indicates a first requested network slice selection assistance information (NSSAI), and the first request further indicates that the UE is capable of receiving simultaneous slice access capability (SSAC) information. User equipment (UE) that performs an operation including receiving a first response from the network, which includes an authorized NSSAI, and further includes SSAC information for one or more S-NSSAIs within the authorized NSSAI.

12. The aforementioned SSAC information is Is it possible that the first S-NSSAI cannot be used with any other network slice? The first S-NSSAI can be used only with network slices having the same slice / service type (SST) value, The first S-NSSAI can be used together with a network slice having the same SST value, The first S-NASSAI can be used with network slices having the same slice numerator (SD) value, or The UE according to claim 11, which indicates that the first S-NSSAI cannot be used with a network slice having the same SD value.

13. The operation further includes receiving an instruction that the first S-NSSAI is associated with a group, The UE according to claim 11, wherein the SSAC information indicates that the S-NSSAI cannot be used with slices that are not part of the group.

14. A user device (UE) comprising a processor, memory, and a network circuit connected to a network, wherein the memory contains computer executable instructions, and when the computer executable instructions are executed by the processor, the UE receives Transmitting a first registration request to the network, which includes a first requested network slice selection assistance information (NSSAI), wherein the first requested NSSAI includes a first single NSSAI (S-NSSAI) and a second S-NSSAI. Receiving a first registration response from the network, which includes a first authorized NSSAI including the first S-NSSAI, a rejected NSSAI including the second S-NSSAI, and a cause code indicating that the second S-NSSAI is incompatible with the first S-NSSAI, Transmitting a second registration request to the network, which includes a second requested NSSAI including the second S-NSSAI, wherein the second registration request excludes the first S-NSSAI. User equipment (UE) that performs an operation including receiving a second registration response from the network, which includes a second authorized NSSAI including the second S-NSSAI.

15. A user device (UE) comprising a processor, memory, and a communication circuit for communicating with a network, wherein the memory includes computer executable instructions, and when the computer executable instructions are executed by the processor, the UE receives A registration request is transmitted to the network, which includes a requested network slice selection support information (NSSAI) that includes at least a first single NSSAI (S-NSSAI) and a second S-NSSAI. Receiving a registration response from the network that includes an authorized NSSAI, wherein the authorized NSSAI includes the first S-NSSAI and the second S-NSSAI. Establishing a first packet data unit (PDU) session using the first S-NSSAI, Sending a first PDU session establishment request to the network relating to establishing a second PDU session, wherein the second PDU session uses the second S-NSSAI, Receiving a PDU session establishment response that includes a cause code indicating that the second PDU session cannot be established because it is not possible to simultaneously maintain PDU sessions with the first S-NSSAI and the second S-NSSAI, Terminating the first PDU session in the first S-NSSAI, To establish the second PDU session, a second PDU session establishment request is sent to the aforementioned network. User equipment, UE, performs an operation that includes receiving a second PDU session establishment response indicating the success of establishing the second PDU session.

Images