SNPN registration and obtaining SNPN service from PLMN

Abstract

A user equipment (UE) operating in a "registration mode" may search for a network that broadcasts registration capability information (OCI), and then register using a registration credential and receive an SNPN credential from the network. The UE may then exit the registration mode, enter a manual or automatic network selection mode, and connect to the SNPN. The UE may also receive a list of equivalent PLMNs and SNPNs from a network, and then indicate to the network when registered that the requested slice is not associated with the UE's HPLMN, but is associated with the SNPN. The network may indicate to the UE how slices of the network are mapped to slices of the SNPN, and may indicate whether slices provided by the network are only partially mapped to slices of the SNPN or HPLMN.

Description

[0001] This application is a divisional application of patent application No. 202180029417.9, filed on March 23, 2021, entitled "SNPN Registration and Obtaining SNPN Services from PLMN". Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 994,916, filed March 26, 2020, and U.S. Provisional Patent Application No. 63 / 057,920, filed July 29, 2020, the contents of which are incorporated herein by reference. Background Technology

[0003] This disclosure relates to the management of devices in wireless networks, such as devices and networks described, for example, in the following documents: 3GPP TS 23.501, System Architecture for 5G Systems (5GS); 3GPP TS 23.502, Procedures for 5G Systems (5GS); 3GPP TS 23.003, Numbering, Addressing and Identification; 3GPP TS 24.501, Non-Access Stratum (NAS) Protocol for 5G Systems (5GS), Phase 3; 3GPP TR 23.700-07, Study on Enhanced Support for Non-Public Networks; and 3GPP TS 24.008, Mobile Radio Interface Layer 3 Specification; Core Network Protocol; Phase 3. Summary of the Invention

[0004] User equipment (UE) operating in "registration mode" can search for networks broadcasting Registration Capability Information (OCI) and then send a registration request to that network using registration credentials. The UE can also send information to the RAN node to help the RAN node select an AMF that supports registration. The UE then receives SNPN credentials from the network and subsequently exits registration mode, enters manual or automatic network selection mode, and connects to the SNPN.

[0005] The UE can also receive a list of equivalent PLMNs and SNPNs from the network. When registering with the network, the UE can then indicate to the network that the requested slice is not associated with the UE's HPLMN, but with the SNPN. The network can then instruct the UE on how network slices are mapped to SNPN slices.

[0006] The network can indicate whether the slices provided by the network are only partially mapped to slices of SNPN or HPLMN.

[0007] The network can also indicate to the UE that it cannot or is unwilling to register the UE. The UE determines which network to connect to when multiple networks broadcast indications that they can register the device. The UE and the network can authenticate each other before performing the registration operation.

[0008] The purpose of providing this summary is to introduce selected concepts in a simplified form, which are further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to addressing any or all of the shortcomings pointed out in any part of this disclosure. Attached Figure Description

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

[0010] Figure 1 An example network identifier (NID) is shown.

[0011] Figure 2 An exemplary S-NSSAI information element is shown.

[0012] Figure 3 This is a block diagram illustrating an example of accessing PLMN services via a standalone, non-public network.

[0013] Figure 4 This is a block diagram illustrating an example of accessing a standalone non-public network service via a PLMN.

[0014] Figure 5 This is a call flowchart for an exemplary registration procedure.

[0015] Figure 6 An example SNPN list information element is shown.

[0016] Figure 7 An exemplary S-NSSAI enhanced to carry SNPN information is shown.

[0017] Figure 8 An exemplary S-NSSAI information element with SST and SD masks is shown.

[0018] Figure 9A An exemplary communication system is shown, in which the methods and apparatus described and claimed herein are specifically embodied.

[0019] Figure 9B This is a block diagram of an exemplary device or apparatus configured for wireless communication.

[0020] Figure 9C This is a system diagram of an exemplary radio access network (RAN) and core network.

[0021] Figure 9D This is another exemplary system diagram of the RAN and core network.

[0022] Figure 9E This is another exemplary system diagram of the RAN and core network.

[0023] Figure 9F This is a block diagram of an exemplary computing system.

[0024] Figure 9G This is a block diagram of another exemplary communication system.

[0025] Figure 10 This is a call flowchart of an exemplary registration procedure, in which the registration process to the first network fails, so the UE attempts to register to the second network. Detailed Implementation

[0026] abbreviation Many of the abbreviations used in this article are described in Table 1 of the appendix.

[0027] It should be understood that both AAA-S and DN-AAA are types of AAA servers.

[0028] User Equipment (UE) Traditionally, a UE refers to a mobile phone, mobile computer, mobile broadband adapter, connected vehicle, or other connected device that can connect to a cellular network. A UE has an MT (Mobile Terminal) portion that provides a cellular radio interface and a TE (Terminal Equipment) portion that provides services to the user and typically does not provide features specific to the cellular radio interface portion. For example, the TE may provide a control GUI. A UE may also have a SIM (SIM) for storing user credentials and network identity. It should be understood that the concepts in this document are equally applicable to devices that do not have a SIM for storing user credentials and network identity. Alternatively, the device may store user credentials and network identity in other forms of non-volatile memory. Therefore, all concepts described in this document as applicable to a UE are equally applicable to any device attempting to register with a network.

[0029] UE Registration UE registration, as defined in TR 23.700-07, is the action of pre-setting the information required by the UE when it obtains authorized access and connection to the NPN.

[0030] Non-public network (NPN) A non-public network (NPN) is a 5GS deployed for non-public purposes. An NPN can be deployed as, for example, a standalone non-public network (SNPN) operated by an NPN operator and not dependent on network functionality provided by a PLMN, or as a public network integrated NPN (PNI-NPN) (e.g., a non-public network deployed with the support of a PLMN). This is further described in Section 5.30 of TS 23.501.

[0031] As explained in TS 23.003, the combined identifier of the SNPN is the PLMN ID and the Network Identifier (NID). The NID consists of the assignment pattern and the NID value, such as... Figure 1 As shown.

[0032] The NID assignment mode can be "locally managed" or "non-locally managed". If the assignment mode is "non-locally managed", an NID can be assigned such that it is globally unique, independent of the PLMN ID used, or an NID can be assigned such that the combination of the NID and the PLMN ID is globally unique.

[0033] It should be understood that the solutions for SNPN described in this document can also be applied to other types of NPN (e.g., PNI-NPN).

[0034] SNPN access mode If the UE is not configured to operate in SNPN access mode, the UE will decode the broadcast system information and take into account information about the available PLMN ID in the PLMN and cell (re)selection procedure.

[0035] If the UE is configured to operate in SNPN access mode, the UE will decode the broadcast system information and take into account information about the available PLMN ID and NID in the network and cell (re)selection procedure.

[0036] Network selection in SNPN access mode UEs operating in SNPN access mode read the list of available PLMN IDs and available NIDs from the broadcast system information and take them into consideration during network selection.

[0037] For automatic network selection, the UE selects and attempts to register with an available SNPN identified by its PLMN ID and NID, and the UE has the SUPI and credentials for that available SNPN. If multiple SNPNs are available, and the UE has the corresponding SUPIs and credentials for each of these multiple SNPNs, the priority order for selecting and attempting to register with the SNPN is based on the specific implementation of the UE.

[0038] For manual network selection, a UE operating in SNPN access mode provides the user with a list of NIDs of available SNPNs and their associated human-readable names (if available), and the UE has the corresponding SUPI and credentials for that available SNPN.

[0039] When the UE performs initial registration with the SNPN, the UE indicates the selected NID and corresponding PLMN ID to the NG-RAN. The NG-RAN then informs the AMF of the selected PLMN ID and NID.

[0040] Equivalent PLMN (EPLMN) The UE stores a list of equivalent PLMNs. These PLMNs should be considered by the UE as equivalent to each other for PLMN selection and cell selection / reselection. The UE updates the list associated with PLMNs at the end of each registration procedure. This is further described in TS 24.501.

[0041] As explained in TS 23.502, when a UE registers in an SNPN, the network does not provide the UE with a list of equivalent PLMNs.

[0042] Connect to a non-public network As described in Section 5.30.2.2 of TS 23.501, NG-RAN nodes providing access to the SNPN broadcast the PLMN ID and a list of NIDs for each PLMN ID. The NID identifies the non-public network for which the NG-RAN provides access.

[0043] As described in Section 4.2.2.2.2 of TS 23.502, when a UE sends a registration request to the NG-RAN, the UE includes AN parameters. The AN parameter information element includes the selected PLMN ID (or PLMN ID and NID).

[0044] Network slices in 5GC A network slice is defined as a logical network that provides specific network capabilities and characteristics. Within a PLMN, a network slice includes core network control plane and user plane network functions. A network slice instance is defined as a set of network function instances and the resources (e.g., compute, storage, and networking resources) required to form the deployed network slice.

[0045] Network slices may differ in their supported features and network function optimizations, in which case such network slices may have different slice / service types. Operators may deploy multiple network slice instances delivering the same features, but for different UE groups, for example, because they deliver different committed services and / or because they are dedicated to a particular customer, such network slices may have the same slice / service type, but be distinguished by different slice distinguishers.

[0046] This network can simultaneously serve a single UE with one or more network slice instances via 5G-AN and is associated with a total of up to eight different S-NSSAIs, regardless of the access type the UE registers on it (e.g., 3GPP access and / or N3GPP access). An AMF instance serving a UE logically belongs to each network slice instance serving the UE; for example, the AMF instance is common to the network slice instance serving the UE.

[0047] Network Slice Identification and Selection: S-NSSAI and NSSAI Network slices are identified by S-NSSAI, which includes Slice / Service Type (SST) and Slice Differentiator (SD). Slice / Service Type (SST) refers to the expected network slice behavior in terms of characteristics and services. SD refers to optional information supplementing the Slice / Service Type to differentiate between multiple network slices of the same Slice / Service Type.

[0048] S-NSSAI can have standard values ​​(e.g., such S-NSSAI consists only of SSTs with standard SST values ​​and no SD) or non-standard values ​​(e.g., such S-NSSAI consists of either both SST and SD, or only of SSTs without standard SST values ​​and no SD). S-NSSAI with non-standard values ​​identifies a single network slice within the PLMN to which it is associated. S-NSSAI with non-standard values ​​should not be used by the UE in any PLMN access stratum procedure, except for the PLMN associated with the S-NSSAI. Table 2 shows the standardized SST values.

[0049] NSSAI is a collection of S-NSSAIs. An NSSAI can be a configured NSSAI, a requested NSSAI, or an allowed NSSAI. A maximum of eight S-NSSAIs can be sent in the signaling messages between the UE and the network, including both allowed and requested NSSAIs. Requested NSSAIs signaled by the UE to the network allow the network to select the serving AMF, network slice, and network slice instance for that UE.

[0050] Based on the operator's operational or deployment requirements, 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. When multiple network slice instances associated with the same S-NSSAI are deployed in the same tracking area, the AMF instance serving the UE can logically belong to (e.g., collectively belong to) more than one network slice instance associated with that S-NSSAI.

[0051] Based on the requested NSSAI (if any) and subscription information, 5GC is responsible for selecting a network slice instance to serve the UE, including the 5GC control plane and user plane network functions corresponding to that network slice instance.

[0052] The (R)AN may use the requested NSSAI in the access stratum signaling to process the UE control plane connection before the 5GC notifies the (R)AN of the allowed NSSAI. The requested NSSAI is used by the RAN for AMF selection, as described in Clause 6.3.5 of TS 23.501. When the UE queries to restore RRC connection and connects to the RRC inactive state CM, the UE should not include the requested NSSAI in the RRC restoration.

[0053] When a UE successfully registers through an access type, the CN notifies the (R)AN by providing an allowed NSSAI for the corresponding access type.

[0054] Standardized SST values ​​provide a way to establish global interoperability for slices, enabling PLMNs to more effectively support roaming use cases for the most commonly used slice / service types. Standardized SSTs are listed in Table 2 of the appendix.

[0055] NSSAI configuration A configured NSSAI is an NSSAI provided in the UE that applies to one or more PLMNs. A configured NSSAI can be configured by and applied to the serving PLMN. Each PLMN can have a maximum of one configured NSSAI.

[0056] NSSAI with default configuration The default NSSAI configuration is provided by the HPLMN and applies to any PLMN that has not provided a specific NSSAI configuration to the UE. The values ​​used in the default NSSAI configuration are generally expected to be determined by all roaming partners. If the default NSSAI configuration is provided in the UE, the UE will only use it in the serving PLMN if the UE has not configured an NSSAI for the serving PLMN. The UE may be pre-configured with a default NSSAI configuration.

[0057] Requested NSSAI The requested NSSAI is the NSSAI provided by the UE to the serving PLMN during registration. The S-NSSAI in the requested NSSAI is selected from the configured NSSAI applicable to that PLMN (when available). If no configured NSSAI for the PLMN is available, then if configured in the UE, the S-NSSAI in the requested NSSAI is selected from the default configured NSSAI.

[0058] The requested NSSAI, signaled by the UE to the network, allows the network to select a serving AMF, network slice, and network slice instance for the UE. Based on the requested NSSAI (if any) and subscription information, the 5GC is responsible for selecting a network slice instance to serve the UE, including the 5GC control plane and user plane network functions corresponding to that network slice instance.

[0059] NSSAI allowed The allowed NSSAI is the NSSAI provided to the UE by the serving PLMN during the registration procedure, indicating the S-NSSAI value the UE registers with in the serving PLMN of the current registration area. When the UE registration procedure is successfully completed by access type, the UE obtains the allowed NSSAI for that access type from the AMF, which includes one or more S-NSSAIs and (if necessary) their mappings to HPLMN S-NSSAIs. These S-NSSAIs are valid for the current registration area and access type and can be used by the UE simultaneously.

[0060] Allowed NSSAI mapping The allowed NSSAI mapping is the mapping of each S-NSSAI of the allowed NSSAI of the PLMN to the HPLMN S-NSSAI.

[0061] Configured NSSAI mapping The configured NSSAI mapping is the mapping of each S-NSSAI of the PLMN to the HPLMN S-NSSAI of the configured NSSAI.

[0062] S-NSSAI encoding The purpose of S-NSSAI information elements is to identify network slices. The encoding of S-NSSAI information elements is as follows: Figure 2 As shown in Table 3 of the appendix, as described in 9.11.2.8 of TS 24.501.

[0063] S-NSSAI is a type 4 information element with a minimum length of 3 octets and a maximum length of 10 octets.

[0064] Accessing PLMN services via SNPN and accessing SNPN services via PLMN As described in Appendix D.3 of TS 23.501, a UE can use its NPN connection to access PLMN services. To gain access to PLMN services while the UE is camped in an NG-RAN on a standalone non-public network, the UE obtains an IP connection, discovers an N3IWF in the PLMN, and establishes a connection with that N3IWF. This is in Figure 3 As shown, it is copied from Appendix D.3 of TS 23.501.

[0065] As described in Appendix D.3 of TS 23.501, a UE can use its PLMN connection to access SNPN services. To gain access to non-public network services while the UE is camped in the NG-RAN of the PLMN, the UE obtains an IP connection, discovers an N3IWF in the independent non-public network, and establishes a connection with that N3IWF. This is in Figure 4 As shown, it is copied from Appendix D.3 of TS 23.501.

[0066] Example Challenge TR 22.821 describes a use case where user Grace is responsible for installing networked devices in a new production line at a factory. She needs to remove, configure, install, and test the devices, and work with her colleagues to ensure smooth operation of the production process. Grace's devices include sensors, actuators, and controllers that communicate using 5G LAN services. In this deployment, her factory owns and deploys a private network using 3GPP technologies and acts as the network operator. Grace uses tools to securely configure the devices for services on the factory's 5G LAN system. This use case raises the requirement that the 5G system needs to support a security mechanism that allows operators to pre-configure 3GPP credentials for industrial IoT devices used for 5G LAN-type services.

[0067] TR 23.700-7 describes key issues concerning UE registration and remote provisioning. A crucial aspect of these key issues is considering how the 5G system provides and updates the subscriptions of authorized UEs to allow them to request connections to their desired NPNs. The aim of these key issues is to investigate how UEs discover and select NPNs before provisioning their subscriptions. The key issues will also consider how the network authenticates the UE before provisioning its subscription, and once authenticated, how it remotely provides the UE with the necessary new or updated information to enable it to access the NPN using 5GS. The solution to this problem should define what triggers the registration process, and the solution should consider the fact that a UE may not have a UICC and the TE may not have an interface available for providing MT.

[0068] In some scenarios, the information broadcast by the O-SNPN may not be sufficient for the UE to determine if the O-SNPN is a network that the UE can register with. This document describes how the UE can detect if a network is not a network that the UE can register with and how the UE can determine which network it should try to contact next for registration. For example, there may be a scenario where the UE attempts to register with the wrong network. Therefore, procedures are needed to allow the UE to verify whether it is already connected to the correct network, and in scenarios where the UE determines that it is not connected to the correct network, procedures are needed to allow the UE to determine which network to connect to. Determining the correct network requires procedures to allow the UE to authenticate the network. Therefore, the registration procedure needs to allow the network and the UE to authenticate each other to prevent a malicious UE from connecting to a valid network or a valid UE from connecting to a malicious network.

[0069] Some devices may have subscriptions in both the NPN and the MNO. In this scenario, the procedures in Annex D.3 of TS 23.501 can be used to access services of the SNPN via the PLMN and services of the PLMN via the SNPN. However, in other scenarios, IP connectivity between the IP (e.g., N6) network of the PLMN and the IP (e.g., N6) network of the SNPN may not be available. In this scenario, some services provided by slices of the SNPN may also be provided by slices of the PLMN of the MNO. In scenarios where some services of the same type are available in both the SNPN and the PLMN of the MNO, 5G systems need to be enhanced to support both seamless service continuity of subscribed PLMN services between the non-public network and the PLMN, and seamless service continuity of non-public network services between the non-public network and the PLMN. To support service continuity between the NPN and the PLMN, the UE needs to be configured with information that allows it to know how slices of the NPN are mapped to slices of the PLMN. Currently, such a mechanism does not exist in 5G systems. A similar issue described in TR 23.700-07 is how to support service continuity between SNPNs. This involves enabling authorized UEs to effectively select equivalent SNPNs during network selection, and to effectively access and move between equivalent SNPNs. Currently, when a UE registers in a PLMN, the AMF can provide a list of equivalent PLMNs as specified in TS 24.501. However, for UEs registered in an SNPN, the AMF should not provide the UE with a list of equivalent PLMNs. Enhancements to the 5G system are needed to configure the UE with information that enables it to move between equivalent SNPNs and understand how slices of one NPN are mapped to slices of another NPN.

[0070] Exemplary Solution This document outlines a registration procedure that a UE can use to obtain SNPN credentials from a network and a procedure that a UE can use to instruct a first network (e.g., PLMN) that it wants to obtain services from the first network that the UE would normally obtain from a second network (e.g., SNPN).

[0071] Registration As described above, a UE operating in SNPN mode performs either automatic network selection or manual network selection. A new third mode, called the registration mode, is proposed for operation when the UE is in SNPN mode without SNPN credentials. In registration mode, the UE selects and attempts to register with a RAN node that broadcasts an indication in its SIB or MIB that the network supports UE registration. Alternatively, the presence of a specific SIB in the base station's broadcast information can be used as an indication to the UE that the network supports UE registration. The RAN node may additionally broadcast registration capability information to the UE, providing information about the network's registration capabilities. For example, registration capability information (OCI) may indicate the following information.

[0072] First, the types of devices that can be registered on the network (e.g., UE type). An example of device capability is a control plane-only type device (e.g., a UE that only uses NAS transmission to send and receive data through the control plane).

[0073] Second, the types of credentials for network authentication.

[0074] Third, if the network can authenticate devices from certain manufacturers, it can broadcast manufacturer identifiers.

[0075] Fourth, if the network can authenticate devices associated with certain AAA servers, it can broadcast the manufacturer's AAA server identifier.

[0076] Fifth, a special CAG identifier pre-configured on the UE and an indication to the UE that it is eligible for registration.

[0077] Sixth, other information, such as support for UEs that register without credentials, UEs with only manufacturer information (e.g., model, serial number, etc.), UEs with only device credentials (e.g., via the manufacturer), UEs with credentials for authentication with the AAA server, and UEs with eSIM capabilities. Additionally, OCI may include network support to help the UE determine whether the network provides the required network slice type (e.g., SST) for the UE.

[0078] Seventh, the network can broadcast instructions that are pre-installed on the device packaging, such as information provided to the network via application functions or servers, and broadcast an invitation code for the device to search on a frequency that the device is monitoring.

[0079] Eighth, the network can broadcast instructions on what authentication, authorization, and registration procedures the network supports. Examples of registration procedures include control plane (NAS)-based registration, user plane-based registration, registration during secondary authorization / authentication by the DN-AAA server during the PDU session establishment process, and registration during network slice-specific authentication and authorization procedures.

[0080] OCI can be broadcast by the network on demand (e.g., per UE request).

[0081] When the UE operates in registration mode, it checks the RAN nodes that broadcast the Registration Support Indicator (OSI). In the following text, the Registration Support Indicator can be understood as an explicit indicator included in system information to indicate support for registration by a given RAN node, or alternatively, the Registration Support Indicator can be understood as the presence of a specific SIB in a base station's broadcast system information message. If the RAN node is broadcasting the Registration Support Indicator, the UE reads the OCI. The UE checks whether the information in the OCI aligns with the type of network the UE needs to register with. Additionally, the UE can be pre-configured with credentials or certificates that it can use to authenticate with the SNPN. If the UE is pre-configured to search for and connect to networks that broadcast certain values ​​in the OCI, the UE may consider aligning the information in the OCI. For example, the UE may be pre-configured to discover and attempt to connect to networks that broadcast indications that they can register from devices from certain manufacturers. If the OCI aligns (e.g., it does match some information pre-configured in the UE), the UE sends a registration request or enrollment request to the network. The registration request may include the following information.

[0082] First, PEI (e.g., manufacturing identifier, serial number, etc.).

[0083] Second, registration credentials (if available).

[0084] Third, register the credential type indicator (e.g., the credential type indicator).

[0085] Fourth, the manufacturer ID, device model and serial number, and other device-related information. Fifth, AAA server identifier Sixth, instructions for UE to register. Seventh, CAG identifier Eighth, an identifier that can be used to identify the UE for charging purposes.

[0086] Ninth, the domain identifier associated with the provisioning server (e.g., the manufacturer's provisioning server).

[0087] Tenth, instructions on what certification, authorization, and registration procedures the device supports.

[0088] Eleventh, indication of equipment capabilities (e.g., if the equipment is a control plane-only device).

[0089] Twelfth, the UE wants to authenticate the network and the network should provide a response indication, wherein at least part of the response is encrypted with a key that is expected to be preset in both the network and the UE.

[0090] The above information can be included in either or both of the NAS registration request and the RRC establishment request. The UE may include the same information in both requests because the NAS registration request can be encrypted with registration credentials, and it may be desirable to make some of the above information visible to the RAN node. For example, the RAN node may use the Manufacturer ID to select the AMF that can be used to authenticate devices from the indicated manufacturer. For example, the RAN node may use the AAA Server ID to select the AMF that can be used to authenticate devices associated with the identified AAA server. For example, the RAN node may use the credential type to select the AMF that can be used to authenticate devices associated with the identified credential type.

[0091] During the registration process, the network (e.g., AMF and AUSF) can authenticate the UE using the UE's registration credentials, just as it normally does during registration. The network can then send the SNPN credential to the UE. The SNPN credential may include the following information.

[0092] First, SUPI can be used to communicate with SNPN.

[0093] Second, SNPN's identity Third, the list of allowed CAGs associated with the UE.

[0094] Fourth, only CAG indication.

[0095] Fifth, any information required by the UE to establish a tunnel between the UE and the NPN's N3IWF via the PLMN.

[0096] The network can choose any of the following options to send SNPN credentials to the UE.

[0097] First, the network can send credentials to the UE in a registration response or rejection message.

[0098] Second, during registration, the network can send a URSP rule to the UE that directs all traffic to the AAA server or directs all authentication requests to the AAA server and all other traffic to an empty destination where no traffic will be processed. The UE can then communicate with the AAA server and download SNPN credentials. The URSP rule can be based on information received from the UE in the registration request. For example, the registration request may have already included a domain identifier for setting up the server. The URSP rule can cause the UE to direct all traffic associated with a specific domain to a certain combination of S-NSSAI / DNN / IP address / port number. Therefore, all traffic is routed to the AAA server associated with the domain identifier.

[0099] Figure 5 An example of a program that can be used to register a UE is shown.

[0100] In step 0, registration credentials and OCI information are pre-configured for the UE. The UE uses the OCI to retrieve network information in registration mode.

[0101] In step 1, the UE is placed into registration mode. This can be done by turning on the UE, resetting the UE, or initiating registration mode using a button or GUI. The UE automatically enters registration mode when turned on, and it only has registration credentials.

[0102] In step 2, the UE receives the OCI broadcast by the RAN.

[0103] In step 3, the UE sends an RRC connection request and a registration request to the network. Both the RRC connection request and the registration request may include information such as the UE's PEI and registration credentials. The RAN node will perform AMF selection and forward the registration request to the AMF. The information in the RRC connection request (e.g., the UE's PEI, registration credentials, registration indication, etc.) is used to detect that the UE is connecting to register, and this information is considered by the RAN node during AMF selection.

[0104] In step 4, the AMF will send a registration response to the UE. The registration response may include the UE's SNPN credentials or URSP rules related to the UE's registration traffic.

[0105] Furthermore, when a UE indicates to the network that the registration request is for UE registration, the network may initiate the network slice-specific authentication and authorization procedure described in Section 4.2.9.2 of TS 23.502. (The indication to the network that the registration request is for UE registration may be made via an explicit indication in the registration request or via a dedicated S-NSSAI that includes the indication to register in the registration request.) The network slice-specific authentication and authorization procedure can be used to authenticate and authorize the UE for registration. Additionally, this procedure can be used to register the UE (e.g., by providing network credentials to the UE in the network slice-specific authentication and authorization procedure described in Section 4.2.9.2 of TS 23.502). Credentials may be provided to the UE as part of an EAP request / response message or as part of an EAP success message carried in a NAS MM transmission message.

[0106] In step 5, the UE can initiate an application layer procedure to download SNPN credentials from a server (e.g., an AAA server). The URSP rules downloaded in step 4 can be used to direct application layer traffic to the server.

[0107] Application layer traffic requires a PDU session. Therefore, a PDU session must be established before any application layer traffic is generated. A PDU session establishment request can be triggered by the DN-AAA server during the PDU session establishment procedure for secondary authorization / authentication. This procedure can be used to authenticate and authorize the UE for registration. Typically, the network will know when a DNN is detected in the PDU session establishment request and that secondary authorization / authentication is triggered by the DN-AAA server during the PDU session establishment procedure. Since it may not be possible to pre-configure the DNN to the UE before the initial registration operation, the PDU session establishment request can be enhanced to allow the UE to include a registration indication in the PDU session establishment request. Additionally, procedures can be used to register the UE (e.g., network credentials can be provided to the UE in EAP-based secondary authentication via an external DN-AAA server procedure defined in Section 11.1.1 of TS 33.501). Credentials can be provided to the UE as part of an EAP request / response message, as part of an EAP success message carried in a PDU session establishment acceptance message, as part of the PCO, or as part of the registration policy.

[0108] In step 6, the UE will enter either automatic network selection mode or manual network selection mode and attempt to connect to the SNPN using SNPN credentials.

[0109] Authentication-based network detection When a UE sends a registration request to the O-SNPN, the UE needs to check that it is connected to the correct network, and the network needs to verify that the UE is a UE that the network should register. If the network determines that the UE is a UE that the network should register, the network needs to further determine what information and credentials it should pre-configure (e.g., register) for the UE.

[0110] The UE may be accompanied by initial information. This initial information can be pre-configured in the UE during the manufacturing process. Initial information may include an initial ID, device key, and network key. This initial information may be provided on the device tag or included with the device packaging. The network may expose an API that allows network administrators to provide the initial information to the network. When the UE sends a registration request to the network (e.g., as...), Figure 5 As shown in step 3, the content of the NAS registration request can be encrypted with the device key, and the initial ID can be sent "plaintext" (e.g., unencrypted). If the network is able to decrypt the NAS registration request using the device key provided by the API, the network can consider the device to be authenticated.

[0111] If the network can authenticate the UE, the network can send a registration response encrypted with the network key provided by the API (e.g., as shown in the image). Figure 5 (See step 4). If the UE can decrypt the NAS registration response using the network key pre-installed on the device during manufacturing, the UE can consider the network to be authenticable. After authenticating with the network, the UE can continue the registration process (e.g., as shown in step 4). Figure 5 (As shown).

[0112] If the network cannot authenticate the UE—in other words, if the network cannot decrypt the registration request or cannot identify the device identifier—the network may send a registration rejection to the UE. The following sections describe what information the network can send to the UE to indicate that the network cannot register the UE and to help the UE identify a new network to attempt registration with.

[0113] As described above, the network slice-specific authentication and authorization procedures described in Section 4.2.9.2 of TS 23.502 or the secondary authorization / authentication performed by the DN-AAA server during the PDU session establishment procedure as described in Section 11.1.1 of TS33.501 can be used to authenticate the UE and determine whether the UE is connected to the correct O-SNPN. These two procedures can be updated so that EAP interactions between the UE and the DN-AAA or AAA-S are mutual authentication procedures between the UE and the DN-AAA or AAA-S using the initial information as previously described.

[0114] Handling the case of selecting the wrong network In some scenarios, the information broadcast by the O-SNPN may not be sufficient for the UE to determine that the O-SNPN is a network that the UE can register with. This section describes how the UE can detect that a network is not a network that the UE can register with, and how the network can determine which network it should try to contact next for registration.

[0115] The selected O-SNPN was detected to be incorrect. exist Figure 5 In step 3, when the UE attempts to register with the network, the AMF can detect that it cannot or is unwilling to register the UE. In this scenario, the AMF can send a registration rejection message to the UE in step 4. The registration rejection reason code can indicate to the UE that the network cannot or is unwilling to register the UE. The reason code can also indicate the reason why the network cannot or is unwilling to register the UE. For example, the reason code can indicate: First, the UE's identifier was not identified (e.g., PEI, manufacturing identifier, serial number, etc. were not identified).

[0116] Second, the UE's registration credentials are not available on the network.

[0117] Third, the indication of the type of registration credentials provided in the registration request (e.g., the indication of the certificate type) was not identified.

[0118] Fourth, the manufacturer ID, device model and serial number, and other device-related information were not identified or supported.

[0119] Fifth, the AAA server identifier provided in the registration request was not identified or could not be obtained at this time.

[0120] Sixth, the network identifies the UE's identifier but has determined that the UE is already registered and should not require new credentials. Human interaction with the network administrator may be necessary to resolve this type of denial.

[0121] Seventh, the CAG identifier received from NG-RAN is not part of the UE's list of allowed CAGs.

[0122] Eighth, an indication that the network recognizes the UE's identifier but the account associated with the UE is not enabled (e.g., the charging system indicates insufficient funds in the user's account). Human interaction with a network administrator may be required to resolve this type of denial. Ninth, registration redirection information instructing the UE that the current network is unable or unwilling to register the UE and providing the UE with sufficient information to discover networks willing to register the UE. Registration redirection information may include the previously described Registration Capability Information (OCI).

[0123] Tenth, a backoff timer that indicates how long the UE must wait before attempting to register with the same network again.

[0124] If network slice-specific authentication and authorization procedures are used to authenticate the UE, authorize the UE, and / or deliver credentials to the UE for accessing the SNPN, then AAA-S may indicate any of the information described above to the UE as part of the registration rejection reason code.

[0125] It is possible that the UE and / or the network are uncertain during the registration process that the network cannot register the UE. Instead, the network may simply instruct the UE to register with the network for the purpose of registration. The UE may interpret the registration acceptance as being used solely for registration because the UE provided a registration instruction in the registration request. Alternatively or additionally, the network may instruct the UE in the registration acceptance message that registration is only for registration. The registration acceptance message may provide the UE with the S-NSSAI and / or DNN that can be used for registration. For example, the URSP rules provided to the UE in the registration acceptance message may direct all traffic to the registration S-NSSAI and DNN combination. The registration acceptance message may also include LADN information (e.g., LADN service area information and LADN DNN), and it is understood that, since registration is only for registration, the LADN information indicates the DNN and area that the UE can establish a PDU session for and register with. The network may provide the same S-NSSAI to the UE in the allowed NSSAI. Alternatively, when the UE establishes a PDU session, the UE may not provide an S-NSSAI or DNN but may provide a registration instruction. The network can associate a PDU session with registration S-NSSAI and DNN. The AMF can determine to associate the PDU session with registration S-NSSAI and DNN based on an indication received from the AMF or based on a registration indication received from the UE in the PDU session establishment request. The UE can then attempt to register by initiating application layer signaling. If secondary authorization / authentication performed by the DN-AAA server during the PDU session establishment procedure is used to authenticate the UE, authorize the UE, and / or deliver credentials to the UE, the DN-AAA can indicate any of the information described above to the UE as part of the registration rejection reason code.

[0126] Once a PDU session for registration is established, the UE and the AAA server (e.g., DN-AAA) can perform application layer operations to send UE credentials from DN-AAA to the UE.

[0127] Determine which network to try. When a UE detects that multiple networks are broadcasting indications that they support UE registration, the UE may randomly select a network to which it intends to perform the registration procedure. However, if the UE has previously attempted to register with a network, it may consider the outcome of the previous registration attempt. For example, the UE may lower the priority of a network from which it previously attempted to receive registration credentials. When a network indicates to the UE that it cannot or is unwilling to perform the registration procedure for the UE, the network may provide the UE with a backoff timer. The UE may run the timer for the duration of the backoff timer value. If a timer associated with a network is running, the UE may not consider that network during network selection. After the timer expires, the UE may reconsider the network, but may still prioritize networks that did not previously reject the UE's registration attempt. If the UE successfully completes the registration operation with a network, the UE may clear or reset all backoff timers associated with previous registration attempts. Alternatively, the UE may only clear or reset backoff timers associated with networks from which it has already received credentials. For example, if a UE fails to successfully attempt to register with network A but subsequently successfully completes registration with network B, where network B registers a UE with credentials for network A, the UE can clear the backoff timer associated with network A and connect to network A (e.g., for non-registration activities).

[0128] Figure 10 An exemplary procedure is shown in which a UE attempts to perform a registration procedure with a first network, the UE is rejected, and the UE attempts to perform a registration procedure with a second network.

[0129] In step 1, the UE is in registration mode and performs network selection. Multiple networks broadcast their indication that they support registration, or the UE determines that multiple networks are suitable for registration, so the UE randomly selects a first network to attempt the registration procedure with.

[0130] In step 2, the UE attempts to register with the first network and is rejected, as described above. The network may provide the UE with a reason for rejection and a backoff timer. The UE starts the backoff timer and associates it with the first network.

[0131] In step 3, the UE re-enters registration mode and performs network selection again. At this point, because the backoff timer associated with the first network is still running, the UE does not consider the first network for network selection. If the timer stops running, the UE may consider the first network to be of lower priority than other networks that have not recently rejected more of the UE's registration requests. The UE will then select a second network to attempt the registration procedure.

[0132] In step 4, the UE attempts to register with the second network as described above and succeeds.

[0133] Obtain SNPN services from PLMN As mentioned above, when a UE registers with a PLMN, it will receive a list of equivalent PLMNs from the network, but when a UE registers with an SNPN, it will not receive a list of equivalent PLMNs from the network.

[0134] It is possible that the UE can obtain services equivalent to those of another SNPN or PLMN. Therefore, it is recommended that the network be able to send a list of equivalent PLMNs to the UE even when the network is an SNPN. This list can consist of both PLMNs and SNPNs. However, the current format of the list of equivalent PLMN information elements, as defined in TS 24.008, should be enhanced so that the information elements can also include the SNPN identity. Alternatively, the UE may be provided with separate lists (e.g., a list of equivalent PLMNs and a list of equivalent SNPNs). Figure 6 An example of a list of equivalent SNPNs is shown. The SNPN list can consist of PLMN IDs, and each PLMN ID can be followed by an NID, as can the equivalent SNPN ID when combined with its associated PLMN ID. The network can indicate to the UE that all NIDs associated with a PLMN are considered equivalent by filling the NID information element with special values ​​(e.g., all 0s or all 1s) or by omitting the NID information element after the PLMN information element.

[0135] When a UE requests a service from the network, it indicates its desired service by providing the requested NSSAI and its mapping in the registration request. The requested NSSAI mapping indicates to the network how the network's slice name (S-NSSAI) maps to the UE's HPLMN's slice name (S-NSSAI). The requested NSSAI mapping is as follows: Figure 2 The format is shown. From the above description, it can be seen that the current 5G system design is insufficient for situations where a UE wants to request services from a PLMN, and those services need to be equivalent to slices (S-NSSAI) provided by the SNPN. The current 5G system design is insufficient because when a UE registers with a VPLMN, the network uses the UE's IMSI to determine the UE's HPLMN and how VPLMN slices are mapped to HPLMN slices. The UE cannot indicate to the network that the slices (S-NSSAI) in the requested NSSAI are not associated with the UE's HPLMN but with the SNPN.

[0136] The proposed feature is that, for each slice (S-NSSAI) in the requested NSSAI, the UE indicates whether the slice is associated with the UE's HPLMN. Figure 7 The S-NSSAI encoding shown in Table 5 of the appendix can be used to indicate this information to the network. For example, in Figure 7As shown in Table 5, the UE can indicate to the network that the S-NSSAI is associated with the SNPN, and can also indicate to the network identity (SNPN identity) associated with the S-NSSAI. In other words, the presence of the NPN ID in the IE indicates to the network that the slice is not associated with the UE's HPLMN.

[0137] It should be understood that Figure 7 Table 5 illustrates only one example of how this information can be conveyed to the UE. Alternatively, the network (e.g., AMF) can send a NAS message to the UE to program the UE with information about how the SNPN identity or NID is mapped to a smaller identification space. For example, the network can program the UE with information about how the SNPN identity or NID is mapped to a single octet value. If the UE is provided with information about how the NID is mapped to a single octet value, only enhanced S-NSSAI encoding is needed to carry the single octet encoding of the MCC, MNC, and NID.

[0138] When the network receives this information from the UE in the registration request and the requested NSSAI, the network can use this information to determine what mapping the requested NSSAI should send to the UE in the registration response message. It can also enhance the mapping of the requested NSSAI information elements, such as... Figure 7 As shown, this enables the network to instruct the UE how the S-NSSAI of the VPLMN is mapped to the S-NSSAI of the HPLMN and the S-NSSAI of the SNPN associated with the UE. Alternatively, the network may provide the UE with multiple copies of the allowed NSSAI mappings and the mappings of the configured NSSAI information elements, and indicate whether each copy is associated with the UE's HPLMN or SNPN.

[0139] In some cases, the PLMN may not be able to provide the exact services offered by the SNPN. For example, the SNPN may provide access to eMBB slices that allow UEs to surf the web and access services available in some private networks. Such slices may be identified by the eMBBSST type and a specific SD value. The PLMN may be able to provide the UE with access to slices available for surfing the web, but the same slices may not be available for access to the private network associated with the SNPN. Therefore, it is proposed to enhance the encoding of the NSSAI described above to allow the network to instruct the network to only partially map the S-NSSAI from the UE subscription to slices available in the PLMN. The network can use this partial indication to tell the UE that the network can provide UE access to slices with the same SST value but not the same SD value. Alternatively, the indication may tell the UE that only the SST value can be supported. Alternatively, where certain bits of the SST or SD value indicate to the UE support for specific features, the encoding of the NSSAI may be enhanced to include a bitmask indicating to the UE which features of the S-NSSAI are supported in the PLMN and which are not. For example, 1 can indicate that a feature is supported by bit indication, and 0 can indicate that a feature is not supported by bit indication. Figure 8 Exemplary encodings are shown in Table 4 of the appendix.

[0140] Example Environment The 3rd Generation Partnership Project (3GPP) developed technical standards for cellular telecommunications network technologies, including radio access, core transport networks and service capabilities, including research on codecs, security and quality of service.

[0141] Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE Advanced. 3GPP has begun working on the standardization of next-generation cellular technology, known as New Radio (NR) (also called "5G"). The development of the 3GPP NR standard is expected to include the definition of next-generation radio access technology (New RAT), which is anticipated to include new flexible radio access below 6 GHz and new ultra-mobile broadband radio access above 6 GHz. This flexible radio access is expected to include new non-backward-compatible radio access in the new spectrum below 6 GHz and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include centimeter-wave and millimeter-wave spectrum, which will provide opportunities for ultra-mobile broadband access for applications such as indoor spaces and hotspots. Specifically, ultra-mobile broadband is expected to share a common design framework with flexible radio access below 6 GHz, while incorporating centimeter-wave and millimeter-wave-specific design optimizations.

[0142] 3GPP has identified a variety of use cases that NR is expected to support, resulting in diverse user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile broadband (e.g., broadband access in dense areas, ultra-high-bandwidth indoor access, broadband access in crowds, 50+ Mbps everywhere, ultra-low-cost broadband access, vehicular mobile broadband), critical communications, large-scale machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications, which can include any of the following: vehicle-to-vehicle communications (V2V), vehicle-to-infrastructure communications (V2I), vehicle-to-network communications (V2N), vehicle-to-pedestrian communications (V2P), and vehicle-to-other-entities communications. Specific services and applications within these categories include, for example: surveillance and sensor networks, remote device control, two-way remote control, personal cloud computing, video streaming, cloud-based wireless offices, first responder connectivity, automotive electronic calling, disaster alerts, real-time gaming, multi-person video calling, autonomous driving, augmented reality, haptic internet, and virtual reality, among others. This paper considers all of these and other use cases.

[0143] Figure 9A An embodiment of an exemplary communication system 100 is illustrated, in which the methods and apparatus described and claimed herein are specifically embodied. As shown, the exemplary communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f and / or 102g (which may generally or commonly be referred to as WTRU 102), radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, other networks 112, and a V2X server (or ProSe functionality and server) 113. However, it should be understood that any number of WTRUs, base stations, networks and / or network elements are contemplated in the embodiments disclosed herein. Each of WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g can be any type of device or apparatus configured to operate and / or communicate in a wireless environment. While each of WTRU 102a, 102b, 102c, 102d, 102e, 102f, and 102g... Figures 9A to 9EWhile described as a handheld wireless communication device, it should be understood that, in the context of the diverse use cases envisioned for 5G wireless communication, each WTRU may include or be embodied as any type of device or apparatus configured to transmit and / or receive wireless signals, including, by way of example only, user equipment (UE), mobile station, fixed or mobile subscriber unit, pager, cellular phone, personal digital assistant (PDA), smartphone, laptop, tablet computer, netbook, notebook computer, personal computer, wireless sensor, consumer electronics, wearable devices (such as smartwatches or smart clothing), medical devices or electronic health devices, robots, industrial equipment, drones, vehicles (such as cars, trucks, trains or airplanes, etc.).

[0144] The communication system 100 may also include base stations 114a and 114b. Base station 114a may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, and / or other networks 112. Base station 114b may be any type of device configured to wired and / or wirelessly interface with at least one of RRHs (Remote Radio Headers) 118a and 118b, TRPs (Transmit and Receive Points) 119a and 119b, and / or RSUs (Roadside Units) 120a and 120b to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, the Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. RRH 118a and 118b can be any type of device configured to wirelessly interface with at least one of WTRU 102c to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112. TRP 119a and 119b can be any type of device configured to wirelessly interface with at least one of WTRU 102d to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, and / or other networks 112. RSU 120a and 120b can be any type of device configured to wirelessly interface with at least one of WTRU 102e or 102f to facilitate access to one or more communication networks, such as core networks 106 / 107 / 109, Internet 110, other networks 112, and / or V2X servers (or ProSe functions and servers) 113. By way of example, base stations 114a and 114b can be transceiver base stations (BTS), Node B, evolved Node B, home Node B, home evolved Node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are each depicted as a single element, it should be understood that base stations 114a and 114b can include any number of interconnected base stations and / or network elements.

[0145] Base station 114a may be part of RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114b may be part of RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a may be configured to transmit and / or receive radio signals within a specific geographical area, which may be referred to as a cell (not shown). Base station 114b may be configured to transmit and / or receive wired and / or radio signals within a specific geographical 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. Therefore, in one embodiment, base station 114a may include three transceivers, for example, one transceiver per sector of the cell. In one implementation, base station 114a may employ multiple-input multiple-output (MIMO) technology, thus enabling the use of multiple transceivers for each sector of the cell.

[0146] Base station 114a can communicate with one or more of WTRUs 102a, 102b, and 102c via air interfaces 115 / 116 / 117, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115 / 116 / 117.

[0147] Base station 114b can communicate with one or more of RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a and 120b via wired or air interfaces 115b / 116b / 117b. These wired or air interfaces can be any suitable wired communication link (e.g., cable, fiber optic, etc.) or wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interfaces 115b / 116b / 117b.

[0148] RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b can communicate with one or more of WTRU 102c, 102d, 102e, 102f via air interface 115c / 116c / 117c, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115c / 116c / 117c.

[0149] WTRUs 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g can communicate with each other via air interface 115d / 116d / 117d (not shown in the attached figures), which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, centimeter wave, millimeter wave, etc.). Any suitable radio access technology (RAT) can be used to establish air interface 115d / 116d / 117d.

[0150] More specifically, as noted above, the communication system 100 can be a multiple access system and can employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c or RRH 118a, 118b, TRP 119a, 119b and RSU 120a, 120b and WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can use Wideband CDMA (WCDMA) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. WCDMA may include communication protocols such as High-Speed ​​Packet Access (HSPA) and / or evolved HSPA (HSPA+). HSPA may include High-Speed ​​Downlink Packet Access (HSDPA) and / or High-Speed ​​Uplink Packet Access (HSUPA).

[0151] In one implementation, base station 114a and WTRUs 102a, 102b, 102c or RRH 118a, 118b in RAN 103b / 104b / 105b, TRP 119a, 119b and / or RSU 120a, 120b, and WTRUs 102c, 102d can implement radio technologies such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE Advanced (LTE-A) to establish air interfaces 115 / 116 / 117 or 115c / 116c / 117c respectively. In the future, air interfaces 115 / 116 / 117 can implement 3GPP NR technology. LTE and LTE-A technologies include LTE D2D and V2X technologies and interfaces (such as sidelink communication). 3GPP NR technology includes NR V2X technologies and interfaces (such as sidelink communication).

[0152] In one implementation, base station 114a in RAN 103 / 104 / 105 and WTRU 102a, 102b, 102c or RRH 118a, 118b, TRP 119a, 119b and / or RSU 120a, 120b, and WTRU 102c, 102d, 102e, 102f in RAN 103b / 104b / 105b can implement radio technologies such as IEEE 802.16 (e.g., Global Microwave Access Interoperability (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

[0153] Figure 9A Base station 114c can be, for example, a wireless router, a home node B, a home evolution node B, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in localized areas such as commercial locations, homes, vehicles, and campuses. In one embodiment, base station 114c and WTRU 102e can implement radio technologies (such as IEEE 802.11) to establish a wireless local area network (WLAN). In one embodiment, base station 114c and WTRU 102d can implement radio technologies (such as IEEE 802.15) to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114c and WTRU 102e can utilize cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish picocells or femtocells. Figure 9A As shown, base station 114b may have a direct connection to the Internet 110. Therefore, base station 114c may not need to access the Internet 110 via core networks 106 / 107 / 109.

[0154] RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b can communicate with core network 106 / 107 / 109, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU 102a, 102b, 102c, and 102d. For example, core network 106 / 107 / 109 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication.

[0155] Although not in Figure 9A As shown, but it should be understood, RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core network 106 / 107 / 109 can communicate directly or indirectly with other RANs employing the same RAT as or a different RAT than RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, which may be utilizing E-UTRA radio technology, core network 106 / 107 / 109 can also communicate with another RAN (not shown) employing GSM radio technology.

[0156] Core networks 106 / 107 / 109 may also act as gateways for WTRUs 102a, 102b, 102c, 102d, and 102e to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another core network connected to one or more RANs, which may use the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT.

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

[0158] Figure 9B This is a block diagram of an exemplary apparatus or device (such as WTRU 102) configured for wireless communication according to the embodiments shown herein. Figure 9B As shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and other peripheral devices 138. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may include any sub-combination of the foregoing elements. Additionally, the implementation envisions that base stations 114a and 114b and / or nodes that base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTS), node B, site controllers, access points (APs), home node B, evolved home node B (eNodeB), home evolved node B (HeNB), home evolved node B gateways, and proxy nodes, etc.) may include... Figure 9B The elements described herein, as well as some or all of the elements described herein.

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

[0160] Transmitting / receiving element 122 can be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via air interface 115 / 116 / 117. For example, in one embodiment, transmitting / receiving element 122 can be an antenna configured to transmit and / or receive RF signals. In one embodiment, transmitting / receiving element 122 can be a transmitter / detector configured to transmit and / or receive, for example, IR, UV, or visible light signals. In yet another embodiment, transmitting / receiving element 122 can be configured to transmit and receive both RF signals and optical signals. It should be understood that transmitting / receiving element 122 can be configured to transmit and / or receive any combination of wireless signals.

[0161] Furthermore, although the transmitting / receiving element 122 is in Figure 9B While depicted as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may employ MIMO technology. Thus, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interfaces 115 / 116 / 117.

[0162] Transceiver 120 can be configured to modulate signals transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 may have multi-mode capability. For example, transceiver 120 may therefore include multiple transceivers to enable WTRU 102 to communicate via various RATs such as UTRA and IEEE 802.11.

[0163] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) unit or an organic light-emitting diode (OLED) display unit), and can receive user input data from the aforementioned components. The processor 118 can also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. Furthermore, the processor 118 can access information from any type of suitable memory (such as non-removable memory 130 and / or removable memory 132) and store data in any type of suitable memory. 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. Removable memory 132 may include a Subscriber Identity Module (SIM) card, a Memory Stick, a Secure Digital (SD) memory card, etc. In one implementation, processor 118 can access memory information that is never physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in that memory.

[0164] The processor 118 may 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 powering the WTRU 102. For example, the power supply 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0165] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or instead of, information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via air interface 115 / 116 / 117 and / or determine its location based on the timing of signals received from two or more nearby base stations. It should be understood that, while remaining consistent with the implementation, the WTRU 102 may acquire location information using any suitable location determination method.

[0166] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules that provide additional features, functions, and / or wired or wireless connectivity. For example, peripheral device 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), Universal Serial Bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, and Bluetooth. ® Modules, FM radio units, digital music players, media players, video game player modules, internet browsers, and so on.

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

[0168] Figure 9C This is a system diagram of RAN 103 and core network 106 according to one implementation scheme. As described above, RAN 103 can communicate with WTRUs 102a, 102b, and 102c via air interface 115 using UTRA radio technology. RAN 103 can also communicate with core network 106. Figure 9C As shown, RAN 103 may include Node Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 115. Node Bs 140a, 140b, and 140c may each be associated with a specific cell (not shown) within RAN 103. RAN 103 may also include RNCs 142a and 142b. It should be understood that RAN 103 may include any number of Node Bs and RNCs while remaining consistent with the implementation scheme.

[0169] like Figure 9CAs shown, nodes B 140a and 140b can communicate with RNC 142a. Additionally, node B 140c can communicate with RNC 142b. Nodes B 140a, 140b, and 140c can communicate with their respective RNCs 142a and 142b via the Iub interface. RNCs 142a and 142b can communicate with each other via the Iur interface. Each of RNCs 142a and 142b can be configured to control its connected corresponding node B 140a, 140b, or 140c. Furthermore, each of RNCs 142a and 142b can be configured to perform or support other functionalities such as outer-loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0170] Figure 9C The core network 106 shown may include a media gateway (MGW) 144, a mobile handover center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. While each of the foregoing elements is depicted as part of the core network 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0171] RNC 142a in RAN 103 can be connected to MSC 146 in core network 106 via IuCS interface. MSC 146 can be connected to MGW 144. MSC 146 and MGW 144 provide WTRU 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and legacy landline communication equipment.

[0172] RNC 142a in RAN 103 can also be connected to SGSN 148 in core network 106 via IuPS interface. SGSN 148 can be connected to GGSN 150. SGSN 148 and GGSN 150 can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices.

[0173] As described above, core network 106 can also be connected to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0174] Figure 9DThis is a system diagram of RAN 104 and core network 107 according to one implementation scheme. As described above, RAN 104 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using E-UTRA radio technology. RAN 104 can also communicate with core network 107.

[0175] RAN 104 may include evolved Nodes B 160a, 160b, and 160c; however, it should be understood that RAN 104 may include any number of evolved Nodes B while remaining consistent with the implementation scheme. Evolved Nodes B 160a, 160b, and 160c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one implementation, evolved Nodes B 160a, 160b, and 160c may implement MIMO technology. Therefore, evolved Node B 160a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a.

[0176] Each of the evolved Nodes B 160a, 160b, and 160c can be associated with a specific cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, user scheduling in the uplink and / or downlink, etc. Figure 9D As shown, evolution nodes 160a, 160b, and 160c can communicate with each other via the X2 interface.

[0177] Figure 9D The core network 107 shown may include a mobility management gateway (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway 166. While each of the foregoing elements is depicted as part of the core network 107, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0178] The MME 162 can connect to each of the evolved nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can also provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies such as GSM or WCDMA.

[0179] Serving Gateway 164 can connect to each of the evolved Nodes B 160a, 160b, and 160c in RAN 104 via the S1 interface. Serving Gateway 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. Serving Gateway 164 can also perform other functions, such as anchoring the user plane during handover between evolved Nodes B, triggering paging when downlink data is available to WTRUs 102a, 102b, and 102c, managing and storing the context of WTRUs 102a, 102b, and 102c, etc.

[0180] Service gateway 164 can also be connected to PDN gateway 166, which provides WTRU 102a, 102b, 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0181] Core network 107 can facilitate communication with other networks. For example, core network 107 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. For example, core network 107 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that serves as an interface between core network 107 and PSTN 108, or can communicate with such an IP gateway. Furthermore, core network 107 can provide WTRUs 102a, 102b, and 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0182] Figure 9E This is a system diagram of RAN 105 and core network 109 according to one implementation scheme. RAN 105 may be an Access Service Network (ASN) that communicates with WTRUs 102a, 102b, and 102c via air interface 117 using IEEE 802.16 radio technology. Communication links between the different functional entities WTRUs 102a, 102b, 102c, RAN 105, and core network 109 can be defined as reference points.

[0183] like Figure 9EAs shown, RAN 105 may include base stations 180a, 180b, 180c and ASN gateway 182; however, it should be understood that RAN 105 may include any number of base stations and ASN gateways while remaining consistent with the implementation scheme. Base stations 180a, 180b, and 180c may each be associated with a specific cell in RAN 105 and may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 117. In one implementation, base stations 180a, 180b, and 180c may implement MIMO technology. Therefore, base station 180a may, for example, use multiple antennas to transmit radio signals to and receive radio signals from WTRU 102a. Base stations 180a, 180b, and 180c may also provide mobility management functions such as handover triggering, tunnel establishment, radio resource management, traffic classification, Quality of Service (QoS) policy enforcement, etc. ASN Gateway 182 can be used as a service aggregation point and can be responsible for paging, subscriber profile caching, routing to the core network 109, etc.

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

[0185] The communication link between each of base stations 180a, 180b, and 180c can be defined as an R8 reference point, which includes protocols for facilitating WTRU handover and data transmission between the base stations. The communication link between base stations 180a, 180b, and 180c and ASN gateway 182 can be defined as an R6 reference point. The R6 reference point may include protocols for facilitating mobility management based on mobility events associated with each of WTRUs 102a, 102b, and 102c.

[0186] like Figure 9EAs shown, RAN 105 can be connected to core network 109. The communication link between RAN 105 and core network 109 can be defined as an R3 reference point, which includes, for example, protocols for facilitating data transfer and mobility management capabilities. Core network 109 may include a Mobile IP Home Agent (MIP-HA) 184, an Authentication, Authorization, and Accounting (AAA) server 186, and a gateway 188. While each of the foregoing elements is depicted as part of core network 109, it should be understood that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0187] MIP-HA manages IP addresses and enables WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. MIP-HA 184 provides WTRUs 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRUs 102a, 102b, and 102c and IP-enabled devices. AAA server 186 handles user authentication and user support services. Gateway 188 facilitates interoperability with other networks. For example, gateway 188 can provide WTRUs 102a, 102b, and 102c with access to circuit-switched networks (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and traditional landline communication equipment. In addition, gateway 188 can provide WTRU 102a, 102b, 102c with access to network 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0188] although Figure 9E Although not shown, it should be understood that RAN 105 can connect to other ASNs, and core network 109 can connect to other core networks. The communication link between RAN 105 and other ASNs can be defined as an R4 reference point, which may include protocols for coordinating the mobility of WTRUs 102a, 102b, and 102c between RAN 105 and other ASNs. The communication link between core network 109 and other core networks can be defined as an R5 reference point, which may include protocols for facilitating interoperability between the home core network and the visited core network.

[0189] The content described herein and in Figure 9A , Figure 9C , Figure 9D and Figure 9EThe core network entities shown are identified by the names given to these entities in certain existing 3GPP specifications; however, it should be understood that these entities and functions may be identified by other names in the future, and some entities or functions may be combined in future specifications published by 3GPP (including future 3GPP NR specifications). Therefore, in Figures 9A-9E The specific network entities and functions described and illustrated herein are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be embodied or implemented in any similar communication system, whether currently defined or to be defined in the future.

[0190] Figure 9F This is a block diagram of the example computing system 90, which can specifically illustrate... Figure 9A , Figure 9C , Figure 9D and Figure 9E The diagram illustrates one or more devices in a communication network, such as certain nodes or functional entities in RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112. The computing system 90 may include a computer or server and may be controlled primarily by computer-readable instructions, which may be in the form of software, regardless of where or by what means such software is stored or accessed. These computer-readable instructions may be executed within a processor 91 to enable the computing system 90 to function. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to function within the communication network. Coprocessor 81 is an optional processor, distinct from main processor 91, that can perform additional functions or assist processor 91. Processor 91 and / or coprocessor 81 can receive, generate, and process data relating to the methods and apparatus disclosed herein.

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

[0192] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. This type of memory includes circuitry that allows information to be stored and retrieved. ROM 93 typically contains stored data that cannot be easily modified. Data stored in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 provides address translation functionality, translating virtual addresses into physical addresses as instructions are executed. The memory controller 92 also provides memory protection functionality that isolates processes within the system and separates system processes from user processes. Therefore, a program running in first mode can only access memory mapped through its own process virtual address space; it cannot access memory in another process's virtual address space unless inter-process memory sharing is configured.

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

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

[0195] Additionally, the computing system 90 may include a communication circuit system, such as a network adapter 97, which can be used to connect the computing system 90 to an external communication network, such as... Figures 9A to 9E The RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, or other network 112 are used to enable the computing system 90 to communicate with other nodes or functional entities in these networks. A communication circuitry system, either alone or in conjunction with the processor 91, can be used to perform the transmit and receive steps of certain means, nodes, or functional entities described herein.

[0196] Figure 9GAn embodiment of an exemplary communication system 111 is illustrated, which may embody the methods and apparatus described herein and protected by the claims. As shown, the exemplary communication system 111 may include Wireless Transmit / Receive Units (WTRUs) A, B, C, D, E, F, a base station, a V2X server, and RSUs A and B; however, it should be understood that the embodiments disclosed herein contemplate any number of WTRUs, base stations, networks, and / or network elements. One or more or all WTRUs A, B, C, D, E may be outside the range of the network (e.g., outside the cell coverage boundary as shown by the dashed line in the figure). WTRUs A, B, C form a V2X group, with WTRU A as the group leader and WTRUs B and C as group members. WTRUs A, B, C, D, E, F may communicate via a Uu interface or a sidelink (PC5) interface.

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

[0198]

[0199]

[0200]

[0201]

[0202]

[0203]

[0204]

[0205]

[0206]

[0207]

[0208]

[0209]

Claims

1. A method implemented in a wireless transmit / receive unit (WTRU), the method comprising: Receive a first broadcast message from the network, the first broadcast message including a registration support indicator; Send a first request to the network, the first request indicating that system information will be broadcast on demand, the system information being associated with a group identifier; Receive a second broadcast message from the network, the second broadcast message including the group identifier; The second broadcast information is used to determine whether to perform a registration operation with the network; Send to the network: (i) a Non-Access Stratum (NAS) registration request portion including a first registration indication and (ii) a Radio Resource Control (RRC) message including a second registration indication; Upon receiving the registration response, SNPN credentials for a Standalone Non-Public Network (SNPN) are received from the network; and Register with the SNPN based on the SNPN credentials.

2. The method of claim 1, further comprising communicating with an Access and Mobility Management Function (AMF), the AMF being selected by the network based on the second registration instruction.

3. The method of claim 1, wherein at least one of the NAS registration request portion and the RRC message includes information to assist the network in determining network functions that can be used to authenticate the WTRU based on the WTRU's registration credentials.

4. The method of claim 1, wherein at least one of the NAS registration request portion and the RRC message includes an indication that the WTRU expects to authenticate the network.

5. The method of claim 1, wherein either the first broadcast information or the second broadcast information includes an indication of whether the network supports a control plane registration procedure, a user plane registration procedure, or both the control plane registration procedure and the user plane registration procedure.

6. The method of claim 1, wherein either the first broadcast information or the second broadcast information includes an indication of the type of network slice supported by the network.

7. The method of claim 1, wherein the SNPN credential includes a Subscription Persistent Identifier (SUPI) and an SNPN identity.

8. The method of claim 7, wherein the SNPN credentials further include information required by the WTRU to establish a tunnel between the WTRU and the non-3GPP interoperability function (N3IWF) of the SNPN.

9. The method according to claim 1 further includes switching to manual network selection mode or automatic network selection mode.

10. The method of claim 1, wherein the SNPN credential is received during the registration process.

11. A network apparatus at a Radio Access Network (RAN) node, comprising circuitry including a transmitter, a receiver, a processor, and a memory, the network apparatus being configured to: Transmit a first broadcast message, the first broadcast message including a registration support indicator; Receive a first request, which instructs system information to be broadcast on demand, the system information being associated with a group identifier; Transmit a second broadcast message, the second broadcast message including the group identifier; Receive from the Wireless Transmit / Receive Unit (WTRU): (i) a Non-Access Stratum (NAS) registration request including a first registration indication and (ii) a Radio Resource Control (RRC) message including a second registration indication; Based on the second registration instruction, select the Access and Mobility Management Function (AMF) for communicating with the WTRU; Send the NAS registration request to the AMF; Receive a registration response from the AMF; as well as Send the registration response to the WTRU.

12. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Receive one or more User Equipment Routing Policy (URSP) rules from the network for routing application layer communications generated by the WTRU; Generate one or more application-layer communications for transmission to the network; The route for each participant in the generated application layer communication is determined based on one or more URSP rules. as well as Each component of the generated application-layer communication is transmitted to the destination based on one or more URSP rules. The one or more URSP rules mentioned therein include rules for directing all application layer communications to the authentication, authorization, and accounting (AAA) server.

13. The method of claim 12, wherein the one or more URSP rules include rules for directing application layer communication associated with an authentication request to the AAA server and directing all other application layer communication to an empty destination in which the application layer communication will not be processed.

14. The method of claim 12, further comprising receiving the one or more URSP rules in a registration response during the registration process.

15. The method of claim 12, further comprising transmitting a domain identifier in the registration request, wherein the WTRU transmits the application layer communication associated with the domain identifier to a combination comprising: (ii) a single network slice selection aid information (S-NSSAI), (iii) a data network name (DNN), (iv) an Internet Protocol (IP) address, and (iv) a port number, wherein the combination is indicated in the one or more URSP rules.

16. The method of claim 12, wherein the one or more URSP rules include rules for directing application layer communications for the registration process.

17. The method of claim 12, further comprising establishing a Protocol Data Unit (PDU) session prior to transmitting the application layer communication.

18. The method of claim 17, further comprising transmitting a PDU session establishment request to the network, the PDU session establishment request triggering auxiliary authentication performed by a Data Network-AAA (DN-AAA) server.

19. The method of claim 12, further comprising, in response to transmitting application-layer communication to the AAA server, initiating an application-layer procedure to download Independent Non-Public Network (SNPN) credentials from the AAA server.

20. The method of claim 12, wherein the one or more URSP rules are received from the Access and Mobility Management Function (AMF) in the network.

Images