Application interaction for network slicing

Abstract

To provide methods, apparatus, and systems for improved application interaction for network slicing.SOLUTION: A wireless transmit / receive unit (WTRU) may send, to a network node, a registration request including an indication that the WTRU is capable of receiving information associated with a temporal availability of a network slice, receive a registration response including the information associated with the temporal availability of the network slice, and determine, based on the temporal availability of the network slice, whether to use a protocol data unit (PDU) session associated with the network slice.SELECTED DRAWING: Figure 11

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 245,656, entitled "APPLICATION INTERACTION FOR NETWORK SLICING," filed September 17, 2021, the contents of which are incorporated herein by reference in their entirety. [Background technology]

[0002] The 3rd Generation Partnership Project (3GPP®) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA® (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on standardizing the next generation of cellular technology, called New Radio (NR), also known as "5G."

[0003] By utilizing 5G network slicing, multiple (e.g., virtualized, independent) networks can be created on top of a common physical infrastructure. Each "slice" or portion of the network can be allocated based on the specific needs of an application, use case, or customer. Operators can allocate resources to each slice with the speed, throughput, and latency required to cover the breadth of network slicing in 5G. Despite the many technical benefits associated with network slicing, many challenges remain for operators and developers. For example, current standards do not address per-application authentication and authorization to access network slices.

[0004] Application interactions for network slicing in 5G networks can encompass a wide variety of scenarios, servers, gateways, and devices, as detailed in [1] 3 GPP TS 23.501, System Architecture for the 5G System, Stage 2, V17.1.1, Release 17, (2021-06), [2] 3GPP TS 23.502, Procedures for the 5G System, Stage 2, V17.1.0, Release 17, (2021-06), [3] GSMA NG.116 Generic Slice Template, Version 1.0, 23 May 2019, [4] 3 GPP TS 38.101-1 User Equipment (UE) radio transmission and reception, Part 1: Range 1, Standalone, V16.1.0 (2019-09), [5] 3 GPP TS This is described in [6] 3GPP TS 23.503 Policy and Charging Control Framework for the 5G system (5GS), Stage 2 (Release 16), [7] TS 23.122 Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode V16.4.0 (2019-12), and [8] 3GPP TS 24.501, Non-Access-Stratum (NAS) protocol for 5G System (5GS), Stage 3 (V16.3.0). Summary of the Invention

[0005] Described herein are methods, apparatus, and systems for application interworking for network slicing, where per-application authentication and authorization (PAAA) may be performed for a UE to access a network slice and a data network.

[0006] 5GS may be extended to enable both the core network and the UE to behave efficiently when no authorized network slice is available at a given location. An extended S-NSSAI with a PAAA indicator may be configured in the core network, and a mechanism is provided for delivering such an S-NSSAI to the UE. The PDU session establishment procedure may be extended to perform per-application authentication and authorization for network slices that require PAAA. A PAAA mechanism may be provided in which the UE receives information for the application function (AF) through which an authenticated / authorized application may send / receive application traffic using the established PDU session. A mechanism may be provided in which an unauthorized second application is restricted from using the PDU session for traffic from the first application.

[0007] According to some aspects, a mechanism may be provided whereby a PDU session established by a first application may be modified and utilized by a second application after the second application has successfully completed per-application authentication and authorization.

[0008] According to some aspects, an enhanced URSP with an NS SA flag may be provided that, upon evaluation, indicates to the UE whether the S-NSSAI selected using the NSSP requires a PAAA.

[0009] According to some aspects, a mechanism is provided that may enable a core network to utilize the integrated temporal and spatial information to proactively redirect a UE to a TA and frequency band for which an associated network slice is authorized for the UE. A mechanism is provided that allows a UE to utilize the integrated temporal and spatial information so that the UE can change its direction and maintain an appropriate speed or decide to follow a route towards a TA with a high probability of finding an authorized network slice.

[0010] According to certain aspects, mechanisms are provided that allow a UE to utilize the integrated temporal and spatial information to gracefully preserve application states (e.g., idle, connected, active, inactive, etc.) and / or disable them, preserve PDU session states (e.g., idle, connected, active, inactive, etc.), buffer uplink data, and / or take one or more power saving actions such as reduced cell search, sleep, etc.

[0011] According to certain aspects, a mechanism is provided whereby a UE registration procedure, a UE registration update procedure, and / or a UE configuration update procedure may be extended to convey temporal and spatial information to the UE.

[0012] According to some aspects, a mechanism is provided whereby a UE may utilize a unique identifier for enhanced privileges to access a network slice where the network slice is not available to a common UE.

[0013] According to some aspects, a Wireless Transmit / Receive Unit (WTRU) may include one or more processors and a memory that stores instructions that, when executed by the one or more processors, cause the WTRU to perform one or more operations.

[0014] According to some aspects, the WTRU may send a registration request to a network node. For example, the network node may be an Access and Mobility Management Function (AMF). The registration request may include an indication that the WTRU is capable of receiving information associated with the temporal availability of a network slice. For example, the information associated with the temporal availability of a network slice may include a time period during which the slice is or is not available to the WTRU. According to some aspects, a slice remapping procedure may be performed based on the temporal availability of the network slice.

[0015] According to some aspects, the WTRU may receive a registration response. The registration response may comprise information associated with the temporal availability of a network slice. The WTRU may decide to stop using a Protocol Data Unit (PDU) session associated with the network slice (e.g., based on the temporal availability of the network slice). According to some aspects, the WTRU may store (e.g., idle, connected, active, inactive, etc.) the PDU session. According to some aspects, uplink data associated with the PDU session may be buffered or transmitted after a delay (e.g., based on the temporal availability of the network slice).

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

[0017] A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings, in which: [Figure 1] 1 illustrates an exemplary 5G system service-based architecture. [Figure 2] 1 illustrates an exemplary non-roaming 5G system architecture in a reference point representation. [Figure 3] 1 illustrates an exemplary network slice-specific authentication and authorization procedure. [Figure 4] An exemplary method for PDU session establishment authentication / authorization by a DN-AAA server is shown. [Figure 5] 1 illustrates an exemplary method for a UE application to establish a PDU session using a network slice. [Figure 6] 10 illustrates an example connected car that does not have access to a licensed slice in a new location. [Figure 7] 10 illustrates an exemplary UE receiving an authorized NS SAI with a PAAA indicator upon registration. [Figure 8] 1 illustrates an exemplary method for per-application authentication and authorization. [Figure 9] 10 illustrates an exemplary PAAA request with PDU session modification. [Figure 10] 1 illustrates an exemplary method for an extended URSP to guide a UE for PAAA. [Figure 11] 1 illustrates an example method for conveying temporal and spatial information to a UE during UE registration. [Figure 12] 1 illustrates an exemplary UE configuration update procedure for conveying spatial and temporal information to a UE. [Figure 13] An example of a method for accessing an alternative network slice with special authorization is shown. [Figure 14] 1 illustrates an exemplary UE UI showing installed applications and various advanced features. [Figure 15A] 1 illustrates an exemplary communication system. [Figure 15B] FIG. 1 is a system diagram of an example RAN and core network. [Figure 15C] FIG. 1 is a system diagram of an example RAN and core network. [Figure 15D] FIG. 1 is a system diagram of an example RAN and core network. [Figure 15E] 2 illustrates another exemplary communication system. [Figure 15F] 1 is a block diagram of an example apparatus or device such as a WTRU. [Figure 15G] FIG. 1 is a block diagram of an exemplary computing system. DETAILED DESCRIPTION OF THE INVENTION

[0018] Table 0.1 lists some of the abbreviations used herein.

[0019] [Table 1-1]

[0020] [Table 1-2]

[0021] Terms and Definitions. Below is a list of terms that may appear in the description that follows: Unless otherwise specified, the terms used herein are defined as follows:

[0022] Network slice - A logical network that provides specific network capabilities and characteristics.

[0023] Network slice instance - a set of NF instances and the necessary resources (e.g., computational resources, storage resources, and network resources) that form a deployed network slice.

[0024] Service Area Restriction - A service area restriction can include one or more (e.g., up to 16) entire tracking areas, and each service area restriction can be set as unlimited (e.g., including all tracking areas of a PLMN). The UE's subscription data in the UDM includes a service area restriction that can include either authorized or unauthorized areas specified by using explicit tracking area identification and / or other geographic information (e.g., longitude / latitude, zip code, etc.).

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

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

[0027] NF instance − An identifiable instance of an NF.

[0028] According to some aspects, FIG. 1 illustrates a non-roaming reference architecture with a service-based interface in the control plane.

[0029] According to some aspects, FIG. 2 illustrates a 5G system architecture for a non-roaming scenario using a reference point representation that shows how various network functions interact with each other.

[0030] According to some aspects, mobility management functions and session management functions are separated. A single N1 NAS connection can be used for both registration management and connection management, as well as for UE messages and procedures related to Session Management (SM). The single N1 termination point can be located within the AMF. The AMF can forward SM-related NAS information to the SMF. The AMF can handle the registration management and connection management portions of NAS signaling exchanged with the UE. The SMF handles the SM portion of NAS signaling exchanged with the UE.

[0031] According to some aspects, a 5G system architecture is defined to support data connectivity and services that enable deployments to use techniques such as network function virtualization and software-defined networking. According to some aspects, the 5G system architecture enables leveraging service-based interactions between Control Plane (CP) Network Functions (NFs), when identified.

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

[0033] The network slice is identified by S-NSSAI, which is (1) Slice / Service Type (SST), which may refer to the expected network slice behavior in terms of features and services; and (2) It can be composed of a slice differentiator (SD), which is optional information that supplements the SST to distinguish between multiple network slices of the same SST.

[0034] According to some aspects, the S-NSSAI can have a standard value (e.g., the S-NSSAI consists only of SST with a standardized SST value and does not include SD) or a non-standard value (e.g., the S-NSSAI consists either of both SST and SD, or of only SST without a standardized SST value and does not include SD). An S-NSSAI with a non-standard value can identify a single network slice within the PLMN with which it is associated. An S-NSSAI with a non-standard value may not be used by the UE in access stratum procedures for any PLMN other than the PLMN with which the S-NSSAI is associated. Table 1 shows standardized SST values.

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

[0036] According to some aspects, based on the operational or deployment needs of an operator, a network slice instance can be associated with one or more S-NSSAIs, and an S-NSSAI can be associated with one or more network slice instances. Multiple network slice instances associated with the same S-NSSAI can be deployed in the same or different Tracking Areas (TAs). When multiple network slice instances associated with the same S-NSSAI are deployed in the same TA, the AMF instance serving the UE may logically belong to (e.g., be common to) two or more network slice instances associated with this S-NSSAI.

[0037] According to some aspects, based on the requested NS SAI (if any) and subscription information, the 5GC is responsible for selecting a network slice instance to serve the UE, including the 5GC control plane and user plane network functions corresponding to this network slice instance.

[0038] According to some aspects, the (R)AN may use the requested NSSAI in access stratum signaling to address the UE CP connection before 5GC notifies the (R)AN of the allowed NSSAI. The requested NSSAI may be used by the RAN for AMF selection, as described in TS 23.501 [1], Section 6.3.5. When the UE requests to resume the RRC connection and is in the CM-CONNECTED RRC inactive state, the UE may not include the requested NSSAI in the RRC resume.

[0039] According to some aspects, once the UE has successfully registered with an access type, the CN may notify the (R)AN by providing the allowed NSSAI for the corresponding access type.

[0040] According to some aspects, standardized SST values ​​provide a way for slicing to establish global interoperability so that PLMNs can more efficiently support roaming use cases for the most commonly used SSTs. For example, the standardized SSTs are in Table 1 below.

[0041] [Table 2]

[0042] A configured NSSAI is an NSSAI provisioned to a UE that is applicable to one or more PLMNs. A configured NSSAI may be configured by and apply to a serving PLMN. According to some aspects, there may be at most one configured NSSAI per PLMN.

[0043] According to some aspects, a default configured NSSAI may be configured by the HPLMN and may apply to any PLMN for which, for example, a specific configured NSSAI has not been provided to the UE. The value used in the default configured NSSAI may be expected to be commonly determined by all roaming partners. When configured in the UE, the default configured NSSAI may be used by the UE in the serving PLMN only if the UE does not have a configured NSSAI for the serving PLMN. The UE may be pre-configured with the default configured NSSAI.

[0044] According to some aspects, the requested NSSAI may be an NSSAI provided by the UE to the serving PLMN during registration. The S-NSSAI in the requested NSSAI may be part of the configured and / or authorized NSSAIs applicable to this PLMN, for example, when they are available. If the configured NSSAI and authorized NSSAI for the PLMN are not available, the S-NSSAI in the requested NSSAI is selected from the default configured NSSAI, if it is configured in the UE.

[0045] According to some aspects, the requested NSSAI signaled by the UE to the network enables the network to select a serving AMF, network slice, and network slice instance for this UE. Based on the requested NSSAI (if any) and subscription information, the 5GC is responsible for selecting a network slice instance to serve the UE, including the 5GC control plane and user plane network functions corresponding to this network slice instance. The (R)AN may use the requested NSSAI in access stratum signaling to address the UE control plane connection before the 5GC notifies the (R)AN of the allowed NSSAI.

[0046] According to some aspects, the allowed NSSAI may be an NSSAI provided by the serving PLMN, for example, during the registration procedure, and indicates the S-NSSAI value that the UE may use in the serving PLMN of the current registration area. Upon successful completion of the UE registration procedure across an access type, the UE may obtain from the AMF one or more S-NSSAIs and, if necessary (see, for example, Section 5.15.4.1.2), the allowed NSSAIs for this access type, including the mapping of the S-NSSAI to the HPLMN S-NSSAI. These S-NSSAIs may be valid for the current registration area and access type provided by the AMF to which the UE registered and may be used simultaneously by the UE (e.g., up to a maximum number of simultaneous network slice instances or PDU sessions).

[0047] According to some aspects, the mapping of allowed NSSAIs may be a mapping of each S-NSSAI of the allowed NSSAIs for the serving PLMN to an HPLMN S-NSSAI.

[0048] The mapping of configured NSSAIs may be a mapping of each S-NSSAI of the configured NSSAIs for the serving PLMN to an HPLMN S-NSSAI.

[0049] According to some aspects, a network slice may be defined as a logical network that provides specific network capabilities and network characteristics. A network slice in a PLMN may include a core network control plane and a user plane network function. According to some aspects, a network slice instance is a set of NF instances and the necessary resources (e.g., computational resources, storage resources, and network resources) that form a deployed network slice.

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

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

[0052] According to some aspects, a network slice-specific authentication and authorization procedure may be triggered for an S-NSSAI requiring network slice-specific authentication and authorization with an AAA server (AAA-S), which may be hosted by the H-PLMN operator or by a third party having a business relationship with the H-PLMN, using an EAP framework. For example, if the AAA server belongs to a third party, an AAA proxy (AAA-P) in the HPLMN may be involved.

[0053] According to some aspects, this procedure may be triggered by the AMF during the registration procedure when some network slices require slice-specific authentication and authorization, when the AMF determines that network slice-specific authentication and authorization is required for an S-NSSAI in the current allowed NSSAI (e.g., a subscription change), or when the AAA server that authenticated the network slice triggers re-authentication.

[0054] According to some aspects, the AMF can act as an EAP authenticator and communicate with the AAA-S via a Network Slice Specific and SNPN Authentication and Authorization Function (NSSAAF), which can undertake any AAA protocol that interworks with the AAA protocol supported by the AAA-S.

[0055] According to some aspects, network slice-specific authentication and authorization procedures may require the use of a GPSI. For example, a subscription including an S-NSSAI that is subject to network slice-specific authentication and authorization may include at least one GPSI. According to some aspects, Figure 3 illustrates a call flow diagram of an NSSAA procedure (e.g., Section 4.2.9.2 of TS 23.502 [2]).

[0056] According to some aspects, PDU session establishment authentication / authorization may be optionally triggered by the SMF during PDU session establishment and may be performed transparently via the UPF or directly with the DN-AAA server without involving the UPF if the DN-AAA server is located within the 5GC and directly reachable (e.g., Section 5.6.6 of TS 23.501 [1]).

[0057] According to some aspects, in the case of Home Routed Roaming, unless otherwise specified, the SMF in the information flows defined in this section is the H-SMF. In the case of Home Routed Roaming, unless otherwise specified, the SMF in the information flows defined in this section is the H-SMF.

[0058] According to some aspects, steps 2, 3a, 3f, and 4 of FIG. 4 may be undefined. Step 3 may be repeated depending on the mechanism used. According to some aspects, when the SMF communicates directly with the DN-AAA server without involving the UPF, step 1 may be skipped and steps 2, 3a, 3f, 4, and 6 may be performed without involving the UPF. According to some aspects, the SMF may determine that it needs to contact the DN-AAA server. The SMF may identify the DN-AAA server based on local configuration or using a DN-specific identity (e.g., TS 33.501) provided by the UE in the SM PDU DN Request Container provided by the UE in the PDU Session Establishment Request or in the EAP message in the PDU Session Authentication Complete message (e.g., TS 24.501).

[0059] According to some aspects, the contents of the SM PDU DN Request Container are defined in TS 24.501. If there is no existing N4 session that can be used to transport DN-related messages between the SMF and the DN, the SMF may select a UPF and trigger an N4 session establishment.

[0060] According to some aspects, the SMF may initiate an authentication procedure with the DN-AAA via the UPF to authenticate the DN-specific identity provided by the UE (e.g., as specified in TS 29.561). If available, the SMF may provide GPSI in signaling exchanged with the DN-AAA. The UPF may transparently relay messages received from the SMF to the DN-AAA server.

[0061] The steps for PDU session establishment authentication / authorization by the DN-AAA server can be described as follows:

[0062] Step 3a: The DN-AAA server may send an authentication / authorization message to the SMF. The message may be carried via the UPF.

[0063] Step 3b: The DN request container information received from the DN-AAA may be forwarded toward the UE. According to some aspects, in the case of non-roaming and LBO, the SMF may invoke a Namf_Communication_NlN2MessageTransfer service operation on the AMF to forward the DN request container information within the N1 SM information sent toward the UE. According to some aspects, in the case of Home Routed roaming, the H-SMF may initiate a Nsmf_PDUSession_Update service operation to request the V-SMF to forward the DN request container to the UE, and the V-SMF may invoke a Namf_Communication_NlN2MessageTransfer service operation on the AMF to forward the DN request container information within the N1 SM information sent toward the UE. In the Nsmf_PDUSession_Update Request, the H-SMF may further include an H-SMF SM Context ID.

[0064] Step 3c: The AMF may send an N1 NAS message to the UE.

[0065] Steps 3d-3e: The DN Request Container information received from the UE may be forwarded towards the DN-AAA. According to some aspects, when the UE responds with an N1 NAS message including the DN Request Container information, the AMF may notify the SMF by invoking the Nsmf_PDUSession_UpdateSMContext service operation. The SMF may issue an Nsmf_PDUSession_UpdateSMContext response. In the case of Home Routed roaming, the V-SMF may relay the N1 SM information to the H-SMF using the information of the PDU session received in step 3b via the Nsmf_PDUSession_Update service operation.

[0066] Step 3f: The SMF (e.g., in the case of HR, it is the H-SMF) can send the contents of the DN Request Container Information (e.g., an authentication message) to the DN-AAA server via the UPF. According to some aspects, step 3 can be repeated until the DN-AAA server confirms successful authentication / authorization of the PDU session.

[0067] Step 4: The DN-AAA server can confirm successful authentication / authorization of the PDU session. According to some aspects, the DN-AAA server can provide (1) an SM PDU DN response container to the SMF to indicate successful authentication / authorization, (2) DN authorization data (e.g., as defined in section 5.6.6 of TS 23.501 [1]), (3) an IP address assigned to the PDU session and / or a request signaled with N6 traffic routing information or a MAC address used by the UE for the PDU session, and / or (4) an IP address (or IPV6 prefix) for the PDU session.

[0068] According to some aspects, N6 traffic routing information is defined in section 5.6.7 of TS 23.501 [1].

[0069] According to some aspects, after successful DN authentication / authorization, a session may be maintained between the SMF and the DN-AAA. When the SMF receives the DN authorization data, the SMF may use the DN authorization profile index to apply policy and charging controls (e.g., section 5.6.6 of TS 23.501 [1]).

[0070] Step 5: The PDU session establishment can continue and be completed. For example, in step 7b of Figure 4.3.2.2.1-1 of TS 23.503 [2], if the SMF receives a DN authorization profile index in the DN authorization data from the DN-AAA, the SMF may send the DN authorization profile index to retrieve PDU session-related policy information (e.g., Section 6.4 of TS 23.502

[20] ) and PCC rules (e.g., Section 6.3 of TS 23.503 [6]) from the PCF. According to some aspects, if the SMF receives a DN authorized session AMBR in the DN authorization data from the DN-AAA, the SMF may send the DN authorized session AMBR in the session AMBR to the PCF to retrieve the authorized session AMBR (e.g., Section 6.4 of TS 23.503 [6]). In case of Ethernet type PDU sessions, the SMF can instruct the UPF to process the VLAN information of Ethernet frames related to the PDU session received and transmitted on N6 or N19 or internal interfaces (e.g., clause 5.6.10.2 of TS 23.501 [1]).

[0071] Step 6: If so required in step 4 or if so configured by local policy, the SMF may notify the DN-AAA of the IP / MAC addresses and / or N6 traffic routing information allocated to the PDU session together with the GPSI.

[0072] According to some aspects, a service area restriction can include one or more (e.g., up to 16) entire tracking areas, and each service area restriction or service area restrictions can be configured as unlimited (e.g., including all tracking areas of a PLMN). The UE's subscription data in the UDM can include a service area restriction, which can include either an allowed area or a non-allowed area specified by using an explicit tracking area identity and / or other geographic information (e.g., longitude / latitude, zip code, etc.). According to some aspects, the geographic information used to specify the allowed or non-allowed area is solely managed within the network, and the network can map it to a list of TAs before sending the service area restriction information to the PCF, the NG-RAN, and the UE.

[0073] According to some aspects, when the AMF assigns a restricted authorized area to a UE, the AMF may provide the UE with a service area restriction consisting of either an authorized area or a non-authorized area. The authorized areas included in the service area restriction may be pre-configured and / or dynamically assigned by the AMF.

[0074] According to some aspects, the allowed area may alternatively be configured as unrestricted, for example, the allowed area may include all tracking areas of a PLMN. The registration area of ​​a UE in a non-allowed area may consist of a set of TAs belonging to the non-allowed area of ​​the UE. The registration area of ​​a UE in an allowed area may consist of a set of TAs belonging to the allowed area of ​​the UE. The AMF may provide the UE with service area restrictions in the form of TA(s) during the registration procedure, which may be a subset of the complete list stored in the UE's subscription data or provided by the PCF.

[0075] According to some aspects, the NG-RAN may prefer to use specific radio resources for each data radio bearer(s), for example, depending on the network slice associated with the data radio bearer used by the UE. When the UE idle mode mobility control and priority-based reselection mechanism operates (e.g., section 5.3.4.3.1 of TS 23.501) and UP resources are activated (e.g., for a particular S-NSSAI), the NG-RAN may use a local policy to determine which specific radio resources to use for the associated data radio bearer. The UE may be served by a set of data radio bearers that may be served by cells in different bands, selected based on the RRM policy.

[0076] According to some aspects, if a network slice is configured to be available only in a TA covering a specific dedicated frequency band, when such an S-NSSAI is requested, the UE may need to be redirected to the dedicated frequency band. If the requested NSSAI includes an S-NSSAI that is not available in the UE's current TA, the AMF itself or by interacting with the NSSF, may determine a target NSSAI to be used by the NG-RAN and attempt to redirect the UE to a cell and TA in another band and TA that supports the S-NSSAI in the target NSSAI. The target NSSAI may include at least one S-NSSAI from the requested NSSAI that is not available in the current TA but is available in another TA in a different frequency band. The target NSSAI may include only S-NSSAIs that may be given in the allowed NSSAIs for the UE.

[0077] According to some aspects, if a network slice is configured to be available only in a TA covering a specific dedicated frequency band, when such an S-NSSAI is requested, the UE may need to be redirected to the dedicated frequency band. If the requested NSSAI includes an S-NSSAI that is not available in the UE's current TA, the AMF itself or by interacting with the NSSF, may determine a target NSSAI to be used by the NG-RAN and attempt to redirect the UE to a cell and TA in another band and TA that supports the S-NSSAI in the target NSSAI. The target NSSAI may include at least one S-NSSAI from the requested NSSAI that is not available in the current TA but is available in another TA in a different frequency band. The target NSSAI may include only S-NSSAIs that may be given in the allowed NSSAIs for the UE.

[0078] According to some aspects, the NG-RAN may attempt to find a cell of the TA that can support all S-NSSAIs in the target S-NSSAI, and if such a cell of the TA is not available, the RAN may attempt to select a cell of the TA that best matches the target S-NSSAI. The NG-RAN may attempt to ensure continuity of PDU sessions with activated user planes associated with S-NSSAIs in the authorized NSSAIs that are also in the target NSSAI. The NG-RAN may also attempt to ensure service continuity for S-NSSAIs of authorized NSSAIs that are also available in the target NSSAI before prioritizing cells that do not support one or more S-NSSAIs of authorized NSSAIs that are also available in the target NSSAI.

[0079] According to some aspects, once the target cell is determined, the NG-RAN can initiate an RRC redirection procedure towards the target cell, if possible.

[0080] According to some aspects, a UE Route Selection Policy (URSP) may include a prioritized list of URSP rules [6]. For example, Table 2 shows a URSP. Further, exemplary structures of URSP rules are described in Tables 3 and 4.

[0081] [Table 3]

[0082] The structure of the URSP rules is set out in Tables 3 and 4 below.

[0083] [Table 4]

[0084] [Table 5]

[0085] According to some aspects, a UE, such as a smartphone, may obtain UE applications from one or more third parties that may also provide services to the UE. The UE can establish multiple PDU sessions with the core network at one time. PDU sessions are typically triggered by an application in the UE. For example, when an application is initiated, the application may wish to access a service from an application server in the data network. As shown in FIG. 5, application App1 can establish a PDU session with a URLLC network slice, represented by a solid line in the figure. The PDU session may be established based on a URSP rule. If the URSP rule for App3 also indicates the same S-NSSAI (e.g., URLLC slice) as its preferred slice in the PLMN, the UE may use the existing PDU session previously established by App1. There may be another application, e.g., App5, that may have triggered the UE to establish a separate PDU session with a different network slice according to the URSP rule.

[0086] According to some aspects, a mobile UE, such as a connected car, may have established PDU sessions with one or more network slices in a core network. As the UE moves, it may traverse new locations (e.g., TA / RA) where the UE may lose access and may not have access to any authorized network slices. As shown in Figure 6, a vehicle UE (CC1) at location A that was accessing a gaming slice cannot access any slices at location B.

[0087] According to some aspects, URSP rules in the UE can guide an application in the UE to use a PDU session that may have been established by another (e.g., first) application, as shown in Figure 5. The second application may belong to a different third party and therefore may need to be authorized before using the network slice. The current 5GS specification does not define how 5GS performs per-application authentication and authorization to access a network slice or DN.

[0088] According to some aspects, a UE may have had an ongoing PDU session with one or more network slices. When the UE moves to a new location (e.g., TA, RA, etc.), the UE may not have access to any authorized network slices in the new location. Current 5GS does not describe how the UE may handle such a scenario so that the UE may notify UE applications that a slice may become unavailable and that the applications may gracefully terminate or preserve their state (e.g., idle, connected, active, inactive, etc.). Additionally, 5GS does not describe how the UE may save power by reducing undesired application activity in the UE in such a scenario.

[0089] According to some aspects, when a UE application starts, it may trigger the UE to establish a PDU session with the network. The PDU session may involve accessing a data network via a network slice. Each UE application may be installed on the UE for a different service (e.g., gaming, video, IoT control, etc.) provided by various third parties and may therefore require different levels of resources for performance, privacy, etc. The data network and / or network slice may require authorization of the application before using the slice to receive services via the application function. Therefore, a 5G system may require a Per-Application Authentication and Authorization (PAAA) procedure. These following sections describe methods for PAAA.

[0090] According to some aspects, a network slice may need to be marked with an indicator for a UE application to identify that the network slice is subject to per-application authentication and authorization. The MNO can mark the network slice with a PAAA indicator according to PAAA during network slice configuration. The UE may have received an S-NSSAI with a PAAA indicator as part of the allowed NSSAI after successful UE registration. Alternatively, the PAAA indicator may be sent to the UE along with the configured NSSAI.

[0091] When an application triggers a PDU session, the UE can identify that the selected network slice is subject to PAAA based on the PAAA indicator. According to some aspects, FIG. 7 illustrates an enhanced UE registration procedure when the PAAA indicator is conveyed to the UE.

[0092] In step 0, each S-NSSAI according to PAAA may be associated with a Per-Application Authentication and Authorization (PAAA) indicator within the UE's UE Access and Mobility Subscription in the UDM / UDR. According to some aspects, PAAA requirements for slice access may depend on factors such as the MNO's agreements with third parties regarding services, security requirements, local policies, etc.

[0093] According to some aspects, PAAA information associated with a slice may be an indication of whether the slice requires PAAA from the UE. The PAAA information may be implemented as a flag that is either Set or Not Set to the UE. A Set flag may indicate that the slice is subject to PAAA, and a Not Set flag may indicate that PAAA is not required to access the slice from the UE.

[0094] In step 1, the UE may send a registration request to the AMF via the RAN (e.g., step 1 of section 4.2.2.2.2 of TS 23.502). In this request, the UE may also indicate its support for PAAA.

[0095] According to some aspects, the request may include a requested NSSAI. In the case of an initial registration or mobility registration update, the UE may include a requested NSSAI mapping (if available), which may be a mapping of each S-NSSAI of the requested NSSAI to an HPLMN S-NSSAI to ensure that the network can verify whether the S-NSSAIs in the requested NSSAI are allowed based on the subscribed S-NSSAIs.

[0096] In step 2, the RAN can select an AMF (e.g., TS 23.501 [1], section 6.3.5).

[0097] In step 3, the registration request may be forwarded to the selected AMF.

[0098] In step 4, if the AMF does not have subscription data for the UE, the AMF can use Nudm_SDM_Get to retrieve access and mobility subscription data, SMF selection subscription data, UE context in SMF data, etc. The UE subscription information retrieved from the UDM may include a set of S-NSSAIs to which the UE is subscribed, each of which may include a PAAA indication.

[0099] In step 5, the AMF may send a registration accept message to the UE via the (R)AN node. The registration accept may include an allowed NSSAI for the UE with each S-NSSAI configured with the PAAA indicator. If the indicator is a flag and the S-NSSAI complies with the PAAA for the UE, the flag may be Set. Otherwise, the flag may be Not Set.

[0100] In addition, the AMF may also send a mapping of the allowed NSSAI to each S-NSSAI and PAAA indicator, a mapping of the configured NSSAI to each S-NSSAI and its PAAA indicator for the serving PLMN, and a mapping of the configured NSSAI to each S-NSSAI and its corresponding PAAA indicator. The (R)AN node may forward the registration accept to the UE.

[0101] Current 5G system designs only consider authentication and authorization per UE when the network slice requires NSSAA. However, each application may affect access to the application function or data network. Therefore, the application's authorization to access the network slice for the UE is combined with the application's authorization to access the application function / DN. This section describes how the core network authenticates and authorizes each application attempting to access the network slice and AF / DN. Figure 8 shows an example procedure, which is described as follows:

[0102] In step 1, a first application in the UE, e.g., App1, initiates traffic. The UE determines that a PDU session needs to be established. App1 may provide a traffic descriptor to the UE. The traffic descriptor may be an application descriptor, an IP descriptor / address, a DNN, etc. (e.g., Table 6.6.2.1-2 of TS 23.503). The UE may evaluate a URSP rule consisting of the traffic descriptor provided by App1. The RSD in the URSP rule may include an S-NSSAI. If the S-NSSAI includes a PAAA indicator as described in FIG. 3, the UE may identify that any PDU session established in that slice needs to undergo a PAAA procedure.

[0103] According to some aspects, the UE can send a PDU session establishment request to the AMF via the RAN, indicating the network slice selected based on the URSP rule. The request may also include an application descriptor. The application descriptor may be a traffic descriptor used in the URSP evaluation or an application identifier such as an OSId and an OSAppId. The UE can also include a DN-specific identifier in the SM PDU DN request container in the request. The DN-specific identifier may be associated with the application and identify an instance of the application on the UE.

[0104] The UE may optionally include a PAAA trigger indicator in the PDU session request, which may later be used to notify the SMF to trigger the PAAA process.

[0105] The application descriptor may consist of one or more IP addresses, port numbers, or MAC addresses that indicate which servers the PDU session will be used to send and receive traffic from.

[0106] The application descriptor may include a service provider ID. The network and UE may be pre-configured to associate the service provider ID with one or more IP addresses, port numbers, or MAC addresses. Thus, the service provider ID may be used by the UE to indicate to the network which server the PDU session will be used to send and receive traffic from.

[0107] The application descriptor may include one or more application identifiers that identify UE applications that will use the PDU session. The format of the application identifiers may be a 3GPP external identifier.

[0108] In step 2, the AMF may determine that the message corresponds to a request for a new PDU session with a request type indicating "initial request" and that the PDU session ID is not used for any existing PDU session of the UE. The AMF selects an SMF (e.g., section 6.3.2 of TS 23.501 [1]).

[0109] In step 3, if the AMF does not have an association with an SMF for the PDU session ID provided by the UE (for example, if the request type indicates an "initial request"), the AMF may call an Nsmf_PDUSession_CreateSMContext request, and the AMF may call an Nsmf_PDUSession_CreateSMContext request.

[0110] In step 4, the SMF can trigger the PAAA process based on a request from the UE, which includes an application descriptor and an S-NSSAI (e.g., S-NSSAI-A) that the UE wants to access, and a PAAA trigger indicator from the UE. Alternatively, the SMF can trigger the PAAA process based on a policy received from the PCF. The SMF can determine that it needs to contact a DN-AAA server for the PAAA procedure. The SMF can identify the DN-AAA server based on a local configuration, the application descriptor, or using DN-specific identity information, and sends the application descriptor along with the PAAA request to the DN-AAA server.

[0111] In step 5a, the DN-AAA server may send an authentication / authorization message addressed to the UE towards the SMF via the UPF.

[0112] In step 5b, in the case of LBO or non-roaming, the SMF can forward the DN request container information received from the DN-AAA to the UE by invoking the Namf_Communication_N1N2MessageTransfer service operation on the AMF in the N1 SM information.

[0113] In the case of home routed roaming, the H-SMF may initiate a Nsmf_PDUSession_Update service operation to request the V-SMF to transfer the DN request container to the UE, and the V-SMF invokes a Namf_Communication_N1N2MessageTransfer service operation on the AMF to transfer the DN request container information within the N1 SM information sent towards the UE.

[0114] In step 5c, the AMF may send an N1 NAS message to the UE.

[0115] In step 5d, the UE may respond to the AMF with an N1 NAS message including DN request container information.

[0116] In step 5e, the AMF may notify the SMF by invoking the Nsmf_PDUSession_UpdateSMContext service operation. The SMF may issue a Nsmf_PDUSession_UpdateSMContext response.

[0117] In the case of home routed roaming, the V-SMF can relay N1 SM information to the H-SMF using the PDU session information received via the Nsmf_PDUSession_Update service operation.

[0118] In step 5f, the SMF (or H-SMF in the case of a home router) Send the contents of the DN request container information (authentication message) to the DN-AAA server via It is possible.

[0119] According to some aspects, step 5 may be repeated until the DN-AAA obtains all necessary information from the UE and confirms successful authentication and authorization of the PDU session.

[0120] In step 6, the DN-AAA server may send a PAAA success message to the SMF. In addition to the PAAA success message, the DN-AAA server may send a set of IP addresses, port numbers, and MAC addresses of application functions (AFs), IP addresses for DNS, etc. to the SMF that the UE can access using network slicing.

[0121] According to some aspects, if App1 is not authenticated, the SMF may reject the PDU session request. However, if the application is authenticated but not authorized to access the particular AF in question, the SMF may accept the PDU session request, but in the PDU session accept message, the SMF may send a list of IP addresses (e.g., AFs) received from the DN-AAA that the UE is authorized to access using App1.

[0122] In step 7, the SMF can send an N4 Session Establishment / Modification Request to the UPF, providing packet detection, enforcement, and reporting rules to be installed on the UPF for this PDU session. The SMF can indicate to the UPF to perform IP address / prefix allocation and can include the information the UPF needs to perform the allocation. This request can include the IP address, port number, and MAC address of the AF received from the DN-AAA server. This information can be used by the UPF to determine the addresses that the PDU session can use to send / receive traffic. The UPF can acknowledge by sending an N4 Session Establishment / Modification Response. The N4 Session Establishment / Modification Request can also indicate to the UPF that all downlink traffic to the UE is allowed, but uplink traffic is only allowed for the indicated IP address, port number, and MAC address. It can be useful to allow downlink traffic to the UE so that the server can initiate contact with the UE. The UE can then be authenticated when attempting to send uplink traffic to a new destination.

[0123] In step 8, the SMF may send a PDU session establishment accept message to the AMF in an N1 SM container, which the AMF may provide to the UE. In addition, the SMF may send to the UE IP addresses, port numbers, and MAC addresses for the AFs that the UE is authorized to use the PDU session to contact (e.g., to send and receive traffic from).

[0124] The AMF can forward the PDU session establishment acceptance message and the AF IP address, port number, and MAC address to the UE via the RAN.

[0125] In step 9, a second application, App2, may generate uplink traffic. However, App2 may not be authorized to use the same slice as App1. In current 5G systems, App2 may be able to utilize the PDU session of any other application (e.g., App1) if there is a match in the URSP traffic descriptor. The following section describes how traffic from App2 may be handled when the app requires PAAA.

[0126] According to some aspects, in step 9 of Figure 8, the UE has already received, along with the PDU session establishment accept message, a set of authorized IP addresses for AFs that the UE may contact via a PDU session using a particular S-NSSAI. For example, App1 may have an ongoing PDU session via a network slice (e.g., S-NSSAI-A).

[0127] A second application (App2) traffic may be initiated. App2 may provide a traffic descriptor (e.g., OSid, DNN, IP address, etc.) to the UE. The UE may evaluate the URSP rule and determine that there is an existing PDU session destined for an S-NSSAI and DNN that matches the S-NSSAI and DNN in the URSP rule. However, the UE may find that the UE is not authorized to access the network slice because the traffic descriptor the UE is attempting to access is an AF (IP address) that is not authorized for this PDU session using the S-NSSAI (e.g., S-NSSAI-A). In other words, the IP address to which App2 is attempting to send data may not be among the authorized IP addresses received in the PDU session establishment accept message described in step 8 of FIG. 8.

[0128] Meanwhile, the UE may be authorized to access an IP address (e.g., AF) using the corresponding network slice with which the UE has established a PDU session for App1.

[0129] According to some aspects, another alternative for triggering the PAAA process is to configure the PAAA trigger indicator information in the URSP rule so that the UE can send a new PDU session request with the PAAA trigger indicator, which will trigger the PAAA procedure in the SMF. Yet another alternative is Config. The SMF or SMF that has the PAAA trigger indicator locally can obtain information or policies from another NF, such as a PCF or UDM, to trigger the PAAA procedure.

[0130] According to some aspects, the UE can use an existing PDU session rather than establishing a new PDU session. When the UE identifies, based on the authorized AF / DN IP address received from the DN-AAA server, that a second UE application is not authorized to access the network slice and the AF using an existing PDU session established by another application, it may be more efficient for the UE to send a PDU session modification command along with a PAAA request for the second application so that, if the UE successfully completes the PAAA process, the PDU session is modified and the UE can incorporate traffic originating from the second application into the PDU session. Figure 9 shows a call flow describing a method for PAAA with PDU session modification.

[0131] In step 1, the first application (App1) may have already established a PDU session towards the AF / DN using a network slice (S-NSSAI-A), as described in Figure 8.

[0132] In step 2, a second app (App2) can initiate traffic. While evaluating the URSP rules, the UE may determine that App2 should use the same PDU session already established for App1, but that App2 is not authorized to access the AF based on the authorized IP address for the AF received in step 1.

[0133] Therefore, the UE can send a PDU Session Modify NAS message towards the network. The PDU Session Modify message can include a PDU Session Modify Request, a PDU Session ID, a requested QoS, etc. Along with the PDU Session Modify message, the UE can include a new application descriptor (e.g., for App2) and a PAAA trigger indicator that indicates the need for PAAA.

[0134] In step 3, the AMF may forward the PDU Session Modify message to the SMF. Based on the request and the application descriptor and / or PAAA trigger indicator received from the UE, a Per-Application Authentication and Authorization (PAAA) procedure may be triggered in the SMF. The SMF may alternatively trigger the PAAA procedure based on information provided by another NF, such as a PCF and / or UDM.

[0135] In step 4, the SMF may send the PAAA request to the DN-AAA server.

[0136] In step 5, the DN-AAA server may determine that App2 is authorized to access the AF. The DN-AAA server may return a PAAA success message to the SMF.

[0137] In step 6, the SMF can send an N4 Session Modification Request to the UPF, providing packet detection, enforcement, and reporting rules to be installed on the UPF to match the PDU session. The SMF can instruct the UPF to perform IP address / prefix allocation and includes the information the UPF needs to perform the allocation. This can include the IP address, port number, and MAC address of the AF received from the DN-AAA server, and the UPF is authorized to establish a PDU session to send / receive traffic. The UPF can acknowledge by sending an N4 Session Establishment / Modification Response.

[0138] In step 7, the SMF can respond to the AMF via an Nsmf_PDUSession_UpdateSMContext response, which can include an N1 SM container (PDU Session Modify Command). The N1 SM container can carry the PDU Session Modify Command, which the AMF can provide to the UE. It can include the QoS rules, flow-level QoS parameters, if required for the QoS flow associated with the QoS rule, and corresponding QoS rule actions and flow-level QoS parameter actions, to notify the UE that one or more QoS rules have been added, removed, or modified. In addition, the N1 SM container can include a PAAA success message. Along with the PDU Session Modify Command sent to the UE, the SMF can include a message indicating successful authorization of application App2. In addition, the message can include an updated list of IP addresses, port numbers, and MAC addresses (e.g., AFs) authorized for the PDU session to transmit traffic using App2.

[0139] In step 8, the AMF can send a message to the N2, e.g., [N2 SM information received from the SMF], NAS message (PDU Session ID, N1 SM container (PDU Session Modify Command, PAAA Success Message, and updated list of IP addresses, port numbers, and MAC addresses (e.g., AFs) the PDU session is authorized to send traffic using App2)), to the (R)AN. The RAN can transport only the N1 SM container to the UE.

[0140] App2 can begin transmitting data using, for example, the same PDU session that App1 was using, which may include the network slice and AF. The UE may retain authorized IP addresses (e.g., AFs) until the authorized App is killed or may clear them based on UE behavior policy (if any) or based on local policy.

[0141] According to some aspects, the UE can receive updated URSP rules and (re)evaluate their validity in a timely manner under some conditions, such as when the UE registers via 3GPP access or non-3GPP access. Changes in the allowed or configured NSSAI and URSP can be updated by the PCF (e.g., TS 23.503).

[0142] According to some aspects, URSP rules can be used to determine whether an existing or new PDU session is required. The MNO itself, or an agreement between the MNO and a third-party entity, can determine which network slice accesses which AF / DN and whether an application requires a PAAA to access the AF / DN using that network slice.

[0143] According to some aspects, when a UE attempts to establish a PDU session and evaluates URSP rules, network slice selection may be performed using a Network Slice Selection Policy (NSSP) in the URSP. The NSSP may ensure that traffic of a matching application can be routed through a PDU session that supports any of the included S-NSSAIs. The URSP may be extended with a network slice selection flag (NSSA flag) for the proposed application so that any slice requiring PAAA can be indicated in the URSP rule with the NSSA flag Set. The NSSP may be independent of the NSSA flag in that the NSSA flag does not affect the UE's network slice selection decision. However, when the UE selects an S-NSSAI, the UE may check whether the NSSA flag is Set for that S-NSSAI.

[0144] If the S-NSSAI does not require a PAAA, the flag may be Not Set. According to some aspects, the flag can serve as an indicator and can be targeted to each S-NSSAI if there is a list of S-NSSAIs in the URSP rule. Thus, for a URSP, each S-NSSAI can have a separate NSSA flag. According to some aspects, Table 5 shows an extended URSP rule with an NSSA flag.

[0145] [Table 6]

[0146] According to some aspects, each time application traffic leads to a PDU session and the UE evaluates the URSP rules, the UE may attempt to select (one or more) S-NSSAIs from the URSP rules using NSSP. The RSD of the URSP may be extended so that the UE also checks whether the NSSA flag for a particular S-NSSAI is Set. If the NSSA flag is set for that S-NSSAI, the UE may determine that the application needs to be authenticated and authorized for a successful PDU session via the corresponding S-NSSAI. The NSSA flag also means that the UE needs to send an application descriptor (e.g., App ID) for the UE application along with an indicator specifying the need for PAAA in a PDU session request to the core network (AMF or SMF). This procedure is shown in Figure 10.

[0147] In step 1, the MNO can configure the core network with a PAAA policy. The SMF can be responsible for performing PAAA procedures for applications requesting PDU session establishment. The PAAA policy can ensure whether and how the SMF needs to contact the AAA / DN-AAA server for application authentication and authorization.

[0148] In addition, the NSSA flag in the URSP rule may also be set for S-NSSAIs that require a PAAA based on local policy or any agreement with a third-party entity.

[0149] In step 2, the UE may receive the extended URSP rules from the core network when the UE registers via 3GPP or non-3GPP access, when there is a change in the allowed NSSAI or configured NSSAI for the UE, when the UE moves from EPC to 5GC, when the URSP is updated by the PCF, etc. (e.g., TS 23.503).

[0150] In step 3, when an application starts and triggers the UE to establish a PDU session, the UE may evaluate the URSP rules. If the NSSA flag is Set for the S-NSSAI for which the UE is attempting to establish a PDU session, the UE may determine, based on the set NSSA flag, that it needs to send an application descriptor (e.g., App ID) to the core network. Therefore, the UE may send the application descriptor in an Authentication and Authorization message (AA message) indicating the need for PAAA in the PDU session establishment request. Alternatively, the UE may send a PAAA trigger indicator, as described herein, to indicate the need for PAAA along with the request. Alternatively, PAAA may be triggered by the SMF based on policies or information received from the PCF / UDM.

[0151] Alternatively, the UE may send only the application descriptor, which may serve as an indication to inform the SMF that the application indicated by the application descriptor needs to be authenticated and authorized to successfully establish a PDU session. In this alternative, if the application does not need to be authenticated and authorized, for example, if the NSSA flag is Not Set, the UE may not include the application descriptor in the PDU session request.

[0152] In step 4, when the SMF receives a PDU session establishment request from the UE, it can identify, based on the AA message, that the application requesting the PDU session requires PAAA. The SMF can also obtain an application descriptor from the UE. Based on the request received from the UE and other information, the SMF can determine an AAA / DN-AAA server for PAAA. The SMF can send a PAAA request and an application descriptor (if required) to the AAA / DN-AAA server. Alternatively, the SMF can trigger application authentication and authorization based on a PAAA trigger indicator. Alternatively, the PAAA SMF can trigger application authentication and authorization based on policy or trigger information received from the PCF / UDM.

[0153] In step 5, if the application is authenticated and authorized, the AAA / DN-AAA server can return a successful authentication and authorization message to the SMF. This message can inform the SMF to accept the PDU session request, which essentially authorizes the PDU session to be established. The successful authentication and authorization message can also include a list of IP addresses, port numbers, and / or MAC addresses (e.g., AFs), DNS names, etc. The PDU session is authorized to send traffic using the application.

[0154] In step 6, the SMF may return a PDU session establishment accept message to the UE.

[0155] If the AAA / DN-AAA server rejects the SMF's PAAA request because the application could not be authenticated or authorized, the PDU session establishment request may be rejected.

[0156] An alternative may be to force the NSSA flag only for PDU sessions that are non-initial or secondary PDU sessions, i.e., for PDU session establishment requests that do not have "initial request" in the request type parameter. In other words, if the NSSA flag is Set for an S-NSSAI, the first PDU session from a first application (e.g., App1) established via an S-NSSAI (e.g., S-NSSAI-X) may not require PAAA. However, when a second (or later) application (e.g., App2, App3) starts and evaluates the URSP, the UE may determine that a PDU session should be established via an S-NSSAI (e.g., S-NSSAI-X) that already has an ongoing PDU session, and may use that existing PDU session. In such a case, the NSSA flag in the URSP may indicate to the UE to send an AA message or a PAAA trigger indicator and an App2 application descriptor to the core network for PAAA.

[0157] According to some aspects, a network slice may be inaccessible to a UE in various scenarios. For example, when a mobile UE crosses a new geographical area (e.g., PLMN, TA / RA, etc.), the UE's desired network slice may be unavailable in the new geographical area. An unavailable network slice may mean that the network slice was initially authorized (e.g., available via an authorized NSSAI) but is now unavailable at the new time or location due to restriction attributes, that the slice is not authorized in a particular TA, or that it is simply unavailable in the new geographical area or PLMN.

[0158] According to some aspects, the new TA / RA may cover specific dedicated frequency bands, and therefore, there may be network slices available or unavailable on those frequency bands. If the requested NSSAI includes an S-NSSAI that is not available in the UE's new TA, the AMF itself or by interacting with the NSSF may determine a target NSSAI to be used by the NG-RAN and attempt to redirect the UE to a cell and TA in another frequency band and a TA that supports the S-NSSAI in the target NSSAI (see TS 23.501). Alternatively, the UE registration may be rejected due to an empty allowed NSSAI, and the PDU session (e.g., if present in the existing network slice) may be abandoned. Meanwhile, 5GS may attempt to remap the network slice with an appropriate network slice (if available) so that ongoing PDU sessions can be gracefully transferred to the new remapped slice, enabling 5GS to provide service continuity and a better user experience. According to some aspects, the remapped slice simply means the appropriate slice to which the PLMN selects to transfer a PDU session from another slice.

[0159] According to some aspects, slice remapping may involve disassociating traffic (or a PDU session) from a first slice and / or S-NSSAI and associating the traffic (or PDU session) with a second slice and / or S-NSSAI. A network-initiated remapping procedure may involve a network node (e.g., an AMF) determining to change a slice and / or S-NSSAI associated with a PDU session of the UE and sending a notification message to the UE to notify the UE that the PDU session that was associated with the first S-NSSAI is now associated with the second S-NSSAI. The notification may include the second S-NSSAI. A UE-initiated remapping procedure may involve the UE determining to request that the PDU session associated with the first S-NSSAI be disassociated from the first S-NSSAI and instead associated with the second S-NSSAI.

[0160] According to some aspects, it is assumed that frequency bands / cells overlap in a TA, and multiple TAs may be available to the UE. However, a network slice may also be unavailable to the UE based on time factors or due to authorization. Thus, the UE may also encounter a situation where a licensed slice may not exist, causing the UE to attempt frequent cell searches and consume its power too quickly. In another scenario, the UE may not be prepared for a sudden but temporary outage of a frequency band, thus preventing the network from slicing and processing ongoing PDU sessions. The UE may encounter several different scenarios. For example, a network slice may simply be unavailable because there may not be any services available in the TA.

[0161] The authorized network slice may not be available in the TA for the UE, however, the UE may be able to access an alternative slice with special privileges / permissions and authorizations.

[0162] The authorized network slice may not be available in the TA for the UE, however, the network slice may be available in a neighboring TA.

[0163] The network slice may not be available within the time period, but may be available shortly (e.g., at 1800 HRS).

[0164] This section describes how time and location information can be used to enhance 5GS so that a UE can be better prepared to handle ongoing PDU sessions. In addition, this section also describes how a UE can utilize the time and location information for enhanced UE efficiency.

[0165] According to some aspects, UE subscription information in the core network may include network slices that the UE is authorized to use, service area restrictions, RAT restrictions, prohibited areas, etc. (e.g., Table 5.2.3.3.1-1 of TS 23.502). Furthermore, the AMF and / or NSSF may identify frequency bands in which one or more network slices are available or unavailable. In addition to this information, the UE and the core network may be able to utilize spatial and temporal information that may describe the availability of network slices at certain times and locations. Temporal and Spatial Information (TSI) and how the UE and the network may be able to utilize the TSI to operate more efficiently are described above.

[0166] According to some aspects, if a network slice is temporarily unavailable or there is a time restriction for slice access for a UE, in other words, if the network slice can only be active for a certain period of time, or if the network slice is not authorized to the UE for a defined period of time, that information may be configured in the core network along with the UE subscription information and made available to the AMF or UDM and ultimately to the UE.

[0167] Meanwhile, the core network (e.g., UDM, NSSF, AMF, or PCF) may have information about which network slices are available in the network or available in some TAs and RAs. As described below, the information may include whether the UE may be present on some cells and whether network slices are authorized for the UE (e.g., available for distribution in permitted NSSAIs) in some frequency bands.

[0168] The aforementioned integrated TSI can be used to notify the network, and thus the UE, about the next network slice access availability. Depending on the UE and its location / status, the next availability may be temporary. In other words, the core network can predetermine when the UE can or cannot access a particular network slice. For example, the UE may be in a home network or may be crossing a VPLMN, and if the authorized network slice in the serving PLMN is only active within a specified period (e.g., after 6:00 PM and before 6:00 AM), this information can be used to the UE's benefit.

[0169] Similarly, the next availability of a network slice may be spatial. For example, a UE (e.g., a smartphone, a car with GPS, a delivery drone UE, a connected car, etc.) may be moving toward a certain direction. The GPS in the car may be configured to follow a specific route. For such a car, location services, the rate at which the UE is moving, and a predefined direction may provide the core network with a sufficient probability that the car will move to a certain geographic location (e.g., TA / RA). Based on that information, the core network may be able to estimate the nature of the traffic, the minimum, average, and / or maximum bandwidth the UE may consume, which may be translated into the network understanding which service and network slice the UE requires. Assuming the network has information about the slice the UE is authorized to access, the frequency bands in which the slice is available, and the TAs in which the network slice may be available, two aspects may be planned in advance.

[0170] First, the network may be able to indicate the topology of the TA. The topology information may include the neighboring TA where the UE is currently located, the TAs where most network slices are authorized for the UE and where frequency band network slices are available, a list of neighboring TAs covering a certain radius, the distance between TAs of interest (e.g., TAs where network slices are authorized), etc. There may be coverage gaps in the TA where authorized network slices are not available or are in a zone where the slices are inaccessible (non-access). Using this information, the network may be able to schedule efficient frequency band redirection for the UE and proactively redirect the UE to the TA and / or frequency band where the most relevant network slice is authorized. In this way, the UE does not need to wait to request a network slice, which subsequently triggers UE redirection to an appropriate frequency band.

[0171] Second, the information can be conveyed to the UE so that the UE can use it to determine expected neighboring TAs and therefore available network slices within the frequency band of interest, which can give the UE an opportunity to change its direction if necessary and maintain an appropriate speed so that the UE (e.g., drone, connected car, etc.) may decide to follow a route towards a TA where the desired slice is available or where there is a high probability of finding an authorized network slice.

[0172] Slice availability, authorized S-NSSAI, TA topology (including neighboring TAs), The time and space information regarding frequency band information, TA / RA id list, etc. may be sent to the UE during a UE configuration update or using a NAS message if necessary. The delivery of this combined time and space information may be triggered by events such as initial registration, mobility / registration update, UE configuration update, etc.

[0173] In addition to the UE's decision to change direction or the core network's decision to proactively redirect the UE to an appropriate frequency band and / or TA, the UE may be able to utilize the TSI to enable the UE to interact with applications that are active or should become active to reduce undesirable behavior, thereby reducing power consumption and aiding UE efficiency.

[0174] If time information about the network slice during the TA (e.g., slice A is inactive between 6:00 AM and 6:00 PM) is available to the UE, the UE may be able to pause / stop a PDU session to be established. For example, if an application task requires a significantly long PDU session (e.g., gaming) and the inactivity time period of the network slice is approaching, the UE may decide to stop initiating that PDU session and notify the relevant parties of the reason. This may mean that the UE may notify the UE application and / or invalidate a request originating from the UE application, or, if the application has not initiated the PDU session, establish a session backoff time during which the application cannot initiate the PDU session. The UE may record a message for its decision and send it to the network or notify the user as needed. Using such a message, the UE may take action to attempt another network slice (if available) or request another network slice, if feasible.

[0175] Similarly, if the UE is mobile and, based on the TA topology, the network identifies a coverage gap in a TA in the UE's path, but the TA is relatively small and the UE can pass through such a TA relatively quickly, the UE may trigger an action to prepare buffered UL data for an application for which access to a slice is unavailable. For example, uplink data may be transmitted after a delay (e.g., starting based on a network slice trigger or temporal availability) so that the application has access to the slice. The delay may be based on the timing of slice availability, e.g., when an unavailable slice becomes available. Similarly, the core network (AMF or SMF) may trigger the participating UPF to buffer DL data (in the case of SSC mode 1). The UE may be informed of the TA topology as described herein, and as a result, the UE may take action to reduce activity and conserve the UE's power consumption.

[0176] If there is no authorized network slice available in the TA, or if there is no authorized network slice available in the TA for a predetermined period of time, the UE may take one or more of the following actions: For example, the UE may reduce cell search attempts (e.g., reduce cell searches by 80%).

[0177] The UE may store the state of the application (e.g., idle, connected, active, inactive, etc.). For example, the UE application may be waiting for a response from the network. Such state can be stored and later retrieved when a licensed slice comes online.

[0178] The UE may store the state of the PDU session (e.g., idle, connected, active, inactive, etc.) and buffer any UL data appropriately. For example, the PDU session may be in an idle state or a connected state.

[0179] The UE may preserve any background data state and / or defer data transfer.

[0180] The UE may disable notifications from active applications within the UE and / or disable push notifications.

[0181] The UE may turn off the non-3GPP access type command and stop searching for N3IWF access points.

[0182] The UE may prepare for slice remapping if the PLMN supports slice remapping.

[0183] The UE may turn off broadcast type activity.

[0184] The UE may take less time to reach the sleep state or may be put to sleep immediately.

[0185] The UE may start a quietness timer that will allow the UE to perform all the aforementioned actions for a certain amount of time (e.g., prevent actions such as buffering UL data from continuing indefinitely). If the unavailability of the network slice persists beyond the quietness timer, the UE may completely kill the application process and flush all incomplete UL data and application state. On the other hand, the SMF may start a different quietness timer as soon as the UE enters a TA where the authorized slice is unavailable.

[0186] If the UE determines, based on the combined spatial and temporal information, that the authorized slice is not available via a 3GPP access type but is accessible via a non-3GPP access type, the UE may trigger a path switch and offload application traffic to the non-3GPP access type.

[0187] The UE capability whereby the UE can receive the integrated TSI, can use the integrated TSI to interact with UE applications, and based on the TSI, can steer the UE when network slices are available so that overall UE efficiency is improved, which can be referred to as UE application interaction and steering capability (AISC).

[0188] According to some aspects, the UE AISC may need to be notified to the network using an AISC indicator. Alternatively, the UE can send a UE release or version number / identifier to the network, which can help the network determine whether the UE is capable of receiving and using the TSI. The TSI may be conveyed to the UE simply during the UE registration or UE registration update procedure after successful UE registration, as described in FIG. 11.

[0189] In step 1, the UE may send a registration or registration update request to the network (AMF) via the RAN. In the request, the UE may send an AISC indicator to the network. Alternatively, this indication may also be conveyed implicitly by sending a UE release number / identifier (e.g., 3 GPP Rel-18, 5G Advanced, etc.) so that the network may send TSI to the UE upon identifying such capability. Application interworking capability may mean that the UE is designed to understand, analyze, and / or utilize TSI received from the network, which may improve the overall efficiency of the UE.

[0190] In step 2, the UE registration procedure may continue (e.g., as described in steps 4 to 18 of TS 23.502 [2], Figure 4.2.2.2.2-1). If the AMF does not have subscription data for the UE, the AMF may use Nudm_SDM_Get to retrieve access and mobility subscription data, SMF selection subscription data.

[0191] In step 3, if the UE registration is successful, the core network (AMF) can send a UE registration accept message to the UE via the RAN. The network can include UE spatial information and time information in the registration accept message.

[0192] Communicating the TSI to the UE using the UE configuration update procedure According to some aspects, the TSI may alternatively be conveyed to the UE using a UE configuration update procedure. If a new TSI is available, the network may trigger a UE configuration update procedure. According to some aspects, a manner in which the TSI may be conveyed during the UE configuration update procedure is described in FIG. 12.

[0193] This procedure may be initiated by the AMF when the AMF wants to update access and mobility management related parameters in the UE configuration.

[0194] This procedure can also be used to trigger the UE, based on a network indication, to perform either a mobility registration update procedure to modify NAS parameters requiring negotiation (e.g., MICO mode) while the UE is in CM-CONNECTED state, or a mobility registration update procedure to steer the UE towards the EPC (e.g., as specified in clause 5.31.3 of TS 23.501 [1]), or a mobility registration update procedure after the UE has entered CM-IDLE state (e.g., for a change to the allowed NSSAI requiring re-registration). If a registration procedure is required, the AMF can provide an indication to the UE to initiate the registration procedure.

[0195] The UE configuration update may be sent via the access type to which the UE configuration update applies (e.g., 3GPP access or non-3GPP access), if applicable. The AMF may request a UE acknowledgement after the NAS parameters, including the temporal and spatial information update, are sent to the UE.

[0196] In accordance with some aspects, a UE configuration update procedure for conveying spatial and temporal information to a UE is illustrated in FIG.

[0197] In step 0, the AMF may determine the need for a UE configuration change due to various reasons (e.g., UE mobility change, NW policy, receiving a subscriber data update notification from the UDM, a change in network slice configuration, a change in extended coverage restriction information in the UE context), or the need for the UE to perform a registration procedure. The reasons may include the need for the network to inform the UE about (updated) temporal and spatial information (TSI).

[0198] In step 1, the AMF sends an extended UE configuration update command including one or more UE parameters including a TSI. The TSI may include an extended TAI list comprising a TA topology and / or gap TA, and an authorization time, etc., as described herein.

[0199] In step 2, if the UE configuration update indication requires an acknowledgement of the UE configuration update command, the UE may send a UE configuration update complete message to the AMF.

[0200] Alternatively, the core network (AMF) may send the TSI to the UE using an NAS message.

[0201] According to some aspects, an MNO / PLMN may have geographical regions where it may only admit those UEs with special permissions. The MNO may configure network slices for special access due to sensitivity or resource availability reasons. Gap TA (slice inaccessible zone) may provide a network slice only for special services with special permissions and authorizations (e.g., military communications). According to some aspects, FIG. 13 illustrates how a UE may be able to submit special permissions / privileges and receive an alternative network slice from the network.

[0202] This section describes how a UE may send a set of credentials and / or identification information to the network so that the network may decide to add a slice to the UE's configured NSSAI. According to some aspects, this may be useful in scenarios where the UE enters a TA / RA where the UE does not have a slice in its configured NSSAI accessible in the TA / RA. The procedure described below may allow the user to enter a set of credentials and / or identification information that can be sent to the network so that the configured NSSAI is updated with a slice accessible in the current RA / TA.

[0203] In step 0, the UE may have received an elevated privilege identification (EPID), which is a separate and unique identifier for special privileges / permissions. The EPID may represent elevated permissions for the UE. For example, the UE may be a designated UE with highest privileges for a high-ranking military or diplomatic officer, or the UE may have a special subscription to elevated privileges that is triggered only when a scenario classified as "special" is encountered. A "special" scenario may be when slicing is not authorized in some geographical areas.

[0204] In step 1, when the UE enters a new geographical area (TA / RA) and undergoes a registration update, the UE may identify that there are no authorized network slices available in the TA. The UE may further identify that there are no overlapping TAs in which any authorized slices are available. The AMF may ask whether the UE has elevated privileges, and if so, may send a request to the UE asking it to send an EPID.

[0205] Alternatively, the UE and the network may identify in advance from the TA topology information (integrated TSI) described herein that there is no authorized network slice available in a TA / RA covering a certain geographical area (which may include a TA list covering neighboring TAs). Based on the UE subscription information, the network may also determine that the UE has an elevated privilege, and therefore the AMF may send a request for an EPID to the UE, asking whether the UE is willing to use the privilege.

[0206] Alternatively, the network may return a set of alternative S-NSSAIs to the UE when requesting an EPID from the UE.

[0207] In step 2, the UE may send the EPID to the UE using a NAS message. Upon receiving the EPID, the core network (AMF, AUSF, and / or UDM) may verify such identifier. If the EPID is not valid / expired or authentic, the AMF may return a NAS message indicating that the UE is denied access to any network slice with a cause code.

[0208] In step 3, the UE may need to undergo an NSSAA procedure. Here, the EAP ID may be extended to include the EPID. In this case, the UE may be authenticated and authorized by the AAA or a third-party AAA server. During the authorization procedure, the AAA-S can verify the EPID for network slice authorization.

[0209] In step 4, the AMF may send to the UE a set of alternative S-NSSAIs that the UE may access using the EPIDs in the allowed NSSAIs that accompany the registration accept message.

[0210] In step 5, the UE may request the core network (AMF or SMF) to forward any ongoing PDU sessions towards the alternative S-NSSAI or to establish a new PDU session towards the alternative S-NSSAI.

[0211] According to some aspects, FIG. 14 illustrates front and back user interfaces of a UE (e.g., a smartphone). The front portion illustrates many applications installed on the UE, suggesting that applications from different vendors may be present. The back user interface illustrates extended UE features. In particular, the UE includes a UE release version identifier, an S-NSSAI with a PAAA indicator, an extended URSP with an NSSA flag, and integrated temporal and spatial information received from the core network.

[0212] According to some aspects, the application can present a GUI that enables a user to enter an application instance identity and / or a set of credentials associated with the application instance. The application instance identity and / or the set of credentials can then be used by the UE in the PAAA procedures described above.

[0213] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunications network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced, and New Radio (NR), also known as "5G." 3GPP NR standard development is expected to continue and include the definition of next-generation radio access technologies (new RATs), including new flexible radio access provisions below 7 GHz and new ultra-mobile broadband radio access provisions above 7 GHz. Flexible radio access is expected to consist of new, non-backward-compatible radio access in new spectrum below 7 GHz, including different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with divergent requirements. Ultra Mobile Broadband is expected to include centimeter-wave and millimeter-wave spectrum, which may provide opportunities for ultra mobile broadband access, for example, for indoor applications and hotspots. In particular, Ultra Mobile Broadband is expected to share a common design framework with sub-7 GHz Flexible Wireless Access, with centimeter-wave and millimeter-wave specific design optimizations.

[0214] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low latency communications (URLLC), massive machine type communications (mMTC), network operations (e.g., network slicing, routing, migration, and interworking, energy conservation), 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 communication with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive e-calling, disaster alerts, real-time gaming, multi-party video calling, autonomous driving, augmented reality, haptic internet, virtual reality, home automation, robotics, and aerial drones, to name a few. All of these use cases and more are contemplated herein.

[0215] 15A illustrates an example communications system 100 in which the systems, methods, and apparatus described and claimed herein may be used. The communications system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which may be generally or collectively referred to as a WTRU 102 or multiple WTRUs 102. The communications system 100 may also 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. 113. The network services 113 may include, for example, a V2X server, a V2X function, a ProSe server, a ProSe function, an IoT service, video streaming, and / or edge computing.

[0216] It may be understood that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102 may be any type of apparatus or device configured to operate and / or communicate in a wireless environment. In the example of FIG. 15A, each of the WTRUs 102 is illustrated in FIGS. 8A-8E as a handheld wireless communication device. In the wide variety of use cases contemplated for wireless communication, it may be understood that each WTRU may include or be included in any type of apparatus or device configured to transmit and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a mobile phone, a personal digital assistant (PDA), a smartphone, a laptop computer, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a household appliance, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial device, a drone, a vehicle such as an automobile, bus, or truck, or an airplane.

[0217] The communications system 100 may also include a base station 114a and a base station 114b. In the example of FIG. 15A, each base station 114a and 114b is illustrated as a single element. In practice, the base stations 114a and 114b may include any number of interconnected base stations and / or network elements. The base station 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 communications networks, such as the core networks 106 / 107 / 109, the Internet 110, the network services 113, and / or other networks 112. Similarly, the base station 114b may be any type of device configured to interface wired and / or wirelessly with at least one of the remote radio heads (RRHs) 118a, 118b, the transmission and reception points (TRPs) 1115A, 1115B, and / or the roadside units (RSUs) 120a and 120b to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. The RRHs 118a, 118b may be any type of device configured to interface wirelessly with at least one of the WTRUs 102, e.g., the WTRU 102c, to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

[0218] The TRPs 1115A, 1115B may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the network services 113, and / or other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core networks 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. As an example, the base stations 114a, 114b may be a Base Transceiver Station (BTS), Node-B, eNode-B, Home Node-B, Home eNodeB, Next Generation Node-B (gNode B), satellite, site controller, access point (AP), wireless router, etc.

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

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

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

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

[0223] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d, such as sidelink communication, which may be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115d / 116d / 117d may be established using any suitable RAT.

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

[0225] The base station 114a and WTRUs 102a, 102b, 102c, and 102g in the RANs 103 / 104 / 105, or the RRHs 118a and 118b, TRPs 1115A and 1115B, and / or RSUs 120a and 120b and WTRUs 102c, 102d in the RANs 103b / 104b / 105b, 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 / 116c / 117c, respectively, using, for example, Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interface 115 / 116 / 117 or 115c / 116c / 117c may implement 3GPP NR technology. LTE and LTE-A technologies may include LTE D2D and / or V2X technologies and interfaces (such as sidelink communications). Similarly, 3GPP NR technology may include NR V2X technologies and interfaces (such as sidelink communications).

[0226] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RANs 103 / 104 / 105, or the RRHs 118a and 118b, TRPs 1115A and 1115B, and / or RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RANs 103b / 104b / 105b, may be compliant with IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1x, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), or any other standard. Radio technologies such as Global System for Mobile Communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), and GSM EDGE (GERAN) may be implemented.

[0227] 15A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as a business, home, vehicle, train, airborne, satellite, factory, campus, etc. The base station 114c and the WTRU 102, e.g., the 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 WTRU 102, e.g., the WTRU 102d, may implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102, e.g., the WTRU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. 15A, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not need to access the Internet 110 through the core network 106 / 107 / 109.

[0228] The RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b may communicate with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, application, and / or Voice Over Internet Protocol (VoIP) services to one or more of the WTRUs 102. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, prepaid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or may perform high-level security functions, such as user authentication.

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

[0230] The core network 106 / 107 / 109 may also serve as a gateway for the WTRU 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network providing Plain Old Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and internet protocol (IP) in the TCP / IP Internet protocol suite. The other networks 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 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 RANs 103 / 104 / 105 and / or RANs 103b / 104b / 105b, or a different RAT.

[0231] 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 example, the WTRU 102g shown in FIG. 15A may be configured to communicate with a base station 114a that may use a cellular-based wireless technology and a base station 114c that may use an IEEE 802.11 wireless technology.

[0232] Although not shown in Figure 15A, it is understood that the user equipment may be wired to a gateway. The gateway may be a residential gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It may be understood that many of the ideas contained herein may apply equally to UEs, which are WTRUs and UEs that use a wired connection to connect to the network. For example, ideas applied to the air interfaces 115, 116, 117, and 115c / 116c / 117c may apply equally to a wired connection.

[0233] FIG. 15B is a system diagram of an example RAN 103 and core network 106. As described above, the RAN 103 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 115 using UTRA radio technology. The RAN 103 may also communicate with the core network 106. As shown in FIG. 15B, the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a and 142b. It may be understood that the RAN 103 may include any number of Node-Bs and radio network controllers (RNCs).

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

[0235] The core network 106 shown in Figure 15B may include a media gateway (MGW) 144, a Mobile Switching Center (MSC) 146, a Serving GPRS Support Node (SGSN) 148, and / or a Gateway GPRS Support Node (GGSN) 150. Although each of the foregoing elements is illustrated as part of the core network 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

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

[0239] 15C is a system diagram of an example RAN 104 and core network 107. As described above, the RAN 104 may communicate with the WTRUs 102a, 102b, and 102c over the air interface 116 using E-UTRA radio technology. The RAN 104 may also communicate with the core network 107.

[0240] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, although it may be understood 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 techniques. Thus, the eNode-B 160a may transmit wireless signals to, and receive wireless signals from, the WTRU 102a, for example, using multiple antennas.

[0241] Each of the eNode-Bs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling, etc. in the uplink and / or downlink. As shown in FIG. 15C, the eNode-Bs 160a, 160b, and 160c may communicate with one another over an X2 interface.

[0242] The core network 107 shown in Figure 15C may include a Mobility Management Gateway (MME) 162, a Serving Gateway 164, and a Packet Data Network (PDN) Gateway 166. Although each of the foregoing elements is illustrated as part of the core network 107, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0243] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during initial attach of the WTRUs 102a, 102b, and 102c, etc. 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.

[0244] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 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 the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, and managing and storing the context of the WTRUs 102a, 102b, and 102c.

[0245] The serving gateway 164 may also be connected to a 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 communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0246] The core network 107 may facilitate communication 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 communication between the WTRUs 102a, 102b, and 102c and traditional landline communication devices. For example, the core network 107 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0247] 15D is a system diagram of an example RAN 105 and core network 109. The RAN 105 may communicate with the WTRUs 102a and 102b over an air interface 117 using NR radio technology. The RAN 105 may also communicate with the core network 109. A Non-3GPP Interworking Function (N3IWF) 199 may communicate with the WTRU 102c over an air interface 198 using non-3GPP radio technology. The N3IWF 199 may also communicate with the core network 109.

[0248] The RAN 105 may include g Node-Bs 180a and 180b. It may be understood that the RAN 105 may include any number of g Node-Bs. The g Node-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 an integrated access and backhaul connection is used, the same air interface may be used between the WTRUs and the g Node-Bs, which may be the core network 109 via one or more gNBs. The g Node-Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the g Node-B 180a may, for example, transmit wireless signals to and receive wireless signals from the WTRU 102a using multiple antennas. It should be understood that the RAN 105 may use other types of base stations, such as eNode-Bs. It may also be appreciated that the RAN 105 may employ more than one type of base station. For example, the RAN may use eNode-B and gNode-B.

[0249] The N3IWF 199 may include a non-3GPP access point 180c. It may be understood 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 WTRU 102c over the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c over the air interface 198 using an 802.11 protocol.

[0250] Each of the eNode-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, user scheduling, etc. on the uplink and / or downlink. As shown in FIG. 15D, the gNode-Bs 180a and 180b may communicate with each other, for example, over an Xn interface.

[0251] The core network 109 shown in FIG. 15D may be a 5G core network (5GC). The core network 109 may provide multiple communication services to customers interconnected by a radio access network. The core network 109 includes several entities that perform core network functions. As used herein, the terms "core network entity" or "network function" refer to any entity that performs one or more functions of a core network. It is understood that such a core network entity may be a device configured for wireless or network communication, or a logical entity implemented in the form of computer-executable instructions (software) stored in a memory of, and executed by, a processor of, a computer system, such as the system 90 shown in FIG. 15G.

[0252] In the example of Figure 15D, 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, a Non-3GPP Interworking Function (N3IWF) 199, and a User Data Repository (UDR) 178. While each of the foregoing elements is illustrated as part of the 5G core network 109, it will be understood that any of these elements may be owned and / or operated by an entity other than the core network operator. It is also understood that the 5G core network may not consist of all of these elements, but may consist of additional elements, and may consist of multiple instances of each of these elements. Although Figure 15D shows the network functions connecting directly to each other, it should be understood that the network functions may communicate through a routing agent, such as a diameter routing agent or message bus.

[0253] In the example of Figure 15D, connectivity between network functions is achieved through a set of interfaces or reference points. It can be understood that network functions can be modeled, described, or implemented as a set of services that are invoked or called by other network functions or services. Invocation of network function services can be achieved through direct connections between network functions, messaging exchanges on a message bus, software function calls, etc.

[0254] The AMF 172 may be connected to the RAN 105 via the N2 interface and may function as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, and access authorization. The AMF may be responsible for forwarding user plane tunnel configuration information to the RAN 105 via the N2 interface. The AMF 172 may receive user plane tunnel configuration information from the SMF via the N11 interface. The AMF 172 may generally route and forward NAS packets to and from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in FIG. 15D.

[0255] The SMF 174 may be connected to the AMF 172 via an N11 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 function 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 UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0256] 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 communication 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, the other network 112 may be an Ethernet network 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 the packet data network with the N6 interface or by connecting to each other or other UPFs via the N9 interface. In addition to providing access to the packet data network, the UPF 176 may be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0257] The AMF 172 may also be connected to the N3IWF 199, for example, via an N2 interface. The N3IWF facilitates connectivity between the WTRU 102c and the 5G core network 170, for example, via an air interface technology not defined by 3GPP. The AMF may interact with the N3IWF 199 in the same or similar manner as it interacts with the RAN 105.

[0258] The PCF 184 may be connected to the SMF 174 via an N7 interface, 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. 15D . 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, and the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

[0259] The UDR 178 may function as a repository for authentication credentials and subscription information. The UDR may connect to a network function so that the network function can add to, read, and modify data residing in the repository. For example, the UDR 178 may connect to the PCF 184 via an N36 interface. Similarly, the UDR 178 may connect to the NEF 196 via an N37 interface, and the UDR 178 may connect to the UDM 197 via an N35 interface.

[0260] The UDM 197 may act as an interface between the UDR 178 and other network functions. The UDM 197 may authorize the network functions for access by the UDR 178. For example, the UDM 197 may connect to the AMF 172 via an N8 interface, and the UDM 197 may connect to the SMF 174 via an N10 interface. Similarly, the UDM 197 may connect to the AUSF 190 via an N13 interface. The UDR 178 and the UDM 197 may be tightly integrated.

[0261] The AUSF 190 performs authentication related operations and connects to the UDM 178 via the N13 interface and to the AMF 172 via the N12 interface.

[0262] The NEF 196 exposes capabilities and services in the 5G core network 109 to the Application Function (AF) 188. The exposure may occur over an N33 API interface. The NEF may connect to the AF 188 via the N33 interface and may connect to other network functions to expose capabilities and services of the 5G core network 109.

[0263] The application functions 188 may interact with network functions within the 5G core network 109. The interaction between the application functions 188 and the 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 companies that have business relationships with the mobile network operators.

[0264] Network slicing is a mechanism that can 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 allows operators to create customized networks to provide optimized solutions for different market scenarios with diverse requirements, for example, in the areas of functionality, performance, and isolation.

[0265] 3GPP is designing the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a diverse set of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband), which may require very different and extreme requirements. Without network slicing technology, the network architecture is likely not flexible and scalable enough to efficiently support the needs of a wider range of use cases, as each use case has its own specific set of performance, scalability, and availability requirements. Furthermore, it should make the introduction of new network services more efficient.

[0266] Referring again to FIG. 15D , in a network slicing scenario, the WTRU 102a, 102b, or 102c may connect to the AMF 172 via an N1 interface. The AMF may be logically part of one or more slices. The AMF may coordinate the WTRU 102a, 102b, or 102c's connectivity or communication with one or more UPFs 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.

[0267] The core network 109 may facilitate communications with other networks. For example, the core network 109 may include or communicate with an IP gateway, such as an IP Multimedia Subsystem (IMS) server, that acts as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 may include or communicate with a short message service (SMS) service center that facilitates communications via 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 the server or application function 188. Additionally, the core network 170 may provide the WTRUs 102a, 102b, and 102c with access to the network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0268] The core network entities described herein and illustrated in Figures 8A, 8C, 8D, and 8E are identified by the names given to those entities in certain existing 3GPP specifications, although it is understood that future such entities and functions may be identified by other names and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Thus, it is understood that the specific network entities and functions described and illustrated in Figures 8A, 8B, 8C, 8D, and 8E are provided by way of example only, and that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communications system, whether currently defined or defined in the future.

[0269] 15E illustrates an example communication system 111 in which the systems, methods, and apparatus described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, and F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may apply to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or more, or all, of WTRUs A, B, C, D, E, and F may be outside the coverage area of ​​the access network 131. WTRUs A, B, and C form a V2X group in which WTRU A is the group lead and WTRUs B and C are group members.

[0270] WTRUs A, B, C, D, E, and F may communicate with each other over Uu interface 129 via gNB 121 when they are within access network coverage 131. In the example of FIG. 15E, WTRUs B and F are shown within access network coverage 131. WTRUs A, B, C, D, E, and F may communicate directly with each other over a sidelink interface (e.g., PC5 or NR PC5), such as interface 125a, 125b, or 128, regardless of whether they are under or outside access network coverage 131. For example, in the example of FIG. 15E, WTRU D, which is outside access network coverage 131, communicates with WTRU F, which is within coverage 131.

[0271] WTRUs A, B, C, D, E, and F may communicate with RSU 123a or 123b via vehicle-to-network communications (V2N) 133 or sidelink interface 125b. WTRUs A, B, C, D, E, and F may communicate to V2X server 124 via vehicle-to-infrastructure communications (V2I) interface 127. WTRUs A, B, C, D, E, and F may communicate to another UE via vehicle-to-person communications (V2P) interface 128.

[0272] Figure 15F is a block diagram of an example apparatus or device WTRU 102 that may be configured for wireless communication and operation in accordance with the systems, methods, and apparatuses described herein, such as the WTRU 102 of Figure 15A, 8B, 8C, 8D, or 8E. As shown in Figure 15F, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicators 128, non-removable memory 130, removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It may be understood that the WTRU 102 may include any sub-combination of the foregoing elements. Additionally, the base stations 114a and 114b and / or the base stations 114a and 114b may represent, but are not limited to, a transceiver station (BTS), a Node-B, a site controller, an access point (AP), a home Node-B, an evolved home Node-B (eNodeB), a home evolved Node-B (HeNB), a home evolved Node-B gateway, a next generation Node-B (gNode-B), a proxy node, and the like, and may include some or all of the elements illustrated in FIG. 15F and described herein, among others.

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

[0274] The transmit / receive element 122 of the UE may be configured to transmit or receive signals to or from a base station (e.g., base station 114a in FIG. 15A) over air interface 115 / 116 / 117, or to transmit or receive signals to or from another UE over air interface 115d / 116d / 117d. For example, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 may be an emitter / detector configured to transmit and / or receive IR, UV, or visible light signals, for example. The transmit / receive element 122 may be configured to transmit and / or receive both RF and light signals. It may be understood that the transmit / receive element 122 may be configured to transmit and / or receive any combination of wireless or wired signals.

[0275] 15F 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.

[0276] The transceiver 120 may be configured to modulate signals transmitted by the transmit / receive element 122 and demodulate signals received by the transmit / receive element 122. As mentioned above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, e.g., 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.

[0277] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light-emitting diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. Note that the processor 118 may access information from and store data in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132. The non-removable memory 130 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SID), a subscriber identity card (PIN), a mobile phone (MPL), a mobile telephone (M2M), a mobile phone ... The processor 118 may include a SIM (Single Serial Imaging Module) card, a memory stick, a Secure Digital (SD) memory card, etc. The processor 118 may access information from and store data in memory that is not physically located on the WTRU 102, such as on a server hosted on a cloud or edge computing platform or a home computer (not shown).

[0278] The processor 118 may receive power from the power source 134, which may also be configured to distribute and / or control the power to other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

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

[0280] The processor 118 may further be coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors, such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnection interface, a vibration device, a television transceiver, a hands-free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, etc.

[0281] The WTRU 102 may be included in other apparatus or devices, such as a sensor, a domestic appliance, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, industrial equipment, a drone, a vehicle such as a car, truck, train, or airplane. The WTRU 102 may connect to other components, modules, or systems of such an apparatus or device via one or more interconnection interfaces, such as an interconnection interface that may include one of the peripherals 138.

[0282] FIG. 15G is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks illustrated in FIGS. 8A, 8C, 8D, and 8E may be embodied, such as particular nodes or functional entities in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112, or network services 113. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions. The computer-readable instructions may be in the form of software, located anywhere or by any means by which such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to perform tasks. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communications network. The coprocessor 81 is any processor different from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

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

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

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

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

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

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

Claims

1. 1. A method implemented in a wireless transmit / receive unit (WTRU), comprising: sending a registration request to a network node, the registration request including an indication that the WTRU is capable of receiving information associated with temporal availability of a network slice; receiving a registration response, the registration response including the information associated with the temporal availability of the network slice; and and determining, based on the temporal availability of the network slice, to stop using a protocol data unit (PDU) session associated with the network slice.

2. 2. The method of claim 1, wherein the information associated with the temporal availability of the network slice includes a time period during which the slice is available to the WTRU.

3. 3. The method of claim 1, wherein the information associated with the temporal availability of the network slice includes a time period during which the slice is unavailable to the WTRU.

4. The method according to any one of claims 1 to 3, further comprising storing the state of the PDU session.

5. 5. The method of claim 4, wherein the state of the PDU session is an idle state or a connected state.

6. The method of any one of claims 1 to 5, further comprising buffering uplink data associated with the PDU session.

7. The method of claim 6 , wherein the uplink data is transmitted after a delay.

8. 8. The method of claim 7, wherein the delay is based at least in part on the temporal availability of the network slice.

9. The method according to any one of claims 1 to 8, further comprising: determining to perform a slice remapping procedure based on the temporal availability of the network slices.

10. The method according to any one of claims 1 to 9, wherein the network node is an Access and Mobility Management Function (AMF).

11. 1. A wireless transmit / receive unit (WTRU) comprising one or more processors and a memory storing instructions that, when executed by the one or more processors, cause the WTRU to: sending a registration request to a network node, the registration request including an indication that the WTRU is capable of receiving information associated with temporal availability of a network slice; receiving a registration response, the registration response including the information associated with the temporal availability of the network slice; and and determining, based on the temporal availability of the network slice, to stop using a protocol data unit (PDU) session associated with the network slice.

12. The WTRU of claim 11 , wherein the information associated with the temporal availability of the network slice includes a time period during which the slice is available to the WTRU.

13. 13. The WTRU of claim 11, wherein the information associated with the temporal availability of the network slice includes a time period during which the slice is unavailable to the WTRU.

14. The WTRU of any one of claims 11 to 13, wherein the instructions, when executed by the one or more processors, further cause the WTRU to store a state of the PDU session.

15. The WTRU of claim 14 , wherein the state of the PDU session is an idle state or a connected state.

16. The WTRU of any one of claims 11 to 15, wherein the instructions, when executed by the one or more processors, further cause the WTRU to buffer uplink data associated with the PDU session.

17. The WTRU of claim 16 , wherein the uplink data is transmitted after a delay.

18. 18. The WTRU of claim 17, wherein the delay is based at least in part on the temporal availability of the network slice.

19. The WTRU of any one of claims 11 to 18, wherein the instructions, when executed by the one or more processors, further cause the WTRU to determine to perform a slice remapping procedure based on the temporal availability of the network slice.

20. The WTRU of any one of claims 11 to 19, wherein the network node is an Access and Mobility Management Function (AMF).

Images