Application Interaction for Network Slicing

Abstract

A method, apparatus, and system for improved application interworking for network slicing are described. A wireless transmit / receive unit can transmit a registration request to a network node including an indication that the WTRU can receive information associated with the temporal availability of the network slice. The WTRU can receive a registration response including the information associated with the temporal availability of the network slice. The WTRU can determine to stop using a protocol data unit (PDU) session associated with the network slice based on the temporal availability of the network slice.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 245,656, filed on September 17, 2021, entitled "APPLICATION INTERACTION FOR NETWORK SLICING", the content of which is incorporated herein by reference in its entirety.

Background Art

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

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

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

Summary of the Invention

[0005] This specification describes a method, an apparatus, and a system for application interaction for network slicing. For example, per-application authentication and authorization (PAAA) can be performed for a UE to access a network slice and a data network.

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

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

[0008] According to some aspects, at the time of evaluation, an extended URSP with an NS SA flag can be provided to indicate to the UE whether the S-NSSAI selected using the NSSP requires PAAA.

[0009] According to some aspects, a mechanism may be provided that enables a core network to utilize integrated time information and spatial information to proactively redirect a UE to a tracking area (TA) and frequency band where a related network slice is authorized for the UE. A mechanism may be provided that enables the UE to utilize the integrated time information and spatial information so that the UE can determine to change its direction, maintain an appropriate speed, or follow a path towards a TA where there is a high probability of discovering an authorized network slice.

[0010] According to some aspects, a mechanism may be provided that enables the UE to utilize integrated time information and spatial information so that the UE can gracefully save the state of applications (e.g., idle, connected, active, inactive, etc.) and / or invalidate them, save the state of PDU sessions (e.g., idle, connected, active, inactive, etc.), buffer uplink data, and / or take one or more power saving actions such as reduced cell search, sleep, etc.

[0011] According to some aspects, a mechanism may be provided that enables the UE registration procedure, the UE registration update procedure, and / or the UE configuration update procedure to be extended to convey time information and spatial information to the UE.

[0012] According to some aspects, a mechanism may be provided that enables the UE to utilize a unique identifier for elevated privileges to access network slices that are not available to common UEs.

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

[0014] According to some aspects, the WTRU can 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 can 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 can include the time periods during which the slice is available or not available to the WTRU. According to some aspects, the slice remapping procedure can be performed based on the temporal availability of a network slice.

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

[0016] This summary is provided to introduce a selection of concepts in a simplified form, which will be further described below in the "Detailed Description". This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Further, the claimed subject matter is not limited to embodiments that solve any or all of the disadvantages noted in any part of this disclosure.

Brief Description of the Drawings

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

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15A

Figure 15B

Figure 15C

Figure 15D

Figure 15E

Figure 15F

Figure 15G

DETAILED DESCRIPTION OF THE INVENTION

[0018] Table 0.1 lists some of the abbreviations used in this specification.

[0019]

Table 1-1

[0020]

Table 1-2

[0021] Terms and Definitions. The following is a list of terms that may appear in the following description. Unless otherwise specified, the terms used in this specification are defined as follows.

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

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

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

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

[0026] Network Function (NF) - A processing function within a network that has defined functional behavior and defined interfaces. The NF can be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., on a cloud infrastructure.

[0027] NF Instance - A distinguishable instance of an NF.

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

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

[0030] 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, as well as for UE messages and procedures related to Session Management (SM). A single N1 endpoint may be located within the AMF. The AMF may transfer SM-related NAS information to the SMF. The AMF can handle the registration management and connection management parts of the NAS signaling exchanged with the UE. The SMF handles the SM part of the NAS signaling exchanged with the UE.

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

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

[0033] A network slice is identified by an S-NSSAI, where the S-NSSAI can be (1) a Slice / Service Type (SST) that can refer to the expected network slice behavior regarding characteristics and services, and (2) It can be composed of a Slice Differentiator (SD). The Slice Differentiator is optional information that supplements the SST to distinguish between multiple network slices of the same SST.

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

[0035] According to some aspects, the NSSAI is a set of S-NSSAIs. The NSSAI can be a configured NSSAI, a requested NSSAI, or a permitted NSSAI. There can be up to 8 S-NSSAIs in the permitted NSSAI and the requested NSSAI transmitted in the signaling message between the UE and the network. The requested NSSAI signaled by the UE to the network enables the network to select the serving AMF, network slice, and network slice instance for this UE.

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

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

[0038] According to some aspects, the (R)AN can use the requested NSSAI in the access layer signaling to handle the UE CP connection before notifying the (R)AN of the NSSAI permitted by the 5GC. The requested NSSAI can be used by the RAN for AMF selection as described in TS23.501 [1], section 6.3.5. When the UE requests to resume the RRC connection and is CM-CONNECTED in the RRC inactive state, the UE may not include the NSSAI requested for the RRC resume.

[0039] According to some aspects, when the UE is successfully registered to the access type, the CN can notify the (R)AN by providing the permitted NSSAI to the corresponding access type.

[0040] According to some aspects, since the standardized SST values provide a way to establish global interoperability to slicing, a PLMN can more efficiently support roaming use cases related to the most commonly used SST. For example, the standardized SST is shown in Table 1 below.

[0041]

Table 2

[0042] The configured NSSAI is the NSSAI provisioned to the UE that is applicable to one or more PLMNs. The configured NSSAI is configured by the serving PLMN and can be applied to the serving PLMN. According to some aspects, there may be at most one configured NSSAI per PLMN.

[0043] According to some aspects, the default configured NSSAI can be configured by the HPLMN and can be applied to, for example, any PLMN to which a specific configured NSSAI is not provided to the UE. The values used in the default configured NSSAI can be expected to be commonly determined by all roaming partners. The default configured NSSAI can be used by the UE in the serving PLMN only if the UE does not have a configured NSSAI for the serving PLMN when it is configured in the UE. The UE can be preconfigured with the default configured NSSAI.

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

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

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

[0047] According to some aspects, the mapping of the permitted NSSAI may be the mapping of each S-NSSAI of the permitted NSSAI related to the serving PLMN to the HPLMN S-NSSAI.

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

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

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

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

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

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

[0054] According to some aspects, the AMF can act as an EAP authenticator and communicate with the AAA-S via a network slice specific and SNPN authentication and authorization function (NSSAAF). The NSSAAF can accept any AAA protocol that interworks with the AAA protocol supported by the AAA-S.

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

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

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

[0058] According to some aspects, steps 2, 3a, 3f, and 4 in Figure 4 may be undefined. Step 3 may be repeated depending on the mechanism used. According to some aspects, when the SMF communicates directly with the DN-AAA server without the UPF, step 1 may be skipped, and steps 2, 3a, 3f, 4, and 6 may be performed without the UPF. According to some aspects, the SMF may be able to determine that it needs to contact the DN-AAA server. The SMF may identify the DN-AAA server based on the local configuration, or within the SM PDU DN request container provided by the UE in the PDU session establishment request, or within the EAP message in the PDU session authentication completion message (e.g., TS 24.501) provided by the UE with the DN specific identification information (e.g., TS 33.501).

[0059] According to some aspects, the content of the SM PDU DN request container is defined in TS 24.501. If there is no existing N4 session available for carrying DN related messages between the SMF and the DN, the SMF may select a UPF and trigger the N4 session establishment.

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

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

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

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

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

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

[0066] Steps 3f: The SMF (e.g., in the case of HR, it is the H-SMF) can send the content of the DN request container information (e.g., authentication message) to the DN-AAA server via the UPF. According to some aspects, step 3 can be repeated until the DN-AAA server confirms the success of the PDU session authentication / authorization.

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

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

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

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

[20] ) and PCC rules (e.g., section 6.3 of TS 23.503 [6]) from the PCF. According to some aspects, when the SMF receives the DN authorization session AMBR within the DN authorization data from the DN-AAA, the SMF can send the DN authorization session AMBR within the session AMBR to the PCF to retrieve the authorized session AMBR (e.g., section 6.4 of TS 23.503 [6]). For an Ethernet type PDU session, the SMF can instruct the UPF to process the Ethernet (VLAN information of the frame for the PDU session received and transmitted on N6 or N19 or the internal interface (e.g., section 5.6.10.2 of TS 23.501 [1]).

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

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

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

[0074] According to some aspects, the permitted area may alternatively be configured as unrestricted, e.g., the permitted area may include all tracking areas of a PLMN. The registered area of a UE within a non-permitted area can be composed of a set of TAs belonging to the non-permitted area of the UE. The registered area of a UE within a permitted area can be composed of a set of TAs belonging to the permitted area of the UE. The AMF can provide the UE with the service area restriction in the form of TA(s) during the registration procedure, which may be a subset of the complete list stored in the UE's subscription data or provided by the PCF.

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

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

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

[0078] According to some aspects, the NG-RAN can attempt to find a cell of a TA that can support all S-NSSAIs within the target S-NSSAI. If such a cell of the TA is not available, the RAN can attempt to select a cell of a TA that best matches the target S-NSSAI. The NG-RAN can attempt to guarantee the continuity of the PDU session with the activated user plane associated with the S-NSSAI within the permitted NSSAI within the target NSSAI. Also, the NG-RAN can attempt to guarantee the continuity of the service for the S-NSSAI of the permitted NSSAI that is also available in the target NSSAI before prioritizing cells that do not support one or more of the S-NSSAIs of the permitted NSSAI that is also available in the target NSSAI.

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

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

[0081]

Table 3

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

[0083]

Table 4

[0084]

Table 5

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

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

[0087] According to some aspects, the URSP rules within the UE can guide the applications within the UE to use a PDU session that may be established by another (e.g., first) application, as shown in FIG. 5. The second application may belong to a different third party and thus may need to be authorized before using the network slice. The current 5GS specifications do not define how 5GS performs per-application authentication and authorization for accessing the network slice or DN.

[0088] According to some aspects, the UE may 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 have access to any authorized network slices in the new location. The current 5GS does not explain how the UE can handle such scenarios such that the 5GS can notify the UE applications that slices can become unavailable and that the applications can gracefully terminate or preserve their states (e.g., idle, connected, active, inactive, etc.). In addition, 5GS does not explain how the UE can save power by reducing unwanted application activities in the UE in such scenarios.

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

[0090] According to some aspects, a network slice may need to be marked with an indicator for the UE application to identify that the network slice receives application-by-application authentication and authorization. The MNO can mark the network slice with a PAAA indicator that complies with PAAA during network slice configuration. The UE may receive an S-NSSAI with a PAAA indicator as part of the permitted NSSAI after successful UE registration. Alternatively, the PAAA indicator may be sent to the UE together with the configured NSSAI.

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

[0092] In step 0, each S-NSSAI according to PAAA can be associated with the authentication and authorization (PAAA) indicator for each application within the UE access and mobility subscription in the UDM / UDR. According to some aspects, the PAAA requirements for slice access may depend on factors such as agreements between the MNO and third parties regarding services, security requirements, local policies, etc.

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

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

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

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

[0097] In step 3, the registration request can be transferred to the selected AMF.

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

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

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

[0101] The current 5G system design only considers authentication and authorization for each UE when network slicing requires NSSAA. However, each application may affect the application function or access to the data network. Therefore, the permission for an application to access a network slice for a UE is combined with the permission for the application to access the application function / DN. This section describes how the core network authenticates and authorizes each application that attempts to access network slices and AF / DN. Figure 8 shows an exemplary procedure and is described as follows.

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

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

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

[0105] The application descriptor can consist of one or more IP addresses, port numbers, or MAC addresses indicating from which server the PDU session is used to send and receive traffic.

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

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

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

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

[0110] In step 4, based on a request from the UE that includes an application descriptor and an S-NSSAI (for example, S-NSSAI-A) that the UE desires to access, and a PAAA trigger indicator from the UE, the SMF can trigger the PAAA process. Alternatively, the SMF may trigger the PAAA process based on a policy received from the PCF. The SMF can determine that it needs to contact the DN-AAA server for the PAAA procedure. The SMF can identify the DN-AAA server based on local configuration, the application descriptor, or by using DN unique identification information, and send the application descriptor to the DN-AAA server together with the PAAA request.

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

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

[0113] In the case of home routed roaming, the H-SMF can start the Nsmf_PDUSession_Update service operation and request the V-SMF to transfer the DN request container to the UE. The V-SMF can then call the Namf_Communication_N1N2MessageTransfer service operation on the AMF to transfer the DN request container information within the N1 SM information sent towards the UE.

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

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

[0116] In step 5e, the AMF can notify the SMF by calling the Nsmf_PDUSession_UpdateSMContext service operation. The SMF can issue an Nsmf_PDUSession_UpdateSMContext response.

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

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

[0119] According to some aspects, step 5 can be repeated until the DN-AAA has obtained all the necessary information from the UE and confirmed a successful authentication and authorization of the PDU session.

[0120] In step 6, the DN-AAA server can send a PAAA success message to the SMF. In addition to the PAAA success message, the DN-AAA server can send a set such as an IP address, a port number, and the MAC address of the application function (AF), and the IP address for DNS to the SMF that the UE can access using the network slice.

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

[0122] In step 7, the SMF can 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 this PDU session. The SMF can indicate to the UPF to perform IP address / prefix allocation and can include the information necessary for the UPF to perform the allocation. This request can include the IP address, port number, and MAC address of the AF received from the DN-AAA server. This information can be used by the UPF to determine the addresses that the PDU session can use to send / receive traffic. The UPF can respond affirmatively by sending an N4 session establishment / modification response. The N4 session establishment / modification request can also indicate to the UPF that all downlink traffic to the UE can be permitted, but uplink traffic is only permitted for the indicated IP address, port number, and MAC address. It may be useful to enable downlink traffic to the UE so that the server can initiate contact with the UE. The UE can then be authenticated when it attempts to send uplink traffic to a new destination.

[0123] In step 8, the SMF can send a PDU session establishment acceptance message within the N1 SM container that the AMF can provide to the UE to the AMF. In addition, the SMF can send the IP address, port number, and MAC address of the AF that is authorized to use the PDU session for the UE to contact (e.g., send and receive traffic from).

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

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

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

[0127] Traffic for a second application (App2) may start. App2 may provide a traffic descriptor (e.g., OSid, DNN, IP address, etc.) to the UE. The UE may evaluate the URSP rule and determine that there is an existing PDU session going towards an S-NSSAI and DNN that match the S-NSSAI and DNN in the URSP rule. However, the UE may know that it is not authorized to access the network slice because the traffic descriptor the UE is trying to access is not an AF (IP address) authorized for this PDU session that uses an S-NSSAI (e.g., S-NSSAI-A). In other words, the IP address that App2 is trying to send data to may not be among the authorized IP addresses received in the PDU session establishment acceptance message described in step 8 of FIG. 8.

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

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

[0130] According to some aspects, the UE can use an existing PDU session rather than establishing a new one. 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, if the UE successfully completes the PAAA process, it may be more efficient for the UE to send a PDU session modification command together with a PAAA request for the second application so that the PDU session is modified and the UE can incorporate traffic originated from the second application into the PDU session. FIG. 9 shows a call flow illustrating a method for PAAA with PDU session modification.

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

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

[0133] Therefore, the UE can send a PDU session modification NAS message to the network. The PDU session modification message can include a PDU session modification request, a PDU session ID, the requested QoS, etc. Along with the PDU session modification message, the UE can include a new application descriptor (e.g., for App2) and a PAAA trigger indicator indicating the need for PAAA.

[0134] In step 3, the AMF can 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, the per-application authentication and authorization (PAAA) procedure can be triggered at the SMF. Alternatively, the SMF can trigger the PAAA procedure based on information provided by another NF such as the PCF and / or UDM.

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

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

[0137] In step 6, the SMF can send an N4 session modification request to the UPF and provide the packet detection, enforcement, and reporting rules installed on the UPF to match the PDU session. The SMF can instruct the UPF to perform IP address / prefix allocation, including the information necessary for the UPF to perform the allocation. This can include the IP address, port number, and MAC address of the AF received from the DN-AAA server, and the UPF is permitted to establish a PDU session to send / receive traffic. The UPF can send a positive response by sending an N4 session establishment / modification response.

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

[0139] In step 8, the AMF can send messages to the (R)AN over N2, e.g., [N2 SM information received from the SMF], NAS messages (PDU session ID, N1 SM container (PDU session modification command, PAAA success message, and an updated list of IP address, port number, and MAC address (e.g., AF), the PDU session is authorized to send traffic using App2)). The RAN can transport only the N1 SM container to the UE.

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

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

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

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

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

[0145]

Table 6

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

[0147] In step 1, the MNO can configure the core network using the PAAA policy. The SMF can be responsible for executing the PAAA procedure for an application that requests PDU session establishment. The PAAA policy can ensure whether and how the SMF needs to contact the AAA / DN-AAA server for application authentication and authorization.

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

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

[0150] In step 3, when the application starts and triggers the UE to establish a PDU session, the UE may evaluate the URSP rule. If the NSSA flag is Set for the S-NSSAI for which the UE is trying 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 the set NSSA flag. Accordingly, the UE may send the application descriptor in an authentication and authorization message (AA message) indicating the need for PAAA within the PDU session establishment request. Alternatively, the UE may send the PAAA trigger indicator described herein to indicate the need for PAAA along with the request. Alternatively, PAAA may be triggered by the SMF based on the policy or information received from the PCF / UDM.

[0151] Alternatively, the UE may send only the 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 form, if the application does not need to be authenticated and authorized, e.g., if the NSSA flag is Not Set, the UE may not include the application descriptor in the PDU session request.

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

[0153] In step 5, if the application is authenticated and authorized, the AAA / DN-AAA server can return a successful authentication and authorization message to the SMF. This message can notify the SMF to accept the PDU session request that essentially authorizes the establishment of the PDU session. The successful authentication and authorization message can also include a list such as an IP address, a port number, and / or a MAC address (e.g., AF), a DNS name, etc. The PDU session is authorized to use the application to send traffic.

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

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

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

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

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

[0159] According to some aspects, slice remapping may involve disassociating traffic (or a PDU session) from a first slice and / or S-NSSAI and associating the traffic (or PDU session) with a second slice and / or S-NSSAI. A network-initiated remapping procedure may involve a network node (e.g., an AMF) determining to change the slice and / or S-NSSAI associated with a UE's PDU session and sending a notification message to the UE to notify the UE that a PDU session that was associated with a first S-NSSAI is now associated with a 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 instead be associated with a second S-NSSAI.

[0160] According to some aspects, it is assumed that frequency bands / cells overlap in a TA and multiple TAs may be available to the UE. However, network slices may also be unavailable to the UE based on time factors or due to permissions. Thus, the UE may also encounter situations where there are no authorized slices and the UE attempts frequent cell searches and consumes its power too quickly. In another scenario, the UE may not be prepared for a sudden but temporary outage of a frequency band and thus the network cannot slice and handle an ongoing PDU session. The UE may encounter several different scenarios. For example, The network slice may simply be unavailable as there may be no services available in the TA.

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

[0162] An approved network slice may not be available in a TA for a UE. However, the network slice may be available in a neighboring TA.

[0163] A network slice may not be available within a time period but may soon be available (e.g., at 1800HRS).

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

[0165] According to some aspects, UE subscription information within the core network may include network slices approved for use by the UE, service area restrictions, RAT restrictions, prohibited areas, etc. (e.g., Table 5.2.3.3.1-1 of TS 23.502). Additionally, the AMF and / or NSSF can identify frequency bands in which one or more network slices are available or unavailable. In addition to this information, the UE and the core network may be able to utilize spatial and time information that describes the availability of network slices at some times and locations. The time and spatial information (TSI), and how the UE and the network may be able to utilize the TSI to operate more efficiently, are described above.

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

[0167] On the other hand, the core network (e.g., UDM, NSSF, AMF, or PCF) may have information about which network slices are available in the network or available in some TAs and RAs. As described below, the information can include whether the UE can be present on some cells and whether a network slice is authorized for the UE (e.g., deliverable in a permitted NSSAI) in some frequency bands.

[0168] The integrated TSI described above can be used to notify the network and as a result notify the UE about the next network slice access availability. Depending on the UE and its location / state, the next availability can be temporary. In other words, the core network can pre-determine when the UE could or could not access a particular network slice. For example, the UE may be within the home network or the UE may traverse a VPLMN, and if the authorized network slice within the serving PLMN is active only within a specified period (e.g., after 6:00 PM, until 6:00 AM), this information can be used for the benefit of the UE.

[0169] Similarly, the next availability of network slices can 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 can be set to follow a specific route. In such a case, the location service, the rate at which the UE is moving, and the predefined direction can give the core network a sufficient probability that the car can move to a certain geographical location (e.g., TA / RA). Based on that information, the core network may be able to estimate the nature of the traffic, the minimum, average, and / or maximum bandwidth that the UE can consume, which can be converted for the network to understand which services and network slices the UE needs. Assuming that the network has information about the slices that the UE is authorized to access, the frequency bands in which the slices are available, and the TAs in which the network slices may be available, two aspects can be pre-planned.

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

[0171] Second, the information can be transmitted to the UE such that the UE utilizes it to determine the expected adjacent TAs and thus the available network slices within the frequency bands of interest, which can enable the UE (e.g., drone, connected car, etc.) to change its direction as needed and gives the UE the opportunity to maintain an appropriate speed by following 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.

[0172] Time information and spatial information regarding slice availability, authorized S-NSSAI, TA topology (including adjacent TAs), frequency band information, TA / RA id list, etc. can be sent to the UE during UE configuration update or, if necessary, using NAS messages. The delivery of this integrated time and spatial information can be triggered by events such as initial registration, mobility / registration update, UE configuration update, etc.

[0173] In addition to the UE's decision to change direction or the core network's decision to proactively redirect the UE to an appropriate frequency band and / or TA, the UE can utilize the TSI to interact with the UE's active applications or applications to become active, reduce undesirable operations, and as a result, reduce power consumption and assist UE efficiency.

[0174] If time information about a network slice in the TA (e.g., slice A is inactive between 6:00 am and 6:00 pm) is available to the UE, the UE may be able to pause / stop the PDU session to be established. For example, if an application task requires a very long PDU session (e.g., a game) and the inactive time period of the network slice is approaching, the UE can decide to stop the start of that PDU session and notify the relevant parties of the reason. This may mean that the UE may notify the UE application and / or invalidate requests sent from the UE application, or if the application has not started the PDU session, the application may establish a session back-off time when the PDU session cannot be started. The UE can record a message for that decision, send it to the network, or notify the user as needed. Using such a message, the UE can attempt another network slice (if available) or take an action to request another network slice if feasible.

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

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

[0177] The UE may save the state of the application (e.g., idle, connected, active, inactive, etc.). For example, the UE application may be waiting for a response from the network. When the authorized slice comes online, such a state can be saved and retrieved later.

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

[0179] The UE can save any background data state and / or delay data transfer.

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

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

[0182] If the PLMN supports slice remapping, the UE can prepare for slice remapping.

[0183] The UE can turn off broadcast type activities.

[0184] The UE can shorten the time to reach the sleep state or put the UE to sleep immediately.

[0185] The UE can start a stationary timer that will enable the UE to perform all of the aforementioned actions for a specific amount of time (e.g., actions such as buffering UL data can be prevented from continuing indefinitely). If the unavailability of the network slice continues beyond the stationary timer, the UE may completely kill the application process and flush all incomplete UL data and application states. On the other hand, the SMF may start a different stationary timer as soon as the UE enters a TA where an authorized slice is unavailable.

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

[0187] The UE capabilities for receiving integrated TSI can interact with UE applications using the integrated TSI and, if network slices are available based on the TSI such that the overall UE efficiency is improved, can steer the UE, which can be referred to as UE application interaction and steering capabilities (AISC).

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

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

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

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

[0192] Transmit the TSI to the UE using the UE configuration update procedure In some embodiments, the TSI can alternatively be conveyed to the UE using the UE configuration update procedure. If there is a new available TSI, the network can trigger the UE configuration update procedure. In some embodiments, the way in which the TSI can be conveyed during the UE configuration update procedure is described in Figure 12.

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

[0194] This procedure can also be used to trigger the UE to execute one of the mobility registration update procedures for modifying NAS parameters that require negotiation (e.g., MICO mode) while the UE is in the CM-CONNECTED state based on network instructions, or the mobility registration update procedure for steering the UE towards the EPC (e.g., as defined in Section 5.31.3 of TS 23.501 [1]), or the mobility registration update procedure after the UE enters the CM-IDLE state (e.g., for a change to a permitted NSSAI that requires re-registration). If a registration procedure is required, the AMF can provide the UE with an instruction to start the registration procedure.

[0195] If applicable, the UE configuration update can be sent via the access type to which the UE configuration update applies (e.g., 3GPP access or non-3GPP access). The AMF can request a UE positive response after NAS parameters including time and spatial information updates have been sent to the UE.

[0196] According to some aspects, a UE configuration update procedure for carrying spatial and time information to the UE is shown in FIG. 12.

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

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

[0199] In step 2, if the UE configuration update indication requires a positive response to the UE configuration update command, the UE can send a UE configuration update complete message to the AMF.

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

[0201] According to some aspects, the MNO / PLMN may have a geographical area that permits only those UEs with special permissions. The MNO can set up a network slice for special access for reasons of sensitivity or resource availability. The gap TA (slice inaccessible zone) can provide a network slice only for special services (e.g., military communication) with special permissions and authorizations. According to some aspects, FIG. 13 illustrates how a UE can submit special permissions / privileges and receive an alternative network slice from the network.

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

[0203] At step 0, the UE may have received an Elevated Privilege Identification (EPID), which is separate unique identification information 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 high-rank military personnel or diplomats, or the UE may have a special subscription for enhanced privileges that is triggered only when encountering a scenario classified as "special". A "special" scenario may be when slices are not authorized in some geographical areas.

[0204] At step 1, when the UE enters a new geographical area (TA / RA) and receives a registration update, the UE may identify that there are no authorized network slices available in the TA. The UE may further identify that there are no overlapping TAs where any authorized slice is available. The AMF can send a request to the UE asking whether the UE has enhanced privileges and, if affirmative, asking the UE to send the EPID.

[0205] Alternatively, the UE and the network may pre-identify from the TA topology information (Integrated TSI) described herein that there are no authorized network slices available in a TA / RA covering a geographical area (which may include a TA list covering adjacent TAs). Based on the UE subscription information, the network can also determine that the UE has enhanced privileges, and thus the AMF can send a request for the EPID to the UE and ask whether the UE intends to use the privileges.

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

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

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

[0209] In step 4, the AMF may send the UE a set of alternative S-NSSAIs that the UE can access using the EPID within the permitted NSSAI with a registration approval message.

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

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

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

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

[0214] 3GPP identifies various use cases that NR is expected to support, leading to diverse user experience requirements for data transfer speed, 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 savings), and enhanced vehicle-to-everything (eV2X) communications, which may include any of vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle communication with other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based offices, first responder connectivity, automotive e-call, disaster alerts, real-time gaming, multiparty videotelephony, autonomous driving, augmented reality, tactile Internet, virtual reality, home automation, robots, and aerial drones. All such use cases are contemplated herein.

[0215] FIG. 15A illustrates an exemplary communication system 100 in which the systems, methods, and apparatuses 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 may be referred to generally or collectively as WTRU 102 or a plurality of 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. The network services 113 may include, for example, a V2X server, V2X functionality, ProSe server, ProSe functionality, IoT services, video streaming, and / or edge computing, etc.

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

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

[0218] TRP1115A and 1115B can be any type of device configured to wirelessly interface with at least one of the WTRU102d to facilitate access to one or more communication networks, such as core network 106 / 107 / 109, Internet 110, network service 113, and / or other network 112. RSU120a and 120b can be any type of device configured to wirelessly interface with at least one of the WTRU102e or 102f to facilitate access to one or more communication networks, such as core network 106 / 107 / 109, Internet 110, other network 112, and / or network service 113. By way of example, base stations 114a, 114b may be a Base Transceiver Station (BTS), Node-B, eNode-B, Home Node B, Home eNode B, Next Generation Node-B (gNode B), satellite, site controller, access point (AP), wireless router, etc.

[0219] Base station 114a may be part of RAN 103 / 104 / 105 and 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, base station 114b may be part of RAN 103b / 104b / 105b and may also include other base stations and / or network elements (not shown), such as a BSC, an RNC, a relay node, etc. 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, base station 114b may be configured to transmit and / or receive wired 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 base station 114a may be divided into three sectors. Thus, for example, base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. Base station 114a may use Multiple-Input Multiple Output (MIMO) technology and thus may utilize multiple transceivers for each sector of the cell, for example.

[0220] Base station 114a may communicate with one or more of WTRUs 102a, 102b, 102c, and 102g via air interfaces 115 / 116 / 117, which may be any suitable wireless communication link (e.g., Radio Frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Air interfaces 115 / 116 / 117 may be established using any suitable Radio Access Technology (RAT).

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

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

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

[0224] The communication system 100 can be a multiple access system and can employ one or more channel access methods, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in RAN103 / 104 / 105, and the RRH118a, 118b, TRP1115A, 1115B, and / or RSU120a, 120b in RAN103b / 104b / 105b, and the WTRU102c, 102d, 102e, and 102f can implement radio technologies such as Universal Mobile Telecommunications System (UMTS), Terrestrial Radio Access (UTRA), etc., which can use Wideband CDMA (WCDMA) to respectively establish the air interfaces 115 / 116 / 117 or 115c / 116c / 117c. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed Uplink Packet Access (HSUPA).

[0225] The base station 114a in RAN103 / 104 / 105, and the WTRUs 102a, 102b, 102c, and 102g, or the RRHs 118a and 118b, the TRPs 1115A and 1115B, and / or the RSUs 120a and 120b in RAN103b / 104b / 105b, and the WTRUs 102c, 102d can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can establish the air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively, for example, using Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A). The air interfaces 115 / 116 / 117 or 115c / 116c / 117c can implement 3GPP NR technology. LTE and LTE-A technologies can include LTE D2D and / or V2X technologies, and interfaces (such as sidelink communication). Similarly, 3GPP NR technology can include NR V2X technology, and interfaces (such as sidelink communication).

[0226] The base station 114a in RAN103 / 104 / 105, and the WTRUs 102a, 102b, 102c, and 102g, or the RRHs 118a and 118b, the TRPs 1115A and 1115B, and / or the RSUs 120a and 120b in RAN103b / 104b / 105b, and the WTRUs 102c, 102d, 102e, and 102f may implement radio technologies such as IEEE802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1x, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0227] The base station 114c in FIG. 15A may be, for example, a wireless router, a home node B, a home e-node B, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area such as an office, a home, a vehicle, a train, the air, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102, for example, the WTRU 102e, may implement a wireless technology such as IEEE 802.11 to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRU 102, for example, the WTRU 102d, may implement a wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). The base station 114c and the WTRU 102, for example, the WTRU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a pico cell or a femto cell. As shown in FIG. 15A, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not need to access the Internet 110 via the core network 106 / 107 / 109 in some cases.

[0228] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b may communicate with the 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, prepaid originating calls, Internet connectivity, packet data network connectivity, Ethernet connectivity, video delivery, etc., and / or may implement high-level security functions such as user authentication.

[0229] Although not shown in Fig. 15A, it will be appreciated that RAN103 / 104 / 105 and / or RAN103b / 104b / 105b and / or core network 106 / 107 / 109 may communicate directly or indirectly with RAN103 / 104 / 105 and / or RAN103b / 104b / 105b using the same RAT or with other RANs using different RATs. For example, in addition to being connected to RAN103 / 104 / 105 and / or RAN103b / 104b / 105b that may utilize E-UTRA radio technology, core network 106 / 107 / 109 may also communicate with another RAN (not shown) using GSM or NR radio technology.

[0230] Core network 106 / 107 / 109 may also function as a gateway for WTRU102 to access PSTN108, Internet 110, and / or other network 112. PSTN108 may include a circuit-switched telephone network that provides the traditional Plain Old Telephone Service (POTS). Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet protocol suite. Other network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE802.3 Ethernet network) or another core network that may be connected to one or more RANs that may employ the same RAT as RAN103 / 104 / 105 and / or RAN103b / 104b / 105b or a different RAT.

[0231] Some or all of the WTRUs 102a, 102b, 102c, 102d, 102e, and 102f in the communication system 100 may include multimode 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. For example, the WTRU 102g shown in FIG. 15A may be configured to communicate with a base station 114a that may use cellular-based wireless technology and a base station 114c that may use IEEE 802 wireless technology.

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

[0233] FIG. 15B is a system diagram of an exemplary RAN 103 and core network 106. As described above, the RAN 103 may communicate with the WTRUs 102a, 102b, and 102c via the air interface 115 using UTRA wireless technology. The RAN 103 may also communicate with the core network 106. As shown in FIG. 15B, the RAN 103 may include Node-Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c via 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 is understood that the RAN 103 may include any number of Node-Bs and Radio Network Controllers (RNCs).

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

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

[0236] RNC 142a within RAN 103 may be connected to MSC 146 within core network 106 via the IuCS interface. MSC 146 may be connected to MGW 144. MSC 146 and MGW 144 may provide access to a circuit-switched network such as PSTN 108 to WTRUs 102a, 102b, and 102c to facilitate communication between WTRUs 102a, 102b, and 102c and conventional landline communication devices.

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

[0238] Core network 106 can also be connected to other network 112 that can include other wired or wireless networks owned and / or operated by other service providers.

[0239] Figure 15C is a system diagram of an exemplary RAN104 and core network 107. As described above, RAN104 can communicate with WTRU102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN104 can also communicate with core network 107.

[0240] RAN104 can include eNode-Bs 160a, 160b, and 160c, although it can be understood that RAN104 can include any number of eNode-Bs. Each of eNode-Bs 160a, 160b, and 160c can include one or more transceivers for communicating with WTRU102a, 102b, and 102c via air interface 116. For example, eNode-Bs 160a, 160b, and 160c can implement MIMO technology. Thus, eNode-B 160a can transmit wireless signals to and receive wireless signals from WTRU102a, for example, using multiple antennas.

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

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

[0243] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c within the RAN 104 via the S1 interface and may function as a control node. For example, the MME 162 may authenticate users of the WTRUs 102a, 102b, and 102c, bearer active / inactive, and may play a role such as selecting a particular serving gateway during the initial attach of the WTRUs 102a, 102b, and 102c. The MME 162 may also provide control plane functions for exchanges between the RAN 104 and other RANs (not shown) using other radio technologies such as GSM or WCDMA.

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

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

[0246] The core network 107 can facilitate communication with other networks. For example, the core network 107 can provide access to a circuit-switched network, such as the PSTN 108, to the WTRUs 102a, 102b, and 102c to facilitate communication between the WTRUs 102a, 102b, and 102c and conventional fixed-line telephone communication devices. For example, the core network 107 can include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that functions as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 can provide access to a network 112 to the WTRUs 102a, 102b, and 102c, where the network 112 can include other wired and / or wireless networks owned and / or operated by other service providers.

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

[0248] The RAN 105 may include g-node Bs 180a and 180b. It can be understood that the RAN 105 may include any number of g-node Bs. Each of the g-node Bs 180a and 180b may include one or more transceivers for communicating with WTRUs 102a and 102b via air interface 117. When integrated access and backhaul connection is used, the same air interface may be used between the WTRU and the g-node B, and this air interface may be the core network 109 via one or more gNBs. The g-node Bs 180a and 180b may implement MIMO, MU-MIMO, and / or digital beamforming techniques. Thus, the g-node B 180a, for example, may transmit wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a using multiple antennas. It should be understood that the RAN 105 may use other types of base stations such as e-node Bs. It should also be understood that the RAN 105 may employ two or more types of base stations. For example, the RAN may use e-node Bs and g-node Bs.

[0249] The N3IWF 199 may include a non-3GPP access point 180c. It can be understood that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c via the air interface 198. The non-3GPP access point 180c may communicate with the WTRU 102c via the air interface 198 using the 802.11 protocol.

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

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

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

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

[0254] AMF172 can be connected to RAN105 via the N2 interface and can function as a control node. For example, AMF172 can play roles such as registration management, connection management, reachability management, access authentication, and access authorization. The AMF can play a role in transferring user plane tunnel configuration information to RAN105 via the N2 interface. AMF172 can receive user plane tunnel configuration information from the SMF via the N11 interface. AMF172 can generally route and transfer NAS packets to / from WTRU102a, 102b, and 102c via the N1 interface. The N1 interface is not shown in Figure 15D.

[0255] SMF174 can be connected to AMF172 via the N11 interface. Similarly, the SMF can be connected to the PCF184 via the N7 interface and to UPF176a and 176b via the N4 interface. SMF174 can function as a control node. For example, SMF174 can play roles such as session management, IP address allocation for WTRU102a, 102b, and 102c, management and configuration of traffic steering rules in UPF176a and UPF176b, and generation of downlink data notifications to AMF172.

[0256] UPF176a and UPF176b may provide access to a packet data network (PDN), such as the Internet 110, to WTRU102a, 102b, and 102c in order to facilitate communication between the WTRU102a, 102b, and 102c and other devices. UPF176a and UPF176b may also provide access to WTRU102a, 102b, and 102c to other types of packet data networks. For example, the other network 112 may be an Ethernet network, or any type of network that exchanges packets of data. UPF176a and UPF176b may receive traffic steering rules from the SMF174 via the N4 interface. UPF176a and UPF176b may provide access to the packet data network by connecting the packet data network to the N6 interface, or by connecting to each other or other UPFs via the N9 interface. In addition to providing access to the packet data network, UPF176 may perform functions such as packet routing and forwarding, enforcement of policy rules, service quality of user plane traffic, and downlink packet buffering.

[0257] The AMF172 may also be connected to the N3IWF199, for example, via the N2 interface. The N3IWF facilitates the connection between the WTRU102c and the 5G core network 170 via a radio interface technology not defined, for example, by 3GPP. The AMF may interact with the N3IWF199 in the same or a similar manner as it interacts with the RAN105.

[0258] PCF184 can be connected to SMF174 via the N7 interface, to AMF172 via the N15 interface, and to the Application Function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not shown in Figure 15D. PCF184 may provide policy rules to control plane nodes such as AMF172 and SMF174, enabling the control plane nodes to enforce these rules. PCF184 can send policies to AMF172 for WTRU102a, 102b, and 102c, and the AMF can deliver the policies to WTRU102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at WTRU102a, 102b, and 102c.

[0259] UDR178 can function as a repository for authentication certificates and subscription information. The UDR may be connected to network functions, such that the network functions can add, read, and modify data in the repository. For example, UDR178 may be connected to PCF184 via the N36 interface. Similarly, UDR178 may be connected to NEF196 via the N37 interface, and UDR178 may be connected to UDM197 via the N35 interface.

[0260] UDM197 can function as an interface between UDR178 and other network functions. UDM197 can authorize network functions to access UDR178. For example, UDM197 may be connected to AMF172 via the N8 interface, and UDM197 may be connected to SMF174 via the N10 interface. Similarly, UDM197 may be connected to AUSF190 via the N13 interface. UDR178 and UDM197 can be tightly integrated.

[0261] AUSF190 performs authentication-related operations and connects to UDM178 via the N13 interface and to AMF172 via the N12 interface.

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

[0263] The application function 188 may interact with the network functions within the 5G core network 109. The interaction between the application function 188 and the network functions may be through a direct interface or may occur via the NEF196. 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 trading relationship with the mobile network operator.

[0264] Network slicing can be used by mobile network operators and is a mechanism that supports 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 that are run across a single RAN. Network slicing enables the operator to create customized networks that can provide optimized solutions for different market scenarios with diverse requirements, for example, in terms of functionality, performance, and isolation.

[0265] 3GPP is designing the 5G core network to support network slicing. Network slicing is a good tool that can be used by network operators to support a diverse set of 5G use cases that may have very diverse and extreme requirements (e.g., massive IoT, mission-critical communications, V2X, and enhanced mobile broadband). Without using network slicing technology, when each use case has its specific set of performance, scalability, and availability requirements, it is highly likely that the network architecture will not have enough flexibility and scalability to efficiently support the needs of a wider range of use cases. Furthermore, the introduction of new network services should be made more efficient.

[0266] Referring again to FIG. 15D, in a network slicing scenario, the WTRU 102a, 102b, or 102c may be connected to the AMF 172 via the N1 interface. The AMF may be logically 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 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 separated from each other in the sense that they may utilize different computing resources, security certificates, etc.

[0267] The core network 109 can facilitate communication with other networks. For example, the core network 109 can include or communicate with an IP gateway such as an IP Multimedia Subsystem (IMS) server that functions as an interface between the 5G core network 109 and the PSTN 108. For example, the core network 109 can include or communicate with a Short Message Service (SMS) service center that facilitates communication via the Short Message Service. For example, the 5G core network 109 can facilitate the exchange of non-IP data packets between the WTRUs 102a, 102b, and 102c and the server or application function 188. In addition, the core network 170 can provide the WTRUs 102a, 102b, and 102c with access to the network 112, which can include other wired or wireless networks owned and / or operated by other service providers.

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

[0269] Figure 15E shows an exemplary communication system 111 in which the systems, methods, and apparatuses 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 gNB121, 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 gNB, V2X networks, and / or other network elements. One or more, or all, of the WTRUs A, B, C, D, E, and F may be outside the coverage 131 of the access network. WTRUs A, B, and C form a V2X group, in which WTRU A is the group leader and WTRUs B and C are group members.

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

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

[0272] Figure 15F is a block diagram of an exemplary apparatus or device WTRU102 that can be configured for wireless communication and operation by the systems, methods, and apparatuses described herein, such as the WTRU102 of FIGS. 15A, 8B, 8C, 8D, or 8E. As shown in FIG. 15F, an exemplary WTRU102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power source 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138. It can be understood that the WTRU102 may include any sub-combination of the foregoing elements. Also, base stations 114a and 114b, and / or base stations 114a and 114b may represent, but are not limited to, a base 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, among others, and may include some or all of the elements illustrated in FIG. 15F and described herein.

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

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

[0275] In addition, although the transmit / receive element 122 is shown in FIG. 15F as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may use MIMO technology. Accordingly, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interfaces 115 / 116 / 117.

[0276] The transceiver 120 may be configured to modulate the signals transmitted by the transmit / receive element 122 and demodulate the signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Accordingly, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11 or NR and E-UTRA, or to communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

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

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

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

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

[0281] WTRU 102 may be included in a sensor, a household appliance, a wearable device such as a smartwatch or smart clothing, a medical or e-health device, a robot, industrial equipment, a drone, a vehicle such as an automobile, a truck, a train, or other devices or apparatuses such as an airplane. WTRU 102 can be connected to other components, modules, or systems of such devices or apparatuses via one or more interconnect interfaces such as an interconnect interface that includes one of the peripheral devices 138.

[0282] FIG. 15G is a block diagram of an exemplary computing system 90 in which one or more devices of the communication networks illustrated in FIGS. 8A, 8C, 8D, and 8E, such as a particular node or functional entity, can be embodied in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, other network 112, or network service 113. The computing system 90 may include a computer or a server and may be primarily controlled by computer-readable instructions. The computer-readable instructions may be in the form of software, located anywhere, or by any means by which such software is stored or accessed. Such computer-readable instructions may be executed within a processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a dedicated 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 coding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. The coprocessor 81 is any processor different from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 can receive, generate, and process data related to the methods and apparatuses disclosed herein.

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

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

[0285] In addition, the computing system 90 can include a peripheral device controller 83 that serves to communicate instructions from the processor 91 to peripheral devices such as a printer 94, a keyboard 84, a mouse 95, and a disk drive 85.

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

[0287] Furthermore, the computing system 90 may include a communication circuit, such as a wireless or wired network adapter 97, that is used to connect the computing system 90 to an external communication network or device, such as the RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other network 112 of FIGS. 8A, 8B, 8C, 8D, and 8E, enabling the computing system 90 to communicate with other nodes or functional entities of those networks. The communication circuit may be used, alone or in combination with the processor 91, to perform the transmit and receive steps of the particular apparatus, node, or functional entity described herein.

[0288] Any or all of the apparatuses, systems, methods, and processes described herein may be embodied in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which instructions, when executed by a processor such as processor 118 or 91, cause the processor to implement and / or execute the systems, methods, and processes described herein. Specifically, any of the steps, operations, or functions described herein may be implemented in the form of such computer-executable instructions that are executed on a processor of an apparatus or computing system configured for wireless and / or wired network communication. A computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage medium does not include signals. Computer-readable storage media includes RAM, ROM, EEPROM, flash memory, or other memory technologies, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage devices, or other magnetic storage devices, or any other tangible or physical medium that can be used to store 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: transmitting a registration request message to a network, the registration request message including an indication that the WTRU is capable of supporting utilization of time availability information of a network slice; receiving from the network a registration acceptance message indicating time availability information of one or more network slices, the time availability information indicating, for each of the one or more network slices, the availability of the one or more network slices during their respective indicated access periods, and each of the respective indicated access periods including a first time at which the one or more network slices become available and a second time at which the one or more network slices become unavailable; determining, based on the received time availability information, that a network slice has become unavailable; releasing one or more protocol data unit (PDU) sessions associated with the network slice determined to be unavailable during a time period; receiving from the network a configuration update message indicating updated time availability information of the one or more network slices.

2. The method of claim 1, further comprising sending a notification indicating a reason to stop starting a PDU session when an inactive time period of the network slice is approaching.

3. The method of claim 1, wherein the registration acceptance message is a registration response message received in response to the registration request message.

4. The method of claim 1, further comprising stopping a PDU session based on the network slice being unavailable during the time period.

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

6. The method of claim 1, wherein the time information of the indicated access period includes a first time at which the one or more network slices become available and a second time at which the one or more network slices become unavailable. **Claim 7**: The method of claim 1, wherein the registration request message further indicates that the WTRU supports per-application authentication and authorization (PAAA). **Claim 8**: The method of claim 7, wherein the registration acceptance message from the network further indicates that a network slice of the one or more network slices requires PAAA from the WTRU. **Claim 9**: Determining to notify an application that a network slice is becoming unavailable; and further comprising determining to attempt a different network slice of the one or more network slices for transmitting data. The method of claim 1.

Images