Application interaction for network slicing

Abstract

The invention relates to application interaction for network slicing. Methods, apparatus, and systems for improved application interaction for network slicing are described. The wireless transmit / receive unit may send a registration request to the network node, the registration request including an indication that the WTRU can receive information associated with the time availability of the network slice. The WTRU may receive a registration response including information associated with time availability of the network slice. The WTRU may determine to cease using a protocol data unit (PDU) session associated with the network slice based on the time availability of the network slice.

Description

[0001] This application is a divisional application of the invention patent application with application number 202280067269.4, application date September 15, 2022, and name “Application Interaction of Network Slices”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 245,656, filed on September 17, 2021, and entitled “APPLICATION INTERACTION FOR NETWORK SLICING,” the contents of which are incorporated herein by reference in their entirety. Background Art

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

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

[0006] Application interactions for network slicing in 5G networks may cover a wide variety of scenarios, servers, gateways and devices, such as those described in, for example, the following specifications: [1] 3GPP TS 23.501, System Architecture for 5G Systems; Stage 2, V17.1.1, Release 17 (2021-06); [2] 3GPP TS 23.502, 5G System Procedures; Stage 2, V17.1.0, Release 17 (2021-06); [3] GSMA NG.116, Generic Slicing Template, Version 1.0, 23 May 2019; [4] 3GPP TS 38.101-1, User Equipment (UE) Radio Transmission and Reception; Part 1: Scope 1 Standalone, V16.1.0 (2019-09); [5] 3GPP TS 38.101-2, User Equipment (UE) Radio Transmission and Reception; Part 2: Scope 2 Standalone, V16.1.0 (2019-09); [6] 3GPP TS 23.503, Policy and Charging Control Framework for 5G System (5GS); Stage 2 (Release 16); [7] TS 23.122, Non-Access Stratum (NAS) Functionality Related to Mobile Station (MS) in Idle Mode, V16.4.0 (2019-12); and [8] 3GPP TS 24.501, Non-Access Stratum (NAS) Protocols for 5G System (5GS); Stage 3 (V16.3.0). Summary of the invention

[0007] Methods, devices, and systems for application interaction with network slicing are described herein. For example, per-application authentication and authorization (PAAA) can be performed for UEs to access network slices and data networks.

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

[0009] According to some aspects, a mechanism can be provided by which a PDU session established by a first application can be modified and utilized by a second application after successful per-application authentication and authorization of the second application.

[0010] According to some aspects, an enhanced URSP with an NS SA flag may be provided that, when evaluated, indicates to the UE whether PAAA is required for the S-NSSAI selected using the NSSP.

[0011] According to some aspects, mechanisms are provided by which the core network can utilize the combined temporal and spatial information to proactively redirect the UE to a TA and frequency band where the relevant network slice is granted to the UE. Mechanisms are provided by which the UE can utilize the combined temporal and spatial information so that the UE can change its direction and maintain a suitable speed or decide to follow a path towards a TA where there is a high probability of finding a granted network slice.

[0012] According to some aspects, mechanisms are provided by which the UE can utilize the combined time and spatial information so that the UE can appropriately save the status of applications (e.g., idle, connected, active, inactive, etc.) and / or disable them, save the status of PDU sessions (e.g., idle, connected, active, inactive, etc.), buffer uplink data and / or take one of multiple energy-saving actions such as reduced cell search, sleep, etc.

[0013] According to some aspects, mechanisms are provided by which a UE registration procedure, a UE registration update procedure, and / or a UE configuration update procedure can be enhanced to convey temporal and spatial information to a UE.

[0014] According to some aspects, mechanisms are provided by which a UE may utilize a unique identifier to enhance privileges for accessing a network slice that is not available to normal UEs.

[0015]

[0013] According to some aspects, a wireless transmit / receive unit (WTRU) may include one or more processors and memory storing instructions that, when executed by the one or more processors, cause the WTRU to perform one or more operations.

[0016] In accordance with 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 available or unavailable to the WTRU. In accordance with some aspects, a slice remapping procedure may be performed based on the temporal availability of the network slice.

[0017] In accordance with some aspects, the WTRU may receive a registration response. The registration response may include information associated with the temporal availability of the network slice. The WTRU may determine (e.g., based on the temporal availability of the network slice) to stop using a protocol data unit (PDU) session associated with the network slice. In accordance with some aspects, the WTRU may store a state (e.g., idle, connected, active, inactive, etc.) of the PDU session. In accordance with 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).

[0018] The purpose of providing this summary is to introduce selected concepts in a simplified form, which are further described in the following detailed description. This summary is neither intended to identify the key 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. In addition, the claimed subject matter is not limited to limitations that address any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 An exemplary 5G system service-based architecture is shown.

[0021] Figure 2 An exemplary non-roaming 5G system architecture represented by reference points is shown.

[0022] Figure 3 An exemplary network slice-specific authentication and authorization procedure is shown.

[0023] Figure 4 An exemplary method of PDU session establishment authentication / authorization by a DN-AAA server is shown.

[0024] Figure 5 An exemplary method for a UE application to establish a PDU session with a network slice is shown.

[0025] Figure 6 An exemplary connected car is shown without access to an authorized slice in a new location.

[0026] Figure 7 An exemplary UE is shown receiving an allowed NS SAI with a PAAA indicator upon registration.

[0027] Figure 8 An exemplary method for per-application authentication and authorization is shown.

[0028] Fig. 9An exemplary PAAA request with PDU session modification is shown.

[0029] Fig.10 An exemplary method for enhanced URSP to direct UE to perform PAAA is shown.

[0030] Fig.11 An example of a method for communicating temporal and spatial information to a UE during UE registration is shown.

[0031] Fig.12 An exemplary UE configuration update procedure for communicating spatial and temporal information to a UE is shown.

[0032] Fig.13 An example of a method for accessing an alternative network slice with special authorization is shown.

[0033] Fig.14 An exemplary UE UI showing installed applications and various enhanced features is shown.

[0034] Fig.15A An exemplary communication system is shown.

[0035] Fig. 15B , Fig. 15C and Fig.15D A system diagram of an exemplary RAN and core network is shown.

[0036] Fig.15E Another exemplary communication system is shown.

[0037] Fig.15F is a block diagram of an exemplary apparatus or device, such as a WTRU.

[0038] Figure 15G A block diagram of an exemplary computing system is shown. DETAILED DESCRIPTION

[0039] Table 0.1 describes some abbreviations used in this paper.

[0040] Table 0.1 - Abbreviations

[0041]

[0042]

[0043]

[0044] Terms and definitions.

[0045] The following is a list of terms that may appear in the description below. Unless otherwise stated, the terms used herein are defined as follows.

[0046] Network Slice - A logical network that provides specific network capabilities and network characteristics.

[0047] Network slice instance - a set of network function instances and the required resources (e.g., compute, storage, and networking resources) that form a deployed network slice.

[0048] Service Area Restrictions - Each service area restriction may contain one or more (e.g., up to 16) entire tracking areas, or a service area restriction may be set to be unlimited (e.g., including all tracking areas of a PLMN). The subscription information of a UE in UDM includes service area restrictions, which may contain allowed areas or non-allowed areas specified by using explicit tracking area identifiers and / or other geographic information (e.g., longitude / latitude, zip code, etc.).

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

[0050] Network Function (NF) - a processing function in a network with defined functional behavior and defined interfaces. NFs can be implemented as network elements on dedicated hardware, or as software instances running on dedicated hardware, or as virtualized functions instantiated on a suitable platform (e.g., on a cloud infrastructure).

[0051] NF Instance - an identifiable instance of a NF.

[0052] According to some aspects, Figure 1 A non-roaming reference architecture with service-based interfaces within the control plane is shown.

[0053] According to some aspects, Figure 2 The 5G system architecture in a non-roaming scenario is shown, using reference point representations that depict how the various network functions interact with each other.

[0054] According to some aspects, the mobility management function and the session management function are separated. A single N1 NAS connection can be used for both registration management and connection management, and for session management (SM) related messages and procedures for the UE. A single N1 termination point may be located in the AMF. The AMF may forward SM related NAS information to the SMF. The AMF may handle the registration management and connection management parts of the NAS signaling exchanged with the UE. The SMF handles the session management part of the NAS signaling exchanged with the UE.

[0055] According to some aspects, the 5G system architecture is defined to support data connectivity and services, enabling deployments using technologies such as network function virtualization and software-defined networking. According to some aspects, the 5G system architecture can utilize service-based interactions between identified control plane (CP) network functions.

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

[0057] The network slice is identified by S-NSSAI, which may include:

[0058] (1) Slice / Service Type (SST), which may refer to the expected network slice behavior in terms of characteristics and services; and

[0059] (2) Slice Differentiator (SD), which may refer to optional information supplementing the slice / service type to distinguish between multiple network slices of the same slice / service type.

[0060] According to some aspects, the S-NSSAI may have a standard value (e.g., the S-NSSAI may consist only of an SST with a standard SST value and no SD) or a non-standard value (e.g., the S-NSSAI may consist of both SST and SD, or only of an SST without a standard SST value and no SD). The S-NSSAI with a non-standard value is capable of identifying a single network slice associated with it within a PLMN. The S-NSSAI with a non-standard value cannot be used by the UE in access stratum procedures in any PLMN, except the PLMN associated with the S-NSSAI. Table 1 shows standardized SST values.

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

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

[0063] In accordance with some aspects, based on the requested NS SAI (if any) and subscription information, the 5GC may be responsible for selecting a network slice instance to serve the UE, including the 5GC control plane and user plane network functions corresponding to the network slice instance.

[0064] In accordance with some aspects, the (R)AN may use the requested NSSAI in access stratum signaling to handle the UE control plane connection before the 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] clause 6.3.5. When the UE inquires about resuming the RRC connection and is connected to an RRC inactive CM, the UE MUST NOT include the requested NSSAI in the RRC resumption.

[0065] According to some aspects, when a UE successfully registers with an access type, the CN may inform the (R)AN by providing the allowed NSSAI for the corresponding access type.

[0066] According to some aspects, standardized SST values ​​may provide a means for establishing global interoperability of slices, so that PLMNs may more efficiently support roaming use cases for the most commonly used slice / service types. For example, the standardized SST is in Table 1 below.

[0067] Table 1. Standardized SST values ​​[1]

[0068] Slice / Serving Type SST value characteristic eMBB 1 Suitable for processing slices for 5G enhanced mobile broadband. URLLC 2 Slices suitable for handling ultra-reliable and low-latency communications. MIoT 3 Suitable for processing large amounts of IoT slices. V2X 4 Slices suitable for handling V2X services.

[0069] According to some aspects, the configured NSSAI may be an NSSAI provided in the UE that is applicable to one or more PLMNs. The configured NSSAI may be configured by the serving PLMN and may be applicable to the serving PLMN. According to some aspects, each PLMN may have at most one configured NSSAI.

[0070] According to some aspects, a default configured NSSAI may be configured by the HPLMN, e.g., applicable to any PLMN for which a specific configured NSSAI is not provided to the UE. The value used in the default configured NSSAI may be expected to be generally determined by all roaming partners. If the default configured NSSAI is configured in the UE, the UE may be able to use it in the serving PLMN only if the UE does not have an NSSAI configured for the serving PLMN. The UE may be pre-configured with a default configured NSSAI.

[0071] According to some aspects, the requested NSSAI may be the NSSAI provided by the UE to the serving PLMN during registration. The S-NSSAI in the requested NSSAI may be a portion of the configured and / or allowed NSSAI applicable to the PLMN, e.g., when they are available. If no configured NSSAI and allowed NSSAI for the PLMN are available, the S-NSSAI in the requested NSSAI may correspond to the default configured NSSAI, e.g., if configured in the UE.

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

[0073] According to some aspects, the allowed NSSAI may be an NSSAI provided by the serving PLMN, for example, during a registration procedure, indicating the S-NSSAI values ​​that the UE may use in the serving PLMN for the current registration area. When the UE's registration procedure is successfully completed with an access type, the UE may obtain the allowed NSSAI for that access type from the AMF, which includes one or more S-NSSAIs and (if necessary, e.g., see clause 5.15.4.1.2) their mapping to the HPLMN S-NSSAI. These S-NSSAIs may be valid for the current registration area and access type provided by the AMF with which the UE has registered, and may be used by the UE simultaneously (e.g., up to the maximum number of simultaneous network slice instances or PDU sessions).

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

[0075] According to some aspects, the mapping of configured NSSAIs may be a mapping of each S-NSSAI of the configured NSSAI of the serving PLMN to the HPLMN S-NSSAI.

[0076] 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 within a PLMN may include core network control plane and user plane network functions. According to some aspects, a network slice instance is defined as a set of network function instances and the required resources (e.g., computing, storage, and networking resources) that form a deployed network slice.

[0077] According to some aspects, network slices may differ with respect to supported features and network function optimizations, in which case such network slices may have different slice / service types. Operators may be able to deploy multiple network slice instances that deliver the same features, but for different groups of UEs, for example, because they deliver different promised services and / or because they are dedicated to customers, in which case such network slices may have the same slice / service type, but be distinguished by different slice discriminators.

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

[0079] According to some aspects, network slice-specific authentication and authorization procedures may be triggered for S-NSSAI that requires network slice-specific authentication and authorization with an AAA server (AAA-S), which may be hosted by the HPLMN operator or by a third party that has a business relationship with the HPLMN using an EAP architecture. For example, if the AAA server belongs to a third party, an AAA proxy (AAA-P) in the HPLMN may be involved.

[0080] In accordance with 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 an S-NSSAI among the currently allowed NSSAI requires network slice-specific authentication and authorization (e.g., subscription change), or when the AAA server authenticating the network slice triggers re-authentication.

[0081] According to some aspects, the AMF may perform the role of an EAP authenticator and communicate with the AAA-S via a network slice specific SNPN authentication and authorization function (NSSAAF). The NSSAAF may assume any AAA protocol that interacts with the AAA protocol supported by the AAA-S.

[0082] According to some aspects, network slice specific authentication and authorization procedures may require the use of GPSI. For example, a subscription containing an S-NSSAI subject to network slice specific authentication and authorization may include at least one GPSI. According to some aspects, Figure 3 A call flow diagram showing the NSSAA procedure (eg, clause 4.2.9.2 of TS23.502 [2]).

[0083] In some aspects, PDU session establishment authentication / authorization may optionally be triggered by the SMF during PDU session establishment and performed transparently via the UPF, or directly with the DN-AAA server without involving the UPF if the DN-AAA server is located in the 5GC and can be reached directly (e.g., clause 5.6.6 of TS23.501[1]).

[0084] According to some aspects, in case of home-routed roaming, unless otherwise specified, the SMF in the information flows defined in this clause is the H-SMF.

[0085] According to some aspects, Figure 4 Steps 2, 3a, 3f, and 4 may be undefined. Depending on the mechanism used, step 3 may be repeated. 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 identifier (e.g., TS TS33.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., TS24.501).

[0086] According to some aspects, the contents of the SM PDU DN request container are defined in TS24.501. If there is no existing N4 session available to carry DN related messages between the SMF and the DN, the SMF may select a UPF and trigger an N4 session establishment.

[0087] 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 TS29.561). When available, the SMF may provide the GPSI in the signaling exchanged with the DN-AAA. The UPF may transparently relay messages received from the SMF to the DN-AAA server.

[0088] The steps of establishing authentication / authorization for a PDU session of a DN-AAA server can be described as follows:

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

[0090] Step 3b: The DN request container information received from the DN-AAA may be transmitted to the UE. According to some aspects, in non-roaming and LBO cases, the SMF may invoke the Namf_Communication_NlN2MessageTransfer service operation on the AMF to transmit the DN request container information within the N1SM message sent to the UE. According to some aspects, in the case of home route roaming, the H-SMF may initiate a Nsmf_PDUSession_Update service operation to request the V-SMF to transmit the DN request container to the UE, and the V-SMF may invoke the Namf_Communication_NlN2MessageTransfer service operation on the AMF to transmit the DN request container information within the N1SM message sent to the UE. In the Nsmf_PDUSession_Update request, the H-SMF may additionally include the H-SMF SM context ID.

[0091] Step 3c: AMF may send N1 NAS message to UE

[0092] Steps 3d-3e: The DN request container information received from the UE may be delivered to the DN-AAA. According to some aspects, when the UE responds with an N1 NAS message containing the DN request container information, the AMF may notify the SMF by invoking the Nsmf_PDUSession_UpdateSMContext service operation. The SMF may issue a 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 via the Nsmf_PDUSession_Update service operation in step 3b.

[0093] Step 3f: The SMF (e.g., in the case of HR, it is the H-SMF) may send the content 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 may be repeated until the DN-AAA server confirms successful authentication / authorization of the PDU session.

[0094] Step 4: The DN-AAA server may confirm successful authentication / authorization of the PDU session. According to some aspects, the DN-AAA server may 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 clause 5.6.6 of TS 23.501 [1]); (3) a request notified with an IP address assigned to the PDU session and / or with N6 service 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.

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

[0096] According to some aspects, after successful DN authentication / authorization, a session may be maintained between the SMF and the DN-AAA. If the SMF receives DN authorization data, the SMF may apply policy and charging control using the DN authorization profile index (e.g., clause 5.6.6 of TS23.501 [1]).

[0097] Step 5: PDU session establishment can continue and complete. For example, in TS 23.503 [2] Figure 4 In step 7b of .3.2.2.1-1, if the SMF receives a DN authorization profile index in the DN authorization data from the DN-AAA, it may send the DN authorization profile index to retrieve PDU session related policy information (e.g., clause 6.4 of TS23.502

[20] ) and PCC rules (e.g., clause 6.3 of TS 23.503 [6]) from the PCF. According to some aspects, if the SMF receives a DN authorization session AMBR in the DN authorization data from the DN-AAA, it may send the DN authorization session AMBR within the session AMBR to the PCF to retrieve the authorization session AMBR (e.g., clause 6.4 of TS23.503 [6]). For Ethernet type PDU sessions, the SMF may instruct the UPF to process VLAN information of Ethernet frames associated with PDU sessions received and sent on N6 or N19 or internal interfaces (e.g., clause 5.6.10.2 of TS23.501 [1]).

[0098] Step 6: If so requested in step 4, or if so configured by local policy, the SMF may notify the DN-AAA of the IP / MAC address and / or N6 service routing information assigned to the PDU session, as well as the GPSI.

[0099] According to some aspects, each service area restriction may include one or more (e.g., up to 16) entire tracking areas, or the service area restriction may be set to be unlimited (e.g., including all tracking areas of the PLMN). The subscription information of the UE in the UDM may include the service area restriction, which may include the allowed area or non-allowed area specified by using explicit tracking area identification 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 managed only in the network, and the network may map the service area restriction information to the TA list before sending it to the PCF, NG-RAN, and UE.

[0100] According to some aspects, when the AMF allocates a limited allowed area to the UE, the AMF may provide the UE with a service area restriction consisting of an allowed area or a non-allowed area. The allowed area included in the service area restriction may be pre-configured and / or dynamically allocated by the AMF.

[0101] According to some aspects, the allowed area may alternatively be configured as unrestricted, for example, it may contain all tracking areas of the 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 TAs during the registration procedure, which may be a subset of the full list stored in the UE's subscription data or provided by the PCF.

[0102] According to some aspects, the NG-RAN may prefer to use specific radio resources per data radio bearer, for example, depending on the network slice associated with the data radio bearer used by the UE. UE idle mode mobility control and priority-based reselection mechanisms operate (e.g., clause 5.3.4.3.1 of TS23.501), and when UP resources are activated (e.g., for a specific S-NSSAI), the NG-RAN may use local policies to decide what specific radio resources to use for the associated radio bearers. The UE may be served by a set of data radio bearers that may be served by cells in different frequency bands selected based on RRM policies.

[0103] According to some aspects, if a network slice is configured to be available only in a TA covering a specific dedicated band, the UE may need to be redirected to the dedicated band when such S-NSSAI is requested. If the requested NSSAI contains an S-NSSAI that is not available in the UE's current TA, the AMF itself or through interaction with the NSSF may determine the target NSSAI to be used by the NG-RAN to attempt to redirect the UE to a cell and TA in another band and a 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 band. The target NSSAI may only include S-NSSAI that can be provided in the allowed NSSAI for the UE.

[0104] According to some aspects, if a network slice is configured to be available only in a TA covering a specific dedicated band, the UE may need to be redirected to the dedicated band when such S-NSSAI is requested. If the requested NSSAI contains an S-NSSAI that is not available in the UE's current TA, the AMF itself or through interaction with the NSSF may determine the target NSSAI to be used by the NG-RAN to attempt to redirect the UE to a cell and TA in another band and a 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 band. The target NSSAI may only include S-NSSAI that can be provided in the allowed NSSAI for the UE.

[0105] According to some aspects, the NG-RAN may attempt to find a cell of a TA that can support all S-NSSAIs in the target S-NSSAI, and if no such cell of the TA is 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 of activated user plane associated with S-NSSAIs in the allowed NSSAIs in the target NSSAI. In addition, before prioritizing cells that do not support one or more of the S-NSSAIs of the allowed NSSAIs that are also available in the target NSSAI, the NG-RAN may attempt to ensure continuity of services of the S-NSSAIs of the allowed NSSAIs that are also available in the target NSSAI.

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

[0107] According to some aspects, a UE routing policy (URSP) may include a prioritized list of URSP rules [6], for example, Table 2 shows the URSP. In addition, exemplary structures of URSP rules are described in Tables 3 and 4.

[0108] Table 2. UE Routing strategy

[0109]

[0110] The structure of the URSP rules is described in Table 3 and Table 4, as follows:

[0111] Table 3. UE Routing policy rules

[0112]

[0113]

[0114] Table 4. Routing Descriptor

[0115]

[0116]

[0117] According to some aspects, a UE, such as a smart phone, may obtain UE applications from one or more third parties that may also provide services to the UE. The UE may establish multiple PDU sessions with the core network at one time. A PDU session is typically triggered by an application in the UE. For example, when an application is launched, the application may want to access services from an application server in the data network. Figure 5 As shown, application App1 can establish a PDU session with the URLLC network slice, as shown by the solid line in the figure. The PDU session can be established based on the URSP rules. If the URSP rules for App3 also indicate the same S-NSSAI as its preferred slice in the PLMN (e.g., URLLC slice), the UE can use the existing PDU session that App1 has previously established. 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 rules.

[0118] According to some aspects, a mobile UE, such as a connected car, may have established a PDU session with one or more network slices in the core network. As the UE moves, it may cross new locations (e.g., TA / RA) where it may lose access and may not be able to access any authorized network slice. Figure 6 As shown in , the vehicle-mounted UE (CC1) in location A that is accessing the game slice may not be able to access any slice at location B.

[0119] According to some aspects, a URSP rule in a UE may direct an application in the UE to use a PDU session that may have been established by another (eg, first) application, such as Figure 5 The second application may belong to a different third party and may therefore need to be authorized before it uses the network slice. The current 5GS specification does not define how 5GS performs per-application authentication and authorization for access to network slices or DNs.

[0120] According to some aspects, the UE may already have 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 be able to access any authorized network slices in the new location. The current 5GS does not describe how the UE can handle such scenarios, so that the UE can notify the UE applications that a slice may become unavailable and the applications can terminate gracefully or save their state (e.g., idle, connected, active, inactive, etc.). Additionally, the 5GS does not describe how the UE can save power in such scenarios by reducing undesired application activity in the UE.

[0121] 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 the data network via a network slice. Each UE application may have been installed in the UE for different services provided by various third parties (e.g., games, videos, IoT control, etc.), and therefore may require different levels of resources for performance, etc. The data network and / or network slice may require the application to be authorized before receiving services via the application function using the slice. Therefore, the 5G system may require a per-application authentication and authorization (PAAA) procedure. The following sections describe the method of PAAA.

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

[0123] When an application triggers a PDU session, the UE may identify the selected network slice as being PAAA compliant based on the PAAA indicator. Figure 7 An enhanced UE registration procedure is shown when a PAAA indicator is communicated to the UE.

[0124] In step 0, each S-NSSAI subject to PAAA may be associated with a per-application authentication and authorization (PAAA) indicator in the UE access and mobility subscription of the UE at the UDM / UDR. According to some aspects, the PAAA requirement for slice access may depend on factors such as the MNO's agreement with third parties regarding services, security requirements, local policies, etc.

[0125] According to some aspects, the PAAA information associated with a slice may be an indication of whether the slice requires PAAA from the UE. For the UE, the PAAA information may be implemented as setting or not setting a flag. Setting the flag may indicate that the slice is subject to PAAA, and not setting the flag may indicate that PAAA is not required from the UE to access the slice.

[0126] 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 TS23.502). In the request, the UE may also indicate its support for PAAA.

[0127] In accordance with some aspects, the request may include the requested NSSAI. In the case of an initial registration or a mobility registration update, the UE may include a mapping of the requested NSSAI (if available) to each S-NSSAI of the requested NSSAI to the HPLMN S-NSSAI to ensure that the network can verify whether the S-NSSAI in the requested NSSAI is permitted based on the subscribed S-NSSAI.

[0128] In step 2, the RAN may select an AMF (eg, TS 23.501 [1], clause 6.3.5).

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

[0130] In step 4, if the AMF does not have the subscription information of the UE, the AMF may use Nudm_SDM_Get to retrieve the access and mobility subscription information, SMF selection subscription information, UE context in SMF information, etc. The UE subscription information retrieved from UDM may contain a set of S-NSSAIs to which the UE subscribes, and each S-NSSAI may contain a PAAA indication.

[0131] In step 5, the AMF sends a Registration Accept message to the UE via the (R)AN node. The Registration Accept may include the allowed NSSAIs of the UE for each S-NSSAI configured with a PAAA indicator. If the indicator is a flag and the S-NSSAI is compliant with the UE's PAAA, the flag may be set. Otherwise, the flag may not be set.

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

[0133] If NSSAA is required for network slicing, the current 5G system design only considers per-UE authentication and authorization. However, each application may affect access to application functions or data networks. Therefore, the permission for the application to access the UE's network slice is coupled with the permission for the application to access the application function / DN. This section describes the method by which the core network authenticates and authorizes each application attempting to access the network slice and AF / DN. Figure 8 An exemplary procedure is shown and described as follows.

[0134] In step 1, the first application (e.g., App1) in the UE starts communication traffic. The UE determines that it needs to establish a PDU session. App1 may provide a service descriptor to the UE. The service descriptor may be an application descriptor, an IP descriptor / address, a DNN, etc. (e.g., Table 6.6.2.1-2 of TS23.503). The UE may evaluate the URSP rules composed of the service descriptors provided by App1. The RSD in the URSP rules may include S-NSSAI. Assume that the S-NSSAI includes Figure 3 If the PAAA indicator described in , the UE can identify that any PDU session established in the slice needs to go through the PAAA procedure.

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

[0136] Optionally, the UE may include a PAAA trigger indicator in the PDU session request. The PAAA trigger indicator may be used later to notify the SMF to trigger the PAAA procedure.

[0137] 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 communication traffic from.

[0138] The application descriptor may include a service provider ID. The network and the UE may be preconfigured 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 what server the PDU session will be used to send and receive communication traffic from.

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

[0140] In step 2, the AMF may determine that the message corresponds to a request for a new PDU Session, where the request type indicates "initial request" and the PDU Session ID is not used for any existing PDU Session of the UE. The AMF selects the SMF (e.g., clause 6.3.2 of TS23.501 [1]).

[0141] In step 3, if the AMF does not have an association with the SMF for the PDU Session ID provided by the UE (e.g. when the request type indicates "initial request"), the AMF may call the Nsmf_PDUSession_CreateSMContext request.

[0142] In step 4, based on a request from the UE including an application descriptor and the S-NSSAI (e.g., S-NSSAI-A) that the UE wants to access, and a PAAA trigger indicator from the UE, the SMF may trigger the PAAA process. Alternatively, the SMF may also trigger the PAAA process based on a policy received from the PCF. The SMF may determine that it needs to contact the DN-AAA server for the PAAA procedure. The SMF may identify the DN-AAA server based on local configuration, the application descriptor, or using a DN-specific identifier, and send the application descriptor together with the request for PAAA to the DN-AAA server.

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

[0144] In step 5b, for LBO or non-roaming case, the SMF may transmit the DN request container information received from the DN-AAA to the UE by invoking the Namf_Communication_N1N2MessageTransfer service operation on the AMF within the N1 SM message.

[0145] For home route roaming, the H-SMF may initiate a Nsmf_PDUSession_Update service operation to request the V-SMF to transmit a DN request container to the UE, and the V-SMF invokes the Namf_Communication_N1N2MessageTransfer service operation on the AMF to transmit the DN request container information within the N1SM message sent to the UE.

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

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

[0148] In step 5e, AMF may notify SMF by calling Nsmf_PDUSession_UpdateSMContext service operation. SMF may issue Nsmf_PDUSession_UpdateSMContext response.

[0149] In 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 via the Nsmf_PDUSession_Update service operation.

[0150] In step 5f, the SMF (or H-SMF in the case of a home router) may send the content of the DN request container information (authentication message) to the DN-AAA server via the UPF.

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

[0152] 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 also 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 the network slice.

[0153] 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 specific 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, where the UE is allowed to access the DN-AAA using App1.

[0154] In step 7, the SMF may send an N4 session establishment / modification request to the UPF and provide the packet detection, enforcement and reporting rules to be installed on the UPF for the PDU session. The SMF may instruct the UPF to perform IP address / prefix allocation and include the information required by the UPF to perform the allocation. The request may include the IP address, port number and MAC address of the AF received from the DN-AAA server. The UPF may use this information to determine what address the PDU session can use to send / receive communication traffic. The UPF can confirm by sending an N4 session establishment / modification response. The N4 session establishment / modification request may also indicate to the UPF that all downlink communication traffic to the UE can be allowed, but only uplink communication traffic is allowed to the indicated IP address, port number and MAC address. It may be useful to allow downlink communication traffic to the UE so that the server can initiate contact with the UE; then, when the UE attempts to send uplink communication traffic to the new destination, the UE can be authenticated.

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

[0156] The AMF may forward the PDU session establishment accept message and the AF IP address, port number, and MAC address to the UE via the RAN.

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

[0158] According to some aspects, Figure 8 In step 9, the UE has received a set of authorized IP addresses for the AF using the PDU Session Setup Accept message, and the UE can contact the AF via the PDU session using a specific S-NSSAI. For example, App1 may have an ongoing PDU session via a network slice (e.g., S-NSSAI-A).

[0159] A second application (App2) communication traffic may begin. App2 may provide a service descriptor (e.g., OSid, DNN, IP address, etc.) to the UE. The UE may evaluate the URSP rules and determine that there is an existing PDU session toward an S-NSSAI and DNN that matches the S-NSSAI and DNN in the URSP rules. However, since the service descriptor that the UE is attempting to access is an AF (IP address) that is not authorized for this PDU session using S-NSSAI (e.g., S-NSSAI-A), the UE may learn that the UE is not authorized to access the network slice. In other words, the IP address to which App2 is attempting to send data may not be among the authorized IP addresses, which are Figure 8 The PDU described in step 8 is received in the SESSION SETUP ACCEPT message.

[0160] On the other hand, the UE may be authorized to use the corresponding network slice to access the IP address (e.g., AF) where the UE has established a PDU session for App1.

[0161] According to some aspects, another alternative to triggering the PAAA procedure is to configure the PAAA trigger indicator information in the URSP rules so that the UE can send a new PDU session request with a PAAA trigger indicator, which will trigger the PAAA procedure in the SMF. Another alternative is to configure the PAAA trigger indicator locally for the SMF, or the SMF can obtain information or policy from another NF (such as PCF or UDM) to trigger the PAAA procedure.

[0162] In accordance with some aspects, the UE may use an existing PDU session instead of establishing a new PDU session. When the UE identifies that a second UE application does not have authorization to access the network slice and AF using an existing PDU session established by another application based on the authorized AF / DN IP address received from the DN-AAA server, it may be more efficient for the UE to send a PDU session modification command with a request for PAAA for the second application, so that if the UE successfully completes the PAAA process, the PDU session is modified and the UE can merge the communication traffic originating from the second application into the PDU session. Fig. 9 A call flow describing a method for PAAA with PDU session modification is shown.

[0163] In step 1, the first application (App1) may have used Figure 8 The network slice (S-NSSAI-A) described in establishes a PDU session towards the AF / DN.

[0164] In step 2, a second application (App2) may start communication traffic. The UE may determine, when evaluating the URSP rules, based on the authorized IP address of the AF received in step 1, that App2 should use the same PDU session established for App1 but App2 is not authorized to access the AF.

[0165] Therefore, the UE may send a PDU Session Modification NAS message to the network. The PDU Session Modification message may include a PDU Session Modification Request, a PDU Session ID, a requested QoS, etc. Together with the PDU Session Modification message, the UE may include a new application descriptor (e.g., for App2) and a PAAA trigger indicator indicating the need for PAAA.

[0166] In step 3, the AMF may forward the PDU Session Modification message to the SMF. Based on the request and the application descriptor and / or PAAA trigger indicator received from the UE, a procedure for per-application authentication and authorization (PAAA) may be triggered at the SMF. Alternatively, the SMF may trigger the PAAA procedure based on information provided by another NF such as the PCF and / or UDM.

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

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

[0169] In step 6, the SMF may send an N4 Session Modification Request to the UPF and provide the packet detection, enforcement and reporting rules to be installed on the UPF for matching the PDU session. The SMF can instruct the UPF to perform the IP address / prefix allocation and include the information required by the UPF to perform the allocation. This may include the IP address, port number and MAC address of the AF received from the DN-AAA server, where the UPF is allowed to establish a PDU session to send / receive communication traffic. The UPF may confirm by sending an N4 Session Establishment / Modification Response.

[0170] In step 7, the SMF may respond to the AMF with a Nsmf_PDUSession_UpdateSMContext response, which may contain an N1 SM container (PDU session modification command). The N1 SM container may carry a PDU session modification command that the AMF can provide to the UE. It may include QoS rules, QoS flow level QoS parameters (if required by the QoS flow associated with the QoS rules), and corresponding QoS rule operations and QoS flow level QoS parameter operations to notify the UE that one or more QoS rules are added, removed or modified. In addition, the N1 SM container may include a PAAA success message. Together with the PDU session modification command sent to the UE, the SMF may include a message indicating the successful authorization of the application App2. In addition, the message may include an updated list of IP addresses, port numbers, and MAC addresses (e.g., AF) for which the PDU session is authorized to use App2 to send communication traffic.

[0171] In step 8, the AMF may send an N2, e.g., [N2 SM information received from SMF], NAS message (PDU session ID, N1 SM container (PDU session modification command, PAAA success message, and updated list of IP addresses, port numbers and MAC addresses (e.g., AF) that are authorized to use App2 to send communication traffic)), message to the (R)AN. The RAN may only transmit the N1SM container to the UE.

[0172] App2 may start sending data using the same PDU session, which may include, for example, the network slice and AF that App1 is using. The UE may maintain the authorized IP address (e.g., AF) based on UE behavior policy (if any) or based on local policy until the authorized App is completely revoked, or the IP address is cleared.

[0173] In some aspects, the UE may receive updated URSP rules and (re)evaluate their validity in a timely manner in certain circumstances (such as when the UE is registered on 3GPP or non-3GPP access); changes to the allowed NSSAI or configured NSSAI and the URSP may be updated by the PCF (e.g., TS23.503).

[0174] According to some aspects, URSP rules may 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 may determine which network slice(s) will access which AF / DN and whether the application requires PAAA to use that network slice to access the AF / DN.

[0175] According to some aspects, when the UE attempts to establish a PDU session and evaluates the URSP rules, a network slice selection policy (NSSP) within the URSP may be used to make a network slice selection. The NSSP ensures that communication traffic for matching applications can be routed via a PDU session that supports any of the included S-NSSAIs. The URSP may be enhanced by a network slice selection proposed for an application flag (NSSA flag) so that any slice requiring PAAA may be indicated in a URSP rule with the NSSA flag set. The NSSP may be independent of the NSSA flag because 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.

[0176] If the S-NSSAI does not require PAAA, the flag may be not set. According to some aspects, if there is a list of S-NSSAIs in the URSP rules, the flag may act as an indicator and may be for each S-NSSAI. Therefore, for URSP, each S-NSSAI may have a separate NSSA flag. According to some aspects, Table 5 shows an enhanced URSP rule with an NSSA flag.

[0177] Table 5. Enhanced routing descriptor

[0178]

[0179]

[0180] According to some aspects, whenever application communication traffic advances to a PDU session and the UE evaluates the URSP rules, the UE may attempt to select an S-NSSAI from the URSP rules using the NSSP. The RSD of the URSP may be enhanced so that the UE also checks whether the NSSA flag for a specific 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 and an indicator specifying the need for PAAA in the PDU session request to the core network (AMF or SMF). This procedure is in Fig.10 Described in.

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

[0182] Additionally, based on local policy or any agreement with a third party entity, the NSSA flag in the URSP rules may also be set for S-NSSAI that requires PAAA.

[0183] In step 2, when the UE registers on 3GPP or non-3GPP access, when the UE's allowed NSSAI or configured NSSAI changes, when the UE moves from EPC to 5GC; when the URSP is updated by PCF, etc. (e.g., TS23.503); the UE may receive enhanced URSP rules from the core network.

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

[0185] Alternatively, the UE may only send an application descriptor, which may serve as an indication to 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.

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

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

[0188] In step 6, the SMF may send a PDU session establishment accept message back to the UE.

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

[0190] An alternative may be to implement the NSSA flag only for PDU sessions that are not initial or secondary PDU sessions, i.e., for those 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 the S-NSSAI, the first PDU session from the first application (e.g., App1) established on the S-NSSAI (e.g., S-NSSAI-X) may not require PAAA. However, if a second (or subsequent) application (e.g., App2, App3) starts and when evaluating the URSP, the UE may determine that a PDU session will be established on an S-NSSAI (e.g., S-NSSAI-X) that already has an ongoing PDU session, and that the existing PDU session may be used. In such a case, the NSSA flag in the URSP may instruct the UE to send an AA message or a PAAA trigger indicator and the App2 application descriptor to the core network for PAAA.

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

[0192] According to some aspects, the new TA / RA may cover specific dedicated frequency bands, and therefore, there may be available or unavailable network slices on these frequency bands. If the requested NSSAI contains an S-NSSAI that is not available in the UE's new TA, the AMF itself or through interaction with the NSSF may determine the target NSSAI to be used by the NG-RAN in an attempt to redirect the UE to a cell and TA in another frequency band and a TA that supports S-NSSAI in the target NSSAI (see TS23.501), or the UE registration may be rejected due to an empty allowed NSSAI and the PDU session (e.g., if present in an existing network slice) may be abandoned. On the other hand, the 5GS may attempt to remap the network slice with a suitable network slice (if available) so that the ongoing PDU session can be gracefully transferred to the new remapped slice and the 5GS is able to provide service continuity and better user experience. According to some aspects, a remapped slice simply means a suitable slice, where the PLMN chooses to transfer the PDU session from another slice.

[0193] According to some aspects, slice remapping may involve disassociating a communication flow (or PDU session) from a first slice and / or S-NSSAI, and associating the communication flow (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 a UE, and sending a notification message to the UE to notify the UE that the PDU session 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 a PDU session associated with a first S-NSSAI be disassociated from the first S-NSSAI and associated with the second S-NSSAI.

[0194] According to some aspects, it is assumed that the bands / cells overlap in a TA and multiple TAs are available to the UE. However, based on time factors or due to licensing, a network slice may also be unavailable to the UE. Therefore, the UE may also encounter a situation where there may be no authorized slices and the UE may attempt frequent cell searches and exhaust its power too quickly. In another scenario, the UE may not be prepared for a sudden but temporary band interruption (and therefore network slice interruption) and cannot handle the ongoing PDU session. The UE may span several different scenarios. For example:

[0195] The network slice may simply be unavailable as no service may be available in the TA.

[0196] No authorized network slices are available to the UE in the TA. However, the UE is able to access alternative slices with special privileges / permissions and authorizations.

[0197] No authorized network slices are available to the UE in the TA. However, network slices may be available in neighboring TAs.

[0198] A network slice may not be available for a period of time, but may become available soon (e.g., at 1800 hours).

[0199] This section describes how time and location information can be used to enhance 5GS so that the UE can be better prepared to handle ongoing PDU sessions. Additionally, this section also describes how the UE can utilize time and location information to improve UE efficiency.

[0200] According to some aspects, the UE subscription information in the core network may include the 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 TS23.502). In addition, the AMF and / or NSSF may identify the frequency bands in which one or more network slices are available or unavailable. In addition to this information, the UE and the core network can also utilize spatial and temporal information, which can describe the availability of network slices at certain times and locations. The above describes time and space information (TSI) and how the UE and the network can utilize TSI to work more efficiently.

[0201] In accordance with some aspects, if a network slice is temporarily unavailable, or if there is a time restriction on slice access for the UE, in other words, the network slice may be active only during a certain time period, or if the network slice is not authorized to the UE for a defined time period, then this information may be configured in the core network along with the UE subscription information and may be made available to the AMF or UDM and ultimately to the UE.

[0202] On the other hand, the core network (e.g., UDM, NSSF, AMF, or PCF) may have information about what network slices are available in the network or available in certain TAs and RAs. As discussed below, this information may include whether the UE can camp on certain cells and whether network slices are authorized to the UE in certain frequency bands (e.g., may be delivered in allowed NSSAI).

[0203] The above-mentioned merged TSI can be used to inform the network and therefore the UE about the upcoming network slice access availability. Depending on the UE and its location / state, the upcoming availability may be temporary. In other words, the core network can determine when the UE can or cannot access certain network slices in advance. For example, the UE may be within a home network, or the UE may span a VPLMN, and if the authorized network slices in the serving PLMN are only active during a specified period (e.g., after 6:00PM and until 6:00AM), this information can be used for the benefit of the UE.

[0204] Similarly, the upcoming availability of network slices 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 in a certain direction. The GPS in the car may be set to follow a specific route. For such a car, location services, the rate at which the UE is moving, and the predefined direction may give the core network a satisfactory probability that the car can travel to a specific geographic location (e.g., TA / RA) with that probability. Based on this information, the core network is able to estimate the nature of the communication traffic, the minimum, average, and / or maximum bandwidth that the UE can consume, which can be converted for the network to understand what services and network slices the UE requires. Assuming that the network has information about the slices that the UE is authorized to access, the frequency bands available for the slices, and the TAs available for the network slices, both aspects can be planned in advance.

[0205] First, the network is able to depict the topology of the TA. The topology information may include the neighboring TA where the UE is currently located, the TA where most network slices are authorized to the UE and where frequency band network slices are available, a list of neighboring TAs covering a specific radius, the distance between TAs of interest (e.g., TAs where network slices are authorized), etc. There may be coverage gaps in the TA, i.e., TAs where no authorized network slices are available or are in slice-inaccessible (no access) areas. Using this information, the network is able to schedule efficient band redirection for the UE and proactively redirect the UE to a TA and / or frequency band where most relevant network slices are authorized. In this way, the UE does not need to wait to request a network slice, and the network slice will then trigger the UE to redirect to the appropriate frequency band.

[0206] Second, this information can be communicated to the UE so that the UE can utilize this information to determine the desired neighboring TA and therefore the available network slices in the frequency band of interest, which can give the UE the opportunity to change its direction and maintain a suitable speed when necessary, so that the UE (e.g., a drone, a connected car, etc.) can decide to follow a path towards a TA where the desired slice is available or a TA where there is a high probability of finding an authorized network slice.

[0207] Time and space information about slice availability, authorized S-NSSAI, TA topology (including neighboring TAs), frequency band information, TA / RA id lists, etc. may be sent to the UE during UE configuration update or when necessary using NAS messages. 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.

[0208] In addition to the UE's decision to change direction or the core network's decision to proactively redirect the UE to an appropriate band and / or TA, the UE can also utilize TSI so that the UE can interact with active or to-be-active applications to reduce undesired operations and thereby reduce power consumption and improve UE efficiency.

[0209] If time information about the network slices in the TA is available to the UE (e.g., slice A is inactive between 6AM and 6PM), the UE is able to pause / stop the PDU session to be established. For example, if an application task requires a significantly longer PDU session (e.g., gaming) and if the inactive period of the network slice is approaching, the UE may decide to stop the start of that PDU session and inform the interested parties of the reason. This may mean that the UE may notify the UE application and / or disable requests originating from the UE application, or if the application has not started any PDU session, establish a session backoff time during which the application cannot start a PDU session. The UE may log a message for its decision and send it to the network or notify the user if necessary. Using such a message, the UE may take action to try another network slice (if available) or request another network slice (if feasible).

[0210] 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 so that the UE can pass through such a TA relatively quickly, the UE may trigger an action to prepare buffered UL data for applications whose access to the slice will be unavailable. For example, the uplink data may be transmitted after a delay (e.g., based on a trigger or temporary availability of the network slice) so that the application will have access to the slice. The delay may be based on the timing of the availability of the slice, for example, when an unavailable slice will become available. Similarly, the core network (AMF or SMF) may trigger the participating UPF to buffer DL data (for SSC mode 1). As discussed herein, the TA topology may be notified to the UE so that the UE may take actions to reduce operations and save power consumed by the UE.

[0211] If there are no authorized network slices available in the TA or there are no authorized network slices available in the TA for a predefined period, the UE may take one or more of the following actions. For example:

[0212] The UE may reduce cell search attempts (eg, reduce cell searches by 80%).

[0213] The UE may save the state of the application (e.g., idle, connected, active, inactive, etc.). For example, a UE application may already be waiting for a response from the network. Such state may be saved and picked up later if the authorized slice is online.

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

[0215] The UE may save any background data state and / or delay data transmission.

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

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

[0218] If the PLMN supports slice remapping, the UE may prepare for slice remapping.

[0219] The UE may disable broadcast type activities.

[0220] The UE may reduce the time to reach the sleep state or put the UE to sleep immediately.

[0221] The UE may start a static timer that will allow the UE to perform all of the aforementioned actions for a certain amount of time (e.g., actions such as buffering UL data may be prevented from continuing indefinitely). If the unavailability of the network slice continues to persist beyond the static timer, the UE may cancel the application process entirely and flush any incomplete UL data and application state. On the other hand, the SMF may start a different static timer as soon as the UE enters a TA where the authorized slice is unavailable.

[0222] If the UE determines based on the combined spatial and temporal information that unauthorized slices will be available via a 3GPP access type but accessible via a non-3GPP access type, the UE may trigger a path switch and offload application communication traffic to the non-3gpp access type.

[0223] The UE capability may be referred to as UE Application Interaction and Steering Capability (AISC), through which the UE may receive a merged TSI, may use the merged TSI to interact with UE applications, and based on the TSI, may steer the UE if a network slice is available, thereby improving overall UE efficiency.

[0224] According to some aspects, it may be desirable to inform the network of the UE AISC using an AISC indicator. Alternatively, the UE may send the network a UE release or version number / identifier, which may help the network determine whether the UE is capable of receiving and using TSI. Fig.11 As described in, after a successful UE registration, the TSI may simply be communicated to the UE during the UE registration or UE registration update procedure.

[0225] In step 1, the UE may send a registration request or a registration update request to the core network (AMF) via the RAN. In the request, the UE may send an AISC indicator to the network. Alternatively, the indication may also be implicitly conveyed by sending a UE release number / identifier (e.g., 3GPP Rel-18, 5G Advanced, etc.), so that once such capabilities are identified, the network may send TSI to the UE. Application interoperability 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.

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

[0227] In step 3, when the UE registration is successful, the core network (AMF) may send a UE registration accept message to the UE via the RAN. The network may include UE spatial and temporal information in the registration accept message.

[0228] Communicate TSI to UE using UE Configuration Update procedure

[0229] According to some aspects, the TSI may be communicated to the UE using a UE configuration update procedure instead. In the event that there is new TSI available, the network may trigger the UE configuration update procedure. According to some aspects, Fig.12 A method by which TSI may be communicated during a UE configuration update procedure is described in.

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

[0231] This procedure may also be used to trigger the UE to perform a Mobility Registration Update procedure based on network indication while the UE is in CM-CONNECTED state to modify NAS parameters that require negotiation (e.g., MICO mode) or to redirect the UE to the EPC (e.g., as specified in clause 5.31.3 of TS 23.501 [1]), or to perform a Mobility Registration Update procedure after the UE enters CM-IDLE state (e.g., for changes in allowed NSSAI that require re-registration). If a registration procedure is required, the AMF may provide an indication to the UE to initiate the registration procedure.

[0232] When applicable, the UE configuration update may be sent by the access type (e.g., 3GPP access or non-3GPP access) to which the UE configuration update is applied. After the NAS parameters including the time and space information update reach the UE, the AMF may request UE confirmation.

[0233] According to some aspects, Fig.12 A UE configuration update procedure for communicating spatial and temporal information to a UE is shown in FIG.

[0234] In step 0, the AMF may determine the necessity of 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 enhanced coverage limitation information in the UE context) or the UE needs to perform a registration procedure. Reasons may include the need for the network to notify the UE of (updated) time and space information (TSI).

[0235] In step 1, the AMF sends an enhanced UE configuration update command containing one or more UE parameters (including TSI). TSI may include an enhanced TAI list, which includes TA topology and / or gap TA and authorization time, etc., as discussed in this document.

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

[0237] Alternatively, the core network (AMF) may transmit the TSI to the UE using a NAS message.

[0238] According to some aspects, the MNO / PLMN may have geographical areas where only those UEs may be allowed with special permissions. For sensitivity or resource availability reasons, the MNO may set up network slices for special access. Interstitial TA (slice inaccessible area) may provide special permissions and authorizations to network slices used only for special services. According to some aspects, Fig.13 Describes how a UE can submit special permissions / privileges and receive an alternative network slice from the network.

[0239] This section describes how the UE may send a set of credentials and / or identities to the network so that the network may determine to add slices to the UE's configured NSSAI. According to some aspects, this may be useful in a scenario where the UE enters a TA / RA where the UE does not have slices accessible in its configured NSSAI in the TA / RA. The procedures described below may allow a user to enter an identity and / or set of credentials that may be sent to the network in order to update the configured NSSAI with slices accessible in the current RA / TA.

[0240] In step 0, the UE may have received an enhanced privilege identification (EPID), which is a separate unique identification for special privileges / permissions. The EPID may represent enhanced permissions for the UE. For example, the UE may be a designated UE with the highest privileges for the highest ranking military officers or diplomats, or the UE may have a special subscription for enhanced privileges that is triggered only when encountering scenarios classified as "special". "Special" scenarios may be when no slices are authorized in some geographical areas.

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

[0242] Alternatively, the UE and the network may identify in advance from the TA topology information (merged TSI) discussed herein that there are no authorized network slices available in the TA / RA covering a specific geographical area (which may include a list of TAs covering neighboring TAs). Based on the UE subscription information, the network may also determine that the UE has enhanced privileges, and therefore, the AMF may send a request for the EPID to the UE and ask the UE whether it is willing to use the privilege.

[0243] Alternatively, when querying the UE for the EPID, the network may send back a set of alternative S-NSSAIs to the UE.

[0244] In step 2, the UE may send its 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 invalid / expired or untrusted, the AMF may send back a NAS message indicating that the UE is denied access to any network slice with a cause code.

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

[0246] In step 4, the AMF may send a set of alternative S-NSSAIs to the UE, which the UE may access using the EPID in the allowed NSSAI with the Registration Accept message.

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

[0248] According to some aspects, Fig.14 The front and back user interfaces of a UE (e.g., a smart phone) are shown. The front part shows many applications installed in the UE, indicating that there may be applications from different vendors. The back user interface shows the features of the enhanced UE. Specifically, the UE is equipped with a UE release version identifier, an S-NSSAI with a PAAA indicator, an enhanced URSP with an NS SA flag, and combined time and space information received from the core network.

[0249] According to some aspects, the application may present a GUI that allows the user to enter an application instance identification and / or a set of credentials associated with the application instance. The application instance identification and / or a set of credentials may then be used by the UE in the PAAA procedure described above.

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

[0251] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (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 communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle communications with other entities. Specific services and applications within these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robotics, and drones. All of these use cases and others are considered in this article.

[0252] Fig.15AAn exemplary communication system 100 is shown in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which are generally or collectively referred to as WTRUs 102 or multiple WTRUs 102. The communication system 100 may include a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and network services 113. 113. The network services 113 may include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, etc.

[0253] It should be appreciated that the concepts disclosed herein may be used with any number of WTRUs, base stations, networks, and / or network elements. Each WTRU in WTRU 102 may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Fig.15A In the example, Figures 15A-15E 102 is depicted as a handheld wireless communication device. It should be understood that, in the context of various use cases contemplated for wireless communication, each WTRU may include or be included in any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only: a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet computer, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic device, a wearable device (such as a smart watch or smart clothing), a medical device or an e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, a truck, a train or an airplane, etc.

[0254] The communication system 100 may also include a base station 114a and a base station 114b. Fig.15AIn the example of FIG. 1 , each base station 114 a and 114 b is depicted as a single element. In practice, the base stations 114 a and 114 b may include any number of interconnected base stations and / or network elements. The base station 114 a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102 a, 102 b, and 102 c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, 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 transmit and receive 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 network 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 wirelessly interface 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 network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

[0255] 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 network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112. The RSUs 120a and 120b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. By way of example, the base stations 114a, 114b may be base transceiver stations (BTSs), Node-Bs, eNode Bs, home Node Bs, home eNode Bs, next generation Node-Bs (gNodeBs), satellites, site controllers, access points (APs), wireless routers, and the like.

[0256] 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 specific 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 signals and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, 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, for example, one transceiver for each sector of the cell. The base station 114a may employ multiple-input multiple-output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell, for example.

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

[0258] The base station 114b may 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 communication link (e.g., cable, fiber optic, etc.) or a 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.

[0259] The RRHs 118a, 118b, TRPs 1115a, 1115B, and / or RSUs 120a, 120b may communicate with one or more of the WTRUs 102c, 102d, 102e, 102f over an 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.

[0260] The WTRUs 102 may communicate with each other via a direct air interface 115d / 116d / 117d such as a 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.

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

[0262] The base station 114a in the RAN 103 / 104 / 105 and the WTRUs 102a, 102b, 102c and 102g, or the RRHs 118a and 118b, TRPs 1115a and 1115B and / or the RSUs 120a and 120b and the WTRUs 102c and 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may use, for example, Long Term Evolution (LTE) and / or LTE Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. 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, etc.). Similarly, 3GPP NR technologies may include NR V2X technologies and interfaces (such as sidelink communications, etc.).

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

[0264] Fig.15AThe base station 114c in the figure can be, for example, a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business place, a home, a vehicle, a train, an antenna, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102 (e.g., WTRU 102e) can implement radio technologies such as IEEE802.11 to establish a wireless local area network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., WTRU 102d) can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102 (e.g., WTRU 102e) can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or a femtocell. As Fig.15A As shown, the base station 114c may have a direct connection to the Internet 110. Therefore, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109.

[0265] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, messaging, authorization and authentication, applications, 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, pre-paid calling, Internet connectivity, packet data network connectivity, Ethernet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication.

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

[0267] The core network 106 / 107 / 109 may also act 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 that provides 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), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include any type of packet data network (e.g., IEEE 802.3 Ethernet) or another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 or the RAN 103b / 104b / 105b or a different RAT.

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

[0269] Despite Fig.15A It is not shown, but it should be understood that the user equipment can establish a wired connection with the gateway. The gateway can be a residential gateway (RG). The RG can provide a connection to the core network 106 / 107 / 109. It should be understood that many of the ideas contained herein are equally applicable to UEs that are WTRUs and UEs that use wired connections to connect to the network. For example, the ideas applied to wireless interfaces 115, 116, 117, and 115c / 116c / 117c are equally applicable to wired connections.

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

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

[0272] Fig. 15B The illustrated core network 106 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. While each of the foregoing elements are depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

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

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

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

[0276] Fig. 15C 1 is a system diagram of an exemplary RAN 104 and core network 107. As noted above, the RAN 104 may employ an E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0277] The RAN 104 may include eNode-Bs 160a, 160b, and 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs. The eNode-Bs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNode-B 160a, for example, may use multiple antennas to transmit wireless signals to, and receive wireless signals from, the WTRU 102a.

[0278] 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 in the uplink and / or downlink, etc. Fig. 15C As shown, eNode-Bs 160a, 160b, and 160c may communicate with one another via an X2 interface.

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

[0280] 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 serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, and 102c, 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.

[0281] 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, managing and storing the context of the WTRUs 102a, 102b, and 102c, and the like.

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

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

[0284] Fig.15D1 is a system diagram of an exemplary RAN 105 and core network 109. The RAN 105 may employ NR radio technology to communicate with the WTRUs 102a and 102b over the air interface 117. The RAN 105 may also be in communication with the core network 109. A non-3GPP interworking function (N3IWF) 199 may employ non-3GPP radio technology to communicate with the WTRU 102c over the air interface 198. The N3IWF 199 may also be in communication with the core network 109.

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

[0286] The N3IWF 199 may include a non-3GPP access point 180c. It should be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the 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 the 802.11 protocol.

[0287] Each of the gNode-Bs 180a and 180b may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Fig.15D As shown, gNode-Bs 180a and 180b may communicate with each other, for example, via an Xn interface.

[0288] Fig.15DThe core network 109 shown may be a 5G core network (5GC). The core network 109 may provide a variety of communication services to customers interconnected by a radio access network. The core network 109 includes multiple entities that perform the functionality of the core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functions of the core network. It should be understood that such core network entities may be logical entities implemented in the form of computer executable instructions (software) stored in a device or computer system (such as a processor) configured for wireless and / or network communications. Figure 15G The system 90 shown is stored in a memory and executed on a processor thereof.

[0289] exist Fig.15D In the example of , the 5G core network 109 may include access and mobility management function (AMF) 172, session management function (SMF) 174, user plane function (UPF) 176a and 176b, user data management function (UDM) 197, authentication server function (AUSF) 190, network exposure function (NEF) 196, policy control function (PCF) 184, non-3GPP interworking function (N3IWF) 199, user data repository (UDR) 178. Although each of the foregoing elements is depicted as part of the 5G core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator. It should also be understood that the 5G core network may not consist of all of these elements, may consist of additional elements, and may consist of multiple instances of each of these elements. Fig.15D The network functions are shown connected directly to each other, however, it should be understood that they may communicate via a routing agent such as a Diameter routing agent or a message bus.

[0290] exist Fig.15D In the example of , the connection between network functions is realized via a set of interfaces or reference points. It should be understood that network functions can be modeled, described or realized as a set of services called or invoked by other network functions or services. The invocation of network function services can be realized via direct connection between network functions, message exchange on a message bus, calling software functions, etc.

[0291] The AMF 172 may be connected to the RAN 105 via an N2 interface and may serve as a control node. For example, the AMF 172 may be responsible for registration management, connection management, reachability management, access authentication, access authorization. The AMF may be responsible 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 / from the WTRUs 102a, 102b, and 102c via the N1 interface. The N1 interface is Fig.15D Not shown in FIG.

[0292] The SMF 174 may be connected to the AMF 172 via the N11 interface. Similarly, the SMF may be connected to the PCF 184 via the N7 interface and to the UPFs 176a and 176b via the N4 interface. The SMF 174 may serve as a control node. For example, the SMF 174 may be responsible for session management, IP address allocation for the WTRUs 102a, 102b, and 102c, management and configuration of traffic steering rules in the UPFs 176a and 176b, and generation of downlink data notifications to the AMF 172.

[0293] The UPF 176a and UPF 176b may provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN), such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and other devices. The UPF 176a and UPF 176b may also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 may be an Ethernet network or any type of network that switches data packets. 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 the packet data network by connecting to the packet data network via the N6 interface or by connecting to each other and to other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF 176 may also be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0294] 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 a radio interface technology that is 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.

[0295] PCF 184 may be connected to SMF 174 via an N7 interface, to AMF 172 via an N15 interface, and to application function (AF) 188 via an N5 interface. The N15 and N5 interfaces are Fig.15D 102a, 102b, and 102c. The PCF 184 may provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to implement these rules. The PCF 184 may send policies for the WTRUs 102a, 102b, and 102c to the AMF 172 so that the AMF may deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be implemented or applied at the WTRUs 102a, 102b, and 102c.

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

[0297] UDM 197 may serve as an interface between UDR 178 and other network functions. UDM 197 may authorize network functions to access UDR 178. For example, UDM 197 may be connected to AMF 172 via an N8 interface, and UDM 197 may be connected to SMF 174 via an N10 interface. Similarly, UDM 197 may be connected to AUSF 190 via an N13 interface. UDR 178 and UDM 197 may be tightly integrated.

[0298] AUSF 190 performs authentication-related operations and is connected to UDM 178 via the N13 interface and to AMF 172 via the N12 interface.

[0299] NEF 196 exposes the capabilities and services in the 5G core network 109 to the application function (AF) 188. The exposure may occur on the N33 API interface. NEF can be connected to AF 188 via the N33 interface, and NEF can be connected to other network functions to expose the capabilities and services of the 5G core network 109.

[0300] The application function 188 may interact with the network functions in the 5G core network 109. The interaction between the application function 188 and the network functions may occur via a direct interface or may occur via the NEF 196. The application function 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by an enterprise having a business relationship with a mobile network operator.

[0301] 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 enables operators to create networks that are customized to provide optimized solutions for different market scenarios that require a wide range of requirements, such as in terms of functionality, performance and isolation.

[0302] 3GPP has designed the 5G core network to support network slicing. Network slicing is a good tool that network operators can use to support a variety of 5G use cases (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband) that require very diverse and sometimes extreme requirements. Without the use of network slicing technology, when each use case has its own set of specific requirements for performance, scalability, and availability, the flexibility and scalability of the network architecture may not be sufficient to effectively support a wider range of usage needs. In addition, new network services should be introduced more efficiently.

[0303] See again Fig.15D In a network slicing scenario, the WTRU 102a, 102b, or 102c may be connected to the AMF 172 via an N1 interface. The AMF may be a logical part of one or more slices. The AMF may coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more of the UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the 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.

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

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

[0306] Fig.15E An exemplary communication system 111 is shown 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, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or several or all of the WTRUs A, B, C, D, E, and F may be outside the range of the access network coverage 131. WTRUs A, B, and C form a V2X group, with WTRU A being the group leader and WTRUs B and C being group members.

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

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

[0309] Fig.15F is an exemplary apparatus or device WTRU 102 (such as Fig.15A , Fig. 15B , Fig. 15C , Fig.15D or Fig.15E 102). Fig.15F As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It should be understood that the WTRU 102 may include any sub-combination of the foregoing elements. In addition, the base stations 114a and 114b and / or the nodes that the base stations 114a and 114b may represent (such as, but 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), and a proxy node, etc.) may include Fig.15F Some or all of the elements depicted in and described herein.

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

[0311] The transmit / receive element 122 of the UE may be configured to transmit data to a base station (eg, Fig.15A The base station 114a) transmits a signal or receives a signal from the base station, or transmits a signal to another UE or receives a signal from the UE through the air interface 115d / 116d / 117d. For example, the transmit / receive element 122 can be an antenna configured to transmit and / or receive RF signals. The transmit / receive element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR signals, UV signals, or visible light signals. The transmit / receive element 122 can be configured to transmit and receive both RF signals and optical signals. It should be understood that the transmit / receive element 122 can be configured to transmit and / or receive any combination of wireless signals or wired signals.

[0312] Furthermore, although the transmit / receive element 122 is Fig.15F Although depicted as a single element in the figure, 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.

[0313] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As noted 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.

[0314] The processor 118 of the WTRU 102 may be coupled to, and may receive user input data from, the speaker / microphone 124, the keypad 126, and / or the 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. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as the non-removable memory 130 and / or the removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, etc. The processor 118 may be located in a manner that is never physically located on the WTRU. The information is accessed from a memory on 102, such as on a server hosted on the cloud or on an edge computing platform or on a home computer (not shown), and the data is stored in the memory.

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method performed by a wireless transmit / receive unit WTRU, the method comprising: sending a registration request message to a network, the registration request message including an indication that the WTRU is capable of supporting use of time information associated with a network slice; receiving, from the network, a message indicating time information associated with availability of one or more network slices, wherein the time information indicates availability of the one or more network slices during a respective indicated access period associated with each of the one or more network slices; and Based on the received time information, it is determined that the network slice is unavailable for a period of time.

2. The method according to claim 1 also includes sending a notification indicating that an inactive time period of the network slice is approaching.

3. The method according to claim 1, further comprising: In a case where the time information indicates that an inactive time period of the network slice is approaching, it is determined to notify an application that the network slice is becoming unavailable.

4. The method according to claim 1, further comprising: In case the time information indicates that an inactive time period of the network slice is approaching, it is determined to try a different network slice among the one or more network slices to send data.

5. The method according to claim 1, wherein: The message is a registration response message received in response to the registration request message.

6. The method according to claim 1, wherein: The message is a configuration update message.

7. The method according to claim 1, further comprising: When the network slice is available, data is sent to the network using a PDU session.

8. The method of claim 1, further comprising receiving updated time information associated with the one or more network slices.

9. The method according to claim 1, wherein: The indicated access period time information includes: a first time when the one or more network slices become available and a second time when the one or more network slices become unavailable.

10. A wireless transmit / receive unit WTRU, the WTRU comprising a processor, the processor being configured to: sending a registration request message to a network, the registration request message including an indication that the WTRU is capable of supporting use of time information associated with a network slice; receiving, from the network, a message indicating time information associated with availability of one or more network slices, wherein the time information indicates availability of the one or more network slices during a respective indicated access period associated with each of the one or more network slices; and Based on the received time information, it is determined that the network slice is unavailable for a period of time.

11. The WTRU of claim 10 wherein: The processor is also configured to send a notification indicating that an inactive period of the network slice is approaching.

12. The WTRU of claim 10 wherein: The processor is further configured to determine to notify an application that the network slice is becoming unavailable if the time information indicates that an inactive time period of the network slice is approaching.

13. The WTRU of claim 10 wherein: The processor is also configured to determine to try a different network slice among the one or more network slices to send data if the time information indicates that an inactive time period of the network slice is approaching.

14. The WTRU of claim 10 wherein: The message is a registration response message received in response to the registration request message.

15. The WTRU of claim 10 wherein: The message is a configuration update message.

16. The WTRU of claim 10 wherein: The processor is also configured to send data to the network using a PDU session when the network slice is available.

17. The WTRU of claim 10, further comprising receiving updated time information associated with the one or more network slices.

18. The WTRU of claim 10 wherein: The indicated access period time information includes: a first time when the one or more network slices become available and a second time when the one or more network slices become unavailable.

19. A wireless transmit / receive unit WTRU, the WTRU comprising a processor, the processor being configured to: receiving slice information and an indication of authentication or authorization required for each application in the slice; Sending a protocol data unit (PDU) session establishment message to the slice; receiving a PDU session establishment accept message for establishing a PDU session for a first application; determining that a second application is attempting to use the PDU session; as well as Trigger the authentication and authorization process of the second application.

20. A wireless transmit / receive unit WTRU, the WTRU comprising a processor, the processor being configured to: Receive an elevated privilege identifier EPID; Sending a non-access stratum NAS message including the EPID; receiving a registration accept message indicating a set of alternate single network slice selection assistance information (S-NSSAI) accessible to the WTRU using the EPID; and Determine whether to transmit an existing PDU session or to establish a new PDU session in one of the set of alternative S-NSSAIs.

Images