WO2022098942A1 - Network controlled ue behavior for slice access - Google Patents

Network controlled ue behavior for slice access Download PDF

Info

Publication number
WO2022098942A1
WO2022098942A1 PCT/US2021/058169 US2021058169W WO2022098942A1 WO 2022098942 A1 WO2022098942 A1 WO 2022098942A1 US 2021058169 W US2021058169 W US 2021058169W WO 2022098942 A1 WO2022098942 A1 WO 2022098942A1
Authority
WO
WIPO (PCT)
Prior art keywords
nssai
slice
network
pdu session
policy
Prior art date
Application number
PCT/US2021/058169
Other languages
French (fr)
Inventor
Jiwan NINGLEKHU
Michael Starsinic
Quang Ly
Catalina MLADIN
Hongkun Li
Original Assignee
Convida Wireless, Llc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Convida Wireless, Llc filed Critical Convida Wireless, Llc
Publication of WO2022098942A1 publication Critical patent/WO2022098942A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/18—Selecting a network or a communication service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/12—Access restriction or access information delivery, e.g. discovery data delivery using downlink control channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W60/00—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration
    • H04W60/04—Affiliation to network, e.g. registration; Terminating affiliation with the network, e.g. de-registration using triggered events
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup

Definitions

  • the 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, and quality of service.
  • Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE-Advanced standards, and New Radio (NR), which is also referred to as “5G” 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz.
  • new RAT next generation radio access technology
  • the flexible radio access is expected to consist of a new, non-backwards compatible radio access in new spectrum below 7 GHz, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements.
  • the ultra-mobile broadband is expected to include cmWave and mmWave spectrum that will provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots.
  • the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.
  • 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility.
  • the use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency Communication (URLLC), Non-Terrestrial Networks (NTN), massive machine type communications (mMTC), network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle- to-everything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities.
  • V2V Vehicle-to-Vehicle Communication
  • V2I Vehicle-to-Infrastructure Communication
  • V2N Vehicle-to-Network Communication
  • V2P Vehicle-to-Pedest
  • Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of tThese use cases and others are contemplated herein.
  • SRMC Slice Resource Management Capability
  • Also described herein is a mechanism by which the network conveys USAB policies to the UE for optimal slice access during UE Registration Procedure or UE Configuration Update procedure. How the UE implements the USAB policies during a UE Registration Procedure to request network slices in an optimal manner is also described.
  • Also described herein is a mechanism for PDU Session release in which, the network sends an explicit release signal to the UE or an explicit release signal with a Grace Timer.
  • Also described herein is a mechanism for PDU Session release in which, a network or UE may apply an additional time called release delay time before releasing a PDU session when the UE encounters a context (e.g., location change).
  • a context e.g., location change
  • a new PDU session control flag is also introduced in the URSP rules, which controls if the UE can establish a new PDU session for a matching Route Selection Descriptor.
  • a method is disclosed by which a UE indicates to the network about the UE’s Slice Remapping Capability (USRC) and the UE’s intention/desire to remap the PDU Session if necessary.
  • USRC Slice Remapping Capability
  • a slice remapping method wherein based on a slice remapping trigger in the network, the network chooses a remapped slice, where PDU Sessions from the old slices are transferred.
  • the UE may receive in the Registration Accept message an Allowed NSSAI that includes the S-NSSAI for the remapped slice with remapped slice indicators and PDU Session IDs for the PDU Sessions that were transferred to the remapped slice.
  • the UE receives remapping rules in the Registration Accept message that indicates to the UE how S-NSSAI(s) in the Rejected NSSAI map to S-NSSAI(s) in the Allowed NSSAI.
  • the UE can consider and access remapped S-NSSAI(s) as equivalent in the Registration Area, should the UE need to access to slices that were rejected.
  • a method for a UE to indicate its preference to receive Remappable Slices during a Registration Procedure and, should the UE Registration procedure be successful, for the network to deliver Allowed NSSAI and Configured NSSAI that preferably consist of S-NSSAI(s) of the Remappable Slices marked with Remappable Slice indicator.
  • Allowed NSSAI and Configured NSSAI that preferably consist of S-NSSAI(s) of the Remappable Slices marked with Remappable Slice indicator.
  • Still further described is a method by which UE may choose to initiate Registration Update procedure with Remappable Slices received in the Configured NSSAI if no Remappable Slices are received in the Allowed NSSAI.
  • the RAN node may receive remapped slices for the Allowed NSSAI in the form of a Slice Remapping table after a successful UE Registration procedure, which is used during slice remapping.
  • FIG. 1 illustrates an example 5G system service-based architecture
  • FIG. 2 illustrates an example non-roaming 5G system architecture in reference point representation
  • FIG. 3 illustrates an example of a UE registering and establishing a PDU session towards one or more network slices;
  • FIG. 4 illustrates an example of USAB policy configuration in a UE
  • FIG. 5 illustrates an example of pre-configured USAB policies and UE configuration update
  • FIG. 6 illustrates an example of PDU session establishment as a UE registers with the network and receives authorized slice(s) information
  • FIG. 7 illustrates an example user interface
  • FIG. 8A illustrates an exemplary communications system
  • FIG. 8B illustrates an exemplary radio access networks (RANs) and core networks
  • FIG. 8C illustrates an exemplary radio access networks (RANs) and core networks
  • FIG. 8D illustrates an exemplary radio access networks (RANs) and core networks
  • FIG. 8E illustrates an exemplary communications system
  • FIG. 8F illustrates an exemplary communications apparatus or device
  • FIG. 8G illustrates an exemplary computing system
  • FIG. 9 illustrates an example use case in which a network slice serving a UE in a first registration area may not be available in a second registration area;
  • FIG. 10 illustrates an exemplary of slice remapping during a UE registration method.
  • FIG. 11 illustrates an example of remappable slice preference during a UE registration method
  • FIG. 12 illustrates an example method for a UE to convey its slice remapping capability during PDU session establishment
  • FIG. 13 illustrates an example method for slice remapping using a RAN node
  • FIG. 14 illustrates an exemplary method for network controlled UE behavior for slice access
  • FIG. 15 illustrates an exemplary method for network controlled UE behavior for slice access.
  • Network Slice A logical network that provides specific network capabilities and network characteristics.
  • Network Slice Instance A set of Network Function instances and the required resources (e.g., compute, storage and networking resources) which form a deployed Network Slice.
  • a Service Area Restriction may contain one or more (e.g., up to 16) entire Tracking Areas each or the Service Area Restriction may be set as unlimited (i.e. contain all Tracking Areas of the PLMN).
  • the UE's subscription data in the UDM includes a Service Area Restriction which may contain either Allowed or Non- Allowed Areas-specified by using explicit Tracking Area identities or other geographical information (e.g., longitude/latitude, zip code, etc.).
  • Tracking Area A tracking area is a set of cells. Tracking areas can be grouped into lists of tracking areas (TA lists), which can be configured on the User Equipment (UE). Tracking Areas (TA) is used for UE’s access control, location registration, paging and mobility management.
  • TA Tracking Area
  • Network Function A processing function in a network, which has defined functional behavior and defined interfaces.
  • An NF can be implemented either as a network element on a dedicated hardware, or as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure.
  • NF instance An identifiable instance of the NF.
  • Slice Registration Hold Time A pre-defined time that describes the inactivity time in a S-NSSAI/slice after UE has received an authorized S-NSSAI for a slice and before UE establishes a protocol data unit (PDU) session towards that slice. For example, if the Slice Registration Hold Time expires for a slice, that slice is removed from the Allowed NS SAI. 2020P00294WG / 106693.001425
  • Session Hold Time A pre-defined time that describes the inactivity time calculated for an established PDU session. In other words, length of time in an established PDU session when no user plane data (UL/DL) is exchanged between the UE and the network. For example, if the Session Hold Time expires for a PDU session, then the session may be released.
  • UL/DL user plane data
  • Slice Remapping is the process of moving a UE’s activity within a first slice to a second slice.
  • Remapped Slice A second slice which acts as an equivalent or substitute for the first slice with respect to capability and service the slice supports.
  • Remappable Slice Any slice for which a remapped slice has been established.
  • the phrase “the UE will Deregister from the Slice” means that, when the slice is in the UE’s Allowed NSSAI, the UE will send a Registration Request to the network without including the slice in the Requested NSSAI of the Registration Request.
  • the phrase “the Network will Deregister the UE from the Slice” means that, when the slice is in the UE’s Allowed NSSAI, the Network will send a UE Configuration Update Request to the UE without including the slice in the Allowed NSSAI of the UE Configuration Update Request.
  • FIG. 1 shows the non-roaming reference architecture with service-based interfaces within the Control Plane.
  • FIG. 2 depicts the 5G System architecture in the nonroaming case, using the reference point representation showing how various network functions interact with each other.
  • a single N1 NAS connection is used for both Registration Management and Connection Management and for Session Management (SM) related messages and procedures for a UE.
  • the single N1 termination point is located in AMF.
  • the AMF forwards SM related NAS information to the SMF.
  • AMF handles the Registration Management and Connection Management part of NAS signaling exchanged with the UE.
  • SMF handles the Session management part of NAS signaling exchanged with the UE.
  • the 5G System architecture is defined to support data connectivity and services enabling deployments to use techniques such as e.g., Network Function Virtualization and Software Defined Networking.
  • the 5G System architecture shall leverage service-based interactions between Control Plane (CP) Network Functions where identified.
  • CP Control Plane
  • An NF is a processing function in a network, which has defined functional behavior and defined interfaces.
  • An NF can be implemented either as a network element on a dedicated hardware, or as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure.
  • a Network Slice is defined as a logical network that provides specific network capabilities and network characteristics.
  • a Network Slice within a PLMN includes the Core Network Control Plane and User Plane Network Functions.
  • Network Slice instance is defined as a set of Network Function instances and the required resources (e.g., compute, storage and networking resources) which form a deployed Network Slice.
  • Network slices may differ for supported features and network function optimizations, in which case such Network Slices may be of different Slice/Service Types.
  • the operator can deploy multiple Network Slice instances delivering the same features but for different groups of UEs, e.g., as they deliver a different committed service or because they are dedicated to a customer, in which case such Network Slices may be of the same Slice/Service Type but are distinguished through different Slice Differentiators.
  • the network may serve a single UE with one or more Network Slice instances simultaneously via a 5G-AN and associated with at most eight different S-NSSAIs in total, regardless of the access type(s) over which the UE is registered (i.e. 3GPP Access or N3GPP Access).
  • the AMF instance serving the UE logically belongs to each of the Network Slice instances serving the UE, i.e. this AMF instance is common to the Network Slice instances serving a UE.
  • a network slice is identified by an S-NSSAI, which is comprised of:
  • SST A Slice/Service type (SST), which refers to the expected Network Slice behavior in terms of features and services;
  • SD Slice Differentiator
  • An S-NSSAI can have standard values (i.e. such S-NSSAI is only comprised of an SST with a standardized SST value, and no SD) or non-standard values (i.e. such S- NSSAI is comprised of either both an SST and an SD or only an SST without a standardized SST value and no SD).
  • An S-NSSAI with anon-standard value identifies a single Network Slice within the PLMN with which it is associated.
  • An S-NSSAI with a non-standard value shall not be used by the UE in access stratum procedures in any PLMN other than the one to which the S-NSSAI is associated. Table 1 shows the standardized SST value.
  • the NSSAI is a collection of S-NSSAIs.
  • An NSSAI may be a Configured NSSAI, a Requested NSSAI or an Allowed NSSAI. There can be at most eight S-NSSAIs in Allowed and Requested NSSAI sent in signaling messages between the UE and the Network.
  • the Requested NSSAI signaled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice instance(s) for this UE.
  • 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 in different Tracking Areas.
  • the AMF instance serving the UE may logically belong to (i.e. be common to) more than one Network Slice instance associated with this S-NSSAI.
  • the 5GC is responsible for selection of a Network Slice instance(s) to serve a UE including the 5GC Control Plane and User Plane Network Functions corresponding to this Network Slice instance(s).
  • the (R)AN may use Requested NSSAI in access stratum signalling to handle the UE Control Plane connection before the 5GC informs the (R)AN of the Allowed NSSAI.
  • the Requested NSSAI is used by the RAN for AMF selection, as described in clause 6.3.5.
  • the UE shall not include the Requested NSSAI in the RRC Resume when the UE asks to resume the RRC connection and is CM-CONNECTED with RRC Inactive state.
  • the CN informs the (R)AN by providing the Allowed NS SAI for the corresponding Access Type.
  • Standardized SST values provide a way for establishing global interoperability for slicing so that PLMNs can support the roaming use case more efficiently for the most commonly used Slice/Service Types.
  • the SSTs which are standardized are in the following Table 1.
  • Configured NSSAI is the NSSAI provisioned in the UE applicable to one or more PLMNs.
  • a Configured NSSAI may be configured by a Serving PLMN and apply to the Serving PLMN. There is at most one Configured NSSAI per PLMN.
  • a Default Configured NSSAI is configured by the HPLMN and that applies to any PLMNs for which no specific Configured NSSAI has been provided to the UE.
  • the value(s) used in the Default Configured NSSAI are expected to be commonly decided by all roaming partners.
  • the Default Configured NSSAI if it is configured in the UE, is used by the UE in a Serving PLMN only if the UE has no Configured NSSAI for the Serving PLMN.
  • the UE may be pre-configured with the Default Configured NSSAI.
  • Requested NSSAI is the NSSAI provided by the UE to the Serving PLMN during registration.
  • the S-NSSAIs in the Requested NSSAI are part of the Configured or Allowed NSSAIs applicable for this PLMN, when they are available. If no Configured
  • the S-NSSAIs in the Requested NSSAI correspond to the Default Configured NSSAI, if configured in the UE.
  • the Requested NSSAI signalled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice instance(s) for this UE.
  • the 5GC is responsible for selection of a Network Slice instance(s) to serve a UE including the 5GC Control Plane and User Plane Network Functions corresponding to this Network Slice instance(s).
  • the (R)AN may use Requested NSSAI in access stratum signalling to handle the UE Control Plane connection before the 5GC informs the (R)AN of the Allowed NSSAI
  • Allowed NSSAI is the NSSAI provided by the Serving PLMN during e.g., a Registration procedure, indicating the S-NSSAIs values the UE could use in the Serving PLMN for the current Registration Area.
  • the UE Upon successful completion of a UE's Registration procedure over an Access Type, the UE obtains from the AMF an Allowed NSSAI for this Access Type, which includes one or more S-NSSAIs and, if needed (see clause 5.15.4.1.2 for when this is needed), their mapping to the HPLMN S-NSSAIs.
  • These S-NSSAIs are valid for the current Registration Area and Access Type provided by the AMF the UE has registered with and can be used simultaneously by the UE (up to the maximum number of simultaneous Network Slice instances or PDU Sessions)
  • the Mapping Of Allowed NSSAI is the mapping of each S-NSSAI of the Allowed NSSAI for the Serving PLMN to the HPLMN S-NSSAIs.
  • the Mapping Of Configured NSSAI is the mapping of each S-NSSAI of the Configured NSSAI for the Serving PLMN to the HPLMN S-NSSAIs. SSC Modes
  • the network preserves the connectivity service provided to the UE.
  • the IP address is preserved.
  • the UPF acting as PDU Session Anchor at the establishment of the PDU Session is maintained regardless of the access technology (e.g., Access Type and cells) a UE is successively using to access the network.
  • the access technology e.g., Access Type and cells
  • IPv4v6 type IP continuity is supported regardless of UE mobility events.
  • SSC Mode 1 may apply to any PDU Session type and to any access type.
  • the network may release the connectivity service delivered to the UE and release the corresponding PDU Session(s).
  • the release of the PDU Session induces the release of IP address(es) that had been allocated to the UE.
  • the network may trigger the release of the PDU Session and instruct the UE to establish a new PDU Session to the same data network immediately.
  • the trigger condition depends on operator policy e.g., request from Application Function, based on load status, etc.
  • a new UPF acting as PDU Session Anchor can be selected. Otherwise, if a PDU Session of SSC mode 2 has multiple PDU Session Anchors (i. e. , in the case of multi-homed PDU Sessions or in the case that UL CL applies to a PDU Session of SSC mode 2), the additional PDU Session Anchors may be released or allocated.
  • SSC mode 2 may apply to any PDU Session type and to any access type.
  • the network allows the establishment of UE connectivity via a new PDU Session Anchor to the same data network before connectivity between the UE and the previous PDU Session Anchor is released.
  • the network decides whether to select a PDU Session Anchor UPF suitable for the UE's new conditions (e.g., point of attachment to the network).
  • PDU Session Anchor UPF suitable for the UE's new conditions (e.g., point of attachment to the network).
  • SSC mode 3 only applies to IP PDU Session type and to any access type. After the new IP address/prefix has been allocated, the old IP address/prefix is maintained during some time indicated to the UE via NAS signaling or via Router Advertisement and then released. If a PDU Session of SSC mode 3 has multiple PDU Session Anchors, the additional PDU Session Anchors may be released or allocated.
  • the UE Route Selection Policy includes a prioritized list of URSP rules. Table 2 shows URSP.
  • UE General behaviors of a UE are to register itself with the core network and establish PDU sessions to send and receive data.
  • UE may receive Configured NSSAI or, may receive Allowed NSSAI from the network if Requested NS SAI was sent in the Registration Request.
  • the UE may initiate PDU Sessions towards one or more slices with S-NSSAIs from Allowed NSSAI.
  • the UE may establish PDU sessions towards one or more data networks.
  • UEs (a mobile phone, smart car, drone, etc.) may use 5GS to carry out respective services.
  • the UE may or may not establish PDU Sessions in the slices. This means that one or more authorized slices could remain “unused” for any services by the UE. But since the slice was regarded authorized and included in the Allowed NSSAI with the Registration Accept message, the network reserves corresponding resources. For example, the UE count for the network slice may be incremented for the registered UEs that received the Allowed S-NSSAI for that slice.
  • an area may be administered for surveillance.
  • FIG. 3 shows that the mobile UE and the drone UE are registered with the network and have been authorized to use classifiedComm and DroneControl slices, respectively. It also shows that although these two UEs are authorized to use their respective slices, they are not utilizing them.
  • the UE may establish a PDU session to send and receive UE data.
  • the PDU session may remain without any UL/DL traffic, and that could be for a substantial amount of time.
  • a smart car may continuously send data via the V2X slice to the network or receive control signal from the network when the car is moving.
  • the registration with the V2X slice may remain intact.
  • a mobile UE which may have had a PDU session earlier, may have that session established but may not have any active UL/DL data for significant amount of time.
  • a mobile UE such as an autonomous vehicle (e.g., AV I) shown in FIG. 9 may have an ongoing PDU session towards the core network via RAN_1 access network.
  • a network slice, V2X_1 is allocated for AV_1 in the core network in the registration area RA I.
  • V2X_1 slice facilitates network infrastructure which provides the required SLA for AV_1.
  • SLA may need to be enforced at all times.
  • AV_1 moves to a different registration area RA_2, it should continue receiving same service as in RA I, desirably without any interruption.
  • the V2X_1 slice may or may not be available in RA_2.
  • UE When UE registers with a network, it may request to register with up to 8 slices.
  • the 5GC does not control how the S-NSSAI(s) in the Requested NSSAI are selected before sending it.
  • UE may decide to attempt to register to any slice from its Configured NSSAI, regardless of whether or not UE intends to access the resources of the slice.
  • This is not an optimal situation because, when the S-NSSAIs remain in the Allowed NSSAI of UE even when UE is not using the services of the slice, the core network still needs to allocate resources for UE in the slices. As a result, resources are wasted.
  • the 5GC needs to be enhanced so that UE-slice registration can be controlled in an optimal manner.
  • the 5GC does not control completely when a UE establishes a PDU Session.
  • Some control over PDU Session establishment is provided by URSP policies which are used by the UE when new application traffic is initiated to determine if a new or existing PDU Session will be used to carry the application traffic.
  • URSP policies which are used by the UE when new application traffic is initiated to determine if a new or existing PDU Session will be used to carry the application traffic.
  • a UE may choose to establish PDU Session(s) towards certain slice/DNN combinations long before Applications on the UE generate traffic for the PDU Session. This is not an optimal situation because, when the PDU Sessions are maintained even when the UE is not using PDU Session, the core network still needs to allocate resources for the PDU Session. As a result, resources are wasted.
  • the 5GC needs to be enhanced so that PDU Session Establishment can be controlled in an optimal manner.
  • a UE may not be actively sending or receiving data, leading to a nonoptimal use of slice resources resulting in a lost utilization opportunity and wasted resources. Therefore, the 5GC needs to be enhanced so that PDU Session Release can be controlled in an optimal manner.
  • a UE may have established PDU sessions in one or more network slices in a given (source) geographical region (e.g., TA, RA, etc.). The UE may move to a different geographical region (e.g., TA, RA, etc.).
  • the UE may move to a different geographical region (e.g., TA, RA, etc.).
  • a UE may have an agreed SLA with the MNO, which needs to be maintained throughout the lifetime of a PDU session.
  • the UE may come across a new scenario, where the network slice that was serving the UE may not be accessible.
  • the 5GS doesn’t provide a service continuity mechanism for PDU sessions that have ongoing services in slices that are not available in the UE’s new RA. This is illustrated in FIG. 9.
  • 3GPP TR 38.832 explores a concept of slice remapping in which the UE may be provided with an equivalent network slice(s) which is able to gracefully accept the PDU session from the source geographical region’s network slice and continue with the services with required SLA.
  • a network may be able to control UE behavior for slice access, both for UE registration with network slices and PDU session establishment towards the slices, in an optimal manner. Following enhancements are disclosed for optimal UE behavior for slice access:
  • SRMC Slice Resource Management Capability
  • a UE that supports the SRMC is able to receive a set of policies for optimal network slice utilization called UE Slice Access Behavior (USAB) policies.
  • USAB are a set of instructions or rules designed to apply various attributes or constraints that instruct UE to request network slices and remove authorized slices and, to establish and release PDU sessions in an optimal manner.
  • the network node that provides the polices to the UE may obtain the policies, or derive the polices, from the UE’s UE Subscription data.
  • a Slice Registration Hold Time is a time which describes the inactivity time in a S-NSSAI/slice after UE has received an authorized S- NSSAI for a slice and before UE establishes a PDU session in that slice.
  • a Session Hold Time is the amount of time that the network tells the UE that a PDU Session may be unused (e.g., no UL or DL data) before it is released.
  • Also described herein is a mechanism for PDU Session release in which, the network sends an explicit release signal to the UE or an explicit release signal with a Grace Timer.
  • the UE may request network for PDU session release or implement the Grace Time before requesting network for PDU session release.
  • Also described herein is a mechanism for PDU Session release in which, a network or UE may apply an additional time called release delay time before releasing a PDU session when the UE encounters a context (e.g., location change).
  • a context e.g., location change
  • a new PDU session control flag is also introduced in the URSP rules, which controls if the UE can establish a new PDU session for a matching Route Selection Descriptor.
  • a UE that has established PDU Sessions in one or more slices in the core network may come across a scenario where the slice may be inaccessible, for example when the UE moves from one registration area to another.
  • the slice may be inaccessible, for example when the UE moves from one registration area to another.
  • 5GS may be enhanced with slice remapping functionality.
  • the following enhancements to slice remapping are disclosed.
  • a method is disclosed by which a UE may indicate to the network about the UE’s Slice Remapping Capability (USRC) and the UE’s intend on/desire to remap the PDU Session if necessary.
  • USRC Slice Remapping Capability
  • a slice remapping method wherein based on a slice remapping trigger in the network, the network chooses a remapped slice, where PDU Sessions from the old slices are transferred.
  • the UE may receive in the Registration Accept message an Allowed NSSAI that includes the S-NSSAI for the remapped slice with remapped slice indicators, and PDU Session IDs for the PDU Sessions that were transferred to the remapped slice.
  • the UE receives remapping rules in the Registration Accept message that indicates to the UE how S-NSSAI(s) in the Rejected NSSAI map to S-NSSAI(s) in the Allowed NSSAI.
  • the UE can consider and access remapped S-NSSAI(s) as equivalent in the Registration Area, should the UE need to access to slices that were rejected.
  • a method for a UE to indicate its preference to receive Remappable Slices during a Registration Procedure and, should the UE Registration procedure be successful, how the network can deliver Allowed NSSAI and Configured NSSAI that preferably include S-NSSAI(s) Remappable Slices marked with Remappable Slice indicator.
  • a UE may choose to initiate Registration Update procedure with Remappable Slices received in the Configured NSSAI if no Remappable Slices are received in the Allowed NSSAI.
  • a RAN node may receive remapped slices for the Allowed NSSAI in the form of a Slice Remapping table after a successful UE Registration procedure, which is used during slice remapping.
  • This disclosure describes enhancement mechanisms to optimize the UE’s behavior as it relates to UE Network Slice registration and de-registration. Similarly, it further describes the enhancement of PDU sessions establishment decisions with the slices and their usage to optimize UE behavior.
  • the mechanism by which UE behavior may be controlled is a capability that a network needs to support. This capability may be referred to as Slice Resource Management Capability (SRMC).
  • SRMC Slice Resource Management Capability
  • the SRMC may be activated and conveyed to the UE by the network.
  • the network may broadcast the SRMC indicator to the UEs.
  • UEs may support SRMC functionality as follows.
  • the UE may request SRMC configuration (e.g., at UE registration) from the network.
  • SRMC configuration e.g., at UE registration
  • the UE’s SRMC configuration request during a UE Registration Request may serve as its indication of support for SRMC and hence, the network may be able to send the policies required to control UE behavior.
  • the UE may convey its support for SRMC during UE Registration Request without any SRMC -related information such as broadcast from the network.
  • the UE may just send an indication for the support of SRMC configuration.
  • the UE’s SRMC configuration request during a UE Registration Request may serve as its indication of support for SRMC and hence, the network may be able to send the policies required to control UE behavior. Note that the mechanisms described in this disclosure may be implemented even without using explicit network or UE SRMC indication (e.g., in the broadcast).
  • One way to control the behavior of the UE for slice access is to configure the UE with policies that control registration decisions.
  • the UE selects a Requested NS SAI or when UE can remove a slice from its Allowed NSSAI (e.g., via a Registration Update) so that network utilization is optimal.
  • a UE may initiate a registration process, which includes receiving authorized network slices based on user input, application requirements, UE type and function, UE capabilities, SLAs, operator policies, environmental contexts like time, place, etc.
  • the UE is also configured with UE Slice Access Behavior (USAB) policies.
  • USAB Policies may be part of the URSP policies, part of the Access and Mobility Policies, or they may be stored as a set of policies that are separate from the URSP and Access and Mobility Policies.
  • the USAB policies may be stored as part of the Configured NS SAI or the Allowed NS SAI.
  • the USAB Policies may be pre-configured or may be received from the network.
  • the USAB policies may be received during the UE Registration Procedure or UE Configuration Update Procedure.
  • the UE may indicate in the UE Registration Procedure that the UE is capable of receiving and applying/enforcing USAB Policies.
  • the USAB policies control when the UE attempts to register with the slices (e.g., send a registration request with the associated S-NSSAI in the Requested NSSAI).
  • the policies may describe what events and conditions, or combination of events (e.g., application traffic or request, no other suitable slice, etc.) should occur or what criteria or conditions (e.g., time of day, UE location) should be met before the UE attempts to register with the slice.
  • the USAB policy For each slice (S-NSSAI) in the Configured NSSAI or the Allowed NSSAI, the USAB policy provides the following six rules or instructions.
  • First, an instruction that the UE should always (herein “always” is meant to be for a defined amount of time or instructed otherwise) include the S-NSSAI in the Requested NSSAI if the UE enters a new Registration Area or when the UE performs any Registration Update.
  • the instruction may be further associated with location information that indicates when the UE should, or should not, attempt to apply the policy.
  • an instruction that the UE should only register for a network slice if an application requests to use it may indicate that the UE should send a Registration Request and include the slice in the Requested NS SAI only when a UE application explicitly requests to utilize the slice (e.g., via an API or AT Command).
  • the USAB policy that is associated with the slice may indicate to the UE that the UE should attempt to register with the slice when traffic belonging to certain access categories is being generated and can be assigned to the slice.
  • the USAB policies may include the following information. First, instruction to only apply a policy in certain time period(s). Second, instruction to only apply a policy in certain location(s) or registration areas or tracking areas or PLMNs. Third, if the UE is a multi-user UE, instruct to apply a policy only for specific users.
  • a multi-user UE may be a 5G router where many UEs are connected and that UE ID may behave as a User ID.
  • an autonomous vehicle may be a multi-user UE that could have multiple drivers (users). In this case, some considerable IDs may be human identifiable IDs (names), unique biometrics, alias ID number, etc.
  • a vehicle’s conveniences e.g., infotainment, work, speed, comfort, etc.
  • a policy e.g., request certain S- NSSAIs
  • the UE is a member of a group (e.g., co-operative robots).
  • the UE instruct the UE not to apply the policy in certain operating band(s) or, to only apply the policy in certain operating bands.
  • UE de-registration from slice(s) may play an important role in UE’s optimal behavior. This section describes when a UE may deregister from an S-NSSAI.
  • the USAB policies may include slice de-registration instructions for a UE.
  • a USAB policy may instruct the UE when to send a Registration Update in which, an S-NSSAI to be de-registered is removed from its Requested NSSAI (e.g., send a Requested NSSAI to the network that does not include at least one of the S-NSSAI(s) that are currently in the UE’s Allowed NSSAI).
  • the USAB may provide the following six instructions to the UE.
  • an instruction for the UE to De-register from the slice if no MO or MT user plane traffic has been received for the slice for a certain amount of time The UE may maintain a timer for the slice when the UE is registered to the slice and reset the timer each time data is sent or received for the slice.
  • an instruction that the UE should Deregister from the slice if no control plane traffic has been received for the slice for a certain amount of time e.g., SMS, NIDD, or Service Requests).
  • the UE may maintain a timer for the slice when the UE is registered to the slice and reset the timer each time control plane data is sent or received for the slice.
  • an instruction for the UE to Deregister from the slice if no PDU session has been established for a certain amount of time may maintain a timer for the slice when the UE is registered to the slice and run the timer only when there is no PDU Session associated with the slice.
  • the timer may be triggered to de-register from the slice(s) or the network may also trigger the process to de-register the slices for the UE.
  • the timer may be triggered to de-register from the slice(s) or the network may also trigger the process to de-register the slices for the UE.
  • This inactivity time may be referred to as the Slice Registration Hold Time.
  • An operator may convey a Slice Registration Hold Time to the UE upon successful UE registration.
  • the Slice Registration Hold Time may be slice-specific.
  • Slice Registration Hold Time for each slice may be different, which may be based on system factors such as slice priority, urgency, security, safety, or SLA, and is configured by the network operator.
  • the Slice Registration Hold Time may be different and customized for each UE registered to a slice. For example, if the slice is designed and dedicated for critical system applications, then the Slice Registration Hold Time may vary for that slice as opposed to personal loT slice.
  • the Slice Registration Hold Time for a UE may be delivered to the UE via USAB policies. Alternatively, it may also be conveyed to the UE separately after a UE successfully register to the network in the Registration Accept message.
  • the USAB policy is made up of instructions or rules. Each instruction may be designed such that it takes parameters for certain attributes and contexts and uses them to determine how and whether to apply certain USAB policies. Previous sections discussed many example instructions or rules for UE Slice Registration and UE Slice De-Registration as being parts of the USAB policy. Example USAB policy attributes are depicted and briefly described in Table 5.
  • the policies may include constraints which can act as a controlling element in the policies as described in Table 6. USAB Policies, or indications in the policies, can be associated with these constraints so that the UE can know to only apply the policy when the conditions in the constraints apply. When the conditions in the constraints do not apply, the UE may consider the slice to be inaccessible or the UE may consider the policy to be invalid under the current conditions.
  • USAB policies that influence the behavior of a UE may be configured in the UE during the registration procedure. This capability may be configured in the AMF.
  • the enhanced slice deregistration rules on the network side may be configured at the AMF. These rules as well as the capabilities may be provided to AMF 203 by PCF 204.
  • the USAB configuration procedure is depicted in FIG. 4.
  • the network operator may configure USAB policies for UE 201 along with Subscribed NSSAIs within the Access and Mobility Subscription data.
  • UE 201 may send a Registration Request to AMF 203 via RAN 202.
  • the registration request may indicate that UE 201 is capable of receiving and enforcing USAB policies (e.g., the request may include the SRMC indication).
  • step 212 upon receiving a Registration Request, AMF 203 may send a Nudm_SDM_Get message to get UE 201 subscription information from UDM 205.
  • UDM 205 may deliver the USAB policy information as part of the Access and Mobility Subscription data and send back to AMF 203.
  • Step 213 may involve Steps 15 to 19 from clause 4.2.2.2 of TS 23.502.
  • AMF 203 delivers the USAB policies to UE 201 as part of the Registration Accept message after a successful UE 201 registration.
  • AMF 203 may also deliver the USAB policies to UE 201 if the registration was not accepted given that UE 201 passed the authorization and authentication phase of the Registration procedure and slicespecific authentication and authorization if required for any S-NSSAI and, may indicate in the Registration Reject message why the registration was not successful.
  • step 215 after UE 201 has received a Configured NSSAI and USAB policy from the network, UE 201 may send Registration Request back to the network. Now, UE 201 may execute USAB policies by checking the criteria, conditions, and attributes that
  • UEs may need a service from a network slice as soon as it is powered on.
  • an loT device that doesn’t have a GUI or any external trigger, which may start sensing and sending data as soon as it is powered on.
  • a vehicular UE may need the access to slice urgently upon startup.
  • These types of UEs may have to register and establish a PDU session as soon as they start.
  • a preconfigured USAB policy may be appropriate which allows the UE to select S-NSSAI(s) based on what startup application(s) starts, contexts, SLAs or other attributes and policies discussed previously, and send it in the Registration Request to the network.
  • the network may be able to send an updated USAB policy if required, using UE Configuration Update Command.
  • a registration procedure that employs pre-configured USAB policy and UE Configuration Update procedure for USAB policies is depicted in FIG. 5 and described as follows.
  • UE 201 may be pre-configured with USAB policy. When UE 201 starts up, it is triggered for registration next. Before UE 201 starts the registration procedure, UE 201 may evaluate the USAB policy. USAB policy discussed in previous section includes various instructions that helps UE 201 to decide on the selection of S- NSSAIs to generate the Requested NSSAI for Registration Request.
  • UE 201 may send a Registration Request to AMF 203 via the RAN.
  • UE 201 takes into account the Requested NSSAI that was populated based on USAB policy.
  • UE 201 may also follow other instructions that USAB policy instructs UE 201 to abide by.
  • AMF 203 receives the Registration Request.
  • AMF 203 may send a Get UE subscription information (Nudm_SDM_Get) message to the UDM/UDR 205.
  • UDM 205 sends back to AMF 203 the UE Subscription Information which includes that Access and Mobility data for the requesting UE 201.
  • the UE Subscription information may
  • 4871-1319-0402.1 include US AB policies for UE 201.
  • AMF 203 may identify that UE 201 is pre-configured with the USAB policy based on the Registration Request. Based on the local policy, UE 201 may overwrite the existing USAB policy of UE 201.
  • UE registration may be an appropriate procedure wherein, the network may update the pre-configured or pre-existing USAB policy at UE 201.
  • AMF 203 may check the Requested NSSAI and if the UE Subscription includes the subscribed S-NSSAIs that match the request, AMF 203 includes them in the Allowed NSSAI in the Registration Accept message.
  • AMF 203 may determine, based on the response received from PCF 204 or UDM 205, that UE 201 needs a new USAB policies, which means AMF 203 may need to initiate a UE Configuration Update procedure.
  • AMF 203 may send to UE 201, a UE Configuration Update command, which may include the new USAB policies for UE 201.
  • UE 201 may send an acknowledgement back to AMF 203 confirming its receipt.
  • Step 224-b UE 201 may use the USAB policies to make registration and PDU Establishment / Release decisions, which may include preparation of a Requested NSSAI. UE 201 may then send a UE Registration Update to the network via RAN 202. Controlling PDU Session Establishments
  • This section describes various enhanced methods that can control PDU sessions establishment and release procedures between a UE and the network for optimal utilization of network resources.
  • UE 201 may be instructed to handle PDU session establishment towards network slice(s) on an as-need basis such that network resources are utilized at their best.
  • the UE’s PDU session establishment may be motivated by user’s desires, UE type and function, network decisions, UE capabilities, SLAs, operator policies, agreement with data network (provider), environmental contexts like time, location, etc. For instance, some of the UEs, upon meeting a criterion, may end the PDU session, while other UEs may keep the PDU session intact and not send or receive any data. For example, a user surfing the web or streaming a video may put his phone down to go to bed. It might be more efficient, from a
  • the network may convey UE behavior instructions via policies to UE 201.
  • the USAB policies discussed in the previous sections may be extended to include policies for optimal control of PDU sessions. This may mean instructing UE 201 when to perform the establishment of new PDU sessions and ending of established PDU sessions towards a network slice(s) more dynamically.
  • UE 201 may be pre-configured with USAB policies or may receive them during a successful completion of UE registration procedure or during a UE Configuration Update Procedure. Based on the features and motivations discussed, following are some example instructions (eight instructions) that an operator may want UE 201 to follow for optimal PDU sessions establishment with the network slices.
  • Certain UEs may be privileged to access some contents that are only accessible in certain areas and are accessible only via the DNN. Eighth, instruct UE 201 to trigger a network slice registration, if during a PDU session establishment UE 201 requires access to a network slice.
  • the indication may be part of an RSD and it may indicate to UE 201 that UE 201 should attempt to add the slice to UE 201’s Allowed NSSAI via a Registration operation so that UE 201 may attempt to establish a PDU Session in the slice.
  • the USAB policy may include PDU session release policies, such as the five below.
  • First instruct UE 201 to release PDU session if there is no activity (e.g., no UL or DL data) for a specified amount of time called Session Hold Time.
  • a Session Hold Time is a pre-defined time period accounted for no activity in an established PDU session. For example, if there are no UL/DL data in the PDU session for a certain amount of time, the PDU session may be released.
  • instruct UE 201 to wait for a certain amount of time, before releasing the ongoing PDU session upon meeting a context (e.g., time, tracking area, etc.).
  • instruct UE 201 to release certain PDU session upon meeting a context or condition.
  • UE 201 may be allowed to access content (e.g., stream video, play an online video game, etc.) from the network within a given time period and, the length of PDU session may be updated based on charging information (e.g., score, payment, etc.).
  • charging information e.g., score, payment, etc.
  • only certain number of PDU Sessions from a home 5G router from a user account may be established towards a DNN, LADN or an edge server.
  • Fifth instruct UE 201 to release an established PDU session in the slice after no application has used the PDU session for a specified Session Hold Time.
  • UE 201 may initiate a request to establish a PDU session when it requires a service. In other words, UE 201 requests for PDU session when it wants to receive or send user data to or from the network.
  • UE 201 may need to start and end PDU sessions by following dynamic triggers that is beyond just a user requesting a service. For example, a low power loT device (e.g., a remote temperature sensor) may need to start sending data as soon as it gets registered to with the network and the network slice. This may mean that the successful registration procedure where UE 201 receives an Allowed NSSAI, acts as a trigger for UE 201 to establish a PDU session towards the allowed S-NSSAIs and start sending data or receive any appropriate data from the network.
  • a low power loT device e.g., a remote temperature sensor
  • the network may send to UE 201, an indication to establish a PDU session after UE 201 has received Registration Accept message.
  • FIG. 6 shows procedures by which PDU session is established as UE 201 registers with the network and receives authorized slices’ information.
  • Step 231 UE 201 goes through successful UE registration procedure when UE also receives Allowed NSSAI from the network.
  • UE 201 may receive a USAB policy that indicates that certain PDU Sessions should be established immediately after the Registration Procedure completes.
  • Step 232-a UE 201 may be triggered to establish a PDU session towards a specified and an authorized slice by executing USAB policy.
  • UE 201 may receive an instruction with the Registration Accept message. This instruction further may include the S-NSSAI where UE 201 needs to establish a PDU session.
  • Step 232-b alternatively, after successful UE registration with Allowed NSSAI, the network may send a trigger to UE 201.
  • the trigger may be carried via SMS / NAS messaging towards an application on UE 201. This trigger may indicate to the application an S-NSSAI and DNN where UE needs to establish a PDU session.
  • UE 201 application may then attempt to Register with the slice and send a request for a PDU session establishment towards the slice.
  • the overall 5GS performance may be enhanced if UE 201 can optimize its behavior.
  • One such frequent behavior is establishment and release of PDU sessions. This section describes how and on what occasions UE 201 can release PDU sessions without affecting the operation while optimizing the performance of the 5GS.
  • UE may have many occasions when UE establishes a PDU session with the core network and exchanges user plane data with the network. However, the established PDU session may remain established even when there is no data in the session or, until the network or the UE triggers a PDU session release indication, which may not be guaranteed.
  • the UE After a successful authentication and authorization, the UE establishes a PDU session with the UPF and may start exchanging user plane data.
  • a UPF is aware of UL and DL traffic. Hence, the UPF may be able to sense an inactive PDU session.
  • An inactive PDU session After a successful authentication and authorization, the UE establishes a PDU session with the UPF and may start exchanging user plane data.
  • a UPF is aware of UL and DL traffic. Hence, the UPF may be able to sense an inactive PDU session. An inactive
  • a Session Hold Time may be activated every time the PDU session stops receiving or sending data.
  • the Session Hold Time may be pre-defined by the operator and may vary among UEs based on attributes such as type of service, slice type, etc.
  • a Wait Time is the time that a UPF waits for another piece of data after the last piece of data has been exchanged in an established PDU session.
  • a Session Hold Time may be activated at the SMF or UPF. If no data is sent or received in that PDU session within the Session Hold Time, then the SMF may take action to release a PDU session between the UE and the network.
  • Session Hold Time may be conveyed as part of the USAB policy and invoked at the UE. This information may be conveyed in PDU Session Establishment Response or PDU Session Establishment Modification message.
  • a UE may activate both Wait Time and the Session Hold Time in the UE. If no user plane data is sent or received over an established PDU session than Session Hold Time is enforced. As the Session Hold Time expires, the UE may request network to release the PDU session. As the AMF receives the PDU session release request, the AMF conveys the request to the SMF. The SMF may send a PDU session release command to the UPF.
  • the 5GS may include following enhanced methods for releasing a PDU session.
  • the UPF may inform about the expired Session Hold Time to the SMF. Otherwise, the SMF may administer the Session Hold Time.
  • the SMF/UPF learns that the Session Hold Time has expired, the SMF may initiate the PDU Session release procedure that is described in section 4.3.4 of TS 23.502.
  • the SMF may send a notification to the UE to inform the UE that the timer has expired.
  • the notification may be received by the UE as a request to consider initiating the release of the PDU Session. For example, after receiving the notification, the UE may decide to send the PDU Session Release Request to the network if the UE does not anticipate using the PDU Session again soon.
  • the SMF receives such request, the SMF
  • the 4871-1319-0402.1 may send session release signal to the UPF eventually ending the PDU session with the UE.
  • the notification from the SMF to the UE may include a Grace Time.
  • the Grace Time may indicate to the UE that the network will terminate the PDU Session if it is not used within the grace time or if the UE does not terminate (e.g., release) the session within the grace time.
  • the UE may meet certain context such as a specified time, TA/RA change or change of geographic location.
  • This event might send a trigger in the network (e.g., AMF, SMF, or UPF) to end an ongoing PDU session and block the UE’s exchange of data with the associated network slice.
  • UE generally may release the PDU session and start a PDU session towards a slice in which data exchange is allowed.
  • the UE may initiate a UE Registration Update procedure with the network to register with a slice that would allow UE to exchange data with the network.
  • the PDU session release may be enhanced so that the release is delayed for a considerable amount of time with a Release Delay Timer.
  • a Release Delay Timer For instance, if the UE (e.g., drone) passes by a TA, and with a probability that it may come across a new TA that may allow for the UE to use the existing PDU session or a graceful handover of the PDU session, the PDU session release may be delayed by certain amount of time.
  • This PDU session Release Delay Time may be administered at the AMF/SMF and a notification of such a context may be sent to the UE.
  • UE and network/UPF may not exchange any UP data.
  • UE may be instructed to practice Release Delay Time when sending a request for PDU session release to the AMF.
  • a Release Delay Time information may be conveyed to the UE with USAB policy.
  • a URSP rule When a URSP rule is determined to be applicable for a given application (e.g., the Traffic Descriptor matches the application traffic), the UE shall select a Route Selection Descriptor (RSD) within this URSP rule in the order of the Route Selection Descriptor Precedence.
  • RSD Route Selection Descriptor
  • the UE determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor.
  • the UE compares the components of the selected Route Selection Descriptor with the existing PDU Session(s).
  • the UE associates the application to the existing PDU Session. If none of the existing PDU Sessions
  • the UE tries to establish a new PDU Session using the values specified by the selected Route Selection Descriptor. If the UE fails to establish a PDU session with any of the Route Selection Descriptors, it tries other URSP rules in the order of Rule Precedence with matching Traffic descriptors, except the URSP rule with the "match-all" Traffic descriptor, if any. If a “match-all” Traffic descriptor exist, then the URSP rule with the "match all" Traffic descriptor is used to route the traffic of applications which do not match any other URSP rules and shall therefore be evaluated as the last URSP rule, e.g., with the lowest priority.
  • the URSP rule may be enhanced with a flag in the RSD, such that the UE behavior for slice access can be optimized.
  • the flag is introduced to help steer the UE towards using existing PDU Sessions and avoid establishing new PDU Sessions.
  • the UE will first check if there are existing PDU Sessions with favorable, or acceptable characteristics before attempting to establish a new one. This flag may be called the “Session Control Flag”.
  • Table 7 depicts enhanced UE Route Selection Descriptor which is an extended version of Table 4.
  • a new Route selection component called “Session Control Flag” has been included to control a creation of new PDU sessions, which is described in this section.
  • the new session control flag may logically change the evaluation of URSP Rules and RSDs to have the effect that UE will be more likely to use existing PDU sessions than establish new PDU sessions.
  • the UE is registered to a URLLC slice and an eMBB slice.
  • the UE may have a PDU Session established in the URLLC slice, but no PDU Session in the eMBB slice.
  • the eMBB traffic may match a URSP rule as shown in Example 1 below.
  • RSD X (describes an eMBB Slice PDU Session)
  • the UE will check if there is a PDU Session that matches the highest precedence RSD X (on the eMBB slice). If there is a PDU Session that
  • the “Session Control Flag” be added to the RSD so that the network can indicate to the UE if the UE should preferably use a PDU Session that is associated with a lower precedence RSD before attempting to establish a new PDU Session with the RSD.
  • the UE may already have some ongoing URLLC traffic.
  • the UE has 1 PDU Session and it matches RSD Y (with a URLLC Slice).
  • RSD Y with a URLLC Slice
  • some eMBB traffic starts.
  • the network prefer that the UE use the URLLC Slice for the eMBB traffic since UE is already using a PDU Session in the URLLC slice.
  • Example 2 describes how the flag might be processed in order to cause the UE to route the eMBB traffic onto the URLLC slice.
  • RSD XI is the same as RSD X2, except for the state of the flag.
  • RSD Y1 is the same as RSD Y2, except for the state of the flag.
  • the UE when the UE sees traffic that matches the eMBB traffic descriptor, it will check if there is a PDU Session that matches RSD XI (e.g., a PDU Session in the eMBB slice). If there is a PDU Session in the eMBB slice, then it will use it. In this example, there is no such PDU Session. Since the “Session Control Flag” is set in RSD XI, the UE will not attempt to establish a PDU Session with RSD XI. The UE will then check if there is a PDU Session that matches RSD Y1 (in the URLLC slice).
  • RSD XI e.g., a PDU Session in the eMBB slice
  • the UE Since there is a PDU Session that matches RSD Y1 (in the URLLC slice), the UE will use the existing session for the eMBB traffic. Thus, the UE will use a single PDU session for both its URLLC and eMBB traffic.
  • the UE may be allowed to evaluate the RSD a two times. During a first evaluation of the RSDs in precedence order, the UE may not be allowed to establish a PDU session for any RSD whose “Session Control Flag” is set. During the second evaluation of the RSDs in precedence order, the UE may ignore the “Session Control Flag”. This is detailed in Example 3. The benefit of this approach, compared to Example 2, is that fewer RSDs will need to be sent to the UE.
  • RSD X (describes an eMBB Slice PDU Session, the “Session Control Flag” is set)
  • RSD Y (describes an URLLC Slice PDU Session, the “Session Control Flag” is set) [00190] In this example, if UE sees traffic that matches the eMBB Traffic
  • Descriptor then it will check if there is a PDU Session that matches RSD X (in the eMBB slice). If there is a PDU Session that matches RSD X, then the UE will use it. In this example, there is no such PDU Session. So, the UE will check if there is a PDU Session that matches RSD Y (in the URLLC slice). If there is a PDU Session that matches RSD Y, then the UE will use it.
  • the UE will go back to the highest precedence RSD and evaluate RSDs again, this time ignoring the state of the Session Control Flag and will try to establish a PDU Session that matches RSD X. If a PDU Session that matches RSD X cannot be established, then the UE will try to establish a PDU Session that matches RSD Y. If a PDU Session that matches RSD Y cannot be established, then UE will move to a lower precedence URSP rule.
  • the indicator that controls the PDU session establishment for optimal performance may be integrated into the URSP rules as shown in Table 8.
  • the RSD evaluation follows the existing functionality. That is, if there exists a matching RSD, the UE may simply use the existing PDU session to send the user plane data as per existing URSP policies. If there is not an existing PDU session, the UE is allowed to establish a new PDU session with the matching RSD.
  • the URSP rule in Table 8 is evaluated as follows. Traffic is generated by Appl.
  • the NAS layer in the UE examines the traffic and detects that the traffic matches Appl.
  • the UE checks the URSP rule with Rule Precedence 1 and finds that the traffic matches the traffic descriptor.
  • the UE will evaluate the RSD(s) that are associated with the rule. In the first URSP rule example of Table 8, there is 1 RSD. If there is an existing PDU Session that matches the RSD (S-NSSAI-B and DNN_A) then the UE will use that PDU Session for Appl.
  • the UE will attempt to establish a PDU Session with the RSD (S-NSSAI-B and DNN_A), based on existing URSP procedure.
  • the UE only establishes a PDU Session with the RSD (S-NSSAI-B and DNN_A) if “Session Control Flag” flag is not set. If the PDU session could’t be created, UE may continue with URSP evaluation (e.g., move to lower precedence RSD(s) and eventually lower precedence URSP rule(s)). But in the first URSP example above, the “Session Control Flag” flag is set and, since it has only 1 RSD. the UE may attempt to_establish the PDU Session with the RSD.
  • the UE will use that PDU Session for traffic from App2. If there is no existing PDU Session that matches the RSD with Precedence 1, then the UE will try to establish a new PDU session with the RSD: S-NSSAI-A, DNN B and 3GPP access. If the PDU session cannot be established then the UE will evaluate the RSD with Precedence 2 (S-NSSAI-C, DNN_B and Non-3GPP access).
  • the UE will use that PDU Session for App2 traffic. If there is no existing PDU Session that matches the RSD with Precedence 2, then the UE will try to create a new PDU session with S-NSSAI-C, DNN_B and Non- 3 GPP access.
  • the UE only establishes a new PDU Session that matches the RSD: S-NSSAI-A, DNN_B, and 3GPP access, if “Session Control Flag” flag is
  • the “Session Control Flag” flag is set, in the first RSD. Therefore, if there is no existing PDU session matching RSD: S-NSSAI-A, DNN_B and 3GPP access, the UE will evaluate the RSD with Precedence 2 (S-NSSAI-C, DNN_B and Non-3GPP access). If there are no existing PDU Session with RSD: S-NSSAI-C, DNN_B and Non-3GPP access and since the “Session Control Flag” flag is not set, the UE may attempt to create anew PDU Session with this RSD.
  • Slice Remapping is the act of moving a UE’s activity from a first slice to a second slice.
  • An example of activity within a slice is a PDU Session.
  • an example of slice remapping is moving a PDU Session from a first slice to a second slice.
  • an example of slice remapping is changing the S-NSSAI that is associated with a PDU Session.
  • Slice Remapping may be triggered by an event.
  • the event will be an event that causes the first network slice to no longer be accessible to the UE.
  • An example of an event that might trigger slice remapping is the first slice becoming unavailable during UE mobility. A slice might become unavailable to a UE because it moves to a Tracking Area (TA) or Registration Area (RA) where the first slice is not available.
  • Another example of an event that might trigger slice remapping is the UE determining to request to register to a second slice in a scenario where simultaneous registration with the first and second slices is not allowed.
  • Other triggers for slice remapping include scenarios where the RAN node doesn’t support the first slice, the first slice is not supported in the VPLMN, the first slice is too congested in the network, the required frequency of the first slice is not supported as the UE moves to a new TA/RA, etc.
  • Slice Remapping is particularly desirable to the UE when the UE has PDU Sessions of SSC Mode 1 established in the slice that needs to be remapped.
  • UPF that acts as the PDU Session anchor will be maintained through the Slice Remapping operation.
  • the UPF that acts as the PDU Session anchor must be part of both the first and second slices.
  • the UE may expect that PDU Session connectivity via the first slice is not lost until PDU Session connectivity via the second slice is established.
  • Slice Remapping may be triggered by an event such as a first slice becoming unavailable or the UE’s desire to register with a second slice. In both examples, the event would trigger the UE to send a Registration Request to the network.
  • FIG. 10 depicts a method for Slice Remapping during UE Registration.
  • UE 201 may have an established PDU session with a data network via a first network slice.
  • the PDU session may be associated with an anchor UPF 209.
  • an event causes UE 201 to send a UE Registration Request or Registration Update to the network (e.g., new AMF 208) via the new RAN node 207.
  • UE 201 may include UE Slice Remapping Capability (USRC) indicator.
  • USRC UE Slice Remapping Capability
  • UE 201 also includes in the Registration Request, the PDU Session Status, Requested NSSAI, Mapping Of Requested NSSAI, Default Configured NSSAI Indication, among other parameters.
  • UE 201 may include an indication for UE 201 ’s desire/intention for slice remapping if slice remapping is necessary.
  • UE 201 can indicate to the network which PDU Session should be remapped if the network determines that remapping is necessary.
  • the network e.g., the new AMF 208 may determine that slice remapping is necessary if the S-NSSAI that is associated with the PDU Session cannot be allowed for UE 201 by the new AMF 208. Note that the AMF may not change during a UE handover from one RAN to another.
  • Step 242 depicts UE Registration Procedure Steps 4-9 from Figure 4.2.2.2.2-1 of TS 23.502.
  • the new AMF 208 determines that it cannot serve one or more PDU sessions (e.g., because the S-NSSAI that is associated with the PDU Session is not available in the new Registration Area). However, the new AMF 208 determines from the PDU Session Status that slice remapping is requested for one or more of those PDU Sessions. The new AMF 208 will next determine if slice remapping is possible for the requested PDU session(s).
  • the new AMF 208 may determine if slice remapping is possible by first checking if local policies indicate that the S-NSSAI that is associated with the PDU Session may be remapped to a second S-NSSAI by the new AMF 208. If the new AMF 208 determines that policies allow the S-NSSAI to be remapped to a second S-NSSAI, the new AMF 208 will next check if UE 201 second S-NSSAI is in UE 201’s subscription or if the second S-NSSAI was included in UE 201 ’s Requested NSSAI.
  • the new AMF 208 may include the second S-NSSAI in UE 201’s Allowed NSSAI.
  • the new AMF 208 will indicate to UE 201 that the second S-NSSAI is present in the Allowed NSSAI for remapping purposes.
  • the AMF may provide the second S-NSSAI, not in the
  • step 244 provided that the slices (identified in Step 243) can be remapped, the new AMF 208 sends the PDU Session ID(s) for PDU Sessions that can be remapped to the old AMF 203.
  • the message will also provide the old AMF 203 with the S- NSSAI’s that PDU Sessions will be remapped to.
  • the old AMF 208 will then notify the SMFs 206 that are managing the PDU Sessions.
  • the notification message from the old AMF 203 to the SMF 206 will also provide the S-NSSAI’s that the PDU Session will be remapped to.
  • the SMF 206 will change the PDU Session to be associated with the new S-NSSAI. If the SMF 206 is not associated with the S-NSSAI that the PDU Session will be remapped to, then the SMF 206 may select a second SMF which is associated with the S-NSSAI that the PDU Session will be remapped to. The SMF 206 will then invoke the
  • Nsmf PDUSession ContextPushRequest operation to send the PDU Session context to the second SMF so that the second SMF can serve the PDU Sessions.
  • the old AMF 203 may select the second SMF which is associated with the S-NSSAI that the PDU Session will be remapped to.
  • the old AMF 203 invokes Nsmf_PDUSession_ContextRequest to request PDU Session context from the old SMF 206.
  • the Old AMF passes the PDU Session context received from the old SMF 206 to the new SMF associated with the remapped slice.
  • the new SMF may then serve the PDU Sessions.
  • the SMF 206 whether the old SMF or the new SMF, notifies UPF 209 of the slice remapping event by changing the TEID to the new RAN node 207 in the case of SSC Mode 1.
  • SMF 206 may respond to the old AMF 203. The response will indicate to the old AMF 203 if the remapping operation was successful.
  • the old AMF 203 may send a response message to the new AMF 208, the response indicates if the remapping operation was successful.
  • the new AMF 208 sends a Registration Accept message to UE 201 via the new RAN 207.
  • the new AMF 208 may include the PDU Session status, the Registration Area, and Allowed NSSAI.
  • the message may also include the PDU Session ID(s) for which the slices have been remapped and indicate S-NSSAI for each remapped slice with a remapped slice indicator.
  • the remapped slice indicator may signify that the S-NSSAI is for a remapped slice. Should a remapped slice be limited, for example, remapping could be timelimited, limited in services that UE 201 can request, limited in max PDU Sessions or UEs that it could handle, etc. In such as case, UE 201 could identify the remapped slice with the indicator and, make traffic adaptation, PDU Session, or other signaling decisions.
  • the Registration Accept message may additionally include remapping rules that indicate to the UE how S-NSSAI(s) in the Rejected NSSAI map to S-NSSAI(s) in the Allowed NSSAI.
  • These rules are generated by PCF or AMF, and interpreted by UE 201 as an indication that the remapped S-NSSAI(s) may be considered equivalent in the Registration Area, and that the Rejected S-NSSAI(s) may not be used, but any operation (e.g., PDU Session Establishment, PDU Session Modification, sending of user plane data, or sending of SMS) that would normally target the Rejected S-NSSAI(s) may target the S-NSSAI(s) that are indicated by the remapping rule.
  • PDU Session Establishment PDU Session Modification
  • sending of user plane data or sending of SMS
  • the Registration Accept response message may also include an indication of whether UE 201 shall use the new slice for activity for which the old slice would have been used (e.g., for future PDU sessions), or only for the existing PDU sessions involved in the current re-mapping process.
  • the new slice information may be indicated as replacing the old slice information, being prioritized over the old slice information, or neither (e.g., existing configuration applies outside the re-mapped PDU sessions). This information may be used, for example, in conjunction with other URSP rules at UE 201 that include the re-mapped slice. This indication will essentially instruct UE 201 to update the URSP rule with the slice re-mapping information, without explicit signaling from the network.
  • the update might take the form of a slice replacement but may also take the form of a reprioritization of the slides provided in the URSP rule. For example, UE 201 is told that slice X needs to be replaced with slice Y for the current PDU sessions. However, the UE has additional URSP rules that specify slice X for other PDU sessions. If UE 201 needs to start another PDU session where the URSP rule indicates X, it is told that it should use Y instead for that session as well.
  • PDU Sessions may be sent back to UE 201 with an appropriate cause code in the Registration Accept message (e.g., step 245).
  • the network slices which can be remapped may be referred to as the Remappable Slices.
  • the 5GS may be able to configure UE 201 with Remappable Slice information during UE Registration Procedure.
  • the network may be able to identify Remappable Slice, and provided that they are authorized during a UE Registration Request, the network may include Remappable Slices for Allowed NSSAI or Configured NSSAI and deliver them to UE 201 after a successful Registration procedure.
  • a UE Registration Procedure in which UE 201 receives Remappable Slice information is shown in FIG. 11.
  • a UE sends a UE Registration Request to the network (e.g., AMF 203) via the RAN node.
  • the Registration Request message includes Requested NSSAI, the UE Slice Remapping Capability (USRC) indicator, UE’s preference to receive Remappable Slices with a “Remappable Slice Preference” indicator, UE type (e.g., TAC), and device type information.
  • the USRC indicator indicates to the network that UE 201 is capable of network slice remapping.
  • the device type and the UE Type may indicate the capabilities with regards to technology and services it can support.
  • UE 201 may include application IDs or application types to indicate UE’s primary/ priority functions, which may help determine S -NS SAI preference.
  • AMF 203 checks the USRC indicator, the core network’s functionality to support Slice Remapping, UE Type, and the device type. AMF 203 identifies UE 201’s preference to receive Remappable Slices from the “Remappable Slices Preference” indicator. AMF 203 may further consider application IDs and application types, if available.
  • AMF 203 may retrieve the Access and Mobility Subscription data using Nudm_SDM_Get and retrieve Subscribed NSSAI. AMF 203 then examines if the slices requested are authorized. Based on the “Remappable Slice Preference” indicator, the URSC indicator, UE Type, the device type information, UE’s primary applications information (if available), AMF 203 identifies the Remappable Slices from among the authorized slices.
  • UE 201 From the authorized set of slices, UE 201 chooses Remappable Slices over the slices that are not Remappable Slices, populates S-NSSAIs for Remappable Slices in the Allowed NSSAI. If there are less than 8 available Remappable Slices, AMF 203 may fill the remaining S- NSSAIs in the Allowed NSSAI with S-NSSAIs for the slices that may not be Remappable Slices.
  • AMF 203 may associate each S-NSSAI with a Remappable Slice Indicator, for example, with a flag (0 or 1) to indicate that the S-NSSAI represents a Remappable Slice.
  • AMF 203 may first populate the Allowed NSSAI, if available. In addition, AMF 203 may populate Configured NSSAI with Remappable Slices from the Subscribed NSSAI that are available to UE 201. Each S-NSSAI for Remappable Slice may be marked with a Remappable Slice Indicator.
  • AMF 203 may trigger to prepare remapped slices for one or more slices in the UE’s Subscribed NSSAI.
  • AMF 203 may trigger a Registration Update procedure once the Remapped Slices are available and, deliver them to UE 201.
  • AMF 203 sends a Registration Accept message to UE 201 via RAN.
  • AMF 203 may include the Allowed NSSAI, Configured NSSAI (from Step 2), and Rejected NSSAI with Remappable Slice Indicator for slices that are remappable.
  • AMF 203 may indicate the presence of Remappable Slices in the Registration Accept message with a separate “Remappable Slices present” indicator.
  • UE 201 may check the Allowed NSSAI received in the Registration Accept message from AMF 203. If the Allowed NSSAI did not include any S- NSSAI for Remappable Slice, then UE 201 may check the Configured NSSAI received in the Registration Accept message and, if UE 201 discovers that one or more S-NSSAIs in the Configured NSSAI are marked with the Remappable Slice Indicator, then UE 201 may choose to initiate Registration Update procedure. This time, the Requested NSSAI shall include one or more S-NSSAIs for Remappable Slices obtained from the Configured NSSAI. UE 201 receives a new set of Allowed NSSAI including S-NSSAIs for Remappable Slices.
  • UE 201 realizes that the network doesn’t have any Remappable Slices in the Subscribed S-NSSAI. UE 201 may send an acknowledgment back to the network to inform the receipt of the Registration Accept message.
  • This response may include a request to prepare Remapped Slice if the network is capable, for one or more S-NSSAI from UE 201’s Subscribed NSSAI.
  • Yet another alternative may be to have the core network configured with a Default Remapped Slice, which may be used, based on local operator policy during the Slice Remapping process if UE desires Slice Remapping, but there are no Remappable Slice available.
  • the local policy may allow any network slice/PDU session to be remapped with a Default Remapped Slice.
  • AMF 203 ignores the USRC indicator, “Remappable Slice Preference” indicator, and other UE information directed to obtain Remappable Slices and treats UE 201 as a legacy UE.
  • UE can establish PDU Sessions PDU Session in the Remappable Slices which are guaranteed to have Remapped Slices.
  • UE 201 When UE 201 establishes a PDU Session, it may be desirable for UE 201 to indicate, in the NAS MM part of the message that Slice Remapping is desired for the PDU Session. Slice remapping does not happen during PDU Session establishment. However, the indication from UE 201 may indicate to UE 201 that UE 201 expects to request slice remapping in the event that it becomes necessary (e.g., UE 201 later moves to an RA where the slice is not available). AMF 203 can then consider this indication when selecting an SMF 206 to serve the PDU Session, thus ensuring that AMF 203 selects an SMF 206 that is able to perform slice remapping as described earlier.
  • UE 201 When UE 201 establishes a PDU Session, it may be desirable for UE 201 to indicate, in the NAS SM part of the message that Slice Remapping is desired for the PDU Session. Slice remapping does not happen during PDU Session establishment. However, the indication from UE 201 may indicate to the network that UE 201 expects to request slice remapping in the event that it becomes necessary (e.g., UE 201 later moves to an RA where
  • the SMF 206 can then consider this indication when selecting a UPF to serve the PDU Session, thus ensuring that AMF 203 selects an SMF 206 that is able to perform slice remapping.
  • AMF 203 may provide UE 201 with an indication of whether Slice Remapping is allowed for the PDU Session and AMF 203 may provide UE 201 with a list of S-NSSAIs that the PDU Session may be remapped to. If the information is provided to UE 201 by AMF 203, it is sent in the NAS MM part of the message. If the information is provided to UE 201 by the SMF 206, it is sent in the NAS SM part of the message.
  • the AMF may check the UE’s Configured NSSAI before sending this information to UE 201 to ensure that the indication of remapping support is sent to UE 201 only if the PDU Session can be remapped to other slices in the UE’s configured NSSAI and that UE 201 is only sent S-NSSAI’s that are in the UE’s Configured NSSAI.
  • FIG. 12 describes the method as follows.
  • Step 260 the network may be equipped with slice remapping functionality.
  • UE 201 may initiate a PDU Session Establishment Request by the transmission of a NAS message including a PDU Session Establishment Request within the N1 SM container towards AMF 203 via the RAN 202 node.
  • UE 201 may include in the PDU Session Establishment Request, PDU session ID, Requested PDU Session Type, a Requested SSC mode, S-NSSAI, and UE Requested DNN.
  • UE 201 may send the UE’s network slice remapping capability (USRC) indication and, may inform the network (e.g., AMF 203, SMF 206, PCF 204, etc.) about UE 201’s desire for network slice remapping.
  • the RAN 202 node forwards the PDU Session Establishment Request towards AMF 203.
  • AMF 203 may select the SMF 206 which is responsible for session management for the PDU session. If the core network supports slice remapping, AMF 203 considers the USRC indication in the NAS MM part of the message when selecting an SMF 206. AMF 203 invokes the Nsmf_PDUSession_CreateSMContext Request operation to create a context for the PDU Session in the SMF 206. The SMF 206 will select a UPF 209 and may consider the network slice remapping capability indication in the NAS SM part of the message. The SMF 206 will reply to UE 201 via AMF 203. The reply may indicate to UE
  • the core network may obtain a remapped slice from the UE Subscription.
  • the remapped slice for the PDU Session may be universal. In other words, a remapped slice for the PDU session may be valid for multiple RAs in that PLMN. This means that when UE 201 moves across RAs, the same remapped slice may be used to remap the PDU Session.
  • AMF 203 may inform about it to UE 201 with a “slice remapping incompatible network” indication.
  • AMF 203 may notify UE 201 using the “remappable slice unavailable” indicator.
  • AMF 203 may be able to identify the S-NSSAIs in UE 201’s Allowed NSSAI that can be remapped or if UE 201 already has remapped slices in the UE Subscription at the UDM 205.
  • a remapped slice may be available in RAI, RA2 but not in RA3.
  • the reply from the SMF 206 to UE 201 is sent in NAS SM.
  • AMF 203 sends the NAS message including PDU Session ID and PDU Session Establishment Accept targeted to UE 201 and the N2 SM information received from the SMF 206 within the N2 PDU Session Request to the (R)AN.
  • the N2 SM Information may also include the information on requesting UE 201’s network slice remapping capability and the S -NS SAI for the network slice with which the PDU session establishment request has been accepted.
  • the reply in the N1 SM container from the SMF 206 may indicate to UE 201 if slice remapping is allowed for the PDU Session with a “slice remapping compatible network” indicator and, the reply may indicate to UE 201 which S- NSSAI(s) the PDU Session may be remapped to, if available.
  • the reply from AMF 203 to UE 201 is sent in NAS MM.
  • AMF 203 includes the “slice remapping incompatible network” indicator in the NAS reply message.
  • the core network supports network slice remapping but the network slice where UE 201 is attempting to establish a PDU Session cannot be remapped or doesn’t have a remapped slice, the NAS message includes a “remappable slice unavailable” indicator.
  • AMF 203 may include a list of one or more Remappable Slice(s) obtained from the UE Subscription with PDU Session Establishment Accept message and send it to UE 201.
  • UE 201 may start exchanging user plane data with the data network.
  • UE 201 will consider the remapping information (e.g., the support indication and S- NSSAI(s)) when an event triggers remapping or makes remapping necessary.
  • UE 201 may include the S-NSSAI(s) in the Requested NSSAI when UE 201 eventually updates its Requested NSSAI.
  • Step 264-B although UE 201 receives PDU Session Establishment Accept message, UE 201 may notice that the network doesn’t have slice remapping functionality for the PDU Session(s) based on the “slice remapping incompatible network” indicator. In such a case, UE 201 may simply continue with Step 264-A where UE 201 and network don’t involve in slice remapping and handle the change of RA as legacy UEs.
  • UE 201 may select a Remappable Slice taking also into consideration the URSP rules and, send a PDU Session Establishment Request towards a Remappable Slice.
  • UE 201 may start sending user plane data to the data network (via a Remappable Slice).
  • the remapping rule could be provided to UE 201 as a part of URSP rules, so that UE 201 will check the URSP rule for a PDU session associated with certain DNN, S-NSSAIs, and SSC modes.
  • the remapping rule will guide UE 201 to switch to another network slice identified by a new S-NSSAIs so that UE 201 can resume data transfer
  • the remapping rule in a URSP rule can be used together with the location criteria and time window in Route Selection Validation Criteria.
  • UE 201 will switch to another network slice in a certain location (e.g., RA, TA, or geographic location area) or a certain time period, the remapping rule could be inserted in the RSD as a new attribute. Alternatively, it could be inserted as a new value in the existing network slice selection attribute, for example, called remapped network slice or alternative set of network slice.
  • FIG. 13 depicts a method in which the RAN nodes participate with the core network to conduct slice remapping. The method is described as follows.
  • the core network e.g., AMF 203, PCF 204, NSSF, etc.
  • the core network may be configured with the Remapped Slices for each network slice in the Subscribed NSSAI for the UEs registered in the core network.
  • each Remapped Slice is designed to have the same SMF or UPF instances as that of the network slice for which it is remapped. This ensures that an SMF 206/UPF 209 preserves the UE IP address when the PDU Session goes through Slice Remapping. Slice remapping may also be performed for cases in which the SMF or UPF are different, where the procedure would just extend signaling to involve the additional SMF or UPF.
  • the SMF 206 in FIG. 13 would contact another UPF to perform the slice remapping.
  • AMF 203 in FIG. 13 would select another SMF to perform the slice remapping.
  • Step 270-B UE 201 may have sent a USRC indicator and UE 20 Ts desire for network slice remapping in the Registration Request during the UE Registration Procedure.
  • the old RAN 202 may have received in the N2 container of the Registration Accept message, the information on UE 201’s Allowed S-NSSAIs and corresponding Remapped Slice/S-NSSAI for each S-NSSAI.
  • the USRC indicator indicates to the network that UE 201 is capable of network slice remapping.
  • the old RAN 202 may receive in the N2 container of the Registration Accept message, a Slice Remapping table.
  • This table may include a list of
  • the Slice Remapping table may be established by the PCF 204, AMF 203, or NSSF based on operator policies and eventually delivered to the RAN 202 node.
  • a Slice Remapping table may be PLMN specific that applies to all the UEs or UE specific.
  • UE 201 may send USRC indication and UE 201 ’s desire for network slice remapping to the network (e.g., AMF 203, SMF 206, PCF 204, etc.) with a PDU Session Establishment Request.
  • the USRC indicator indicates to the network that UE 201 is capable of network slice remapping.
  • Step 272 the PDU Session is established and the old RAN 202 receives the PDU Session Establishment Accept message.
  • the PDU Session Establishment Accept message may include one or more Remapped Slice for the PDU Session.
  • the old RAN 202 saves the Remapped Slice information from AMF 203 and forwards the PDU Session Establishment Accept message to UE 201.
  • Step 273 UE 201 may exchange user plane data with the data network via the old RAN 202 node.
  • Step 274 UE 201 comes across a scenario (e.g., UE 201 may move and enters into a new RA of the PLMN) that triggers Slice Remapping, e.g., UE 201 performs registration update procedure due to UE mobility.
  • the old NG-RAN 202 may send to the new NG-RAN 207, UE 201 handover information and prepare for the handover.
  • the old NG-RAN 202 may also include the PDU Session that needs slice remapping and corresponding Remapped Slice.
  • Step 275 as the new RAN 207 receives the request, it may send the N2 Path Switch Request to AMF 203.
  • the new RAN 207 sends an N2 Path Switch Request message to an AMF 203 to inform that UE 201 has moved to a new target cell, the S-NSSAI for the Remapped Slice (received from the old NG-RAN 202) and, provides a List Of PDU Sessions To Be Switched.
  • the target NG-RAN shall include in the message, the serving PLMN ID, UE Location Information, PDU Sessions Rejected list with the failure cause in the N2 SM information element.
  • AMF 203 identifies the PDU Sessions that need to be remapped. AMF 203 selects the SMF 206 for the Remapped Slice, which further selects UPF 209 where the PDU Sessions need to be transferred. UPF 209 for the Remapped Slice is
  • AMF 203 may include Remapped Slice’s S-NSSAI in the new RA’s Allowed NS SAI.
  • AMF 203 sends UE Configuration Update Command including one or more UE parameters (Configuration Update Indication, Allowed NSSAI, Configured NSSAI, rejected NSSAI, etc.) and may request acknowledgment from UE 201.
  • the Allowed NSSAI also includes the Remapped Slices for PDU Session with remapped slice indicator.
  • the remapped slice indicator signifies that the S-NSSAI is for a remapped slice. Should a remapped slice be limited, for example, remapping could be time-limited, limited in services that UE 201 can request, limited in max PDU Sessions or UEs that it could handle, etc. In such as case, UE 201 could identify the remapped slice with the indicator and, make traffic adaptation, PDU Session, or other signaling decisions.
  • UE 201 shall provide the acknowledgment back to AMF 203 for the UE Configuration Update command.
  • Step 278 If the PDU Session could’t be remapped and hence, the PDU Session is rejected but AMF 203 identified the slices that are accessible for UE 201 in the new RA, AMF 203 shall indicate that UE 201 should initiate a Registration Update procedure.
  • UE 201 may send a Registration Update Request to UE 201 with the new Requested NSSAI.
  • AMF 203 may send a Registration Accept message with a new Allowed NSSAI where UE 201 can establish new PDU Sessions.
  • FIG. 14 illustrates an exemplary method for network controlled UE behavior for slice access.
  • a policy may be received from a network.
  • the policy may indicate that: UE 201 include an S-NSSAI value in the Requested NSSAI when the type of registration request is an initial registration and the S-NSSAI value is indicated in the policy; UE 201 include an S-NSSAI value in the Requested NSSAI when UE 201 enters a new Registration Area and the S-NSSAI value is indicated in the policy; UE 201 excludes a S-NSSAI value from the Requested NSSAI and where the S-NSSAI value is part of the UE 201’s Allowed NSSAI; UE 201 send the Registration Request in a time period and the time period is indicated in the policy; UE 201 send the Registration Request when UE 201 is in a location and the location is indicated in the policy; UE 201 send the Registration Request when no traffic has been sent or received with the S-
  • UE 201 send the Registration Request if no control plane traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy; or UE 201 send the Registration Request when no PDU Session has been established with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy.
  • the policy may be a URSP rule.
  • the policy may be used to determine a Requested NSSAI.
  • a registration request may be sent to the network.
  • the registration request may include the Requested NSSAI.
  • the Requested NSSAI may include one or more S-NSSAI.
  • FIG. 15 illustrates an exemplary method for network controlled UE behavior for slice access.
  • an Allowed NSSAI may be received from the network.
  • the Allowed NSSAI may include one S-NSSAI.
  • a policy may be received from the network.
  • the policy may be used to determine an S-NSSAI.
  • the policy may be used to: determine to send a PDU Session Establishment Request to the network after receiving the Allowed NSSAI on the condition that the Allowed NSSAI includes the S-NSSAI; determine to send a PDU Session Establishment Request to the network when UE 201 is in a location on the condition that the Allowed NSSAI includes the S-NSSAI; or determine to send a PDU Session Release Request to the network after a condition is met.
  • the condition may include that no data has been sent on the PDU Session for a time period and the policy indicates the time period.
  • the PDU Session Establishment Request may be sent to the network and the request may include the S-NSSAI.
  • UE 201 may use the policy to determine a DNN and the PDU Session Establishment Request may include the DNN.
  • a policy may be a URSP rule.
  • the USRP rule may include one RSD.
  • the RSD may include a second S-NSSAI, the second S-NSSAI is not included in the Allowed NSSAI, the RSD includes an indication that the UE should request that the network add the second S-NSSAI to the Allowed NSSAI if the RSD is evaluated.
  • a registration request may be determined to be sent to the network in order to request that the second S-NSSAI be added to the Allowed NSSAI.
  • FIG. 4- FIG. 15 may be logical entities.
  • the steps may be stored in a memory of, and executing on a processor of, a device, server, or computer system such as those illustrated in
  • FIG. 8F or FIG. 8G Skipping steps, combining steps, or adding steps between exemplary methods disclosed herein (e.g., FIG. 4 - FIG. 14) is contemplated.
  • FIG. 7 depicts that a UE has been configured with US AB policy and Enhanced URSP rules.
  • the USAB policy may include UE registration and de-registration rules and PDU session establishment and release rules for optimized UE behavior of slice access.
  • FIG. 8 A illustrates an example communications system 100 in which the methods and apparatuses of network controlled UE behavior for slice access, such as the systems and methods illustrated in figures described and claimed herein may be used.
  • the communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, or 102g (which generally or collectively may be referred to as WTRU 102 or WTRUs 102).
  • the communications system 100 may include, a radio access network (RAN) 103/104/105/103b/104b/105b, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and Network Services 113.
  • Network Services 113 may include, for example, a V2X server, V2X functions, a ProSe server, ProSe functions, loT services, video streaming, or edge computing, etc.
  • Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be any type of apparatus or device configured to operate or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be depicted in FIG 8 A, FIG 8B, FIG 8C, FIG. 8D, FIG. 8E, or FIG.
  • each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot,
  • UE user equipment
  • PDA personal digital assistant
  • smartphone a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot,
  • the communications system 100 may also include a base station 114a and a base station 114b.
  • each base stations 114a and 114b is depicted as a single element.
  • the base stations 114a and 114b may include any number of interconnected base stations or network elements.
  • Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, or the other networks 112.
  • base station 114b may be any type of device configured to wiredly or wirelessly interface with at least one of the Remote Radio Heads (RRHs) 118a, 118b, Transmission and Reception Points (TRPs) 119a, 119b, or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, other networks 112, or Network Services 113.
  • RRHs Remote Radio Heads
  • TRPs Transmission and Reception Points
  • RSUs Roadside Units
  • RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102, e.g., WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, or other networks 112
  • TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, or other networks 112.
  • RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, other networks 112, or Network Services 113.
  • the base stations 114a, 114b may be a Base Transceiver Station (BTS), aNode-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.
  • BTS Base Transceiver Station
  • gNode B Next Generation Node-B
  • satellite a site controller
  • AP access point
  • AP access point
  • the base station 114a may be part of the RAN 103/104/105, which may also include other base stations or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc.
  • BSC Base Station Controller
  • RNC Radio Network Controller
  • the base station 114b may be part of the RAN 103b/l 04b/ 105b, which may also include other base stations or network elements (not shown), such as a BSC, a RNC, relay nodes, etc.
  • the base station 114a may be part of the RAN 103/104/105, which may also include other base stations or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc.
  • BSC Base Station Controller
  • RNC Radio Network Controller
  • 4871-1319-0402.1 station 114a may be configured to transmit or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
  • the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown) for methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein.
  • the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown).
  • the cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors.
  • the base station 114a may include three transceivers, e.g., one for each sector of the cell.
  • the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
  • MIMO multiple-input multiple output
  • the base stations 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, or 102g over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), micro wave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.).
  • the air interface 115/116/117 may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b, over a wired or air interface 115b/l 16b/l 17b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), micro wave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.).
  • the air interface 115b/l 16b/l 17b may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the RRHs 118a, 118b, TRPs 119a, 119b or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c/l 16c/l 17c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.).
  • the air interface 115c/l 16c/l 17c may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the WTRUs 102a, 102b, 102c,102d, 102e, or 102f may communicate with one another over an air interface 115d/l 16d/l 17d, such as Sidelink communication, which may be any suitable wireless communication link (e.g., radio frequency (RF), micro wave,
  • RF radio frequency
  • the air interface 115d/l 16d/l 17d may be established using any suitable radio access technology (RAT).
  • RAT radio access technology
  • the communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC- FDMA, and the like.
  • the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b,TRPs 119a, 119b and RSUs 120a, 120b, in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, 102f may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using wideband CDMA (WCDMA).
  • UMTS Universal Mobile Telecommunications System
  • UTRA Universal Mobile Telecommunications System
  • WCDMA wideband CDMA
  • WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) or Evolved HSPA (HSPA+).
  • HSPA may include High-Speed Downlink Packet Access (HSDPA) or High-Speed Uplink Packet Access (HSUPA).
  • HSPA High-Speed Packet Access
  • HSUPA High-Speed Uplink Packet Access
  • the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using Long Term Evolution (LTE) or LTE-Advanced (LTE-A).
  • E-UTRA Evolved UMTS Terrestrial Radio Access
  • the air interface 115/116/117 or 115c/l 16c/l 17c may implement 3GPP NR technology.
  • the LTE and LTE-A technology may include LTE D2D and V2X technologies and interfaces (such as Sidelink communications, etc.).
  • the 3GPP NR technology includes NR V2X technologies and interface (such as Sidelink communications, etc.).
  • the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, and 102g or RRHs 118a, 118b, TRPs 119a, 119b or RSUs 120a, 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
  • IEEE 802.16 e.g., Worldwide Interoperability for Microwave Access (WiMAX)
  • the base station 114c in FIG. 8A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for
  • the base station 114c and the WTRUs 102 may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN), similarly, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN).
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • the base station 114c and the WTRUs 102 may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell.
  • a cellular-based RAT e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.
  • the base station 114c may have a direct connection to the Internet 110.
  • the base station 114c may not be required to access the Internet 110 via the core network 106/107/109.
  • the RAN 103/104/105 or RAN 103b/104b/105b may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d.
  • the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or perform high-level security functions, such as user authentication.
  • the RAN 103/104/105 or RAN 103b/104b/105b or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or RAN 103b/104b/105b or a different RAT.
  • the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM or NR radio technology.
  • the core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, or other networks 112.
  • the PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS).
  • POTS plain old telephone service
  • the Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the
  • the networks 112 may include wired or wireless communications networks owned or operated by other service providers.
  • the networks 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or RAN 103b/104b/105b or a different RAT.
  • Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks over different wireless links for implementing methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein.
  • the WTRU 102g shown in FIG. 8 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.
  • a User Equipment may make a wired connection to a gateway.
  • the gateway maybe a Residential Gateway (RG).
  • the RG may provide connectivity to a Core Network 106/107/109.
  • UEs that are WTRUs and UEs that use a wired connection to connect with a network.
  • the subject matter that applies to the wireless interfaces 115, 116, 117 and 115c/l 16c/l 17c may equally apply to a wired connection.
  • FIG. 8B is a system diagram of an example RAN 103 and core network 106 that may implement methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein.
  • the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115.
  • the RAN 103 may also be in communication with the core network 106.
  • the RAN 103 may include Node-Bs 140a, 140b, and 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115.
  • the Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103.
  • the RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs.)
  • the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, and 140c may communicate with the respective RNCs 142a and 142b via an lub interface. The RNCs 142a and 142b may be in communication with one another via an lur interface. Each of the RNCs 142aand 142b may be configured to control the respective Node-Bs 140a, 140b, and 140c to which it is connected. In addition, each of the RNCs 142aand 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.
  • outer loop power control such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.
  • the core network 106 shown in FIG. 8B may include a media gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, or a Gateway GPRS Support Node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator.
  • MGW media gateway
  • MSC Mobile Switching Center
  • SGSN Serving GPRS Support Node
  • GGSN Gateway GPRS Support Node
  • the RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface.
  • the MSC 146 may be connected to the MGW 144.
  • the MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c, and traditional land-line communications devices.
  • the RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface.
  • the SGSN 148 may be connected to the GGSN 150.
  • the SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and 102c, and IP-enabled devices.
  • the core network 106 may also be connected to the other networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
  • FIG. 8C is a system diagram of an example RAN 104 and core network 107 that may implement methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein.
  • the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116.
  • the RAN 104 may also be in communication with the core network 107.
  • the RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs.
  • the eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116.
  • the eNode-Bs 160a, 160b, and 160c may implement MIMO technology.
  • the eNode-B 160a for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
  • Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, and the like. As shown in FIG. 8C, the eNode-Bs 160a, 160b, and 160c may communicate with one another over an X2 interface.
  • the core network 107 shown in FIG. 8C may include a Mobility Management Gateway (MME) 162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator.
  • MME Mobility Management Gateway
  • PDN Packet Data Network
  • the MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node.
  • the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like.
  • the MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
  • the serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the SI interface.
  • the serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and 102c.
  • the serving gateway 164 may also perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, and the like.
  • the serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c, and IP-enabled devices.
  • the PDN gateway 166 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c, and IP-enabled devices.
  • the core network 107 may facilitate communications with other networks.
  • the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices.
  • the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108.
  • IMS IP Multimedia Subsystem
  • the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
  • FIG. 8D is a system diagram of an example RAN 105 and core network 109 that may implement methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein.
  • the RAN 105 may employ an NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117.
  • the RAN 105 may also be in communication with the core network 109.
  • a Non-3GPP Interworking Function (N3IWF) 199 may employ a non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198.
  • the N3IWF 199 may also be in communication with the core network 109.
  • the RAN 105 may include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of gNode-Bs.
  • the gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When integrated access and backhaul connection are used, the same air interface may be used between the WTRUs and gNode-Bs, which may be the core network 109 via one or multiple gNBs.
  • the gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, or digital beamforming technology.
  • the gNode-B 180a may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It should be appreciated that the RAN 105 may employ of other types of base stations such as an eNode-B. It will also be appreciated the
  • RAN 105 may employ more than one type of base station.
  • the RAN may employ eNode-Bs and gNode-Bs.
  • the N3IWF 199 may include anon-3GPP Access Point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP Access Points.
  • the non-3GPP Access Point 180c may include one or more transceivers for communicating with the WTRUs 102c over the air interface 198.
  • the non-3GPP Access Point 180c may use the 802.11 protocol to communicate with the WTRU 102c over the air interface 198.
  • Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, and the like. As shown in FIG. 8D, the gNode-Bs 180a and 180b may communicate with one another over an Xn interface, for example.
  • the core network 109 shown in FIG. 8D may be a 5G core network (5GC).
  • the core network 109 may offer numerous communication services to customers who are interconnected by the radio access network.
  • the core network 109 comprises a number of entities that perform the functionality of the core network.
  • the term “core network entity” or “network function” refers to any entity that performs one or more functionalities of a core network. It is understood that such core network entities may be logical entities that are implemented in the form of computer-executable instructions (software) stored in a memory of, and executing on a processor of, an apparatus configured for wireless or network communications or a computer system, such as system 90 illustrated in FIG. 8G.
  • the 5G Core Network 109 may include an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPFs) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, aNon-3GPP Interworking Function (N3IWF) 199, a User Data Repository (UDR) 178.
  • AMF access and mobility management function
  • SMF Session Management Function
  • UPFs User Plane Functions
  • UDM User Data Management Function
  • AUSF Authentication Server Function
  • NEF Network Exposure Function
  • PCF Policy Control Function
  • N3IWF Network 3GPP Interworking Function
  • UDR User Data Repository
  • 5G core network 109 While each of the foregoing elements are depicted as part of the 5G core network 109, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator. It will also be appreciated that a 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these
  • FIG. 8D shows that network functions directly connect with one another, however, it should be appreciated that they may communicate via routing agents such as a diameter routing agent or message buses.
  • connectivity between network functions is achieved via a set of interfaces, or reference points. It will be appreciated that network functions could be modeled, described, or implemented as a set of services that are invoked, or called, by other network functions or services. Invocation of a Network Function service may be achieved via a direct connection between network functions, an exchange of messaging on a message bus, calling a software function, etc.
  • the AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node.
  • the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization.
  • the AMF may be responsible forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface.
  • the AMF 172 may receive the user plane tunnel configuration information from the SMF via an N11 interface.
  • the AMF 172 may generally route and forward NAS packets to/from the WTRUs 102a, 102b, and 102c via an N1 interface.
  • the N1 interface is not shown in FIG. 8D.
  • the SMF 174 may be connected to the AMF 172 via an Nll interface. Similarly the SMF may be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface.
  • the SMF 174 may serve as a control node.
  • the SMF 174 may be responsible for Session Management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.
  • the UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a Packet Data Network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices.
  • PDN Packet Data Network
  • the UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks.
  • Other Networks 112 may be Ethernet Networks or any type of network that exchanges packets of data.
  • the UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface.
  • the UPF 176a and UPF 176b may provide access to a packet data network by connecting a packet data network with an N6 interface or by connecting to each other and to other UPFs via an N9 interface.
  • the UPF 176 may be responsible packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.
  • the AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface.
  • the N3IWF facilitates a connection between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies that are not defined by 3GPP.
  • the AMF may interact with the N3IWF 199 in the same, or similar, manner that it interacts with the RAN 105.
  • the PCF 184 may be connected to the SMF 174 via an N7 interface, connected to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface.
  • the N15 and N5 interfaces are not shown in FIG. 8D.
  • the PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules.
  • the PCF 184 may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via an Nl interface. Policies may then be enforced, or applied, at the WTRUs 102a, 102b, and 102c.
  • the UDR 178 may act as a repository for authentication credentials and subscription information.
  • the UDR may connect with network functions, so that network function can add to, read from, and modify the data that is in the repository.
  • the UDR 178 may connect with the PCF 184 via an N36 interface.
  • the UDR 178 may connect with the NEF 196 via an N37 interface, and the UDR 178 may connect with the UDM 197 via an N35 interface.
  • the UDM 197 may serve as an interface between the UDR 178 and other network functions.
  • the UDM 197 may authorize network functions to access of the UDR 178.
  • the UDM 197 may connect with the AMF 172 via an N8 interface
  • the UDM 197 may connect with the SMF 174 via an N10 interface.
  • the UDM 197 may connect with the AUSF 190 via an N13 interface.
  • the UDR 178 and UDM 197 may be tightly integrated.
  • the AUSF 190 performs authentication related operations and connect with the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.
  • the NEF 196 exposes capabilities and services in the 5G core network 109 to Application Functions (AF) 188. Exposure may occur on the N33 API interface.
  • AF Application Functions
  • 4871-1319-0402.1 may connect with an AF 188 via an N33 interface and it may connect with other network functions in order to expose the capabilities and services of the 5G core network 109.
  • Application Functions 188 may interact with network functions in the 5G Core Network 109. Interaction between the Application Functions 188 and network functions may be via a direct interface or may occur via the NEF 196.
  • the Application Functions 188 may be considered part of the 5G Core Network 109 or may be external to the 5G Core Network 109 and deployed by enterprises that have a business relationship with the mobile network operator.
  • Network Slicing is a mechanism that could be used by mobile network operators to support one or more ‘virtual’ core networks behind the operator’s air interface. This involves ‘slicing’ the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g., in the areas of functionality, performance and isolation.
  • 3GPP has designed the 5G core network to support Network Slicing.
  • Network Slicing is a good tool that network operators can use to support the diverse set of 5G use cases (e.g., massive loT, critical communications, V2X, and enhanced mobile broadband) which demand very diverse and sometimes extreme requirements.
  • massive loT massive loT
  • critical communications V2X
  • enhanced mobile broadband a set of 5G use cases
  • the network architecture would not be flexible and scalable enough to efficiently support a wider range of use cases need when each use case has its own specific set of performance, scalability, and availability requirements.
  • introduction of new network services should be made more efficient.
  • a WTRU 102a, 102b, or 102c may connect with an AMF 172, via an N1 interface.
  • the AMF may be logically part of one or more slices.
  • the AMF may coordinate the connection or communication of WTRU 102a, 102b, or 102c with one or more UPF 176a and 176b, SMF 174, and other network functions.
  • Each of the UPFs 176a and 176b, SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.
  • the core network 109 may facilitate communications with other networks.
  • the core network 109 may include, or may communicate with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and a PSTN 108.
  • the core network 109 may include, or communicate with a short message service (SMS) service center that facilities communication via the short message service.
  • SMS short message service
  • the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and servers or applications functions 188.
  • the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
  • the core network entities described herein and illustrated in FIG. 8A, FIG. 8C, FIG. 8D, or FIG. 8E are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications.
  • the particular network entities and functionalities described and illustrated in FIG. 8A, FIG. 8B, FIG. 8C, FIG. 8D, or FIG. 8E are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.
  • FIG. 8E illustrates an example communications system 111 in which the systems, methods, apparatuses that implement network controlled UE behavior for slice access, described herein, may be used.
  • Communications system 111 may include Wireless Transmit/Receive Units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and Road Side Units (RSUs) 123a and 123b.
  • WTRUs Wireless Transmit/Receive Units
  • RSUs Road Side Units
  • the concepts presented herein may be applied to any number of WTRUs, base station gNBs, V2X networks, or other network elements.
  • WTRUs A, B, C, D, E, and F may be out of range of the access network coverage 131.
  • WTRUs A, B, and C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members.
  • WTRUs A, B, C, D, E, and F may communicate with each other over a Uu interface 129 via the gNB 121 if they are within the access network coverage 131.
  • WTRUs B and F are shown within access network coverage 131.
  • WTRUs A, B, C, D, E, and F may communicate with each other directly via a Sidelink
  • WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via a Vehicle-to-Network (V2N) 133 or Sidelink interface 125b.
  • V2N Vehicle-to-Network
  • WTRUs A, B, C, D, E, and F may communicate to a V2X Server 124 via a Vehicle-to-Infrastructure (V2I) interface 127.
  • WTRUs A, B, C, D, E, and F may communicate to another UE via a Vehicle-to-Person (V2P) interface 128.
  • V2N Vehicle-to-Network
  • V2I Vehicle-to-Infrastructure
  • V2P Vehicle-to-Person
  • FIG. 8F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communications and operations in accordance with the systems, methods, and apparatuses that implement network controlled UE behavior for slice access, described herein, such as a WTRU 102 of FIG. 8A, FIG. 8B, FIG. 8C, FIG. 8D, or FIG. 8E, or devices of FIG. 1 - FIG. 13. As shown in FIG. 8A, FIG. 8B, FIG. 8C, FIG. 8D, or FIG. 8E, or devices of FIG. 1 - FIG. 13. As shown in FIG.
  • the example WTRU 102 may include a processor 78, a transceiver 120, a transmit/ receive element 122, a speaker/mi crophone 74, a keypad 126, a display/touchpad/indicators 77, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements.
  • GPS global positioning system
  • the base stations 114a and 114b, or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node- B gateway, a next generation node-B (gNode-B), and proxy nodes, among others, may include some or all of the elements depicted in FIG. 8F and may be an exemplary implementation that performs the disclosed systems and methods for network controlled UE behavior for slice access described herein.
  • BTS transceiver station
  • Node-B a Node-B
  • AP access point
  • eNodeB evolved home node-B
  • HeNB home evolved node-B gateway
  • gNode-B next generation node-B
  • proxy nodes among others, may include some or all of the elements depicte
  • the processor 78 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like.
  • the processor 78 may perform signal coding, data processing, power control,
  • the processor 78 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 8F depicts the processor 78 and the transceiver 120 as separate components, it will be appreciated that the processor 78 and the transceiver 120 may be integrated together in an electronic package or chip.
  • the transmit/receive element 122 of a UE may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a of FIG. 8A) over the air interface 115/116/117 or another UE over the air interface 115d/l 16d/l 17d.
  • the transmit/receive element 122 may be an antenna configured to transmit or receive RF signals.
  • the transmit/receive element 122 may be an emitter/detector configured to transmit or receive IR, UV, Radar, LIDAR, or visible light signals, for example.
  • the transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit or receive any combination of wireless or wired signals.
  • the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
  • the transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122.
  • the WTRU 102 may have multi-mode capabilities.
  • the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, for example NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.
  • the processor 78 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/mi crophone 74, the keypad 126, or the display/touchpad/indicators 77 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit.
  • the processor 78 may also output user data to the speaker/mi crophone 74, the keypad 126, or the display/touchpad/indicators 77.
  • the processor 78 may access information from, and store data in, any type of suitable
  • the nonremovable 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.
  • SIM subscriber identity module
  • SD secure digital
  • the processor 78 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server that is hosted in the cloud or in an edge computing platform or in a home computer (not shown).
  • the processor 78 may be configured to control lighting patterns, images, or colors on the display or indicators 77 in response to whether the setup of network controlled UE behavior for slice access in some of the examples described herein are successful or unsuccessful, or otherwise indicate a status of network controlled UE behavior for slice access and associated components.
  • the control lighting patterns, images, or colors on the display or indicators 77 may be reflective of the status of any of the method flows or components in the FIG.’s illustrated or discussed herein (e.g., FIG. 9 -FIG. 13, etc.).
  • Disclosed herein are messages and procedures of network controlled UE behavior for slice access.
  • the messages and procedures may be extended to provide interface/ API for users to request resources via an input source (e.g., speaker/mi crophone 74, keypad 126, or display/touchpad/indicators 77) and request, configure, or query network controlled UE behavior for slice access related information, among other things that may be displayed on display 77.
  • an input source e.g., speaker/mi crophone 74, keypad 126, or display/touchpad/indicators 77
  • request, configure, or query network controlled UE behavior for slice access related information among other things that may be displayed on display 77.
  • the processor 78 may receive power from the power source 134 and may be configured to distribute or control the power to the other components in the WTRU 102.
  • the power source 134 may be any suitable device for powering the WTRU 102.
  • the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.
  • the processor 78 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102.
  • location information e.g., longitude and latitude
  • the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method.
  • the processor 78 may further be coupled to other peripherals 138, which may include one or more software or hardware modules that provide additional features, functionality, or wired or wireless connectivity.
  • the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
  • biometrics e.g., finger print
  • a satellite transceiver for photographs or video
  • USB universal serial bus
  • FM frequency modulated
  • the WTRU 102 may be included in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or an airplane.
  • the WTRU 102 may connect with other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.
  • FIG. 8G is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communications networks illustrated in FIG. 8A, FIG. 8C, FIG. 8D and FIG. 8E as well as network controlled UE behavior for slice access, such as the systems and methods illustrated in FIG. 1 through FIG. 13 described and claimed herein may be embodied, such as certain nodes or functional entities in the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, Other Networks 112, or Network Services 113.
  • Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed.
  • Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work.
  • the processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, 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, or any other functionality that enables the computing system 90 to operate in a communications network.
  • Coprocessor 81 is an optional processor, distinct from main processor 91, that may
  • Processor 91 or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein for network controlled UE behavior for slice access, such as receiving messages.
  • processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data- transfer path, system bus 80.
  • system bus 80 Such a system bus connects the components in computing system 90 and defines the medium for data exchange.
  • System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus.
  • An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.
  • RAM random access memory
  • ROM read only memory
  • Such memories include circuitry that allows information to be stored and retrieved.
  • ROMs 93 generally include stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 or ROM 93 may be controlled by memory controller 92.
  • Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory sharing between the processes has been set up.
  • computing system 90 may include peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
  • peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
  • Display 86 which is controlled by display controller 96, is used to display visual output generated by 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).
  • GUI graphical user interface
  • Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touchpanel.
  • Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.
  • computing system 90 may include communication circuitry, such as for example a wireless or wired network adapter 97, that may be used to connect computing system 90 to an external communications network or devices, such as the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, WTRUs 102, or Other Networks 112 of FIG. 8A, FIG. 8B, FIG. 8C, FIG. 8D, or FIG. 8E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks.
  • the communication circuitry alone or in combination with the processor 91, may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.
  • any or all of the apparatuses, systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 78 or 91, cause the processor to perform or implement the systems, methods and processes described herein.
  • a processor such as processors 78 or 91
  • any of the steps, operations, or functions described herein may be implemented in the form of such computer executable instructions, executing on the processor of an apparatus or computing system configured for wireless or wired network communications.
  • Computer readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer readable storage media do not include signals.
  • Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.
  • Table 9 provides for list of acronyms that may appear in the description.
  • the various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effectuate the methods described herein.
  • the terms “apparatus,” “network apparatus,” “node,” “device,” “network node,” or the like may be used interchangeably.
  • the use of the word “or” is generally used inclusively unless otherwise provided herein.
  • “desire” herein may be considered a request for or a determination of an action based on a certain trigger, such as a threshold value or state. For example, request slice remapping or determine slice remapping is appropriate based on a threshold value.
  • Methods, systems, and apparatuses, among other things, as described herein may provide for network controlled UE behavior for slice access.
  • a method by which a UE indicates to a network about its support for Slice Resource Management Capability (SRMC) is described herein.
  • a method by which a network conveys USAB policies to a UE for optimal slice access during UE Registration Procedure or UE Configuration Update procedure is described herein.
  • a method by which a UE implements USAB policies during a PDU Session Establishment Procedure to establish PDU sessions in an optimal manner is described herein.
  • a method for PDU Session release in which, a network sends an explicit release signal to a UE or an explicit release signal with a Grace Timer is described herein.
  • a method for PDU Session release in which, a network or a UE may apply an additional time called release delay time before releasing a PDU session when the UE encounters a context (e.g., location change) is described herein.
  • Methods for slice remapping is described herein, method, system, computer readable storage medium, or apparatus provides for using the
  • a method, system, computer readable storage medium, or apparatus provides for receiving a policy from a network; using the policy to determine a Requested NSSAI, and sending a registration request to the network, the registration request includes a Requested NSSAI and the Requested NSSAI includes at least one S-NSSAI.
  • the policy instructs a UE to sometime or always include an S-NSSAI value in the Requested NSSAI when the type of registration request is an initial registration and the S-NSSAI value is indicated in the policy.
  • the policy instructs the UE to always include an S-NSSAI value in the Requested NSSAI when the UE enters a new Registration Area and the S-NSSAI value is indicated in the policy.
  • the policy instructs the UE to exclude a S-NSSAI value from the Requested NSSAI and where the S-NSSAI value is part of the UE’s Allowed NSSAI.
  • the policy further instructs the UE to send the Registration Request in a time period and the time period is indicated in the policy.
  • the policy further instructs the UE to send the Registration Request when the UE in a location and the location is indicated in the policy.
  • the policy further instructs the UE to send the Registration Request if no traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy.
  • the policy further instructs the UE to send the Registration Request if no control plane traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy.
  • the policy further instructs the UE to send the Registration Request if no PDU Session has been established with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy.
  • the policy may be a URSP rule.
  • a method, system, computer readable storage medium, or apparatus provides for receiving an Allowed NSSAI from the network; the Allowed NSSAI includes at least one S-NSSAI; receiving a policy from a network; using the policy to determine an S-
  • NS SAI using the policy to determine to send a PDU Session Establishment Request to the network after receiving the Allowed NS SAI on the condition that the Allowed NS SAI includes the S-NSSAI; and sending a PDU Session Establishment Request to the network and the request includes the S-NSSAI.
  • the UE uses the policy to determine a DNN and the PDU Session Establishment Request includes the DNN. All combinations in this paragraph and the below paragraphs (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.
  • a method, system, computer readable storage medium, or apparatus provides for receiving an Allowed NS SAI from the network, the Allowed NS SAI includes at least one S-NSSAI; receiving a policy from a network; using the policy to determine an S- NSSAI; and using the policy to determine to send a PDU Session Establishment Request to the network when the UE is in a location on the condition that the Allowed NS SAI includes the S-NSSAI.
  • An apparatus may use the policy to determine to send a PDU Session Release Request to the network after a condition is met.
  • a condition may be that no data has been sent on the PDU Session for a time period and the policy indicates the time period.
  • a method, system, computer readable storage medium, or apparatus provides for receiving an Allowed NSSAI from the network, the Allowed NSSAI includes at least one S-NSSAI; receiving a URSP rule from the network, the URSP rule include at least one RSD, the RSD include a second S-NSSAI, the second S-NSSAI is not included in the Allowed NSSAI, the RSD includes an indication that the UE should request that the network add the second S-NSSAI to the Allowed NSSAI if the RSD is evaluated; and determining to send a registration request to the network in order to request that the second S-NSSAI be added to the Allowed NSSAI. All combinations in this paragraph (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Methods, apparatus, and systems for network-controlled UE behavior for slice access and remapping.

Description

NETWORK CONTROLLED UE BEHAVIOR FOR SLICE ACCESS
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63/110,197, filed on November 5, 2020, entitled “Network Controlled UE Behavior For Slice Access” and U.S. Provisional Patent Application No. 63/185,619, filed on May 7, 2021, entitled “Network Controlled UE Behavior For Slice Access,” the contents of which are hereby incorporated by reference herein.
BACKGROUND
[0002] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, the core transport network, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred as 3G), LTE (commonly referred as 4G), LTE-Advanced standards, and New Radio (NR), which is also referred to as “5G” 3GPP NR standards development is expected to continue and include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 7 GHz, and the provision of new ultra-mobile broadband radio access above 7 GHz. The flexible radio access is expected to consist of a new, non-backwards compatible radio access in new spectrum below 7 GHz, and it is expected to include different operating modes that may be multiplexed together in the same spectrum to address a broad set of 3GPP NR use cases with diverging requirements. The ultra-mobile broadband is expected to include cmWave and mmWave spectrum that will provide the opportunity for ultra-mobile broadband access for, e.g., indoor applications and hotspots. In particular, the ultra-mobile broadband is expected to share a common design framework with the flexible radio access below 7 GHz, with cmWave and mmWave specific design optimizations.
[0003] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB) ultra-reliable low-latency Communication (URLLC), Non-Terrestrial Networks (NTN), massive machine type communications (mMTC), network operation (e.g., network slicing, routing, migration and interworking, energy savings), and enhanced vehicle- to-everything (eV2X) communications, which may include any of Vehicle-to-Vehicle Communication (V2V), Vehicle-to-Infrastructure Communication (V2I), Vehicle-to-Network Communication (V2N), Vehicle-to-Pedestrian Communication (V2P), and vehicle communications with other entities. Specific service and applications in these categories include, e.g., monitoring and sensor networks, device remote controlling, bi-directional remote controlling, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive ecall, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones to name a few. All of tThese use cases and others are contemplated herein.
[0004] This background information is provided to reveal information believed by the applicant to be of possible relevance. No admission is necessarily intended, nor should be construed, that any of the preceding information constitutes prior art.
SUMMARY
[0005] Described herein are methods, apparatus, and systems for improved network-controlled UE behavior for slice access. In one aspect, described herein is a mechanism by which the UE indicates to the network about its support for Slice Resource Management Capability (SRMC).
[0006] Also described herein is a mechanism by which the network conveys USAB policies to the UE for optimal slice access during UE Registration Procedure or UE Configuration Update procedure. How the UE implements the USAB policies during a UE Registration Procedure to request network slices in an optimal manner is also described.
[0007] How the network or the UE keeps track of a Slice Registration Hold Time and the UE enforces Slice Registration Hold Time to remove authorized network slices (deregister S-NSSAIs) from the UE is also described.
[0008] How the UE or the network may enforce a Session Hold Time to release an established protocol data unit (PDU) session is also described. [0009] Also described herein are mechanisms by which the UE implements the USAB policies during a PDU Session Establishment Procedure to establish PDU sessions in an optimal manner.
[0010] Also described herein is a mechanism for PDU Session release in which, the network sends an explicit release signal to the UE or an explicit release signal with a Grace Timer.
[0011] Also described herein is a mechanism for PDU Session release in which, a network or UE may apply an additional time called release delay time before releasing a PDU session when the UE encounters a context (e.g., location change).
[0012] A new PDU session control flag is also introduced in the URSP rules, which controls if the UE can establish a new PDU session for a matching Route Selection Descriptor.
[0013] Also described are enhancements related to slice remapping.
[0014] For example, a method is disclosed by which a UE indicates to the network about the UE’s Slice Remapping Capability (USRC) and the UE’s intention/desire to remap the PDU Session if necessary.
[0015] Also described is a slice remapping method wherein based on a slice remapping trigger in the network, the network chooses a remapped slice, where PDU Sessions from the old slices are transferred. The UE may receive in the Registration Accept message an Allowed NSSAI that includes the S-NSSAI for the remapped slice with remapped slice indicators and PDU Session IDs for the PDU Sessions that were transferred to the remapped slice.
[0016] Also described is a method by which the UE receives remapping rules in the Registration Accept message that indicates to the UE how S-NSSAI(s) in the Rejected NSSAI map to S-NSSAI(s) in the Allowed NSSAI. The UE can consider and access remapped S-NSSAI(s) as equivalent in the Registration Area, should the UE need to access to slices that were rejected.
[0017] Further described is a method for a UE to indicate its preference to receive Remappable Slices during a Registration Procedure and, should the UE Registration procedure be successful, for the network to deliver Allowed NSSAI and Configured NSSAI that preferably consist of S-NSSAI(s) of the Remappable Slices marked with Remappable Slice indicator. [0018] Still further described is a method by which UE may choose to initiate Registration Update procedure with Remappable Slices received in the Configured NSSAI if no Remappable Slices are received in the Allowed NSSAI.
[0019] Also further described is a method that allows a UE to receive a Default Remapped Slice if the UE indicated in the Registration Request message a preference to receive a Remapped Slice but there are no Remapped Slices available.
[0020] Also described is a method for a UE to indicate to the network USRC and UE’s desire for slice remapping of the slice where PDU Session is being established, during a PDU Session Establishment procedure and, receive an indication if the slice can be remapped and the S-NSSAI where the slice with PDU Session will be remapped to, in the PDU Session Accept message.
[0021] Also described is a method that allows the UE to choose a Remappable Slice from the Allowed NSSAI, if available, and establish a PDU Session towards the Remappable Slice if the slice with the PDU Session doesn’t have a Remapped Slice.
[0022] Further described is a method for RAN nodes to assist the UE with the slice remapping process. The RAN node may receive remapped slices for the Allowed NSSAI in the form of a Slice Remapping table after a successful UE Registration procedure, which is used during slice remapping.
[0023] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to features that solve any or all disadvantages noted in any part of this disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0024] The following detailed description is better understood when read in conjunction with the appended drawings. In the drawings:
[0025] FIG. 1 illustrates an example 5G system service-based architecture;
[0026] FIG. 2 illustrates an example non-roaming 5G system architecture in reference point representation; [0027] FIG. 3 illustrates an example of a UE registering and establishing a PDU session towards one or more network slices;
[0028] FIG. 4 illustrates an example of USAB policy configuration in a UE;
[0029] FIG. 5 illustrates an example of pre-configured USAB policies and UE configuration update;
[0030] FIG. 6 illustrates an example of PDU session establishment as a UE registers with the network and receives authorized slice(s) information;
[0031] FIG. 7 illustrates an example user interface;
[0032] FIG. 8A illustrates an exemplary communications system;
[0033] FIG. 8B illustrates an exemplary radio access networks (RANs) and core networks;
[0034] FIG. 8C illustrates an exemplary radio access networks (RANs) and core networks;
[0035] FIG. 8D illustrates an exemplary radio access networks (RANs) and core networks;
[0036] FIG. 8E illustrates an exemplary communications system;
[0037] FIG. 8F illustrates an exemplary communications apparatus or device;
[0038] FIG. 8G illustrates an exemplary computing system;
[0039] FIG. 9 illustrates an example use case in which a network slice serving a UE in a first registration area may not be available in a second registration area;
[0040] FIG. 10 illustrates an exemplary of slice remapping during a UE registration method.
[0041] FIG. 11 illustrates an example of remappable slice preference during a UE registration method;
[0042] FIG. 12 illustrates an example method for a UE to convey its slice remapping capability during PDU session establishment;
[0043] FIG. 13 illustrates an example method for slice remapping using a RAN node;
[0044] FIG. 14 illustrates an exemplary method for network controlled UE behavior for slice access; and
[0045] FIG. 15 illustrates an exemplary method for network controlled UE behavior for slice access. DET AILED DESCRIPTION
Terms and Definitions
[0046] The following is a list of terms that may appear in the following description. Unless otherwise specified, the terms used herein are defined as follows.
[0047] Network Slice: A logical network that provides specific network capabilities and network characteristics.
[0048] Network Slice Instance: A set of Network Function instances and the required resources (e.g., compute, storage and networking resources) which form a deployed Network Slice.
[0049] Service Area Restrictions: A Service Area Restriction may contain one or more (e.g., up to 16) entire Tracking Areas each or the Service Area Restriction may be set as unlimited (i.e. contain all Tracking Areas of the PLMN). The UE's subscription data in the UDM includes a Service Area Restriction which may contain either Allowed or Non- Allowed Areas-specified by using explicit Tracking Area identities or other geographical information (e.g., longitude/latitude, zip code, etc.).
[0050] Tracking Area: A tracking area is a set of cells. Tracking areas can be grouped into lists of tracking areas (TA lists), which can be configured on the User Equipment (UE). Tracking Areas (TA) is used for UE’s access control, location registration, paging and mobility management.
[0051] Network Function (NF): A processing function in a network, which has defined functional behavior and defined interfaces. An NF can be implemented either as a network element on a dedicated hardware, or as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure.
[0052] NF instance: An identifiable instance of the NF.
[0053] Slice Registration Hold Time: A pre-defined time that describes the inactivity time in a S-NSSAI/slice after UE has received an authorized S-NSSAI for a slice and before UE establishes a protocol data unit (PDU) session towards that slice. For example, if the Slice Registration Hold Time expires for a slice, that slice is removed from the Allowed NS SAI. 2020P00294WG / 106693.001425
[0054] Session Hold Time: A pre-defined time that describes the inactivity time calculated for an established PDU session. In other words, length of time in an established PDU session when no user plane data (UL/DL) is exchanged between the UE and the network. For example, if the Session Hold Time expires for a PDU session, then the session may be released.
[0055] Slice Remapping: Slice Remapping is the process of moving a UE’s activity within a first slice to a second slice.
[0056] Remapped Slice: A second slice which acts as an equivalent or substitute for the first slice with respect to capability and service the slice supports.
[0057] Remappable Slice: Any slice for which a remapped slice has been established.
[0058] As used herein, the phrase “the UE will Deregister from the Slice” means that, when the slice is in the UE’s Allowed NSSAI, the UE will send a Registration Request to the network without including the slice in the Requested NSSAI of the Registration Request.
[0059] As used herein, the phrase “the Network will Deregister the UE from the Slice” means that, when the slice is in the UE’s Allowed NSSAI, the Network will send a UE Configuration Update Request to the UE without including the slice in the Allowed NSSAI of the UE Configuration Update Request.
Architecture of 5G Network
[0060] FIG. 1 shows the non-roaming reference architecture with service-based interfaces within the Control Plane. FIG. 2 depicts the 5G System architecture in the nonroaming case, using the reference point representation showing how various network functions interact with each other.
[0061] The mobility management and session management functions are separated. A single N1 NAS connection is used for both Registration Management and Connection Management and for Session Management (SM) related messages and procedures for a UE. The single N1 termination point is located in AMF. The AMF forwards SM related NAS information to the SMF. AMF handles the Registration Management and Connection Management part of NAS signaling exchanged with the UE. SMF handles the Session management part of NAS signaling exchanged with the UE.
Network Function
- 7 -
4871-1319-0402.1 2020P00294WG / 106693.001425
[0062] The 5G System architecture is defined to support data connectivity and services enabling deployments to use techniques such as e.g., Network Function Virtualization and Software Defined Networking. The 5G System architecture shall leverage service-based interactions between Control Plane (CP) Network Functions where identified.
[0063] An NF is a processing function in a network, which has defined functional behavior and defined interfaces. An NF can be implemented either as a network element on a dedicated hardware, or as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure.
Network Slicing in 5GC
[0064] A Network Slice is defined as a logical network that provides specific network capabilities and network characteristics. A Network Slice within a PLMN includes the Core Network Control Plane and User Plane Network Functions. Network Slice instance is defined as a set of Network Function instances and the required resources (e.g., compute, storage and networking resources) which form a deployed Network Slice.
[0065] Network slices may differ for supported features and network function optimizations, in which case such Network Slices may be of different Slice/Service Types. The operator can deploy multiple Network Slice instances delivering the same features but for different groups of UEs, e.g., as they deliver a different committed service or because they are dedicated to a customer, in which case such Network Slices may be of the same Slice/Service Type but are distinguished through different Slice Differentiators.
[0066] The network may serve a single UE with one or more Network Slice instances simultaneously via a 5G-AN and associated with at most eight different S-NSSAIs in total, regardless of the access type(s) over which the UE is registered (i.e. 3GPP Access or N3GPP Access). The AMF instance serving the UE logically belongs to each of the Network Slice instances serving the UE, i.e. this AMF instance is common to the Network Slice instances serving a UE.
Identification and selection of a Network Slice: S-NSSAI and NSSAI
[0067] A network slice is identified by an S-NSSAI, which is comprised of:
• A Slice/Service type (SST), which refers to the expected Network Slice behavior in terms of features and services;
- 8 -
4871-1319-0402.1 • A Slice Differentiator (SD), which is optional information that complements the Slice/Service type(s) to differentiate amongst multiple Network Slices of the same Slice/Service type.
[0068] An S-NSSAI can have standard values (i.e. such S-NSSAI is only comprised of an SST with a standardized SST value, and no SD) or non-standard values (i.e. such S- NSSAI is comprised of either both an SST and an SD or only an SST without a standardized SST value and no SD). An S-NSSAI with anon-standard value identifies a single Network Slice within the PLMN with which it is associated. An S-NSSAI with a non-standard value shall not be used by the UE in access stratum procedures in any PLMN other than the one to which the S-NSSAI is associated. Table 1 shows the standardized SST value.
[0069] The NSSAI is a collection of S-NSSAIs. An NSSAI may be a Configured NSSAI, a Requested NSSAI or an Allowed NSSAI. There can be at most eight S-NSSAIs in Allowed and Requested NSSAI sent in signaling messages between the UE and the Network. The Requested NSSAI signaled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice instance(s) for this UE.
[0070] 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 in different Tracking Areas. When multiple Network Slice instances associated with the same S-NSSAI are deployed in the same Tracking Areas, the AMF instance serving the UE may logically belong to (i.e. be common to) more than one Network Slice instance associated with this S-NSSAI.
[0071] Based on the Requested NSSAI (if any) and the Subscription Information, the 5GC is responsible for selection of a Network Slice instance(s) to serve a UE including the 5GC Control Plane and User Plane Network Functions corresponding to this Network Slice instance(s).
[0072] The (R)AN may use Requested NSSAI in access stratum signalling to handle the UE Control Plane connection before the 5GC informs the (R)AN of the Allowed NSSAI. The Requested NSSAI is used by the RAN for AMF selection, as described in clause 6.3.5. The UE shall not include the Requested NSSAI in the RRC Resume when the UE asks to resume the RRC connection and is CM-CONNECTED with RRC Inactive state.
- 9 -
4871-1319-0402.1 2020P00294WG / 106693.001425
[0073] When a UE is successfully registered over an Access Type, the CN informs the (R)AN by providing the Allowed NS SAI for the corresponding Access Type.
[0074] Standardized SST values provide a way for establishing global interoperability for slicing so that PLMNs can support the roaming use case more efficiently for the most commonly used Slice/Service Types. The SSTs which are standardized are in the following Table 1.
Table 1 Standardised SST values
Figure imgf000012_0001
Configured NSSAI
[0075] Configured NSSAI is the NSSAI provisioned in the UE applicable to one or more PLMNs. A Configured NSSAI may be configured by a Serving PLMN and apply to the Serving PLMN. There is at most one Configured NSSAI per PLMN.
Default Configured NSSAI
[0076] A Default Configured NSSAI is configured by the HPLMN and that applies to any PLMNs for which no specific Configured NSSAI has been provided to the UE. The value(s) used in the Default Configured NSSAI are expected to be commonly decided by all roaming partners. The Default Configured NSSAI, if it is configured in the UE, is used by the UE in a Serving PLMN only if the UE has no Configured NSSAI for the Serving PLMN. The UE may be pre-configured with the Default Configured NSSAI.
Requested NSSAI
[0077] Requested NSSAI is the NSSAI provided by the UE to the Serving PLMN during registration. The S-NSSAIs in the Requested NSSAI are part of the Configured or Allowed NSSAIs applicable for this PLMN, when they are available. If no Configured
- 10 -
4871-1319-0402.1 2020P00294WG / 106693.001425
NSSAI and Allowed NSSAI for the PLMN are available, the S-NSSAIs in the Requested NSSAI correspond to the Default Configured NSSAI, if configured in the UE.
[0078] The Requested NSSAI signalled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice instance(s) for this UE. Based on the Requested NSSAI (if any) and the Subscription Information, the 5GC is responsible for selection of a Network Slice instance(s) to serve a UE including the 5GC Control Plane and User Plane Network Functions corresponding to this Network Slice instance(s). The (R)AN may use Requested NSSAI in access stratum signalling to handle the UE Control Plane connection before the 5GC informs the (R)AN of the Allowed NSSAI
Allowed NSSAI
[0079] Allowed NSSAI is the NSSAI provided by the Serving PLMN during e.g., a Registration procedure, indicating the S-NSSAIs values the UE could use in the Serving PLMN for the current Registration Area. Upon successful completion of a UE's Registration procedure over an Access Type, the UE obtains from the AMF an Allowed NSSAI for this Access Type, which includes one or more S-NSSAIs and, if needed (see clause 5.15.4.1.2 for when this is needed), their mapping to the HPLMN S-NSSAIs. These S-NSSAIs are valid for the current Registration Area and Access Type provided by the AMF the UE has registered with and can be used simultaneously by the UE (up to the maximum number of simultaneous Network Slice instances or PDU Sessions)
Mapping Of Allowed NSSAI
[0080] The Mapping Of Allowed NSSAI is the mapping of each S-NSSAI of the Allowed NSSAI for the Serving PLMN to the HPLMN S-NSSAIs.
Mapping Of Configured NSSAI
[0081] The Mapping Of Configured NSSAI is the mapping of each S-NSSAI of the Configured NSSAI for the Serving PLMN to the HPLMN S-NSSAIs. SSC Modes
SSC Mode 1
[0082] With SSC mode 1, the network preserves the connectivity service provided to the UE. For the case of PDU Session of IPv4 or IPv6 or IPv4v6 type, the IP address is preserved. The UPF acting as PDU Session Anchor at the establishment of the PDU Session is maintained regardless of the access technology (e.g., Access Type and cells) a UE is successively using to access the network. In the case of a PDU Session of IPv4 or IPv6 or
- 11 -
4871-1319-0402.1 IPv4v6 type, IP continuity is supported regardless of UE mobility events. SSC Mode 1 may apply to any PDU Session type and to any access type.
SSC Mode 2
[0083] With SSC mode 2, the network may release the connectivity service delivered to the UE and release the corresponding PDU Session(s). For the case of IPv4 or IPv6 or IPv4v6 type, the release of the PDU Session induces the release of IP address(es) that had been allocated to the UE. If a PDU Session of SSC mode 2 has a single PDU Session Anchor, the network may trigger the release of the PDU Session and instruct the UE to establish a new PDU Session to the same data network immediately.
[0084] The trigger condition depends on operator policy e.g., request from Application Function, based on load status, etc. At establishment of the new PDU Session, a new UPF acting as PDU Session Anchor can be selected. Otherwise, if a PDU Session of SSC mode 2 has multiple PDU Session Anchors (i. e. , in the case of multi-homed PDU Sessions or in the case that UL CL applies to a PDU Session of SSC mode 2), the additional PDU Session Anchors may be released or allocated. SSC mode 2 may apply to any PDU Session type and to any access type.
SSC Mode 3
[0085] With SSC mode 3, a connection through new PDU Session Anchor point is established before the previous connection is terminated in order to allow for better service continuity. For the case of IPv4 or IPv6 or IPv4v6 type, the IP address is not preserved in this mode when the PDU Session Anchor changes.
[0086] For PDU Session of SSC mode 3, the network allows the establishment of UE connectivity via a new PDU Session Anchor to the same data network before connectivity between the UE and the previous PDU Session Anchor is released. When trigger conditions apply, the network decides whether to select a PDU Session Anchor UPF suitable for the UE's new conditions (e.g., point of attachment to the network). In Release 16, SSC mode 3 only applies to IP PDU Session type and to any access type. After the new IP address/prefix has been allocated, the old IP address/prefix is maintained during some time indicated to the UE via NAS signaling or via Router Advertisement and then released. If a PDU Session of SSC mode 3 has multiple PDU Session Anchors, the additional PDU Session Anchors may be released or allocated.
- 12 -
4871-1319-0402.1 URSP Rules
[0087] The UE Route Selection Policy (URSP) includes a prioritized list of URSP rules. Table 2 shows URSP.
Table 2 UE Route Selection Policy
Figure imgf000015_0001
[0088] The structure of the URSP rules is described in Table 3 and Table 4 as follows:
Table 3 UE Route Selection Policy Rule
Figure imgf000015_0002
- 13 -
4871-1319-0402.1
Figure imgf000016_0001
- 14-
4871-1319-0402.1 Table 4 Route Selection Descriptor
Figure imgf000017_0001
- 15 -
4871-1319-0402.1
Figure imgf000018_0001
- 16-
4871-1319-0402.1 2020P00294WG / 106693.001425
Figure imgf000019_0001
Example Use Case 1
[0089] General behaviors of a UE are to register itself with the core network and establish PDU sessions to send and receive data. Upon a successful registration, UE may receive Configured NSSAI or, may receive Allowed NSSAI from the network if Requested NS SAI was sent in the Registration Request. The UE may initiate PDU Sessions towards one or more slices with S-NSSAIs from Allowed NSSAI. The UE may establish PDU sessions towards one or more data networks. As shown in FIG. 3, UEs (a mobile phone, smart car, drone, etc.) may use 5GS to carry out respective services.
[0090] After a UE receives an Allowed NSSAI, the UE may or may not establish PDU Sessions in the slices. This means that one or more authorized slices could remain “unused” for any services by the UE. But since the slice was regarded authorized and included in the Allowed NSSAI with the Registration Accept message, the network reserves corresponding resources. For example, the UE count for the network slice may be incremented for the registered UEs that received the Allowed S-NSSAI for that slice.
- 17 -
4871-1319-0402.1 2020P00294WG / 106693.001425
[0091] Consider a scenario where, an area may be administered for surveillance. There could be multiple fixed surveillance cameras and, some surveillance drones equipped with 5G capabilities for security and monitoring purposes. While fixed cameras may surveil the area the entire time, the drones may be triggered for surveillance only when there occurs a special case where, some target subject may be moving and may needed to be tracked beyond the points where the fixed cameras wouldn’t be sufficient to locate the subject. In such a case, drones may remain on standby until such event occurs. In other words, drones may be registered with the network but may not transmit or receive user data to and from the network until a specified event occurs.
[0092] FIG. 3 shows that the mobile UE and the drone UE are registered with the network and have been authorized to use classifiedComm and DroneControl slices, respectively. It also shows that although these two UEs are authorized to use their respective slices, they are not utilizing them.
[0093] Similarly, after a UE has received an Allowed NSSAI, the UE may establish a PDU session to send and receive UE data. For a service which may not need a continuous flow of user plane data, the PDU session may remain without any UL/DL traffic, and that could be for a substantial amount of time. In FIG. 3 a smart car may continuously send data via the V2X slice to the network or receive control signal from the network when the car is moving. However, when the car is based at a charging station and uploading its data to an loT slice (not shown in the figure), the registration with the V2X slice may remain intact. In another example, a mobile UE which may have had a PDU session earlier, may have that session established but may not have any active UL/DL data for significant amount of time.
Example Use Case 2
[0094] A mobile UE such as an autonomous vehicle (e.g., AV I) shown in FIG. 9 may have an ongoing PDU session towards the core network via RAN_1 access network. A network slice, V2X_1 is allocated for AV_1 in the core network in the registration area RA I. V2X_1 slice facilitates network infrastructure which provides the required SLA for AV_1. As an autonomous vehicle can be mission critical in nature, SLA may need to be enforced at all times. As AV_1 moves to a different registration area RA_2, it should continue receiving same service as in RA I, desirably without any interruption. However, the V2X_1 slice may or may not be available in RA_2.
- 18 -
4871-1319-0402.1 Example Problems
[0095] When UE registers with a network, it may request to register with up to 8 slices. Currently, the 5GC does not control how the S-NSSAI(s) in the Requested NSSAI are selected before sending it. In other words, UE may decide to attempt to register to any slice from its Configured NSSAI, regardless of whether or not UE intends to access the resources of the slice. This is not an optimal situation because, when the S-NSSAIs remain in the Allowed NSSAI of UE even when UE is not using the services of the slice, the core network still needs to allocate resources for UE in the slices. As a result, resources are wasted. Hence, the 5GC needs to be enhanced so that UE-slice registration can be controlled in an optimal manner.
[0096] When a UE Application stops utilizing the services of a slice, there is no system control over when UE de-registers from the slice. Thus, the situation with respect to slice de-regi station is similar. That is, when the S-NSSAIs remain in the Allowed NSSAI of even when the UE is not using the services of the slice, the core network still needs to allocate resources for the UE in the slices. As a result, resources are wasted. Hence, the 5GC needs to be enhanced so that UE-slice de-registration can be controlled in an optimal manner.
[0097] The 5GC does not control completely when a UE establishes a PDU Session. Some control over PDU Session establishment is provided by URSP policies which are used by the UE when new application traffic is initiated to determine if a new or existing PDU Session will be used to carry the application traffic. However, a UE may choose to establish PDU Session(s) towards certain slice/DNN combinations long before Applications on the UE generate traffic for the PDU Session. This is not an optimal situation because, when the PDU Sessions are maintained even when the UE is not using PDU Session, the core network still needs to allocate resources for the PDU Session. As a result, resources are wasted. Hence, the 5GC needs to be enhanced so that PDU Session Establishment can be controlled in an optimal manner. On the other hand, there may be services that may not require data transfers the majority of the time. Hence, even with an established PDU session, a UE may not be actively sending or receiving data, leading to a nonoptimal use of slice resources resulting in a lost utilization opportunity and wasted resources. Therefore, the 5GC needs to be enhanced so that PDU Session Release can be controlled in an optimal manner.
[0098] A UE may have established PDU sessions in one or more network slices in a given (source) geographical region (e.g., TA, RA, etc.). The UE may move to a different
- 19 -
4871-1319-0402.1 (destination) geographical region during the lifetime of a PDU session. A UE may have an agreed SLA with the MNO, which needs to be maintained throughout the lifetime of a PDU session. However, when a UE moves to a destination geographical region, the UE may come across a new scenario, where the network slice that was serving the UE may not be accessible. Currently, the 5GS doesn’t provide a service continuity mechanism for PDU sessions that have ongoing services in slices that are not available in the UE’s new RA. This is illustrated in FIG. 9.
[0099] 3GPP TR 38.832 explores a concept of slice remapping in which the UE may be provided with an equivalent network slice(s) which is able to gracefully accept the PDU session from the source geographical region’s network slice and continue with the services with required SLA.
[00100] Furthermore, provided that the slice is remapped to an equivalent network slice with UE in the destination geographic region and services to the UE are facilitated, currently 5GS doesn’t provide mechanisms by which the source network slice seamlessly serves the UE when the UE moves back to the source geographical region.
- 20 -
4871-1319-0402.1 Network Controlled UE Behavior for Slice Access
[00101] Described herein are methods, apparatus, and systems for improved network-controlled UE behavior for slice access, which address the shortcomings discussed above.
[00102] A network may be able to control UE behavior for slice access, both for UE registration with network slices and PDU session establishment towards the slices, in an optimal manner. Following enhancements are disclosed for optimal UE behavior for slice access:
[00103] Described herein is a mechanism by which the UE indicates to the network about its support for Slice Resource Management Capability (SRMC). SRMC is a capability to control UE behavior for optimal slice access and PDU Session access.
[00104] A UE that supports the SRMC is able to receive a set of policies for optimal network slice utilization called UE Slice Access Behavior (USAB) policies. USAB are a set of instructions or rules designed to apply various attributes or constraints that instruct UE to request network slices and remove authorized slices and, to establish and release PDU sessions in an optimal manner.
[00105] Also described herein is a mechanism by which the network conveys USAB policies to the UE for optimal slice access during UE Registration Procedure or UE Configuration Update procedure. The network node that provides the polices to the UE (e.g., the AMF or PCF) may obtain the policies, or derive the polices, from the UE’s UE Subscription data.
[00106] How the UE implements the USAB policies during a UE Registration Procedure to request network slices in an optimal manner is also described. In other words, how the USAB policies are used to control what slices (S-NSSAI’s) are included in the UE’s Requested NS SAI is described.
[00107] How the network or the UE keeps track of a Slice Registration Hold Time and the UE enforces Slice Registration Hold Time to remove authorized network slices (deregister S-NSSAIs) from the UE is also described. A Slice Registration Hold Time is a time which describes the inactivity time in a S-NSSAI/slice after UE has received an authorized S- NSSAI for a slice and before UE establishes a PDU session in that slice.
- 21 -
4871-1319-0402.1 [00108] Furthermore, how the UE or the network may enforce a Session Hold Time to release an established PDU session is also described. A Session Hold Time is the amount of time that the network tells the UE that a PDU Session may be unused (e.g., no UL or DL data) before it is released.
[00109] Also described herein are mechanisms by which the UE implements the USAB policies during a PDU Session Establishment Procedure to establish PDU sessions in an optimal manner. For example, the UE may be instructed to start a PDU session immediately after UE receives authorized slices.
[00110] Also described herein is a mechanism for PDU Session release in which, the network sends an explicit release signal to the UE or an explicit release signal with a Grace Timer. The UE may request network for PDU session release or implement the Grace Time before requesting network for PDU session release.
[00111] Also described herein is a mechanism for PDU Session release in which, a network or UE may apply an additional time called release delay time before releasing a PDU session when the UE encounters a context (e.g., location change).
[00112] A new PDU session control flag is also introduced in the URSP rules, which controls if the UE can establish a new PDU session for a matching Route Selection Descriptor.
[00113] Furthermore, a UE that has established PDU Sessions in one or more slices in the core network may come across a scenario where the slice may be inaccessible, for example when the UE moves from one registration area to another. In such a scenario, to help the UE with session continuity 5GS may be enhanced with slice remapping functionality. In particular, the following enhancements to slice remapping are disclosed.
[00114] A method is disclosed by which a UE may indicate to the network about the UE’s Slice Remapping Capability (USRC) and the UE’s intend on/desire to remap the PDU Session if necessary.
[00115] Also described is a slice remapping method wherein based on a slice remapping trigger in the network, the network chooses a remapped slice, where PDU Sessions from the old slices are transferred. The UE may receive in the Registration Accept message an Allowed NSSAI that includes the S-NSSAI for the remapped slice with remapped slice indicators, and PDU Session IDs for the PDU Sessions that were transferred to the remapped slice.
- 22 -
4871-1319-0402.1 [00116] Also described is a method by which the UE receives remapping rules in the Registration Accept message that indicates to the UE how S-NSSAI(s) in the Rejected NSSAI map to S-NSSAI(s) in the Allowed NSSAI. The UE can consider and access remapped S-NSSAI(s) as equivalent in the Registration Area, should the UE need to access to slices that were rejected.
[00117] Also described is a method for a UE to indicate its preference to receive Remappable Slices during a Registration Procedure and, should the UE Registration procedure be successful, how the network can deliver Allowed NSSAI and Configured NSSAI that preferably include S-NSSAI(s) Remappable Slices marked with Remappable Slice indicator.
[00118] Also described is a method by which a UE may choose to initiate Registration Update procedure with Remappable Slices received in the Configured NSSAI if no Remappable Slices are received in the Allowed NSSAI.
[00119] Also further described is a method that allows a UE to receive a Default Remapped Slice if the UE indicated in the Registration Request message a preference to receive a Remapped Slice but there are no Remapped Slices available.
[00120] Also described is a method for a UE to indicate to the network USRC and UE’s desire for slice remapping of the slice where PDU Session is being established, during a PDU Session Establishment procedure and, receive an indication if the slice can be remapped and the S-NSSAI where the slice with PDU Session will be remapped to, in the PDU Session Accept message.
[00121] Still further described is a method that allows the UE to choose a Remappable Slice from the Allowed NSSAI, if available, and establish a PDU Session towards the Remappable Slice if the slice with the PDU Session doesn’t have a Remapped Slice.
[00122] Also described is a method for RAN nodes to assist the UE with the slice remapping process. A RAN node may receive remapped slices for the Allowed NSSAI in the form of a Slice Remapping table after a successful UE Registration procedure, which is used during slice remapping.
[00123] The two fundamental activities that a UE is constantly involved in are registration and PDU session establishment with the core network. As discussed above, there are occasions when UE registers with a network slice but may not use it (e.g., establish a
- 23 -
4871-1319-0402.1 PDU session) or UE establishes a PDU session but may not send or receive any user plane data in the PDU Session. Unused Registrations and PDU Sessions with the network slices may result in a non-optimal utilization of resources in the 5G system.
Slice Resource Management Capability
[00124] This disclosure describes enhancement mechanisms to optimize the UE’s behavior as it relates to UE Network Slice registration and de-registration. Similarly, it further describes the enhancement of PDU sessions establishment decisions with the slices and their usage to optimize UE behavior. The mechanism by which UE behavior may be controlled is a capability that a network needs to support. This capability may be referred to as Slice Resource Management Capability (SRMC). The SRMC may be activated and conveyed to the UE by the network. The network may broadcast the SRMC indicator to the UEs. UEs may support SRMC functionality as follows.
[00125] Upon detecting the SRMC indicator (e.g., from the network broadcast), the UE may request SRMC configuration (e.g., at UE registration) from the network. The UE’s SRMC configuration request during a UE Registration Request may serve as its indication of support for SRMC and hence, the network may be able to send the policies required to control UE behavior.
[00126] The UE may convey its support for SRMC during UE Registration Request without any SRMC -related information such as broadcast from the network. The UE may just send an indication for the support of SRMC configuration. The UE’s SRMC configuration request during a UE Registration Request may serve as its indication of support for SRMC and hence, the network may be able to send the policies required to control UE behavior. Note that the mechanisms described in this disclosure may be implemented even without using explicit network or UE SRMC indication (e.g., in the broadcast).
Controlling when a UE Registers to a Slice
[00127] One way to control the behavior of the UE for slice access, is to configure the UE with policies that control registration decisions. In particular, to provide the UE with mechanisms by which the UE selects a Requested NS SAI or when UE can remove a slice from its Allowed NSSAI (e.g., via a Registration Update) so that network utilization is optimal.
- 24 -
4871-1319-0402.1 Network Slice Registration Policies
[00128] A UE may initiate a registration process, which includes receiving authorized network slices based on user input, application requirements, UE type and function, UE capabilities, SLAs, operator policies, environmental contexts like time, place, etc.
[00129] In this solution, the UE is also configured with UE Slice Access Behavior (USAB) policies. The USAB Policies may be part of the URSP policies, part of the Access and Mobility Policies, or they may be stored as a set of policies that are separate from the URSP and Access and Mobility Policies. The USAB policies may be stored as part of the Configured NS SAI or the Allowed NS SAI.
[00130] The USAB Policies may be pre-configured or may be received from the network. The USAB policies may be received during the UE Registration Procedure or UE Configuration Update Procedure. The UE may indicate in the UE Registration Procedure that the UE is capable of receiving and applying/enforcing USAB Policies.
[00131] The USAB policies control when the UE attempts to register with the slices (e.g., send a registration request with the associated S-NSSAI in the Requested NSSAI). For example, the policies may describe what events and conditions, or combination of events (e.g., application traffic or request, no other suitable slice, etc.) should occur or what criteria or conditions (e.g., time of day, UE location) should be met before the UE attempts to register with the slice.
[00132] For each slice (S-NSSAI) in the Configured NSSAI or the Allowed NSSAI, the USAB policy provides the following six rules or instructions. First, an instruction that the UE should always (herein “always” is meant to be for a defined amount of time or instructed otherwise) include the S-NSSAI in the Requested NSSAI if the UE enters a new Registration Area or when the UE performs any Registration Update. The instruction may be further associated with location information that indicates when the UE should, or should not, attempt to apply the policy. Second, an instruction that the UE should register with specified slices as soon as UE powers on, enters a new PLMN, or certain PLMNs. In other words, the indication may indicate that the UE should include the slice in its Requested NSSAI in Registration Request whose Registration Type is Initial Registration or the first registration in a PLMN after being in a different PLMN.
- 25 -
4871-1319-0402.1 [00133] Third, an instruction that the UE should only register for a network slice if an application requests to use it. In other words, the indication may indicate that the UE should send a Registration Request and include the slice in the Requested NS SAI only when a UE application explicitly requests to utilize the slice (e.g., via an API or AT Command). Fourth, an instruction for a traffic that, if matches with certain Traffic Descriptors, should not be sent to particular S-NSSAIs. Fifth, instruct a UE to register for only slice requested by top priority applications. For example, the UE may determine priority of a piece of MO traffic based on the Access Category that is associated with the traffic. Thus, the USAB policy that is associated with the slice may indicate to the UE that the UE should attempt to register with the slice when traffic belonging to certain access categories is being generated and can be assigned to the slice. Sixth, an instruction that the S-NSSAI should always be included in the Requested NS SAI of an Initial Registration Request and the UE should remove the slice from the Requested NSSAI and attempt to re-register only when the slice is not being used (e.g., has no established PDU Sessions) and, a space is needed in the Requested NSSAI for a slice that is associated with an application that is attempting to generate MO traffic or needs to receive MT traffic.
[00134] The aforementioned example instructions can be affected by constraints described in Table 6. For example, the USAB policies may include the following information. First, instruction to only apply a policy in certain time period(s). Second, instruction to only apply a policy in certain location(s) or registration areas or tracking areas or PLMNs. Third, if the UE is a multi-user UE, instruct to apply a policy only for specific users. A multi-user UE may be a 5G router where many UEs are connected and that UE ID may behave as a User ID. Alternatively, an autonomous vehicle may be a multi-user UE that could have multiple drivers (users). In this case, some considerable IDs may be human identifiable IDs (names), unique biometrics, alias ID number, etc. For instance, a vehicle’s conveniences (e.g., infotainment, work, speed, comfort, etc.) may need to be adjusted based on each user’s preferences. Fourth, instruct UE to apply a policy (e.g., request certain S- NSSAIs) only if the UE is a member of a group (e.g., co-operative robots). Fifth, instruct the UE not to apply the policy in certain operating band(s) or, to only apply the policy in certain operating bands.
- 26 -
4871-1319-0402.1 Slice De-registration Instructions
[00135] Similar to UE’s registration decisions, UE de-registration from slice(s) may play an important role in UE’s optimal behavior. This section describes when a UE may deregister from an S-NSSAI.
[00136] The USAB policies may include slice de-registration instructions for a UE. In other words, a USAB policy may instruct the UE when to send a Registration Update in which, an S-NSSAI to be de-registered is removed from its Requested NSSAI (e.g., send a Requested NSSAI to the network that does not include at least one of the S-NSSAI(s) that are currently in the UE’s Allowed NSSAI).
[00137] For each slice (S-NSSAI) in the Configured NSSAI or Mapping of NSSAI or the Allowed NSSAI, the USAB may provide the following six instructions to the UE. First, an instruction for UE to de-register from certain S-NSSAIs in specified time periods. Second, instruction for the UE to de-register from certain S-NSSAIs if UE arrives at certain geographical locations, Registration Areas, Tracking Areas, or PLMNs. Third, an instruction for UE to de-register from one or more S-NSSAIs when UE selects particular V-PLMNs. This might be indicated to the UE in the Mapping of Configured NSSAI that is associated with the PLMN. Fourth, an instruction for the UE to De-register from the slice if no MO or MT user plane traffic has been received for the slice for a certain amount of time. The UE may maintain a timer for the slice when the UE is registered to the slice and reset the timer each time data is sent or received for the slice. Fifth, an instruction that the UE should Deregister from the slice if no control plane traffic has been received for the slice for a certain amount of time (e.g., SMS, NIDD, or Service Requests). The UE may maintain a timer for the slice when the UE is registered to the slice and reset the timer each time control plane data is sent or received for the slice. Sixth, an instruction for the UE to Deregister from the slice if no PDU session has been established for a certain amount of time. The UE may maintain a timer for the slice when the UE is registered to the slice and run the timer only when there is no PDU Session associated with the slice.
Instruct UE to De-register S-NSSAI after no activity
[00138] If there is no PDU session establishment towards a slice, it may be identified as a time of inactivity. This inactivity time may be accounted for and, upon attaining a specified time, the UE may be triggered to de-register from the slice(s) or the network may also trigger the process to de-register the slices for the UE. Thus, the timer may
- 27 -
4871-1319-0402.1 2020P00294WG / 106693.001425 be maintained in the UE or the AMF. This inactivity time may be referred to as the Slice Registration Hold Time. An operator may convey a Slice Registration Hold Time to the UE upon successful UE registration.
[00139] Optionally, the Slice Registration Hold Time may be slice-specific. In other words, Slice Registration Hold Time for each slice may be different, which may be based on system factors such as slice priority, urgency, security, safety, or SLA, and is configured by the network operator. In addition, the Slice Registration Hold Time may be different and customized for each UE registered to a slice. For example, if the slice is designed and dedicated for critical system applications, then the Slice Registration Hold Time may vary for that slice as opposed to personal loT slice.
[00140] The Slice Registration Hold Time for a UE may be delivered to the UE via USAB policies. Alternatively, it may also be conveyed to the UE separately after a UE successfully register to the network in the Registration Accept message.
USAB Policy Attributes
[00141] The USAB policy is made up of instructions or rules. Each instruction may be designed such that it takes parameters for certain attributes and contexts and uses them to determine how and whether to apply certain USAB policies. Previous sections discussed many example instructions or rules for UE Slice Registration and UE Slice De-Registration as being parts of the USAB policy. Example USAB policy attributes are depicted and briefly described in Table 5.
Table 5 USAB Policy Attributes
Figure imgf000030_0001
- 28 -
4871-1319-0402.1
Figure imgf000031_0001
-29-
4871-1319-0402.1 2020P00294WG / 106693.001425
Figure imgf000032_0001
Constraints
[00142] In addition to attributes, which are the basis for applying policies, the policies may include constraints which can act as a controlling element in the policies as described in Table 6. USAB Policies, or indications in the policies, can be associated with these constraints so that the UE can know to only apply the policy when the conditions in the constraints apply. When the conditions in the constraints do not apply, the UE may consider the slice to be inaccessible or the UE may consider the policy to be invalid under the current conditions.
- 30 -
4871-1319-0402.1 Table 6 Example Constraints for USAB policies
Figure imgf000033_0001
- 31 -
4871-1319-0402.1 2020P00294WG / 106693.001425
Figure imgf000034_0001
UE Slice Access Behavior Policy Configuration
[00143] USAB policies that influence the behavior of a UE may be configured in the UE during the registration procedure. This capability may be configured in the AMF. In addition, the enhanced slice deregistration rules on the network side may be configured at the AMF. These rules as well as the capabilities may be provided to AMF 203 by PCF 204. The USAB configuration procedure is depicted in FIG. 4.
[00144] In step 210, the network operator may configure USAB policies for UE 201 along with Subscribed NSSAIs within the Access and Mobility Subscription data. In step 211, UE 201 may send a Registration Request to AMF 203 via RAN 202. The registration request may indicate that UE 201 is capable of receiving and enforcing USAB policies (e.g., the request may include the SRMC indication).
[00145] In step 212, upon receiving a Registration Request, AMF 203 may send a Nudm_SDM_Get message to get UE 201 subscription information from UDM 205. UDM 205 may deliver the USAB policy information as part of the Access and Mobility Subscription data and send back to AMF 203. Step 213 may involve Steps 15 to 19 from clause 4.2.2.2 of TS 23.502.
[00146] In step 214, AMF 203 delivers the USAB policies to UE 201 as part of the Registration Accept message after a successful UE 201 registration. AMF 203 may also deliver the USAB policies to UE 201 if the registration was not accepted given that UE 201 passed the authorization and authentication phase of the Registration procedure and slicespecific authentication and authorization if required for any S-NSSAI and, may indicate in the Registration Reject message why the registration was not successful.
[00147] In step 215, after UE 201 has received a Configured NSSAI and USAB policy from the network, UE 201 may send Registration Request back to the network. Now, UE 201 may execute USAB policies by checking the criteria, conditions, and attributes that
- 32 -
4871-1319-0402.1 2020P00294WG / 106693.001425 are included in the USAB policies. Evaluation of the polices may result in UE 201 determining if it needs to Register with a slice or De-register from a slice. This determination will result in a new UE Registration request. Hence, the resulting Requested NS SAI will include those S-NSSAIs that comply with USAB policy. The Registration Update is sent to the AMF via the RAN. In step 216, UE 201 may receive a new Allowed NS SAI in the Registration Accept message.
USAB Policy Configuration Update
[00148] There are UEs that may need a service from a network slice as soon as it is powered on. For example, an loT device that doesn’t have a GUI or any external trigger, which may start sensing and sending data as soon as it is powered on. In another example, a vehicular UE may need the access to slice urgently upon startup. These types of UEs may have to register and establish a PDU session as soon as they start. For such a UE, a preconfigured USAB policy may be appropriate which allows the UE to select S-NSSAI(s) based on what startup application(s) starts, contexts, SLAs or other attributes and policies discussed previously, and send it in the Registration Request to the network. Additionally, the network may be able to send an updated USAB policy if required, using UE Configuration Update Command. A registration procedure that employs pre-configured USAB policy and UE Configuration Update procedure for USAB policies is depicted in FIG. 5 and described as follows.
[00149] In step 220, UE 201 may be pre-configured with USAB policy. When UE 201 starts up, it is triggered for registration next. Before UE 201 starts the registration procedure, UE 201 may evaluate the USAB policy. USAB policy discussed in previous section includes various instructions that helps UE 201 to decide on the selection of S- NSSAIs to generate the Requested NSSAI for Registration Request.
[00150] In step 221, UE 201 may send a Registration Request to AMF 203 via the RAN. UE 201 takes into account the Requested NSSAI that was populated based on USAB policy. UE 201 may also follow other instructions that USAB policy instructs UE 201 to abide by.
[00151] In Step 222-a, AMF 203 receives the Registration Request. AMF 203 may send a Get UE subscription information (Nudm_SDM_Get) message to the UDM/UDR 205. UDM 205 sends back to AMF 203 the UE Subscription Information which includes that Access and Mobility data for the requesting UE 201. The UE Subscription information may
- 33 -
4871-1319-0402.1 include US AB policies for UE 201. AMF 203 may identify that UE 201 is pre-configured with the USAB policy based on the Registration Request. Based on the local policy, UE 201 may overwrite the existing USAB policy of UE 201. UE registration may be an appropriate procedure wherein, the network may update the pre-configured or pre-existing USAB policy at UE 201.
[00152] In Step 223-a, AMF 203 may check the Requested NSSAI and if the UE Subscription includes the subscribed S-NSSAIs that match the request, AMF 203 includes them in the Allowed NSSAI in the Registration Accept message.
[00153] In Step 222 -b, AMF 203 may determine, based on the response received from PCF 204 or UDM 205, that UE 201 needs a new USAB policies, which means AMF 203 may need to initiate a UE Configuration Update procedure.
[00154] In Step 223-b, AMF 203 may send to UE 201, a UE Configuration Update command, which may include the new USAB policies for UE 201. Upon receiving the UE Configuration update command, UE 201 may send an acknowledgement back to AMF 203 confirming its receipt.
[00155] In Step 224-b, UE 201 may use the USAB policies to make registration and PDU Establishment / Release decisions, which may include preparation of a Requested NSSAI. UE 201 may then send a UE Registration Update to the network via RAN 202. Controlling PDU Session Establishments
[00156] This section describes various enhanced methods that can control PDU sessions establishment and release procedures between a UE and the network for optimal utilization of network resources.
PDU Session Establishment Policies
[00157] UE 201 may be instructed to handle PDU session establishment towards network slice(s) on an as-need basis such that network resources are utilized at their best. The UE’s PDU session establishment may be motivated by user’s desires, UE type and function, network decisions, UE capabilities, SLAs, operator policies, agreement with data network (provider), environmental contexts like time, location, etc. For instance, some of the UEs, upon meeting a criterion, may end the PDU session, while other UEs may keep the PDU session intact and not send or receive any data. For example, a user surfing the web or streaming a video may put his phone down to go to bed. It might be more efficient, from a
- 34 -
4871-1319-0402.1 network perspective, to end the PDU Session after some timeout (or after UE 201 detects the user’s context is sleep) rather than to keep it maintained.
[00158] The network may convey UE behavior instructions via policies to UE 201. The USAB policies discussed in the previous sections may be extended to include policies for optimal control of PDU sessions. This may mean instructing UE 201 when to perform the establishment of new PDU sessions and ending of established PDU sessions towards a network slice(s) more dynamically. UE 201 may be pre-configured with USAB policies or may receive them during a successful completion of UE registration procedure or during a UE Configuration Update Procedure. Based on the features and motivations discussed, following are some example instructions (eight instructions) that an operator may want UE 201 to follow for optimal PDU sessions establishment with the network slices.
[00159] First, instruct UE 201 to always establish a PDU session towards particular S-NSSAI/DNN combinations. Second, instruct UE 201 to always initiate a PDU session towards a particular S-NSSAI/DNN combination as soon as UE receives the S-NSSAI in its Allowed NSSAI. Third, instruct UE 201 to always initiate PDU session in particular S- NSSAI(s) or slice type. Fourth, instruct UE 201 to only establish a PDU session in a Network slice if at least one application uses it, within an indicated time period. A timer may be activated to track the state of this PDU session.
[00160] Fifth, instruct UE 201 not to establish a PDU session towards a particular S-NSSAI unless UE 201 includes a DNN in the PDU Session Establishment Request. In other words, instruct UE 201 that there is not default DNN for the S-NSSAI. Sixth, instruct UE 201 to initiate a redundant a PDU session in a different access type when a context is met. For e.g., data loss is beyond a threshold. Seventh, instruct UE 201 to initiate PDU session towards a slice associated with a DNN (e.g., an LADN) when certain context is met. For example, sensitivity of the session or special privilege is activated. Certain UEs may be privileged to access some contents that are only accessible in certain areas and are accessible only via the DNN. Eighth, instruct UE 201 to trigger a network slice registration, if during a PDU session establishment UE 201 requires access to a network slice. For example, the indication may be part of an RSD and it may indicate to UE 201 that UE 201 should attempt to add the slice to UE 201’s Allowed NSSAI via a Registration operation so that UE 201 may attempt to establish a PDU Session in the slice.
- 35 -
4871-1319-0402.1 [0100] Similar to PDU session establishment the USAB policy may include PDU session release policies, such as the five below. First, instruct UE 201 to release PDU session if there is no activity (e.g., no UL or DL data) for a specified amount of time called Session Hold Time. A Session Hold Time is a pre-defined time period accounted for no activity in an established PDU session. For example, if there are no UL/DL data in the PDU session for a certain amount of time, the PDU session may be released. Second, instruct UE 201 to release PDU session in an access type and start PDU session to the same slice from another access type. Third, instruct UE 201 to wait for a certain amount of time, before releasing the ongoing PDU session upon meeting a context (e.g., time, tracking area, etc.). Fourth, instruct UE 201 to release certain PDU session upon meeting a context or condition. For example, UE 201 may be allowed to access content (e.g., stream video, play an online video game, etc.) from the network within a given time period and, the length of PDU session may be updated based on charging information (e.g., score, payment, etc.). In another example, only certain number of PDU Sessions from a home 5G router from a user account may be established towards a DNN, LADN or an edge server. Fifth, instruct UE 201 to release an established PDU session in the slice after no application has used the PDU session for a specified Session Hold Time.
Registration Triggered PDU Sessions
[00161] UE 201 may initiate a request to establish a PDU session when it requires a service. In other words, UE 201 requests for PDU session when it wants to receive or send user data to or from the network. As 5GS may involve variety of UEs based on diverse services that it incorporates, UE 201 may need to start and end PDU sessions by following dynamic triggers that is beyond just a user requesting a service. For example, a low power loT device (e.g., a remote temperature sensor) may need to start sending data as soon as it gets registered to with the network and the network slice. This may mean that the successful registration procedure where UE 201 receives an Allowed NSSAI, acts as a trigger for UE 201 to establish a PDU session towards the allowed S-NSSAIs and start sending data or receive any appropriate data from the network.
[00162] The USAB policy discussed in the previous sections may be extended to incorporate the policies that involves UE’s PDU session establishment with the network. The instruction to register as soon as the slice appears in the Allowed NSSAI may be included as
- 36 -
4871-1319-0402.1 2020P00294WG / 106693.001425 part of the USAB policies. Alternatively, the network may send to UE 201, an indication to establish a PDU session after UE 201 has received Registration Accept message.
[00163] FIG. 6 shows procedures by which PDU session is established as UE 201 registers with the network and receives authorized slices’ information.
[00164] In Step 231, UE 201 goes through successful UE registration procedure when UE also receives Allowed NSSAI from the network. UE 201 may receive a USAB policy that indicates that certain PDU Sessions should be established immediately after the Registration Procedure completes.
[00165] In Step 232-a, UE 201 may be triggered to establish a PDU session towards a specified and an authorized slice by executing USAB policy. Alternatively, UE 201 may receive an instruction with the Registration Accept message. This instruction further may include the S-NSSAI where UE 201 needs to establish a PDU session.
[00166] In Step 232-b, alternatively, after successful UE registration with Allowed NSSAI, the network may send a trigger to UE 201. The trigger may be carried via SMS / NAS messaging towards an application on UE 201. This trigger may indicate to the application an S-NSSAI and DNN where UE needs to establish a PDU session. UE 201 application may then attempt to Register with the slice and send a request for a PDU session establishment towards the slice.
Releasing an Established PDU Session
[00167] The overall 5GS performance may be enhanced if UE 201 can optimize its behavior. One such frequent behavior is establishment and release of PDU sessions. This section describes how and on what occasions UE 201 can release PDU sessions without affecting the operation while optimizing the performance of the 5GS.
Releasing PDU session if no activity in the established PDU session.
[00168] UE may have many occasions when UE establishes a PDU session with the core network and exchanges user plane data with the network. However, the established PDU session may remain established even when there is no data in the session or, until the network or the UE triggers a PDU session release indication, which may not be guaranteed.
[00169] After a successful authentication and authorization, the UE establishes a PDU session with the UPF and may start exchanging user plane data. A UPF is aware of UL and DL traffic. Hence, the UPF may be able to sense an inactive PDU session. An inactive
- 37 -
4871-1319-0402.1 PDU session is when there is no UL/DL data in the session. In such a case, for each PDU session, a Session Hold Time may be activated every time the PDU session stops receiving or sending data. The Session Hold Time may be pre-defined by the operator and may vary among UEs based on attributes such as type of service, slice type, etc.
[00170] Before starting a Session Hold Time for a PDU session, the UPF may need to wait a small amount of time, which may be referred to as a Wait Time. A Wait Time is the time that a UPF waits for another piece of data after the last piece of data has been exchanged in an established PDU session.
[00171] After a Wait Time expires in an established PDU session, a Session Hold Time may be activated at the SMF or UPF. If no data is sent or received in that PDU session within the Session Hold Time, then the SMF may take action to release a PDU session between the UE and the network.
[00172] Alternatively, the information on Session Hold Time may be conveyed as part of the USAB policy and invoked at the UE. This information may be conveyed in PDU Session Establishment Response or PDU Session Establishment Modification message. A UE may activate both Wait Time and the Session Hold Time in the UE. If no user plane data is sent or received over an established PDU session than Session Hold Time is enforced. As the Session Hold Time expires, the UE may request network to release the PDU session. As the AMF receives the PDU session release request, the AMF conveys the request to the SMF. The SMF may send a PDU session release command to the UPF.
[00173] The 5GS may include following enhanced methods for releasing a PDU session.
Explicit Release signal to the UE
[00174] If the UPF administers a Session Hold Time, the UPF may inform about the expired Session Hold Time to the SMF. Otherwise, the SMF may administer the Session Hold Time. When the SMF/UPF learns that the Session Hold Time has expired, the SMF may initiate the PDU Session release procedure that is described in section 4.3.4 of TS 23.502. Alternatively, the SMF may send a notification to the UE to inform the UE that the timer has expired. The notification may be received by the UE as a request to consider initiating the release of the PDU Session. For example, after receiving the notification, the UE may decide to send the PDU Session Release Request to the network if the UE does not anticipate using the PDU Session again soon. When the SMF receives such request, the SMF
- 38 -
4871-1319-0402.1 may send session release signal to the UPF eventually ending the PDU session with the UE. The notification from the SMF to the UE may include a Grace Time. The Grace Time may indicate to the UE that the network will terminate the PDU Session if it is not used within the grace time or if the UE does not terminate (e.g., release) the session within the grace time.
Delay before the Session Release
[00175] As discussed before, when a UE has an ongoing PDU session where UL/DL data is being exchanged with a network slice, the UE may meet certain context such as a specified time, TA/RA change or change of geographic location. This event might send a trigger in the network (e.g., AMF, SMF, or UPF) to end an ongoing PDU session and block the UE’s exchange of data with the associated network slice. In such a case, UE generally may release the PDU session and start a PDU session towards a slice in which data exchange is allowed. On the other hand, the UE may initiate a UE Registration Update procedure with the network to register with a slice that would allow UE to exchange data with the network.
[00176] In such a situation, the PDU session release may be enhanced so that the release is delayed for a considerable amount of time with a Release Delay Timer. For instance, if the UE (e.g., drone) passes by a TA, and with a probability that it may come across a new TA that may allow for the UE to use the existing PDU session or a graceful handover of the PDU session, the PDU session release may be delayed by certain amount of time. This PDU session Release Delay Time may be administered at the AMF/SMF and a notification of such a context may be sent to the UE. During the Release Delay Time, UE and network/UPF may not exchange any UP data. Alternatively, UE may be instructed to practice Release Delay Time when sending a request for PDU session release to the AMF. A Release Delay Time information may be conveyed to the UE with USAB policy.
Controlling New PDU Session Request with URSP
[00177] When a URSP rule is determined to be applicable for a given application (e.g., the Traffic Descriptor matches the application traffic), the UE shall select a Route Selection Descriptor (RSD) within this URSP rule in the order of the Route Selection Descriptor Precedence. When a valid Route Selection Descriptor is found, the UE determines if there is an existing PDU Session that matches all components in the selected Route Selection Descriptor. The UE compares the components of the selected Route Selection Descriptor with the existing PDU Session(s). When a matching PDU Session exists, the UE associates the application to the existing PDU Session. If none of the existing PDU Sessions
- 39 -
4871-1319-0402.1 matches, the UE tries to establish a new PDU Session using the values specified by the selected Route Selection Descriptor. If the UE fails to establish a PDU session with any of the Route Selection Descriptors, it tries other URSP rules in the order of Rule Precedence with matching Traffic descriptors, except the URSP rule with the "match-all" Traffic descriptor, if any. If a “match-all” Traffic descriptor exist, then the URSP rule with the "match all" Traffic descriptor is used to route the traffic of applications which do not match any other URSP rules and shall therefore be evaluated as the last URSP rule, e.g., with the lowest priority.
[00178] However, the URSP rule may be enhanced with a flag in the RSD, such that the UE behavior for slice access can be optimized. In particular, the flag is introduced to help steer the UE towards using existing PDU Sessions and avoid establishing new PDU Sessions. In other words, the UE will first check if there are existing PDU Sessions with favorable, or acceptable characteristics before attempting to establish a new one. This flag may be called the “Session Control Flag”.
[00179] Table 7 depicts enhanced UE Route Selection Descriptor which is an extended version of Table 4. In Table 7, a new Route selection component called “Session Control Flag” has been included to control a creation of new PDU sessions, which is described in this section.
Table 7 Enhanced Route Selection Descriptor
Figure imgf000042_0001
- 40 -
4871-1319-0402.1
Figure imgf000043_0001
-41 -
4871-1319-0402.1
Figure imgf000044_0001
-42-
4871-1319-0402.1 2020P00294WG / 106693.001425
Figure imgf000045_0001
[00180] The new session control flag may logically change the evaluation of URSP Rules and RSDs to have the effect that UE will be more likely to use existing PDU sessions than establish new PDU sessions.
[00181] For example, consider how URSP rules are evaluated today. Consider a case where the UE is registered to a URLLC slice and an eMBB slice. The UE may have a PDU Session established in the URLLC slice, but no PDU Session in the eMBB slice. In such a scenario, when eMBB traffic starts, the eMBB traffic may match a URSP rule as shown in Example 1 below.
Example 1 of Existing Behavior:
URSP1
• Traffic Descriptor that matches eMBB traffic
1. RSD X (describes an eMBB Slice PDU Session)
2. RSD Y (describes an URLLC Slice PDU Session)
[00182] In this first example, the UE will check if there is a PDU Session that matches the highest precedence RSD X (on the eMBB slice). If there is a PDU Session that
- 43 -
4871-1319-0402.1 matches RSD X, then the UE will use it. However, there is no such PDU Session established, thus the UE will try to establish a PDU Session that matches X. The UE will then have 2 PDU Sessions (one in each slice). However, it might be the case, that the network prefers that the eMBB traffic be routed via the URLLC slice in this example. The UE may have already been attached to the network via frequency bands that are optimized for URLLC traffic and the network operator might prefer that the UE keep its traffic in the same operating band. In other words, notice that, with the existing behavior, if the UE doesn’t find a PDU Session matching RSD X, the UE will establish a new PDU session with the RSD X, although the UE could have used URLLC slice with RSD Y.
[00183] It is disclosed that the “Session Control Flag” be added to the RSD so that the network can indicate to the UE if the UE should preferably use a PDU Session that is associated with a lower precedence RSD before attempting to establish a new PDU Session with the RSD.
[00184] In a first example of how this flag may be processed, the UE may already have some ongoing URLLC traffic. Thus, the UE has 1 PDU Session and it matches RSD Y (with a URLLC Slice). Later, some eMBB traffic starts. The network prefer that the UE use the URLLC Slice for the eMBB traffic since UE is already using a PDU Session in the URLLC slice.
[00185] Example 2 below describes how the flag might be processed in order to cause the UE to route the eMBB traffic onto the URLLC slice.
Example 2 (New Behavior - Option A):
URSP1
• Traffic Descriptor that matches eMBB traffic
1. RSD XI (describes an eMBB Slice PDU Session, the “Session Control Flag” is set)
2. RSD Y1 (describes an URLLC Slice PDU Session, the “Session Control Flag” is set)
3. RSD X2 (describes an eMBB Slice PDU Session, the “Session Control Flag” is not set)
4. RSD Y2 (describes an URLLC Slice PDU Session, the “Session Control Flag” is not set)
[00186] RSD XI is the same as RSD X2, except for the state of the flag.
- 44 -
4871-1319-0402.1 [00187] RSD Y1 is the same as RSD Y2, except for the state of the flag.
[00188] In this example, when the UE sees traffic that matches the eMBB traffic descriptor, it will check if there is a PDU Session that matches RSD XI (e.g., a PDU Session in the eMBB slice). If there is a PDU Session in the eMBB slice, then it will use it. In this example, there is no such PDU Session. Since the “Session Control Flag” is set in RSD XI, the UE will not attempt to establish a PDU Session with RSD XI. The UE will then check if there is a PDU Session that matches RSD Y1 (in the URLLC slice). Since there is a PDU Session that matches RSD Y1 (in the URLLC slice), the UE will use the existing session for the eMBB traffic. Thus, the UE will use a single PDU session for both its URLLC and eMBB traffic.
[00189] In an alternative processing procedure, the UE may be allowed to evaluate the RSD a two times. During a first evaluation of the RSDs in precedence order, the UE may not be allowed to establish a PDU session for any RSD whose “Session Control Flag” is set. During the second evaluation of the RSDs in precedence order, the UE may ignore the “Session Control Flag”. This is detailed in Example 3. The benefit of this approach, compared to Example 2, is that fewer RSDs will need to be sent to the UE.
Example 3 (New Behavior - Option B): URSP1
• Traffic Descriptor that matches eMBB traffic
1. RSD X (describes an eMBB Slice PDU Session, the “Session Control Flag” is set)
2. RSD Y (describes an URLLC Slice PDU Session, the “Session Control Flag” is set) [00190] In this example, if UE sees traffic that matches the eMBB Traffic
Descriptor, then it will check if there is a PDU Session that matches RSD X (in the eMBB slice). If there is a PDU Session that matches RSD X, then the UE will use it. In this example, there is no such PDU Session. So, the UE will check if there is a PDU Session that matches RSD Y (in the URLLC slice). If there is a PDU Session that matches RSD Y, then the UE will use it. If there is no PDU Session in RSD Y, the UE will go back to the highest precedence RSD and evaluate RSDs again, this time ignoring the state of the Session Control Flag and will try to establish a PDU Session that matches RSD X. If a PDU Session that matches RSD X cannot be established, then the UE will try to establish a PDU Session that matches RSD Y. If a PDU Session that matches RSD Y cannot be established, then UE will move to a lower precedence URSP rule.
- 45 -
4871-1319-0402.1 2020P00294WG / 106693.001425
[00191] To illustrate further, let’s take example of URSP rules from Table 8 that resembles the actual URSP rules. Table 8 shows two different URSP rules with varying Rule Precedence and RSD Precedence.
[00192] The indicator that controls the PDU session establishment for optimal performance may be integrated into the URSP rules as shown in Table 8.
[00193] If the “Session Control Flag” flag is not set or not included in the RSD, the RSD evaluation follows the existing functionality. That is, if there exists a matching RSD, the UE may simply use the existing PDU session to send the user plane data as per existing URSP policies. If there is not an existing PDU session, the UE is allowed to establish a new PDU session with the matching RSD.
[00194] However, if the “Session Control Flag” is set or is included in the RSD and if there is no PDU session with matching RSD that has already been established. Then, the UE’s attempt to request for a new PDU session establishment may be blocked until other RSDs are evaluated. Notice that “Session Control Flag” applies only to RSD and not the traffic descriptor.
Table 8 Example URSP rules
Figure imgf000048_0001
- 46 -
4871-1319-0402.1 2020P00294WG / 106693.001425
[00195] For instance, the URSP rule in Table 8 is evaluated as follows. Traffic is generated by Appl. The NAS layer in the UE examines the traffic and detects that the traffic matches Appl. The UE checks the URSP rule with Rule Precedence 1 and finds that the traffic matches the traffic descriptor. The UE will evaluate the RSD(s) that are associated with the rule. In the first URSP rule example of Table 8, there is 1 RSD. If there is an existing PDU Session that matches the RSD (S-NSSAI-B and DNN_A) then the UE will use that PDU Session for Appl. Otherwise, the UE will attempt to establish a PDU Session with the RSD (S-NSSAI-B and DNN_A), based on existing URSP procedure. Disclosed herein, the UE only establishes a PDU Session with the RSD (S-NSSAI-B and DNN_A) if “Session Control Flag” flag is not set. If the PDU session couldn’t be created, UE may continue with URSP evaluation (e.g., move to lower precedence RSD(s) and eventually lower precedence URSP rule(s)). But in the first URSP example above, the “Session Control Flag” flag is set and, since it has only 1 RSD. the UE may attempt to_establish the PDU Session with the RSD.
[00196] In the second URSP rule example depicted in Table 8, let’s assume, that the traffic is generated by App2. The NAS layer in the UE examines the traffic and detects that the traffic matches App2. Based on existing mechanisms, the UE checks the URSP rules and finds that the URSP rule with Rule Precedence 2 matches the traffic descriptor. The UE will evaluate the RSD(s) that are associated with this rule. In this example, there are two RSD(s). Hence, the UE examines the RSD with highest precedence (RSD Precedence = 1). If there is an existing PDU Session that matches the RSD (S-NSSAI-A, DNN_B and 3GPP access), then the UE will use that PDU Session for traffic from App2. If there is no existing PDU Session that matches the RSD with Precedence 1, then the UE will try to establish a new PDU session with the RSD: S-NSSAI-A, DNN B and 3GPP access. If the PDU session cannot be established then the UE will evaluate the RSD with Precedence 2 (S-NSSAI-C, DNN_B and Non-3GPP access). Again, if there is an existing PDU Session that matches the RSD (S-NSSAI-C, DNN_B and Non-3GPP access) then the UE will use that PDU Session for App2 traffic. If there is no existing PDU Session that matches the RSD with Precedence 2, then the UE will try to create a new PDU session with S-NSSAI-C, DNN_B and Non- 3 GPP access.
[00197] Here, it is disclosed that the UE only establishes a new PDU Session that matches the RSD: S-NSSAI-A, DNN_B, and 3GPP access, if “Session Control Flag” flag is
- 47 -
4871-1319-0402.1 2020P00294WG / 106693.001425 not set. But in this example, the “Session Control Flag” flag is set, in the first RSD. Therefore, if there is no existing PDU session matching RSD: S-NSSAI-A, DNN_B and 3GPP access, the UE will evaluate the RSD with Precedence 2 (S-NSSAI-C, DNN_B and Non-3GPP access). If there are no existing PDU Session with RSD: S-NSSAI-C, DNN_B and Non-3GPP access and since the “Session Control Flag” flag is not set, the UE may attempt to create anew PDU Session with this RSD. But if PDU Session couldn’t be created even with the RSD with Precedence 2 (S-NSSAI-C, DNN_B and Non-3GPP access), then the UE continue with URSP evaluation (e.g., move to lower precedence RSD(s) and eventually lower precedence URSP rule(s)).
[00198] Therefore, some best practices for using the “Session Control Flag” flag effectively would be to have URSP rules with multiple RSDs and for each URSP rule, at least have a “Session Control Flag” flag that is not set, for the RSD with lowest precedence.
[00199] Network Slice Remapping
[00200] The description herein explains various aspects of methods for slice remapping.
[00201] Slice Remapping
[00202] Slice Remapping is the act of moving a UE’s activity from a first slice to a second slice. An example of activity within a slice is a PDU Session. Thus, an example of slice remapping is moving a PDU Session from a first slice to a second slice. In other words, an example of slice remapping is changing the S-NSSAI that is associated with a PDU Session.
[00203] Slice Remapping may be triggered by an event. Typically, the event will be an event that causes the first network slice to no longer be accessible to the UE. An example of an event that might trigger slice remapping is the first slice becoming unavailable during UE mobility. A slice might become unavailable to a UE because it moves to a Tracking Area (TA) or Registration Area (RA) where the first slice is not available. Another example of an event that might trigger slice remapping is the UE determining to request to register to a second slice in a scenario where simultaneous registration with the first and second slices is not allowed. Yet, another example of an event that might trigger slice remapping in a scenario where the UE wishes to register to a slice beyond the maximum the UE is allowed to register to, but registration with the slice requires that the UE remove a slice from the UE’s requested NSSAI (e.g., because the UE is already registered with the maximum 8 slices).
- 48 -
4871-1319-0402.1 [00204] Other triggers for slice remapping include scenarios where the RAN node doesn’t support the first slice, the first slice is not supported in the VPLMN, the first slice is too congested in the network, the required frequency of the first slice is not supported as the UE moves to a new TA/RA, etc.
[00205] Slice Remapping is particularly desirable to the UE when the UE has PDU Sessions of SSC Mode 1 established in the slice that needs to be remapped. By remapping a PDU Session of SSC Mode 1, UPF that acts as the PDU Session anchor will be maintained through the Slice Remapping operation. Thus, when PDU Sessions of SSC Mode 1 are remapped, the UPF that acts as the PDU Session anchor must be part of both the first and second slices.
[00206] Slice Remapping where the UE has established PDU Sessions of SSC Mode 2 may also be possible. However, solutions for remapping PDU Sessions of SSC Mode
2 do not need to maintain the same PDU Session anchor through the remapping process.
[00207] Slice Remapping where the UE has established PDU Sessions of SSC Mode 3 may also be possible. Although solutions for remapping PDU Sessions of SSC Mode
3 do not need to maintain the same PDU Session anchor through the remapping process, the UE may expect that PDU Session connectivity via the first slice is not lost until PDU Session connectivity via the second slice is established.
[00208] Note that the terms ‘remapping PDU Sessions’ and ‘slices remapping’ are used interchangeably in the disclosure.
[00209] Slice Remapping During UE Registration
[00210] As described herein, Slice Remapping may be triggered by an event such as a first slice becoming unavailable or the UE’s desire to register with a second slice. In both examples, the event would trigger the UE to send a Registration Request to the network. FIG. 10 depicts a method for Slice Remapping during UE Registration.
[00211] In step 240, UE 201 may have an established PDU session with a data network via a first network slice. The PDU session may be associated with an anchor UPF 209. In step 241, as described above, an event causes UE 201 to send a UE Registration Request or Registration Update to the network (e.g., new AMF 208) via the new RAN node 207. In the Registration Request message, UE 201 may include UE Slice Remapping Capability (USRC) indicator. The USRC indicator indicates to the network that UE 201 is capable of Network Slice Remapping.
- 49 -
4871-1319-0402.1 [00212] UE 201 also includes in the Registration Request, the PDU Session Status, Requested NSSAI, Mapping Of Requested NSSAI, Default Configured NSSAI Indication, among other parameters.
[00213] Within the PDU Session Status information element of the Registration Request, UE 201 may include an indication for UE 201 ’s desire/intention for slice remapping if slice remapping is necessary. By providing such an indication in the PDU Session Status (e.g., on a per-PDU Session basis), UE 201 can indicate to the network which PDU Session should be remapped if the network determines that remapping is necessary. The network (e.g., the new AMF 208) may determine that slice remapping is necessary if the S-NSSAI that is associated with the PDU Session cannot be allowed for UE 201 by the new AMF 208. Note that the AMF may not change during a UE handover from one RAN to another.
[00214] Step 242 depicts UE Registration Procedure Steps 4-9 from Figure 4.2.2.2.2-1 of TS 23.502. In step 243, the new AMF 208 determines that it cannot serve one or more PDU sessions (e.g., because the S-NSSAI that is associated with the PDU Session is not available in the new Registration Area). However, the new AMF 208 determines from the PDU Session Status that slice remapping is requested for one or more of those PDU Sessions. The new AMF 208 will next determine if slice remapping is possible for the requested PDU session(s).
[00215] The new AMF 208 may determine if slice remapping is possible by first checking if local policies indicate that the S-NSSAI that is associated with the PDU Session may be remapped to a second S-NSSAI by the new AMF 208. If the new AMF 208 determines that policies allow the S-NSSAI to be remapped to a second S-NSSAI, the new AMF 208 will next check if UE 201 second S-NSSAI is in UE 201’s subscription or if the second S-NSSAI was included in UE 201 ’s Requested NSSAI. If the second S-NSSAI is in UE 201 ’s subscription or if the second S-NSSAI was included in UE 201 ’s Requested NSSAI, then the new AMF 208 may include the second S-NSSAI in UE 201’s Allowed NSSAI.
[00216] If the second S-NSSAI was not in UE 201’s Requested NSSAI, but the new AMF 208 determines that it should be included in UE 201 ’s Allowed NSSAI, the new AMF 208 will indicate to UE 201 that the second S-NSSAI is present in the Allowed NSSAI for remapping purposes. Alternatively, the AMF may provide the second S-NSSAI, not in the
- 50 -
4871-1319-0402.1 Allowed NSSAI, but as a separate information element that indicates to UE 201 that the AMF recommends UE 201 register with the second S-NSSAI for remapping purposes.
[00217] In step 244, provided that the slices (identified in Step 243) can be remapped, the new AMF 208 sends the PDU Session ID(s) for PDU Sessions that can be remapped to the old AMF 203. The message will also provide the old AMF 203 with the S- NSSAI’s that PDU Sessions will be remapped to. The old AMF 208 will then notify the SMFs 206 that are managing the PDU Sessions. The notification message from the old AMF 203 to the SMF 206 will also provide the S-NSSAI’s that the PDU Session will be remapped to. If the SMF 206 is associated with the S-NSSAI that the PDU will be remapped to, then the SMF 206 will change the PDU Session to be associated with the new S-NSSAI. If the SMF 206 is not associated with the S-NSSAI that the PDU Session will be remapped to, then the SMF 206 may select a second SMF which is associated with the S-NSSAI that the PDU Session will be remapped to. The SMF 206 will then invoke the
Nsmf PDUSession ContextPushRequest operation to send the PDU Session context to the second SMF so that the second SMF can serve the PDU Sessions.
[00218] Alternatively, if the SMF 206 is not associated with the S-NSSAI, the old AMF 203 may select the second SMF which is associated with the S-NSSAI that the PDU Session will be remapped to. The old AMF 203 invokes Nsmf_PDUSession_ContextRequest to request PDU Session context from the old SMF 206. The Old AMF passes the PDU Session context received from the old SMF 206 to the new SMF associated with the remapped slice. The new SMF may then serve the PDU Sessions.
[00219] Furthermore, the SMF 206, whether the old SMF or the new SMF, notifies UPF 209 of the slice remapping event by changing the TEID to the new RAN node 207 in the case of SSC Mode 1. SMF 206 may respond to the old AMF 203. The response will indicate to the old AMF 203 if the remapping operation was successful. The old AMF 203 may send a response message to the new AMF 208, the response indicates if the remapping operation was successful.
[00220] In step 245, the new AMF 208 sends a Registration Accept message to UE 201 via the new RAN 207. In the message, the new AMF 208 may include the PDU Session status, the Registration Area, and Allowed NSSAI. In addition, the message may also include the PDU Session ID(s) for which the slices have been remapped and indicate S-NSSAI for each remapped slice with a remapped slice indicator.
- 51 -
4871-1319-0402.1 [00221] The remapped slice indicator may signify that the S-NSSAI is for a remapped slice. Should a remapped slice be limited, for example, remapping could be timelimited, limited in services that UE 201 can request, limited in max PDU Sessions or UEs that it could handle, etc. In such as case, UE 201 could identify the remapped slice with the indicator and, make traffic adaptation, PDU Session, or other signaling decisions. The Registration Accept message may additionally include remapping rules that indicate to the UE how S-NSSAI(s) in the Rejected NSSAI map to S-NSSAI(s) in the Allowed NSSAI. These rules are generated by PCF or AMF, and interpreted by UE 201 as an indication that the remapped S-NSSAI(s) may be considered equivalent in the Registration Area, and that the Rejected S-NSSAI(s) may not be used, but any operation (e.g., PDU Session Establishment, PDU Session Modification, sending of user plane data, or sending of SMS) that would normally target the Rejected S-NSSAI(s) may target the S-NSSAI(s) that are indicated by the remapping rule.
[00222] The Registration Accept response message may also include an indication of whether UE 201 shall use the new slice for activity for which the old slice would have been used (e.g., for future PDU sessions), or only for the existing PDU sessions involved in the current re-mapping process. In addition, the new slice information may be indicated as replacing the old slice information, being prioritized over the old slice information, or neither (e.g., existing configuration applies outside the re-mapped PDU sessions). This information may be used, for example, in conjunction with other URSP rules at UE 201 that include the re-mapped slice. This indication will essentially instruct UE 201 to update the URSP rule with the slice re-mapping information, without explicit signaling from the network. The update might take the form of a slice replacement but may also take the form of a reprioritization of the slides provided in the URSP rule. For example, UE 201 is told that slice X needs to be replaced with slice Y for the current PDU sessions. However, the UE has additional URSP rules that specify slice X for other PDU sessions. If UE 201 needs to start another PDU session where the URSP rule indicates X, it is told that it should use Y instead for that session as well.
[00223] Note that if the core network doesn’t support the network slice remapping process or if the network does support slice remapping but UE 201’s PDU Sessions could not be remapped (e.g., because it could not remap the particular slices), information for rejected
- 52 -
4871-1319-0402.1 PDU Sessions may be sent back to UE 201 with an appropriate cause code in the Registration Accept message (e.g., step 245).
[00224] Remappable Slice Preference During UE Registration
[00225] The network slices which can be remapped may be referred to as the Remappable Slices. In order to support the case where UE 201 establishes a PDU Session and UE 201 or network (e.g., RAN 202) later determines that the slice needs to be remapped, the 5GS may be able to configure UE 201 with Remappable Slice information during UE Registration Procedure.
[00226] If UE 201 indicated a preference for Remappable Slices, the network may be able to identify Remappable Slice, and provided that they are authorized during a UE Registration Request, the network may include Remappable Slices for Allowed NSSAI or Configured NSSAI and deliver them to UE 201 after a successful Registration procedure. A UE Registration Procedure in which UE 201 receives Remappable Slice information is shown in FIG. 11.
[00227] In Step 251, a UE sends a UE Registration Request to the network (e.g., AMF 203) via the RAN node. The Registration Request message includes Requested NSSAI, the UE Slice Remapping Capability (USRC) indicator, UE’s preference to receive Remappable Slices with a “Remappable Slice Preference” indicator, UE type (e.g., TAC), and device type information. The USRC indicator indicates to the network that UE 201 is capable of network slice remapping. The device type and the UE Type may indicate the capabilities with regards to technology and services it can support. Alternatively, UE 201 may include application IDs or application types to indicate UE’s primary/ priority functions, which may help determine S -NS SAI preference.
[00228] In step 252, AMF 203 checks the USRC indicator, the core network’s functionality to support Slice Remapping, UE Type, and the device type. AMF 203 identifies UE 201’s preference to receive Remappable Slices from the “Remappable Slices Preference” indicator. AMF 203 may further consider application IDs and application types, if available.
[00229] AMF 203 may retrieve the Access and Mobility Subscription data using Nudm_SDM_Get and retrieve Subscribed NSSAI. AMF 203 then examines if the slices requested are authorized. Based on the “Remappable Slice Preference” indicator, the URSC indicator, UE Type, the device type information, UE’s primary applications information (if available), AMF 203 identifies the Remappable Slices from among the authorized slices.
- 53 -
4871-1319-0402.1 From the authorized set of slices, UE 201 chooses Remappable Slices over the slices that are not Remappable Slices, populates S-NSSAIs for Remappable Slices in the Allowed NSSAI. If there are less than 8 available Remappable Slices, AMF 203 may fill the remaining S- NSSAIs in the Allowed NSSAI with S-NSSAIs for the slices that may not be Remappable Slices.
[00230] AMF 203 may associate each S-NSSAI with a Remappable Slice Indicator, for example, with a flag (0 or 1) to indicate that the S-NSSAI represents a Remappable Slice.
[00231] Alternatively, if the Requested NSSAI didn’t include any S-NSSAI that are Remappable Slice, but the UE Subscription includes Remappable Slices in the Subscribed NSSAIs or UE 201 provided the USRC or “Remappable Slice Preference” indicator(s), then AMF 203 may first populate the Allowed NSSAI, if available. In addition, AMF 203 may populate Configured NSSAI with Remappable Slices from the Subscribed NSSAI that are available to UE 201. Each S-NSSAI for Remappable Slice may be marked with a Remappable Slice Indicator.
[00232] Alternatively, if the UE Subscription information doesn’t include any Remappable Slices, then AMF 203 may trigger to prepare remapped slices for one or more slices in the UE’s Subscribed NSSAI. AMF 203 may trigger a Registration Update procedure once the Remapped Slices are available and, deliver them to UE 201.
[00233] In step 253, AMF 203 sends a Registration Accept message to UE 201 via RAN. In the message, AMF 203 may include the Allowed NSSAI, Configured NSSAI (from Step 2), and Rejected NSSAI with Remappable Slice Indicator for slices that are remappable. Alternatively, AMF 203 may indicate the presence of Remappable Slices in the Registration Accept message with a separate “Remappable Slices present” indicator.
[00234] In step 254, UE 201 may check the Allowed NSSAI received in the Registration Accept message from AMF 203. If the Allowed NSSAI did not include any S- NSSAI for Remappable Slice, then UE 201 may check the Configured NSSAI received in the Registration Accept message and, if UE 201 discovers that one or more S-NSSAIs in the Configured NSSAI are marked with the Remappable Slice Indicator, then UE 201 may choose to initiate Registration Update procedure. This time, the Requested NSSAI shall include one or more S-NSSAIs for Remappable Slices obtained from the Configured NSSAI. UE 201 receives a new set of Allowed NSSAI including S-NSSAIs for Remappable Slices.
- 54 -
4871-1319-0402.1 [00235] Alternatively, if the Registration Accept message in step 253 did not include the “Remappable Slices present” indicator, then UE 201 realizes that the network doesn’t have any Remappable Slices in the Subscribed S-NSSAI. UE 201 may send an acknowledgment back to the network to inform the receipt of the Registration Accept message.
[00236] This response may include a request to prepare Remapped Slice if the network is capable, for one or more S-NSSAI from UE 201’s Subscribed NSSAI.
[00237] Yet another alternative may be to have the core network configured with a Default Remapped Slice, which may be used, based on local operator policy during the Slice Remapping process if UE desires Slice Remapping, but there are no Remappable Slice available. In other words, the local policy may allow any network slice/PDU session to be remapped with a Default Remapped Slice.
[00238] If the network doesn’t support slice remapping functionality then AMF 203 ignores the USRC indicator, “Remappable Slice Preference” indicator, and other UE information directed to obtain Remappable Slices and treats UE 201 as a legacy UE.
[00239] UE can establish PDU Sessions PDU Session in the Remappable Slices which are guaranteed to have Remapped Slices.
[00240] Conveying UE’s Slice Remapping Capability during PDU Session Establishment
[00241] When UE 201 establishes a PDU Session, it may be desirable for UE 201 to indicate, in the NAS MM part of the message that Slice Remapping is desired for the PDU Session. Slice remapping does not happen during PDU Session establishment. However, the indication from UE 201 may indicate to UE 201 that UE 201 expects to request slice remapping in the event that it becomes necessary (e.g., UE 201 later moves to an RA where the slice is not available). AMF 203 can then consider this indication when selecting an SMF 206 to serve the PDU Session, thus ensuring that AMF 203 selects an SMF 206 that is able to perform slice remapping as described earlier.
[00242] When UE 201 establishes a PDU Session, it may be desirable for UE 201 to indicate, in the NAS SM part of the message that Slice Remapping is desired for the PDU Session. Slice remapping does not happen during PDU Session establishment. However, the indication from UE 201 may indicate to the network that UE 201 expects to request slice remapping in the event that it becomes necessary (e.g., UE 201 later moves to an RA where
- 55 -
4871-1319-0402.1 the slice is not available). The SMF 206 can then consider this indication when selecting a UPF to serve the PDU Session, thus ensuring that AMF 203 selects an SMF 206 that is able to perform slice remapping.
[00243] In response to the PDU Session Establishment request, AMF 203 may provide UE 201 with an indication of whether Slice Remapping is allowed for the PDU Session and AMF 203 may provide UE 201 with a list of S-NSSAIs that the PDU Session may be remapped to. If the information is provided to UE 201 by AMF 203, it is sent in the NAS MM part of the message. If the information is provided to UE 201 by the SMF 206, it is sent in the NAS SM part of the message. The AMF may check the UE’s Configured NSSAI before sending this information to UE 201 to ensure that the indication of remapping support is sent to UE 201 only if the PDU Session can be remapped to other slices in the UE’s configured NSSAI and that UE 201 is only sent S-NSSAI’s that are in the UE’s Configured NSSAI. FIG. 12 describes the method as follows.
[00244] In Step 260, the network may be equipped with slice remapping functionality.
[00245] In Step 261, UE 201 may initiate a PDU Session Establishment Request by the transmission of a NAS message including a PDU Session Establishment Request within the N1 SM container towards AMF 203 via the RAN 202 node. UE 201 may include in the PDU Session Establishment Request, PDU session ID, Requested PDU Session Type, a Requested SSC mode, S-NSSAI, and UE Requested DNN. In addition, UE 201 may send the UE’s network slice remapping capability (USRC) indication and, may inform the network (e.g., AMF 203, SMF 206, PCF 204, etc.) about UE 201’s desire for network slice remapping. The RAN 202 node forwards the PDU Session Establishment Request towards AMF 203.
[00246] In Step 262, AMF 203 may select the SMF 206 which is responsible for session management for the PDU session. If the core network supports slice remapping, AMF 203 considers the USRC indication in the NAS MM part of the message when selecting an SMF 206. AMF 203 invokes the Nsmf_PDUSession_CreateSMContext Request operation to create a context for the PDU Session in the SMF 206. The SMF 206 will select a UPF 209 and may consider the network slice remapping capability indication in the NAS SM part of the message. The SMF 206 will reply to UE 201 via AMF 203. The reply may indicate to UE
- 56 -
4871-1319-0402.1 201 if slice remapping is allowed for the PDU Session and the reply may indicate to UE 201 which S-NSSAI(s) the PDU Session may be remapped to.
[00247] The core network may obtain a remapped slice from the UE Subscription. The remapped slice for the PDU Session may be universal. In other words, a remapped slice for the PDU session may be valid for multiple RAs in that PLMN. This means that when UE 201 moves across RAs, the same remapped slice may be used to remap the PDU Session.
[00248] If the core network doesn’t support slice remapping functionality, AMF 203 may inform about it to UE 201 with a “slice remapping incompatible network” indication.
[00249] If the core network supports network slice remapping but the network slice where UE 201 is attempting to establish a PDU Session cannot be remapped or doesn’t have a remapped slice, AMF 203 may notify UE 201 using the “remappable slice unavailable” indicator.
[00250] In addition, AMF 203 may be able to identify the S-NSSAIs in UE 201’s Allowed NSSAI that can be remapped or if UE 201 already has remapped slices in the UE Subscription at the UDM 205.
[00251] Note that it may be possible for the core network/PLMN to implement restrictions on what RA the slice remapping may be applicable for the PDU Session established by UE 201. For instance, a remapped slice may be available in RAI, RA2 but not in RA3.
[00252] The reply from the SMF 206 to UE 201 is sent in NAS SM.
[00253] In Step 263, AMF 203 sends the NAS message including PDU Session ID and PDU Session Establishment Accept targeted to UE 201 and the N2 SM information received from the SMF 206 within the N2 PDU Session Request to the (R)AN. The N2 SM Information may also include the information on requesting UE 201’s network slice remapping capability and the S -NS SAI for the network slice with which the PDU session establishment request has been accepted. The reply in the N1 SM container from the SMF 206 may indicate to UE 201 if slice remapping is allowed for the PDU Session with a “slice remapping compatible network” indicator and, the reply may indicate to UE 201 which S- NSSAI(s) the PDU Session may be remapped to, if available. The reply from AMF 203 to UE 201 is sent in NAS MM.
- 57 -
4871-1319-0402.1 [00254] If the core network doesn’t support slice remapping functionality, AMF 203 includes the “slice remapping incompatible network” indicator in the NAS reply message.
[00255] If the core network supports network slice remapping but the network slice where UE 201 is attempting to establish a PDU Session cannot be remapped or doesn’t have a remapped slice, the NAS message includes a “remappable slice unavailable” indicator. In such a scenario, however, AMF 203 may include a list of one or more Remappable Slice(s) obtained from the UE Subscription with PDU Session Establishment Accept message and send it to UE 201.
[00256] In Step 264-A, UE 201 may start exchanging user plane data with the data network. UE 201 will consider the remapping information (e.g., the support indication and S- NSSAI(s)) when an event triggers remapping or makes remapping necessary. For example, UE 201 may include the S-NSSAI(s) in the Requested NSSAI when UE 201 eventually updates its Requested NSSAI.
[00257] In Step 264-B, although UE 201 receives PDU Session Establishment Accept message, UE 201 may notice that the network doesn’t have slice remapping functionality for the PDU Session(s) based on the “slice remapping incompatible network” indicator. In such a case, UE 201 may simply continue with Step 264-A where UE 201 and network don’t involve in slice remapping and handle the change of RA as legacy UEs.
[00258] If UE 201 receives in the PDU Session Establishment Accept message, a “remappable slice unavailable” indicator for the requested PDU Session, and one or more S- NSSAIs in UE 201’s Allowed NSSAI for which remapped slice(s) are available or slice remapping can be done, then it may be desirable for UE 201 to have the PDU Session(s) in the network slice(s) that can be remapped based on UE 201’s application/service, etc. Hence in such a case, UE 201 may select a Remappable Slice taking also into consideration the URSP rules and, send a PDU Session Establishment Request towards a Remappable Slice. Once the PDU Session Establishment procedure is complete, UE 201 may start sending user plane data to the data network (via a Remappable Slice).
[00259] Note that the remapping rule could be provided to UE 201 as a part of URSP rules, so that UE 201 will check the URSP rule for a PDU session associated with certain DNN, S-NSSAIs, and SSC modes. The remapping rule will guide UE 201 to switch to another network slice identified by a new S-NSSAIs so that UE 201 can resume data transfer
- 58 -
4871-1319-0402.1 over the existing PDU session. In addition, the remapping rule in a URSP rule can be used together with the location criteria and time window in Route Selection Validation Criteria. In other words, UE 201 will switch to another network slice in a certain location (e.g., RA, TA, or geographic location area) or a certain time period, the remapping rule could be inserted in the RSD as a new attribute. Alternatively, it could be inserted as a new value in the existing network slice selection attribute, for example, called remapped network slice or alternative set of network slice.
[00260] Slice Remapping using RAN Node
[00261] When UE 201 triggers Slice Remapping for an ongoing PDU Session in a network slice, the participating RAN nodes may be able to trigger the Slice Remapping process (e.g., moving a PDU session from a first slice to a second slice). FIG. 13 depicts a method in which the RAN nodes participate with the core network to conduct slice remapping. The method is described as follows.
[00262] In Step 270-A, the core network (e.g., AMF 203, PCF 204, NSSF, etc.) may be configured with the Remapped Slices for each network slice in the Subscribed NSSAI for the UEs registered in the core network. As described herein, each Remapped Slice is designed to have the same SMF or UPF instances as that of the network slice for which it is remapped. This ensures that an SMF 206/UPF 209 preserves the UE IP address when the PDU Session goes through Slice Remapping. Slice remapping may also be performed for cases in which the SMF or UPF are different, where the procedure would just extend signaling to involve the additional SMF or UPF. For example, if the UPF is different, then the SMF 206 in FIG. 13 would contact another UPF to perform the slice remapping. Similarly, if the SMF is different, AMF 203 in FIG. 13 would select another SMF to perform the slice remapping.
[00263] In Step 270-B, as an alternative, UE 201 may have sent a USRC indicator and UE 20 Ts desire for network slice remapping in the Registration Request during the UE Registration Procedure. The old RAN 202 may have received in the N2 container of the Registration Accept message, the information on UE 201’s Allowed S-NSSAIs and corresponding Remapped Slice/S-NSSAI for each S-NSSAI. The USRC indicator indicates to the network that UE 201 is capable of network slice remapping.
[00264] Alternatively, the old RAN 202 may receive in the N2 container of the Registration Accept message, a Slice Remapping table. This table may include a list of
- 59 -
4871-1319-0402.1 Remapped Slices for each S-NSSAI in the Allowed NSSAI. The Slice Remapping table may be established by the PCF 204, AMF 203, or NSSF based on operator policies and eventually delivered to the RAN 202 node. A Slice Remapping table may be PLMN specific that applies to all the UEs or UE specific.
[00265] In Step 271, UE 201 may send USRC indication and UE 201 ’s desire for network slice remapping to the network (e.g., AMF 203, SMF 206, PCF 204, etc.) with a PDU Session Establishment Request. The USRC indicator indicates to the network that UE 201 is capable of network slice remapping.
[00266] In Step 272, the PDU Session is established and the old RAN 202 receives the PDU Session Establishment Accept message. The PDU Session Establishment Accept message may include one or more Remapped Slice for the PDU Session. The old RAN 202 saves the Remapped Slice information from AMF 203 and forwards the PDU Session Establishment Accept message to UE 201.
[00267] In Step 273, UE 201 may exchange user plane data with the data network via the old RAN 202 node.
[00268] In Step 274, UE 201 comes across a scenario (e.g., UE 201 may move and enters into a new RA of the PLMN) that triggers Slice Remapping, e.g., UE 201 performs registration update procedure due to UE mobility. As UE 201 moves, the old NG-RAN 202 may send to the new NG-RAN 207, UE 201 handover information and prepare for the handover. The old NG-RAN 202 may also include the PDU Session that needs slice remapping and corresponding Remapped Slice.
[00269] In Step 275, as the new RAN 207 receives the request, it may send the N2 Path Switch Request to AMF 203. The new RAN 207 sends an N2 Path Switch Request message to an AMF 203 to inform that UE 201 has moved to a new target cell, the S-NSSAI for the Remapped Slice (received from the old NG-RAN 202) and, provides a List Of PDU Sessions To Be Switched. In addition, the target NG-RAN shall include in the message, the serving PLMN ID, UE Location Information, PDU Sessions Rejected list with the failure cause in the N2 SM information element.
[00270] In Step 276, AMF 203 identifies the PDU Sessions that need to be remapped. AMF 203 selects the SMF 206 for the Remapped Slice, which further selects UPF 209 where the PDU Sessions need to be transferred. UPF 209 for the Remapped Slice is
- 60 -
4871-1319-0402.1 selected such that UPF 209 preserves the IP address for the previous anchor UPF, contributing to the seamless transfer of PDU Sessions.
[00271] AMF 203 may include Remapped Slice’s S-NSSAI in the new RA’s Allowed NS SAI.
[00272] In Step 277, AMF 203 sends UE Configuration Update Command including one or more UE parameters (Configuration Update Indication, Allowed NSSAI, Configured NSSAI, rejected NSSAI, etc.) and may request acknowledgment from UE 201. The Allowed NSSAI also includes the Remapped Slices for PDU Session with remapped slice indicator. The remapped slice indicator signifies that the S-NSSAI is for a remapped slice. Should a remapped slice be limited, for example, remapping could be time-limited, limited in services that UE 201 can request, limited in max PDU Sessions or UEs that it could handle, etc. In such as case, UE 201 could identify the remapped slice with the indicator and, make traffic adaptation, PDU Session, or other signaling decisions. UE 201 shall provide the acknowledgment back to AMF 203 for the UE Configuration Update command.
[00273] In Step 278, If the PDU Session couldn’t be remapped and hence, the PDU Session is rejected but AMF 203 identified the slices that are accessible for UE 201 in the new RA, AMF 203 shall indicate that UE 201 should initiate a Registration Update procedure.
[00274] UE 201 may send a Registration Update Request to UE 201 with the new Requested NSSAI. AMF 203 may send a Registration Accept message with a new Allowed NSSAI where UE 201 can establish new PDU Sessions.
[00275] FIG. 14 illustrates an exemplary method for network controlled UE behavior for slice access. At step 281, a policy may be received from a network. In an example, the policy may indicate that: UE 201 include an S-NSSAI value in the Requested NSSAI when the type of registration request is an initial registration and the S-NSSAI value is indicated in the policy; UE 201 include an S-NSSAI value in the Requested NSSAI when UE 201 enters a new Registration Area and the S-NSSAI value is indicated in the policy; UE 201 excludes a S-NSSAI value from the Requested NSSAI and where the S-NSSAI value is part of the UE 201’s Allowed NSSAI; UE 201 send the Registration Request in a time period and the time period is indicated in the policy; UE 201 send the Registration Request when UE 201 is in a location and the location is indicated in the policy; UE 201 send the Registration Request when no traffic has been sent or received with the S-NSSAI within a given amount
- 61 -
4871-1319-0402.1 of time and the amount of time is indicated in the policy; UE 201 send the Registration Request if no control plane traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy; or UE 201 send the Registration Request when no PDU Session has been established with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy. The policy may be a URSP rule.
[00276] At step 282, the policy may be used to determine a Requested NSSAI. At step 283, a registration request may be sent to the network. The registration request may include the Requested NSSAI. The Requested NSSAI may include one or more S-NSSAI.
[00277] FIG. 15 illustrates an exemplary method for network controlled UE behavior for slice access. At step 291, an Allowed NSSAI may be received from the network. The Allowed NSSAI may include one S-NSSAI. At step 292, a policy may be received from the network. At step 293, the policy may be used to determine an S-NSSAI. At step 294, the policy may be used to: determine to send a PDU Session Establishment Request to the network after receiving the Allowed NSSAI on the condition that the Allowed NSSAI includes the S-NSSAI; determine to send a PDU Session Establishment Request to the network when UE 201 is in a location on the condition that the Allowed NSSAI includes the S-NSSAI; or determine to send a PDU Session Release Request to the network after a condition is met. The condition may include that no data has been sent on the PDU Session for a time period and the policy indicates the time period.
[00278] At step 295, the PDU Session Establishment Request may be sent to the network and the request may include the S-NSSAI. UE 201 may use the policy to determine a DNN and the PDU Session Establishment Request may include the DNN.
[00279] As disclosed herein a policy may be a URSP rule. In an example, the USRP rule may include one RSD. The RSD may include a second S-NSSAI, the second S-NSSAI is not included in the Allowed NSSAI, the RSD includes an indication that the UE should request that the network add the second S-NSSAI to the Allowed NSSAI if the RSD is evaluated. A registration request may be determined to be sent to the network in order to request that the second S-NSSAI be added to the Allowed NSSAI.
[00280] It is understood that the entities performing the steps illustrated herein, such as FIG. 4- FIG. 15, may be logical entities. The steps may be stored in a memory of, and executing on a processor of, a device, server, or computer system such as those illustrated in
- 62 -
4871-1319-0402.1 FIG. 8F or FIG. 8G. Skipping steps, combining steps, or adding steps between exemplary methods disclosed herein (e.g., FIG. 4 - FIG. 14) is contemplated.
Example User Interface
[00281] FIG. 7 depicts that a UE has been configured with US AB policy and Enhanced URSP rules. The USAB policy may include UE registration and de-registration rules and PDU session establishment and release rules for optimized UE behavior of slice access.
Example Communications System
[00282] FIG. 8 A illustrates an example communications system 100 in which the methods and apparatuses of network controlled UE behavior for slice access, such as the systems and methods illustrated in figures described and claimed herein may be used. The communications system 100 may include wireless transmit/receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, or 102g (which generally or collectively may be referred to as WTRU 102 or WTRUs 102). The communications system 100 may include, a radio access network (RAN) 103/104/105/103b/104b/105b, a core network 106/107/109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and Network Services 113. Network Services 113 may include, for example, a V2X server, V2X functions, a ProSe server, ProSe functions, loT services, video streaming, or edge computing, etc.
[00283] It will be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, or network elements. Each of the WTRUs 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be any type of apparatus or device configured to operate or communicate in a wireless environment. Although each WTRU 102a, 102b, 102c, 102d, 102e, 102f, or 102g may be depicted in FIG 8 A, FIG 8B, FIG 8C, FIG. 8D, FIG. 8E, or FIG. 8F as a hand-held wireless communications apparatus, it is understood that with the wide variety of use cases contemplated for 5G wireless communications, each WTRU may comprise or be embodied in any type of apparatus or device configured to transmit or receive wireless signals, including, by way of example only, user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot,
- 63 -
4871-1319-0402.1 industrial equipment, a drone, a vehicle such as a car, bus, truck, train, or airplane, and the like.
[00284] The communications system 100 may also include a base station 114a and a base station 114b. In the example of FIG. 8A, each base stations 114a and 114b is depicted as a single element. In practice, the base stations 114a and 114b may include any number of interconnected base stations or network elements. Base stations 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, or the other networks 112. Similarly, base station 114b may be any type of device configured to wiredly or wirelessly interface with at least one of the Remote Radio Heads (RRHs) 118a, 118b, Transmission and Reception Points (TRPs) 119a, 119b, or Roadside Units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, other networks 112, or Network Services 113. RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102, e.g., WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, or other networks 112
[00285] TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRU 102d, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, Network Services 113, or other networks 112. RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRU 102e or 102f, to facilitate access to one or more communication networks, such as the core network 106/107/109, the Internet 110, other networks 112, or Network Services 113. By way of example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), aNode-B, an eNode B, a Home Node B, a Home eNode B, a Next Generation Node-B (gNode B), a satellite, a site controller, an access point (AP), a wireless router, and the like.
[00286] The base station 114a may be part of the RAN 103/104/105, which may also include other base stations or network elements (not shown), such as a Base Station Controller (BSC), a Radio Network Controller (RNC), relay nodes, etc. Similarly, the base station 114b may be part of the RAN 103b/l 04b/ 105b, which may also include other base stations or network elements (not shown), such as a BSC, a RNC, relay nodes, etc. The base
- 64 -
4871-1319-0402.1 station 114a may be configured to transmit or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). Similarly, the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown) for methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein. Similarly, the base station 114b may be configured to transmit or receive wired or wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an example, the base station 114a may include three transceivers, e.g., one for each sector of the cell. In an example, the base station 114a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
[00287] The base stations 114a may communicate with one or more of the WTRUs 102a, 102b, 102c, or 102g over an air interface 115/116/117, which may be any suitable wireless communication link (e.g., radio frequency (RF), micro wave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115/116/117 may be established using any suitable radio access technology (RAT).
[00288] The base stations 114b may communicate with one or more of the RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b, over a wired or air interface 115b/l 16b/l 17b, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., radio frequency (RF), micro wave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b/l 16b/l 17b may be established using any suitable radio access technology (RAT).
[00289] The RRHs 118a, 118b, TRPs 119a, 119b or RSUs 120a, 120b, may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an air interface 115c/l 16c/l 17c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c/l 16c/l 17c may be established using any suitable radio access technology (RAT).
[00290] The WTRUs 102a, 102b, 102c,102d, 102e, or 102f may communicate with one another over an air interface 115d/l 16d/l 17d, such as Sidelink communication, which may be any suitable wireless communication link (e.g., radio frequency (RF), micro wave,
- 65 -
4871-1319-0402.1 infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115d/l 16d/l 17d may be established using any suitable radio access technology (RAT).
[00291] The communications system 100 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC- FDMA, and the like. For example, the base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b,TRPs 119a, 119b and RSUs 120a, 120b, in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, 102f, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) or High-Speed Uplink Packet Access (HSUPA).
[00292] In an example, the base station 114a and the WTRUs 102a, 102b, 102c, or RRHs 118a, 118b, TRPs 119a, 119b, or RSUs 120a, 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 115/116/117 or 115c/l 16c/l 17c respectively using Long Term Evolution (LTE) or LTE-Advanced (LTE-A). In the future, the air interface 115/116/117 or 115c/l 16c/l 17c may implement 3GPP NR technology. The LTE and LTE-A technology may include LTE D2D and V2X technologies and interfaces (such as Sidelink communications, etc.). Similarly, the 3GPP NR technology includes NR V2X technologies and interface (such as Sidelink communications, etc.).
[00293] The base station 114a in the RAN 103/104/105 and the WTRUs 102a, 102b, 102c, and 102g or RRHs 118a, 118b, TRPs 119a, 119b or RSUs 120a, 120b in the RAN 103b/104b/105b and the WTRUs 102c, 102d, 102e, 102f may implement radio technologies such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 IX, CDMA2000 EV-DO, Interim Standard 2000 (IS- 2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
[00294] The base station 114c in FIG. 8A may be a wireless router, Home Node B, Home eNode B, or access point, for example, and may utilize any suitable RAT for
- 66 -
4871-1319-0402.1 facilitating wireless connectivity in a localized area, such as a place of business, a home, a vehicle, a train, an aerial, a satellite, a manufactory, a campus, and the like, for implementing the methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein. In an example, the base station 114c and the WTRUs 102, e.g., WTRU 102e, may implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN), similarly, the base station 114c and the WTRUs 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another example, the base station 114c and the WTRUs 102, e.g., WTRU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. As shown in FIG. 8A, the base station 114cmay have a direct connection to the Internet 110. Thus, the base station 114c may not be required to access the Internet 110 via the core network 106/107/109.
[00295] The RAN 103/104/105 or RAN 103b/104b/105b may be in communication with the core network 106/107/109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106/107/109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., or perform high-level security functions, such as user authentication.
[00296] Although not shown in FIG. 8A, it will be appreciated that the RAN 103/104/105 or RAN 103b/104b/105b or the core network 106/107/109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103/104/105 or RAN 103b/104b/105b or a different RAT. For example, in addition to being connected to the RAN 103/104/105 or RAN 103b/104b/105b, which may be utilizing an E- UTRA radio technology, the core network 106/107/109 may also be in communication with another RAN (not shown) employing a GSM or NR radio technology.
[00297] The core network 106/107/109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, or other networks 112. The PSTN 108 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the
- 67 -
4871-1319-0402.1 transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 112 may include wired or wireless communications networks owned or operated by other service providers. For example, the networks 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103/104/105 or RAN 103b/104b/105b or a different RAT.
[00298] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communications system 100 may include multi-mode capabilities, e.g., the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f may include multiple transceivers for communicating with different wireless networks over different wireless links for implementing methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein. For example, the WTRU 102g shown in FIG. 8 A may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.
[00299] Although not shown in FIG. 8A, it will be appreciated that a User Equipment may make a wired connection to a gateway. The gateway maybe a Residential Gateway (RG). The RG may provide connectivity to a Core Network 106/107/109. It will be appreciated that much of the subject matter included herein may equally apply to UEs that are WTRUs and UEs that use a wired connection to connect with a network. For example, the subject matter that applies to the wireless interfaces 115, 116, 117 and 115c/l 16c/l 17c may equally apply to a wired connection.
[00300] FIG. 8B is a system diagram of an example RAN 103 and core network 106 that may implement methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein. As noted above, the RAN 103 may employ a UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 8B, the RAN 103 may include Node-Bs 140a, 140b, and 140c, which may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs.)
- 68 -
4871-1319-0402.1 [00301] As shown in FIG. 8B, the Node-Bs 140a, 140b may be in communication with the RNC 142a. Additionally, the Node-B 140c may be in communication with the RNC 142b. The Node-Bs 140a, 140b, and 140c may communicate with the respective RNCs 142a and 142b via an lub interface. The RNCs 142a and 142b may be in communication with one another via an lur interface. Each of the RNCs 142aand 142b may be configured to control the respective Node-Bs 140a, 140b, and 140c to which it is connected. In addition, each of the RNCs 142aand 142b may be configured to carry out or support other functionality, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro-diversity, security functions, data encryption, and the like.
[00302] The core network 106 shown in FIG. 8B may include a media gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, or a Gateway GPRS Support Node (GGSN) 150. While each of the foregoing elements are depicted as part of the core network 106, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator.
[00303] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an luCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c, and traditional land-line communications devices.
[00304] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an luPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between and the WTRUs 102a, 102b, and 102c, and IP-enabled devices.
[00305] The core network 106 may also be connected to the other networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
[00306] FIG. 8C is a system diagram of an example RAN 104 and core network 107 that may implement methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.
- 69 -
4871-1319-0402.1 [00307] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.
[00308] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, and the like. As shown in FIG. 8C, the eNode-Bs 160a, 160b, and 160c may communicate with one another over an X2 interface.
[00309] The core network 107 shown in FIG. 8C may include a Mobility Management Gateway (MME) 162, a serving gateway 164, and a Packet Data Network (PDN) gateway 166. While each of the foregoing elements are depicted as part of the core network 107, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator.
[00310] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an SI interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation/deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.
[00311] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the SI interface. The serving gateway 164 may generally route and forward user data packets to/from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring user planes during inter- eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing contexts of the WTRUs 102a, 102b, and 102c, and the like.
- 70 -
4871-1319-0402.1 2020P00294WG / 106693.001425
[00312] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c, and IP-enabled devices.
[00313] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
[00314] FIG. 8D is a system diagram of an example RAN 105 and core network 109 that may implement methods, systems, and devices of network controlled UE behavior for slice access, as disclosed herein. The RAN 105 may employ an NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A Non-3GPP Interworking Function (N3IWF) 199 may employ a non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.
[00315] The RAN 105 may include gNode-Bs 180a and 180b. It will be appreciated that the RAN 105 may include any number of gNode-Bs. The gNode-Bs 180a and 180b may each include one or more transceivers for communicating with the WTRUs 102a and 102b over the air interface 117. When integrated access and backhaul connection are used, the same air interface may be used between the WTRUs and gNode-Bs, which may be the core network 109 via one or multiple gNBs. The gNode-Bs 180a and 180b may implement MIMO, MU-MIMO, or digital beamforming technology. Thus, the gNode-B 180a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a. It should be appreciated that the RAN 105 may employ of other types of base stations such as an eNode-B. It will also be appreciated the
- 71 -
4871-1319-0402.1 RAN 105 may employ more than one type of base station. For example, the RAN may employ eNode-Bs and gNode-Bs.
[00316] The N3IWF 199 may include anon-3GPP Access Point 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP Access Points. The non-3GPP Access Point 180c may include one or more transceivers for communicating with the WTRUs 102c over the air interface 198. The non-3GPP Access Point 180c may use the 802.11 protocol to communicate with the WTRU 102c over the air interface 198.
[00317] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in the uplink or downlink, and the like. As shown in FIG. 8D, the gNode-Bs 180a and 180b may communicate with one another over an Xn interface, for example.
[00318] The core network 109 shown in FIG. 8D may be a 5G core network (5GC). The core network 109 may offer numerous communication services to customers who are interconnected by the radio access network. The core network 109 comprises a number of entities that perform the functionality of the core network. As used herein, the term “core network entity” or “network function” refers to any entity that performs one or more functionalities of a core network. It is understood that such core network entities may be logical entities that are implemented in the form of computer-executable instructions (software) stored in a memory of, and executing on a processor of, an apparatus configured for wireless or network communications or a computer system, such as system 90 illustrated in FIG. 8G.
[00319] In the example of FIG. 8D, the 5G Core Network 109 may include an access and mobility management function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPFs) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, aNon-3GPP Interworking Function (N3IWF) 199, a User Data Repository (UDR) 178. While each of the foregoing elements are depicted as part of the 5G core network 109, it will be appreciated that any one of these elements may be owned or operated by an entity other than the core network operator. It will also be appreciated that a 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these
- 72 -
4871-1319-0402.1 elements. FIG. 8D shows that network functions directly connect with one another, however, it should be appreciated that they may communicate via routing agents such as a diameter routing agent or message buses.
[00320] In the example of FIG. 8D, connectivity between network functions is achieved via a set of interfaces, or reference points. It will be appreciated that network functions could be modeled, described, or implemented as a set of services that are invoked, or called, by other network functions or services. Invocation of a Network Function service may be achieved via a direct connection between network functions, an exchange of messaging on a message bus, calling a software function, etc.
[00321] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive the user plane tunnel configuration information from the SMF via an N11 interface. The AMF 172 may generally route and forward NAS packets to/from the WTRUs 102a, 102b, and 102c via an N1 interface. The N1 interface is not shown in FIG. 8D.
[00322] The SMF 174 may be connected to the AMF 172 via an Nll interface. Similarly the SMF may be connected to the PCF 184 via an N7 interface, and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for Session Management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPF 176a and UPF 176b, and generation of downlink data notifications to the AMF 172.
[00323] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a Packet Data Network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, Other Networks 112 may be Ethernet Networks or any type of network that exchanges packets of data. The UPF 176a and UPF 176b may receive traffic steering rules from the SMF 174 via the N4 interface. The UPF 176a and UPF 176b may provide access to a packet data network by connecting a packet data network with an N6 interface or by connecting to each other and to other UPFs via an N9 interface. In
- 73 -
4871-1319-0402.1 addition to providing access to packet data networks, the UPF 176 may be responsible packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, downlink packet buffering.
[00324] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates a connection between the WTRU 102c and the 5G core network 170, for example, via radio interface technologies that are not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same, or similar, manner that it interacts with the RAN 105.
[00325] The PCF 184 may be connected to the SMF 174 via an N7 interface, connected to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 8D. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and SMF 174, allowing the control plane nodes to enforce these rules. The PCF 184, may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via an Nl interface. Policies may then be enforced, or applied, at the WTRUs 102a, 102b, and 102c.
[00326] The UDR 178 may act as a repository for authentication credentials and subscription information. The UDR may connect with network functions, so that network function can add to, read from, and modify the data that is in the repository. For example, the UDR 178 may connect with the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect with the NEF 196 via an N37 interface, and the UDR 178 may connect with the UDM 197 via an N35 interface.
[00327] The UDM 197 may serve as an interface between the UDR 178 and other network functions. The UDM 197 may authorize network functions to access of the UDR 178. For example, the UDM 197 may connect with the AMF 172 via an N8 interface, the UDM 197 may connect with the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect with the AUSF 190 via an N13 interface. The UDR 178 and UDM 197 may be tightly integrated.
[00328] The AUSF 190 performs authentication related operations and connect with the UDM 178 via an N13 interface and to the AMF 172 via an N12 interface.
[00329] The NEF 196 exposes capabilities and services in the 5G core network 109 to Application Functions (AF) 188. Exposure may occur on the N33 API interface. The NEF
- 74 -
4871-1319-0402.1 may connect with an AF 188 via an N33 interface and it may connect with other network functions in order to expose the capabilities and services of the 5G core network 109.
[00330] Application Functions 188 may interact with network functions in the 5G Core Network 109. Interaction between the Application Functions 188 and network functions may be via a direct interface or may occur via the NEF 196. The Application Functions 188 may be considered part of the 5G Core Network 109 or may be external to the 5G Core Network 109 and deployed by enterprises that have a business relationship with the mobile network operator.
[00331] Network Slicing is a mechanism that could be used by mobile network operators to support one or more ‘virtual’ core networks behind the operator’s air interface. This involves ‘slicing’ the core network into one or more virtual networks to support different RANs or different service types running across a single RAN. Network slicing enables the operator to create networks customized to provide optimized solutions for different market scenarios which demands diverse requirements, e.g., in the areas of functionality, performance and isolation.
[00332] 3GPP has designed the 5G core network to support Network Slicing. Network Slicing is a good tool that network operators can use to support the diverse set of 5G use cases (e.g., massive loT, critical communications, V2X, and enhanced mobile broadband) which demand very diverse and sometimes extreme requirements. Without the use of network slicing techniques, it is likely that the network architecture would not be flexible and scalable enough to efficiently support a wider range of use cases need when each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, introduction of new network services should be made more efficient.
[00333] Referring again to FIG. 8D, in a network slicing scenario, a WTRU 102a, 102b, or 102c may connect with an AMF 172, via an N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the connection or communication of WTRU 102a, 102b, or 102c with one or more UPF 176a and 176b, SMF 174, and other network functions. Each of the UPFs 176a and 176b, SMF 174, and other network functions may be part of the same slice or different slices. When they are part of different slices, they may be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.
- 75 -
4871-1319-0402.1 [00334] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include, or may communicate with, an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that serves as an interface between the 5G core network 109 and a PSTN 108. For example, the core network 109 may include, or communicate with a short message service (SMS) service center that facilities communication via the short message service. For example, the 5G core network 109 may facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and servers or applications functions 188. In addition, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the networks 112, which may include other wired or wireless networks that are owned or operated by other service providers.
[00335] The core network entities described herein and illustrated in FIG. 8A, FIG. 8C, FIG. 8D, or FIG. 8E are identified by the names given to those entities in certain existing 3GPP specifications, but it is understood that in the future those entities and functionalities may be identified by other names and certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, the particular network entities and functionalities described and illustrated in FIG. 8A, FIG. 8B, FIG. 8C, FIG. 8D, or FIG. 8E are provided by way of example only, and it is understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether presently defined or defined in the future.
[00336] FIG. 8E illustrates an example communications system 111 in which the systems, methods, apparatuses that implement network controlled UE behavior for slice access, described herein, may be used. Communications system 111 may include Wireless Transmit/Receive Units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and Road Side Units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base station gNBs, V2X networks, or other network elements. One or several or all WTRUs A, B, C, D, E, and F may be out of range of the access network coverage 131. WTRUs A, B, and C form a V2X group, among which WTRU A is the group lead and WTRUs B and C are group members.
[00337] WTRUs A, B, C, D, E, and F may communicate with each other over a Uu interface 129 via the gNB 121 if they are within the access network coverage 131. In the example of FIG. 8E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate with each other directly via a Sidelink
- 76 -
4871-1319-0402.1 2020P00294WG / 106693.001425 interface (e.g., PC5 or NR PC5) such as interface 125a, 125b, or 128, whether they are under the access network coverage 131 or out of the access network coverage 131. For instance, in the example of FIG. 8E, WRTU D, which is outside of the access network coverage 131, communicates with WTRU F, which is inside the coverage 131.
[00338] WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via a Vehicle-to-Network (V2N) 133 or Sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate to a V2X Server 124 via a Vehicle-to-Infrastructure (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via a Vehicle-to-Person (V2P) interface 128.
[00339] FIG. 8F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communications and operations in accordance with the systems, methods, and apparatuses that implement network controlled UE behavior for slice access, described herein, such as a WTRU 102 of FIG. 8A, FIG. 8B, FIG. 8C, FIG. 8D, or FIG. 8E, or devices of FIG. 1 - FIG. 13. As shown in FIG. 8F, the example WTRU 102 may include a processor 78, a transceiver 120, a transmit/ receive element 122, a speaker/mi crophone 74, a keypad 126, a display/touchpad/indicators 77, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It will be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements. Also, the base stations 114a and 114b, or the nodes that base stations 114a and 114b may represent, such as but not limited to transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home node-B, an evolved home node-B (eNodeB), a home evolved node-B (HeNB), a home evolved node- B gateway, a next generation node-B (gNode-B), and proxy nodes, among others, may include some or all of the elements depicted in FIG. 8F and may be an exemplary implementation that performs the disclosed systems and methods for network controlled UE behavior for slice access described herein.
[00340] The processor 78 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 78 may perform signal coding, data processing, power control,
- 77 -
4871-1319-0402.1 input/ output processing, or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 78 may be coupled to the transceiver 120, which may be coupled to the transmit/receive element 122. While FIG. 8F depicts the processor 78 and the transceiver 120 as separate components, it will be appreciated that the processor 78 and the transceiver 120 may be integrated together in an electronic package or chip.
[00341] The transmit/receive element 122 of a UE may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 114a of FIG. 8A) over the air interface 115/116/117 or another UE over the air interface 115d/l 16d/l 17d. For example, the transmit/receive element 122 may be an antenna configured to transmit or receive RF signals. The transmit/receive element 122 may be an emitter/detector configured to transmit or receive IR, UV, Radar, LIDAR, or visible light signals, for example. The transmit/receive element 122 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 122 may be configured to transmit or receive any combination of wireless or wired signals.
[00342] In addition, although the transmit/receive element 122 is depicted in FIG. 8F as a single element, the WTRU 102 may include any number of transmit/receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit/receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115/116/117.
[00343] The transceiver 120 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 122 and to demodulate the signals that are received by the transmit/receive element 122. As noted above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers for enabling the WTRU 102 to communicate via multiple RATs, for example NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.
[00344] The processor 78 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker/mi crophone 74, the keypad 126, or the display/touchpad/indicators 77 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit. The processor 78 may also output user data to the speaker/mi crophone 74, the keypad 126, or the display/touchpad/indicators 77. In addition, the processor 78 may access information from, and store data in, any type of suitable
- 78 -
4871-1319-0402.1 memory, such as the non-removable memory 130 or the removable memory 132. The nonremovable 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. The processor 78 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server that is hosted in the cloud or in an edge computing platform or in a home computer (not shown). The processor 78 may be configured to control lighting patterns, images, or colors on the display or indicators 77 in response to whether the setup of network controlled UE behavior for slice access in some of the examples described herein are successful or unsuccessful, or otherwise indicate a status of network controlled UE behavior for slice access and associated components. The control lighting patterns, images, or colors on the display or indicators 77 may be reflective of the status of any of the method flows or components in the FIG.’s illustrated or discussed herein (e.g., FIG. 9 -FIG. 13, etc.). Disclosed herein are messages and procedures of network controlled UE behavior for slice access. The messages and procedures may be extended to provide interface/ API for users to request resources via an input source (e.g., speaker/mi crophone 74, keypad 126, or display/touchpad/indicators 77) and request, configure, or query network controlled UE behavior for slice access related information, among other things that may be displayed on display 77.
[00345] The processor 78 may receive power from the power source 134 and may be configured to distribute or control the power to the other components in the WTRU 102. The power source 134 may be any suitable device for powering the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, and the like.
[00346] The processor 78 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or in lieu of, the information from the GPS chipset 136, the WTRU 102 may receive location information over the air interface 115/116/117 from a base station (e.g., base stations 114a, 114b) or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information by way of any suitable location-determination method.
- 79 -
4871-1319-0402.1 [00347] The processor 78 may further be coupled to other peripherals 138, which may include one or more software or hardware modules that provide additional features, functionality, or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as an accelerometer, biometrics (e.g., finger print) sensors, an e- compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
[00348] The WTRU 102 may be included in other apparatuses or devices, such as a sensor, consumer electronics, a wearable device such as a smart watch or smart clothing, a medical or eHealth device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or an airplane. The WTRU 102 may connect with other components, modules, or systems of such apparatuses or devices via one or more interconnect interfaces, such as an interconnect interface that may comprise one of the peripherals 138.
[00349] FIG. 8G is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communications networks illustrated in FIG. 8A, FIG. 8C, FIG. 8D and FIG. 8E as well as network controlled UE behavior for slice access, such as the systems and methods illustrated in FIG. 1 through FIG. 13 described and claimed herein may be embodied, such as certain nodes or functional entities in the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, Other Networks 112, or Network Services 113. Computing system 90 may comprise a computer or server and may be controlled primarily by computer readable instructions, which may be in the form of software, wherever, or by whatever means such software is stored or accessed. Such computer readable instructions may be executed within a processor 91, to cause computing system 90 to do work. The processor 91 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, 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, or any other functionality that enables the computing system 90 to operate in a communications network. Coprocessor 81 is an optional processor, distinct from main processor 91, that may
- 80 -
4871-1319-0402.1 2020P00294WG / 106693.001425 perform additional functions or assist processor 91. Processor 91 or coprocessor 81 may receive, generate, and process data related to the methods and apparatuses disclosed herein for network controlled UE behavior for slice access, such as receiving messages.
[00350] In operation, processor 91 fetches, decodes, and executes instructions, and transfers information to and from other resources via the computing system’s main data- transfer path, system bus 80. Such a system bus connects the components in computing system 90 and defines the medium for data exchange. System bus 80 typically includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for operating the system bus. An example of such a system bus 80 is the PCI (Peripheral Component Interconnect) bus.
[00351] Memories coupled to system bus 80 include random access memory (RAM) 82 and read only memory (ROM) 93. Such memories include circuitry that allows information to be stored and retrieved. ROMs 93 generally include stored data that cannot easily be modified. Data stored in RAM 82 may be read or changed by processor 91 or other hardware devices. Access to RAM 82 or ROM 93 may be controlled by memory controller 92. Memory controller 92 may provide an address translation function that translates virtual addresses into physical addresses as instructions are executed. Memory controller 92 may also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in a first mode may access only memory mapped by its own process virtual address space; it cannot access memory within another process’s virtual address space unless memory sharing between the processes has been set up.
[00352] In addition, computing system 90 may include peripherals controller 83 responsible for communicating instructions from processor 91 to peripherals, such as printer 94, keyboard 84, mouse 95, and disk drive 85.
[00353] Display 86, which is controlled by display controller 96, is used to display visual output generated by 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). Display 86 may be implemented with a CRT-based video display, an LCD-based flat-panel display, gas plasma-based flat-panel display, or a touchpanel. Display controller 96 includes electronic components required to generate a video signal that is sent to display 86.
- 81 -
4871-1319-0402.1 2020P00294WG / 106693.001425
[00354] Further, computing system 90 may include communication circuitry, such as for example a wireless or wired network adapter 97, that may be used to connect computing system 90 to an external communications network or devices, such as the RAN 103/104/105, Core Network 106/107/109, PSTN 108, Internet 110, WTRUs 102, or Other Networks 112 of FIG. 8A, FIG. 8B, FIG. 8C, FIG. 8D, or FIG. 8E, to enable the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuitry, alone or in combination with the processor 91, may be used to perform the transmitting and receiving steps of certain apparatuses, nodes, or functional entities described herein.
[00355] It is understood that any or all of the apparatuses, systems, methods and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium which instructions, when executed by a processor, such as processors 78 or 91, cause the processor to perform 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, executing on the processor of an apparatus or computing system configured for wireless or wired network communications. Computer readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storage of information, but such computer readable storage media do not include signals. Computer readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible or physical medium which may be used to store the desired information and which may be accessed by a computing system.
[00356] Table 9 provides for list of acronyms that may appear in the description.
Table 9 - Abbreviations and Definitions
Figure imgf000084_0001
- 82 -
4871-1319-0402.1
Figure imgf000085_0001
- 83 -
4871-1319-0402.1
Figure imgf000086_0001
[00357] While certain example aspects have been described, these aspects have been presented by way of example only, and are not intended to limit the scope of the inventions disclosed herein. Nothing in the foregoing description is intended to imply that any particular feature, characteristic, step, module, or block is necessary or indispensable. The novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions disclosed herein. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of certain of the inventions disclosed herein.
[00358] In describing preferred methods, systems, or apparatuses of the subject matter of the present disclosure - network controlled UE behavior for slice access - as illustrated in the Figures, specific terminology is employed for the sake of clarity. The
- 84 -
4871-1319-0402.1 claimed subject matter, however, is not intended to be limited to the specific terminology so selected.
[00359] The various techniques described herein may be implemented in connection with hardware, firmware, software or, where appropriate, combinations thereof. Such hardware, firmware, and software may reside in apparatuses located at various nodes of a communication network. The apparatuses may operate singly or in combination with each other to effectuate the methods described herein. As used herein, the terms “apparatus,” “network apparatus,” “node,” “device,” “network node,” or the like may be used interchangeably. In addition, the use of the word “or” is generally used inclusively unless otherwise provided herein. Also, “desire” herein may be considered a request for or a determination of an action based on a certain trigger, such as a threshold value or state. For example, request slice remapping or determine slice remapping is appropriate based on a threshold value.
[00360] This written description uses examples for the disclosed subject matter, including the best mode, and also to enable any person skilled in the art to practice the disclosed subject matter, including making and using any devices or systems and performing any incorporated methods. The disclosed subject matter may include other examples that occur to those skilled in the art (e.g., skipping steps, combining steps, or adding steps between exemplary methods disclosed herein).
[00361] Methods, systems, and apparatuses, among other things, as described herein may provide for network controlled UE behavior for slice access. A method by which a UE indicates to a network about its support for Slice Resource Management Capability (SRMC) is described herein. A method by which a network conveys USAB policies to a UE for optimal slice access during UE Registration Procedure or UE Configuration Update procedure is described herein. A method by which a UE implements USAB policies during a PDU Session Establishment Procedure to establish PDU sessions in an optimal manner is described herein. A method for PDU Session release in which, a network sends an explicit release signal to a UE or an explicit release signal with a Grace Timer is described herein. A method for PDU Session release in which, a network or a UE may apply an additional time called release delay time before releasing a PDU session when the UE encounters a context (e.g., location change) is described herein. Methods for slice remapping is described herein, method, system, computer readable storage medium, or apparatus provides for using the
- 85 -
4871-1319-0402.1 policy to determine: to send a protocol data unit (PDU) session establishment request to a network slice that is associated with the S-NSSAI after receiving the allowed NSSAI on the condition that the allowed NSSAI includes the S-NSSAI; or to send a PDU session establishment request to a network slice that is associated with the S-NSSAI when the apparatus is in a location on the condition that the allowed NSSAI includes the S-NSSAI; or to send a PDU session release request to a network slice that is associated with the S-NSSAI after a condition is met. All combinations in this paragraph and the below paragraphs (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.
[00362] A method, system, computer readable storage medium, or apparatus provides for receiving a policy from a network; using the policy to determine a Requested NSSAI, and sending a registration request to the network, the registration request includes a Requested NSSAI and the Requested NSSAI includes at least one S-NSSAI. The policy instructs a UE to sometime or always include an S-NSSAI value in the Requested NSSAI when the type of registration request is an initial registration and the S-NSSAI value is indicated in the policy. The policy instructs the UE to always include an S-NSSAI value in the Requested NSSAI when the UE enters a new Registration Area and the S-NSSAI value is indicated in the policy. The policy instructs the UE to exclude a S-NSSAI value from the Requested NSSAI and where the S-NSSAI value is part of the UE’s Allowed NSSAI. The policy further instructs the UE to send the Registration Request in a time period and the time period is indicated in the policy. The policy further instructs the UE to send the Registration Request when the UE in a location and the location is indicated in the policy. The policy further instructs the UE to send the Registration Request if no traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy. The policy further instructs the UE to send the Registration Request if no control plane traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy. The policy further instructs the UE to send the Registration Request if no PDU Session has been established with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy. The policy may be a URSP rule. A method, system, computer readable storage medium, or apparatus provides for receiving an Allowed NSSAI from the network; the Allowed NSSAI includes at least one S-NSSAI; receiving a policy from a network; using the policy to determine an S-
- 86 -
4871-1319-0402.1 NS SAI; using the policy to determine to send a PDU Session Establishment Request to the network after receiving the Allowed NS SAI on the condition that the Allowed NS SAI includes the S-NSSAI; and sending a PDU Session Establishment Request to the network and the request includes the S-NSSAI. The UE uses the policy to determine a DNN and the PDU Session Establishment Request includes the DNN. All combinations in this paragraph and the below paragraphs (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.
[00363] A method, system, computer readable storage medium, or apparatus provides for receiving an Allowed NS SAI from the network, the Allowed NS SAI includes at least one S-NSSAI; receiving a policy from a network; using the policy to determine an S- NSSAI; and using the policy to determine to send a PDU Session Establishment Request to the network when the UE is in a location on the condition that the Allowed NS SAI includes the S-NSSAI. An apparatus may use the policy to determine to send a PDU Session Release Request to the network after a condition is met. A condition may be that no data has been sent on the PDU Session for a time period and the policy indicates the time period. A method, system, computer readable storage medium, or apparatus provides for receiving an Allowed NSSAI from the network, the Allowed NSSAI includes at least one S-NSSAI; receiving a URSP rule from the network, the URSP rule include at least one RSD, the RSD include a second S-NSSAI, the second S-NSSAI is not included in the Allowed NSSAI, the RSD includes an indication that the UE should request that the network add the second S-NSSAI to the Allowed NSSAI if the RSD is evaluated; and determining to send a registration request to the network in order to request that the second S-NSSAI be added to the Allowed NSSAI. All combinations in this paragraph (including the removal or addition of steps) are contemplated in a manner that is consistent with the other portions of the detailed description.
- 87 -
4871-1319-0402.1

Claims

What is claimed is:
1. An apparatus that performs wireless communication comprising: a processor; and memory coupled with the processor, the memory comprising executable instructions stored thereon that when executed by the processor cause the processor to effectuate operations comprising: receiving a policy from a network; using the policy to determine a requested network slice selection assistance information (NSSAI); and sending a registration request to the network, wherein the registration request comprises the requested NSSAI.
2. The apparatus of claim 1, wherein the requested NSSAI comprises a single -NSSAI (S- NSSAI).
3. The apparatus of claim 1, wherein the policy indicates that the apparatus include a single - NSSAI (S-NSSAI) value in the requested NSSAI when a type of the registration request is an initial registration and the S-NSSAI value is indicated in the policy.
4. The apparatus of claim 1, wherein the policy indicates that the apparatus include a single - NSSAI (S-NSSAI) value in the requested NSSAI when the apparatus enters a new registration area and the S-NSSAI value is indicated in the policy.
5. The apparatus of claim 1, wherein the policy indicates that the apparatus excludes a single -NSSAI (S-NSSAI) value from the requested NSSAI and when the S-NSSAI value is part of the allowed NSSAI of the apparatus.
6. The apparatus of claim 1, wherein the policy indicates that the apparatus send the registration request in a time period and the time period is indicated in the policy.
7. The apparatus of claim 1, wherein the policy indicates that the apparatus send the registration request when the apparatus is in a location and the location is indicated in the policy.
8. The apparatus of claim 1, wherein the policy indicates that the apparatus send the Registration Request when no traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy.
9. The apparatus of claim 1, wherein the policy indicates that the apparatus send the Registration Request if no control plane traffic has been sent or received with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy.
10. The apparatus of claim 1, wherein the policy indicates that the apparatus send the Registration Request when no protocol data unit (PDU) Session has been established with the S-NSSAI within a given amount of time and the amount of time is indicated in the policy.
11. The apparatus of claim 1, wherein the policy user equipment route selection policy £URSP} rule.
12. An apparatus comprising: a processor; and memory coupled with the processor, the memory comprising executable instructions stored thereon that when executed by the processor cause the processor to effectuate operations comprising: sending a policy to a user equipment, wherein the policy is used by the user equipment to determine a requested network slice selection assistance information (NSSAI); and based on the policy, receiving a registration request, wherein the registration request comprises the requested NSSAI.
13. The apparatus of claim 12, wherein the requested NSSAI comprises a single -NSSAI (S- NSSAI).
- 89 -
4871-1319-0402.1
14. The apparatus of claim 12, wherein the policy indicates that the user equipment include a single -NSSAI (S-NSSAI) value in the requested NSSAI when a type of the registration request is an initial registration and the S-NSSAI value is indicated in the policy.
15. The apparatus of claim 1, wherein the policy indicates that the apparatus include a single -NSSAI (S-NSSAI) value in the requested NSSAI when the apparatus enters anew registration area and the S-NSSAI value is indicated in the policy.
16. The apparatus of claim 1, wherein the policy indicates that the apparatus excludes a single -NSSAI (S-NSSAI) value from the requested NSSAI and when the S-NSSAI value is part of the allowed NSSAI of the apparatus.
17. The apparatus of claim 1, wherein the policy indicates that the apparatus send the registration request in a time period and the time period is indicated in the policy.
18. The apparatus of claim 1, wherein the policy indicates that the apparatus send the registration request when the apparatus is in a location and the location is indicated in the policy.
19. An apparatus that performs wireless communication comprising: a processor; and memory coupled with the processor, the memory comprising executable instructions stored thereon that when executed by the processor cause the processor to effectuate operations comprising: receiving an allowed network slice selection assistance information (NSSAI) from a network, the allowed NSSAI includes a single -NSSAI (S-NSSAI); receiving a policy from the network; using the policy to determine: to send a protocol data unit (PDU) session establishment request to a network slice that is associated with the S-NSSAI after receiving the allowed NSSAI on a condition that the allowed NSSAI includes the S-NSSAI;
- 90 -
4871-1319-0402.1 to send a PDU session establishment request to a network slice that is associated with the S-NSSAI when the apparatus is in a location on a condition that the allowed NSSAI includes the S-NSSAI; or to send a PDU session release request to a network slice that is associated with the S-NSSAI after a condition is met.
20. The apparatus of claim 19, wherein the condition that is met includes that no data has been sent on the PDU Session for a time period and the policy indicates the time period.
- 91 -
4871-1319-0402.1
PCT/US2021/058169 2020-11-05 2021-11-05 Network controlled ue behavior for slice access WO2022098942A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202063110197P 2020-11-05 2020-11-05
US63/110,197 2020-11-05
US202163185619P 2021-05-07 2021-05-07
US63/185,619 2021-05-07

Publications (1)

Publication Number Publication Date
WO2022098942A1 true WO2022098942A1 (en) 2022-05-12

Family

ID=78725743

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2021/058169 WO2022098942A1 (en) 2020-11-05 2021-11-05 Network controlled ue behavior for slice access

Country Status (1)

Country Link
WO (1) WO2022098942A1 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116528272A (en) * 2023-06-29 2023-08-01 中国电信股份有限公司 Non-land service network slice creation method, communication system and related equipment
WO2024017023A1 (en) * 2022-07-21 2024-01-25 维沃移动通信有限公司 Method for acquiring allowed nssai, and terminal and network-side device
WO2024028831A1 (en) * 2022-08-05 2024-02-08 Lenovo (Singapore) Pte. Ltd. Exchanging a network slice initiated by an access and mobility management function
WO2024026773A1 (en) * 2022-08-04 2024-02-08 Huawei Technologies Co., Ltd. Improving network slice resource efficiency

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200120721A1 (en) * 2018-10-11 2020-04-16 Verizon Patent And Licensing Inc. Method and system for network slice identification and selection

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200120721A1 (en) * 2018-10-11 2020-04-16 Verizon Patent And Licensing Inc. Method and system for network slice identification and selection

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
3GPP TR 38.832
CHINA TELECOM: "Clarification the NSSAI from the URSP which not in the allowed NSSAI or configured NSSAI can be included into the requested NSSAI when Registration procedure", vol. CT WG1, no. Electronic meeting; 20201015 - 20201023, 7 October 2020 (2020-10-07), XP051950693, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_126e/Docs/C1-205937.zip C1-205937 Clarification the NSSAI from the URSP which not in the allowed NSSAI or configured NSSAI can be included into the requested NSSAI when Registration procedure.doc> [retrieved on 20201007] *
ORANGE ET AL: "Condition for the UE to provide a Requested NSSAI", vol. SA WG2, no. Reno, Nevada, United States; 20191118 - 20191122, 3 December 2019 (2019-12-03), XP051835052, Retrieved from the Internet <URL:https://ftp.3gpp.org/3guInternal/3GPP_Ultimate_CRPacks/SP-191074.zip 23501_CR1687r1_(Rel-16)_S2-1910901 23501 Requested mirror.docx> [retrieved on 20191203] *
SHARP: "Proposal of solution for Key issue X found in C1-206198", vol. CT WG1, no. Electronic meeting; 20201015 - 20201023, 22 October 2020 (2020-10-22), XP051940995, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ct/WG1_mm-cc-sm_ex-CN1/TSGC1_126e/Docs/C1-206530.zip C1-206530.doc> [retrieved on 20201022] *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024017023A1 (en) * 2022-07-21 2024-01-25 维沃移动通信有限公司 Method for acquiring allowed nssai, and terminal and network-side device
WO2024026773A1 (en) * 2022-08-04 2024-02-08 Huawei Technologies Co., Ltd. Improving network slice resource efficiency
WO2024028831A1 (en) * 2022-08-05 2024-02-08 Lenovo (Singapore) Pte. Ltd. Exchanging a network slice initiated by an access and mobility management function
CN116528272A (en) * 2023-06-29 2023-08-01 中国电信股份有限公司 Non-land service network slice creation method, communication system and related equipment
CN116528272B (en) * 2023-06-29 2023-10-10 中国电信股份有限公司 Non-land service network slice creation method, communication system and related equipment

Similar Documents

Publication Publication Date Title
US20220159605A1 (en) Dynamic network capability configuration
US20210168584A1 (en) Methods of managing connections to a local area data network (ladn) in a 5g network
US20240121709A1 (en) Server in internet-of-things communication path
EP3926930A1 (en) Network service exposure for service and session continuity
US20220210698A1 (en) Electronic device and methods for performing data aggregation in a 5g user equipment
WO2022098942A1 (en) Network controlled ue behavior for slice access
US20230026316A1 (en) Paging remote ue using a relay
JP2023549722A (en) Adaptive traffic steering communication
US20230345310A1 (en) Methods of delivery mode switch for multicast and broadcast service in a 5g network
US20240007925A1 (en) Enhancement to redundant transmission in 5g network
US20210258275A1 (en) Low latency messaging service for the 5gc
US20240137855A1 (en) Enhancements for edge network access for a ue
US20240163966A1 (en) Method of configuring pc5 drx operation in 5g network
US20240172175A1 (en) Method and appartuses for group paging for signal efficiency in 5g network
US20240171968A1 (en) Reduced capacity ues and 5th generation core network interactions
AU2022381190A1 (en) Preservation of session context in a communications network
WO2023049744A1 (en) Architecture enhancements for network slicing
EP4292258A1 (en) Enhancements for edge network access for a ue
TW202329719A (en) Application interaction for network slicing
WO2022212749A9 (en) Dynamic user plane management
WO2023039409A1 (en) Support of end-to-end edge application service continuity
CN118104313A (en) Architecture enhancements for network slicing
CN116982303A (en) Enhancement of edge network access for UEs
CN118120295A (en) Application interactions for network slicing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21811699

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21811699

Country of ref document: EP

Kind code of ref document: A1