3GPP-specific LAN

Abstract

This document describes methods and apparatuses for securely connecting to a private local area network (LAN). According to one embodiment, a device may receive a first broadcast message from a private LAN that has been provisioned with first identification information associated with the device, the first broadcast message including an invitation to connect to the private LAN and the first identification information. The device may send a request for system information and second identification information associated with the device based on the first broadcast message including the first identification information. The device may receive the requested system information from the private LAN. The device may send a registration request and third identification information associated with the device based on the requested system information. The device may receive an acceptance of the registration request from the private LAN.

Description

[0001] Cross - reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 737,276, filed on September 27, 2018, which is hereby incorporated by reference in its entirety. Background Art

[0003] When packaging devices with wireless communication capabilities, device manufacturers do not know which network information is required to provision the devices. Therefore, these devices need to be configured after the initial purchase. Additionally, the broadcast of network identifiers by (R)AN nodes with a private network can be considered a security risk, and if this information is broadcast periodically by the (R)AN nodes, it will increase unnecessary overhead. (R)AN nodes can provide connections to private LANs and public cellular networks, but it is currently not possible for a UE to have two non - access stratum (NAS) connections through the same (R)AN node.

[0004] Consequently, there is a need for enhanced methods and apparatuses for securely connecting to 3GPP private networks. Summary of the Invention

[0005] This Summary of the Invention is provided to introduce some concepts in a simplified form that will be further described in the Detailed Description below. This Summary of the Invention is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Additionally, the claimed subject matter is not limited to limitations that solve any or all of the disadvantages noted in any part of this disclosure.

[0006] Methods and apparatuses for securely connecting to a private local area network (LAN) are described herein. According to one embodiment, a device can receive a first broadcast message from a private LAN that has been provisioned with first identification information associated with the device. The first broadcast message includes an invitation to connect to the private LAN and the first identification information. The device can send a first message based on the first broadcast message that includes the first identification information. The first message includes a request for system information and second identification information associated with the device. The device can receive a second broadcast message from the private LAN that includes the requested system information. The device can send a second message based on the requested system information. The second message includes a registration request and third identification information associated with the device. The device can receive a third message from the private LAN indicating acceptance of the registration request. Brief Description of the Drawings

[0007] To facilitate a more robust understanding of this application, reference is now made to the drawings, in which like elements are referenced with like reference numerals. These drawings should not be construed as limiting this application, but are merely illustrative.

[0008] Figure 1 is a diagram of an example process for obtaining system information;

[0009] Figure 2 is a diagram of a LAN system with a device credentials panel according to an example;

[0010] Figure 3 is a diagram of an example process for loading a device onto a type b network according to an example;

[0011] Figure 4 is a diagram of an example process for network discovery according to an example;

[0012] Figure 5A illustrates an example communication system;

[0013] Figure 5B is a system diagram of an example RAN and core network;

[0014] Figure 5C is a system diagram of an example RAN and core network;

[0015] Figure 5D is a system diagram of an example RAN and core network;

[0016] Figure 5E illustrates another example communication system;

[0017] Figure 5F is a block diagram of an example apparatus or device, such as a wireless transmit / receive unit (WTRU); and

[0018] Figure 5G is a block diagram of an exemplary computing system. Detailed Description

[0019] Third Generation Partnership Project (3GPP) networks are using a network called 3GPP LAN (also referred to herein as a private LAN) to provide services similar to a local area network (LAN) to subscribers. Methods and apparatuses are described herein that allow a device without pre-provisioned network credentials to securely connect to a 3GPP LAN. The network may use the provisioned information to broadcast an invitation for selected devices to connect to the network. The device may receive the invitation and request that the network broadcast additional information so that the device can determine if it is the intended recipient of the invitation. The request includes information that the network can use to identify the device. Once network credentials are provisioned for the device, the credentials can be used to discover the LAN, identify the LAN as a connection candidate, and provide the credentials to an (R)AN node for requesting the network to broadcast the network identifier.

[0020] For example, a radio access network (RAN) node may broadcast only partial identification information. When a device detects an (R)AN node broadcasting partial identification information corresponding to a network it wants to associate with, it may decide to send a request to the (R)AN node to broadcast more information about the network. The request may include an invitation tag that helps to prove to the (R)AN node that the device is permitted to associate with the network.

[0021] As used herein, the term "type a network" refers to a 3GPP local area network (LAN) for non-public use, and for which service continuity and roaming with a public land mobile network (PLMN) are possible.

[0022] As used herein, the term "type b network" refers to an isolated 3GPP network that does not interact with a PLMN.

[0023] A PLMN identifier is used to identify a 3GPP mobile network. A PLMN ID may also be used to identify a private network, such as a LAN.

[0024] The embodiments described herein refer to various actions that a device such as, for example, a user equipment (UE) may perform. The terms "device" and "UE" may be used interchangeably herein. A UE may have one or more packet data network (PDN) connections. In a 5G system, a PDN connection may also be referred to as a protocol data unit (PDU) session.

[0025] As used herein, a LAN or a private LAN refers to a 3GPP LAN.

[0026] A type a network or a type b network may also be referred to as a non-public network.

[0027] A type b network may also be referred to as a stand-alone non-public network.

[0028] Table 1 below provides a list of acronyms related to the techniques that may be used in the examples described herein:

[0029] AF Application Function AMF Access and Mobility Management Function AP Access Point API Application Programming Interface EAP Extensible Authentication Protocol GUAMI Globally Unique AMF Identifier MCC Mobile Country Code MIB Master Information Block MNC Mobile Network Code NAS Non-Access Stratum NEF Network Exposure Function NSSAI Network Slice Selection Assistance Information OTT Over The Top PCF Policy and Charging Function PDU Protocol Data Unit PEI Permanent Equipment Identifier PLMN Public Land Mobile Network (R)AN Radio Access Network S-RAN Source Radio Access Network S-NSSAI Single NSSAI SIB System Information Block SMF Session Management Function SD Slice Differentiator SSID Service Set Identifier SST Slice / Service Type SUCI Subscription Concealed Identifier T-RAN Target Radio Access Network UDR User Data Repository UPF User Plane Function 5G-GUTI 5G Globally Unique Temporary Identifier 5G-S-TMSI 5G SAE Temporary Mobile Subscriber Identity 5G-TMSI 5G Temporary Mobile Subscriber Identity

[0030] Table 1 Acronyms

[0031] The embodiments described herein can be applied to various use cases. One example use case includes device management and provisioning. For example, a factory worker may be installing new devices (e.g., sensors, actuators, and controllers) in a factory. In this example, the factory may own and deploy a private network using 3GPP technology and may act as a network operator. The devices in this example need to be able to connect to the network and communicate securely. However, the devices may not have pre-provisioned credentials. The embodiments described herein support a security mechanism for an operator to provision 3GPP certificates to industrial IoT devices for 5G LAN type services.

[0032] Another example use case is related to a device discovery mechanism. For example, a user may be browsing the Internet with a tablet and trying to print an article. Initially, no printer is plugged in, so the tablet cannot discover the printer. The user plugs in the printer power, and then the tablet subsequently discovers the printer and can then send the article to the printer. The embodiments described herein support a LAN discovery mechanism.

[0033] Another example use case includes when a technician's UE has an app designed to communicate with an app hosted on a UE embedded in a piece of equipment. The equipment is not always reachable, so the app on the technician's UE needs to be able to determine when the UE in the equipment is reachable. The embodiments described herein support enabling a UE to know whether a specific UE in the same 5G LAN set is available for communication based on operator policies and user permissions, regardless of whether they are roaming.

[0034] In another example, a local operator may want to operate a device near them rather than browse a list of many (possibly thousands) of devices installed in a factory. The embodiments described herein support the automatic discovery of 5G devices belonging to a certain group (such as those located in a factory close to the user (e.g., within a certain radius)) and provide the user with a list of all detected 5G devices. For example, without prior knowledge of the factory, a service technician may want to connect to a certain device near them. However, due to obstacles in the factory, direct access to the device may not be possible. The device can be easily discovered using the automatic discovery described herein.

[0035] Another example use case includes a plug-and-play feature for field devices, where a 5G system allows devices to easily connect to the 5G system. For example, constrained devices (such as battery-powered field devices) may not be deliverable through pre-configured over-the-top (OTT) application layer security. The embodiments described herein provide network layer security and perform authentication based on a set of authentication credentials.

[0036] Another example use case includes a type a network - PLMN interaction, where the UE communicates simultaneously via the PLMN and within the type a network, including service continuity when the UE moves from the PLMN to the type a network. For example, the UE can be handed over from the PLMN to the factory type a network when the latter is within its range. The embodiments described herein support various handover scenarios.

[0037] The embodiments described herein can be applied to various enhancements to the 5G system to support 5G LAN services. Examples of such enhancements include enhancements to service exposure via application programming interfaces (APIs) for third-party use of functions (e.g., for information on the geographical location of type a / type b network coverage areas); support for type b networks; support for the UE to be registered in both the type b network and the PLMN when the UE supports the credentials required for the type b network and the credentials required for the PLMN and is able to maintain the two registrations independently; support for type a networks and the interworking, roaming between the public network and type a networks; and support for roaming, mobility, and service continuity between the PLMN and type a network for direct interaction between the PLMN and type a network (e.g., for mobility from the type a network to the PLMN).

[0038] The type a network can be uniquely identified by a combination of a PLMN identifier and a type a network identifier (TA-NID). It can be assumed that the UE is configured with one or more tuples consisting of the PLMN identifier and the TA-NID corresponding to the type a network to which the UE is authorized to register. The next-generation radio access network (NG-RAN) node that supports access to the type a network can broadcast one or more tuples consisting of the PLMN identifier and the TA-NID to indicate to the UE which type a networks are supported.

[0039] The type b network can be identified by a type b network identifier (TB-NID). In a given area, the TB-NID can be centrally managed and assigned (and thus considered unique in that area), or can be assigned by individual type b network operators (i.e., unmanaged and thus not unique). Both assignment strategies can exist in the same area. It is assumed that the UE is configured with the TB-NID corresponding to the type b network to which the UE is authorized to register.

[0040] The NG-RAN node that supports access to the type b network can broadcast one or more TB-NIDs to indicate to the UE the type b networks they support. The UE can automatically select and attempt to register with the type a and type b networks for which the UE is authorized and configured.

[0041] The 5G globally unique temporary identifier (5G-GUTI) can be constructed as:

[0042] <5G-GUTI>:= <guami><5G-TMSI>

[0043] Among them, the GUAMI identifies the assigned Access and Mobility Function (AMF), while the 5G Temporary Mobile Subscriber Identity (5G-TMSI) uniquely identifies the UE within the AMF.

[0044] The globally unique AMF ID (GUAMI) can be constructed as:

[0045] <guami> :＝ <mcc> <mnc><AMF Region ID><AMF Set ID><AMF Pointer>

[0046] Among them, the AMF Region ID identifies the region, the AMF Set ID uniquely identifies the AMF set within the AMF region, and the AMF Pointer uniquely identifies the AMF within the AMF set. The AMF Region ID solves the situation where the number of AMFs in the network exceeds the number of AMFs that the AMF Set ID and AMF Pointer can support by enabling the operator to reuse the same AMF Set ID and AMF Pointer in different regions.

[0047] 5G-S-TMSI can be an abbreviated form of GUTI to enable a more efficient radio signaling process (e.g., during paging and service requests), and can be defined as:

[0048] <5G-S-TMSI> := <AMF Provisioning ID><AMF Pointer><5G-TMSI>

[0049] When the UE sends a registration request to the (R)AN node, the message can include an AN parameter field that can be used by the (R)AN node to help guide its selection of the AMF. The AN parameter field can include a Subscription Concealed Identifier (SUCI) or a 5G Globally Unique Temporary Identifier (5G-GUTI), a PLMN ID, and Network Slice Selection Assistance Information (NSSAI).

[0050] The handover process between 3GPP access networks is used to switch the UE from the source radio access network (S-RAN) node to the target RAN (T-RAN) node. The first type can be based on the availability of the Xn interface between the S-RAN node and the T-RAN node. When the Xn interface is unavailable, an N2-based handover can be performed, where the S-RAN node transmits the handover request to the target network via the source AMF. The handover between 3GPP access networks can be initiated by the RAN.

[0051] Figure 1 It is a diagram of an example procedure 50 for obtaining system information. In this example, the UE 51 can obtain system information from the NR(R)AN node 52. The Master Information Block (MIB) is always transmitted by the (R)AN node 52 and contains information for the UE 51 to obtain SIB1 (step 53). The System Information Block Type 1 (SIB1) is transmitted periodically and contains information such as scheduling information and availability information of other SIBs (step 54). The UE 51 can use a system information request (SI request) to request the (R)AN node 52 to broadcast a specific SIB (step 55), and the (R)AN node 52 then transmits a System Information message (step 56).

[0052] In the factory automation scenario or plug-and-play scenario as described above, it is necessary for the provisioned devices (e.g., sensors, actuators, and controllers) to know which TA-NID (or TB-NID) they are associated with. In the scenario of purchasing devices in a "ready-to-use" manner, this can be a problem. When packaging the devices, the device manufacturer may not know which TA-NID (or TB-NID) the device needs to be provisioned with. Therefore, devices often without a user interface need to be configured with a TA-NID after the initial purchase. In addition, it may be necessary to provision the devices with subscriptions or credentials that can be used to access the network.

[0053] Once the UE decides to connect to a TA-NID or TB-NID, the UE needs to discover a RAN node that can provide connectivity to the identified network. One possible solution is to let the RAN node broadcast the TA-NID or TB-NID to which it can provide access. However, this type of solution may be undesirable; letting the RAN node broadcast the TA-NID or TB-NID can be regarded as a security risk. Additionally, periodically broadcasting the TA-NID or TB-NID by the RAN node will increase unnecessary overhead.

[0054] As described above, the UE needs to be able to connect to the PLMN and the type a network simultaneously. When using the same RAN node to connect to both the PLMN and the type a network, it requires the UE to have two NAS connections, one NAS connection to the AMF in each network.

[0055] As described above, after connecting to the network, the device must be able to discover and establish communication with other devices in the LAN, and the network should be able to restrict which devices a given device can discover. For the purposes of security and signaling efficiency, it is important for the network to be able to efficiently restrict which devices a given device can discover. Additionally, it may not be desirable to allow a device to see certain other devices within the network, and it is not necessary to allow a device to discover devices with which it is not permitted to establish a communication session.

[0056] As described above, service continuity may be required between a PLMN and a type a network. Thus, the network may need to redirect the UE between the PLMN and the type a network (or the UE may determine that it needs to move between the type a network and the PLMN) and provide service continuity between the type a network and the PLMN, including enabling the UE to identify which PDU sessions need to support service continuity when moving between the type a network and the wide area network.

[0057] Figures 2 to 4 (Described below) illustrates various embodiments associated with a 3GPP dedicated LAN that enhance 5G networks to address the use cases described above. In these figures, various steps or operations performed by one or more nodes, devices, apparatuses, servers, functions, or networks are shown. For example, the apparatuses may operate individually or in combination with each other to implement the methods described herein. As used herein, the terms "apparatus", "network apparatus", "node", "server", "device", "entity", "network function", and "network node" may be used interchangeably. It should be understood that the nodes, devices, servers, functions, or networks shown in these figures may represent logical entities in a communication network and may be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a node of such a network and executable on the processor of a node of such a network, such a network may include one of the architectures shown in Figure 5A or one of the architectures shown in 5B. That is, it may be implemented in the form of software (e.g., computer-executable instructions) stored in the memory of a network node such as a Figure 5C node or computer system shown in or 5D that can store computer-executable instructions Figures 2 to 4 The method shown in, the computer-executable instructions of which, when executed by the processor of the node, perform the steps shown in the figures and described herein. It should also be understood that any transmission and reception steps shown in these figures may be performed by the communication circuitry of the node (e.g., circuitry 34 or 97 for Figure 5C and 5D respectively) under the control of the processor of the node and the computer-executable instructions (e.g., software) it executes. It should also be understood that the nodes, devices, and functions described herein may be implemented as virtualized network functions.

[0058] This document describes methods and apparatuses for securely connecting a device without pre-provisioned network credentials to a LAN. According to one embodiment, a device that has not been provisioned with LAN credentials at the time of manufacture can detect or discover the LAN, review an invitation to connect to the LAN, request to connect to the network, determine whether the device should connect to the network, and then receive network credentials after learning that it is the correct network. A LAN operator can use APIs exposed by the Network Exposure Function (NEF) to supply the network with information about devices permitted to connect to the network. The network can use the supplied information to broadcast an invitation for the device to connect to the network. The device can receive the invitation and request the network to broadcast additional information so that the device can determine whether it is the intended recipient of the invitation. Once the device confirms that it is the intended recipient of the invitation, it can attempt to register with the network, and the network can use the device information supplied by the network operator to authenticate and authorize the device. Network credentials can then be provisioned to the device.

[0059] According to another embodiment, the system can allow a device that has been provisioned with LAN credentials to discover the LAN without the (one or more) RAN nodes of the LAN continuously broadcasting network identification information. This allows the UE to use the broadcast information to detect that nearby RAN nodes may provide access to the LAN to which it wants to connect. The (R)AN node can broadcast partial identification information (e.g., a combination of MCC, MNC, service identifier, operator identifier, network identifier, digits, etc.). When the UE detects a RAN node broadcasting partial identification information corresponding to the network it wants to associate with, it can decide to send a request to the (R)AN node to broadcast additional information about the network. The request can include an invitation tag that helps prove to the (R)AN node that the UE is permitted to associate with the network. Once the UE determines that it may want to connect to the LAN, the UE can present an identifier to the RAN node that indicates that it was previously invited to connect to the LAN. After receiving the identifier, the RAN node can broadcast the remainder of the identification information, such as its network identifier.

[0060] According to another embodiment, a network operator may deploy a traditional 5G wide-area cellular network and a local area network. One or more RAN nodes of the network operator (or a subset of one or more RAN nodes) may provide connectivity to the traditional 5G wide-area network and one or more LANs. A device may be connected to both the 5G wide-area cellular network and the local area network via the same RAN node. The device may be connected to two AMFs via the same RAN node: one AMF associated with the LAN and another second AMF associated with the traditional 5G wide-area cellular network. Alternatively or additionally, the device may send a request to establish two separate connections to the same AMF via the same RAN node. The UE may indicate to the network that two separate connections are necessary so that the UE can be connected to the wide-area cellular network and the LAN. When establishing the second connection, the UE may provide the 5G-GUTI or SUCI associated with the first connection to the RAN node.

[0061] According to another embodiment, a policy may be provisioned to a device so that it is aware of the types of devices it is permitted to discover and communicate with, which may enable the discovery process to be more efficient. The policy may also assist in preventing the device from attempting to discover devices it is not permitted to discover or communicate with. The device may filter discovery requests received on its user interface, thereby restricting its requests to the network to those that the policy indicates are acceptable.

[0062] According to another embodiment, an existing handover process may be enhanced to enable the movement of a PDN connection from a wide-area cellular network to a LAN (and vice versa). For example, a device may have multiple PDN connections to a wide-area cellular network and may need to move one or more PDN connections to a LAN (and vice versa), which may be triggered by the device moving into the range of the LAN. In another example, an N2-based handover process may enable the handover of selected PDU sessions. This process may allow the device to indicate to the RAN whether certain PDU sessions should be served only by certain network services. The RAN may then use this information to determine which PDU sessions should be handed over and notify the AMF of which PDU sessions should be handed over.

[0063] Figure 2 FIG. 200 is a diagram of a LAN system having a device credential panel according to an example, which may be used in conjunction with any of the embodiments described herein. The LAN system 200 may be used when devices without pre-provisioned credentials, such as factory automation, home automation, and home security devices, are to be loaded onto the LAN. For example, the network may include a type b network. In Figure 2 In an example LAN system 200, a device that may not have been supplied with a LAN credential at the time of manufacture can detect the LAN, review an invitation to connect to the LAN, request to connect to the LAN, determine whether it is the LAN to which it should connect, and receive a network credential after learning that it is the correct network.

[0064] As Figure 2 shown in the example of, UE 207 can access the access and mobility management function (AMF) of the LAN (L-AMF 202) via the radio access network ((R)AN) 208 through the N1 interface 211. The (R)AN 208 can access the L-AMF 202 via the N2 interface 212. The (R)AN 208 can access the user plane function (UPF) of the LAN (L-UPF 209) via the N3 interface 213. The L-UPF 209 can access the session management function (SMF) of the LAN (L-SMF) 203 via the N4 interface 214. The L-UPF 209 can access the data network (DN) 210 via the N6 interface 215. The policy control function (PCF) of the LAN (L-PCF) 201 can access the L-AMF 202 via the N15 interface 219. The L-AMF 202 can access the L-SMF 203 via the N11 interface 218. The L-SMF 203 can access the unified data management (UDM) of the LAN (L-UDM 206a) via the N10 interface 217.

[0065] The NEF in the LAN (L-NEF 204) can expose an API via the Nnef interface 221, which allows the application function (AF) 205 to supply device credentials via the device credential portal 222 in the user data repository (UDR) of the LAN (L-UDR 206b). The L-NEF 204 accesses the L-UDR 206b via the Nudr interface 220. This API can be referred to as the onBoard_Device API and is further described below.

[0066] A device can be tagged or wrapped with identification information (in this example, the device can include Figure 2 the UE207 in). The identification information can include a device identifier (e.g., a permanent equipment identifier (PEI)) and a secret device identifier (SDI). The PEI and SDI can be in a well-known format. As referred to herein, well-known means standardized in the specification and known to be suitable for connection to obtain network credentials. The identification information can also include an indication of the PEI and SDI formats. The identification information can also include an invitation-request tag, which will be further described below. The identification information can also include device type, service requirements (e.g., ultra-reliable low-latency communication (URLLC)), subscriptions, security credentials, security keys, etc.

[0067] Before the device (e.g., UE 207) is powered on for the first time and within the scope of the type b network, the network operator can use the device credential portal 222 to provide the network with the identification information of the device. It should be noted that there is an implicit assumption that the device information has been supplied to the network before the device 207 is powered on for the first time. For example, the onBoard_DeviceAPI exposed by the L-NEF 204 can allow the device credential portal 222 (acting as the AF 205) to provide the network with the identification information of the device 27 and the connection time parameters. The connection time parameters can indicate how much time the device 207 is given to connect to the network or the time window during which the device 207 is expected to connect. The onBoard_Device API can also be used to provide the network with geographical information, which the network uses to deduce or determine which RAN node(s) 208 the device 207 is expected to connect to first. Alternatively, the geographical information can include the identities of the candidate RAN nodes 208 that the device 207 is expected to connect to first. It should be noted that the API exposed by the L-NEF 204 can also allow the AF 205 to indicate that certain devices or device types are not allowed to access the LAN at a specific time. The L-NEF 204 can distribute this information to the RAN node 208 directly or via the N2 interface 212 of the L-AMF 202 and the L-AMF 202.

[0068] Once the device information is provided to the network via its API and the current time is within the connection time, the network can start broadcasting invitation information, which the device 207 can use to help it determine whether to attempt to connect to the network. If the network has the geographical information of the device, it can use this information to help determine the specific RAN node(s) 208 in the expected geographical area (e.g., tracking area) of the device where the invitation information should be broadcast. One or more RAN nodes 208 of the network can broadcast the invitation information of the network, which includes any combination of the following information:

[0069] (1) An indication that the network is willing to accept new devices. This indication can also indicate that the network is willing to accept certain device types or devices that require certain services, certain QoS levels, etc. This indication can be a reserved PLMN identifier. The device can receive an indication that the network is a LAN (e.g., a reserved network identifier) and use this indication to determine whether to request the RAN node 208 to broadcast more information about the network (e.g., whether the network is willing to accept certain device types, devices that require certain services, certain QoS levels).

[0070] (2) The PEI of the device that the network is willing to allow to connect.

[0071] (3) The part of the PEI of the device that the network is willing to allow to connect to it.

[0072] (4) The PEI or a part of the PEI that is currently not allowed or prohibited from connecting

[0073] The RAN node 208 may broadcast the invitation information as part of the master information block (MIB) or system information block 1 (SIB1) or other system information indicated by SIB1. Alternatively, the invitation information may be broadcast by the RAN node 208 as part of one or more system information (SI) messages. When the invitation information is part of one or more system information messages, the device may send a system information request to the RAN node 208 to cause the RAN node 208 to broadcast one or more system information messages so that the device can receive it. The system information request may include an indication that the device 207 wants the invitation information to be broadcast and / or an invitation tag. The invitation tag may be a value used to help the RAN node 208 ensure that it is responding to the device 207 that is invited to connect to the network. For example, the invitation tag may be an identifier or device type supplied to the device 207 at the time of manufacture. The indication may also be sent via the random access channel (RACH) between the device 207 and the RAN 208 as part of the second message of the initial random access procedure (i.e., the response from the RAN 208). Alternatively, the invitation tag may be a device identifier (e.g., the PEI of the device 207).

[0074] Alternatively, a paging channel may be defined that allows the network to page a device based on its device identifier and the format of its device identifier. The core network (CN) typically only pages attached / registered devices. However, in this case, the CN knows based on the information provided via the portal that it needs to contact the device 207. When the identification information of the device 207 is provided to the network and the current time is within the connection time, the network may attempt to page the device 207 in the area specified by the geographical information. The paging may be sent to the device 207 via a preconfigured paging occasion (i.e., time and frequency resources and / or spatial information), but the device 207 has not previously registered with the network. When a device 207 that has not previously registered with the network blindly decodes its paging indication during the connection time window and then receives a paging message indicating the identifier and the format of the device identifier of the device 207, the device 207 may interpret the message as an invitation to connect.

[0075] When device 207 is turned on and network credentials have not been pre-provisioned in device 207, or when device 207 discovers a network for which it has not been provisioned with credentials, device 207 may start reading the Master Information Block (MIB) or System Information Block 1 (SIB1) or other system information indicated by SIB1 to look for invitation information. Alternatively or additionally, device 207 may send a system information request to the RAN node to cause the RAN to broadcast a system information message with the invitation information, such that device 207 may receive the invitation information. The system information request may include an invitation tag. When device 207 receives the invitation information and confirms that the invitation includes the identifier of device 207, device 207 may request to connect to the network.

[0076] Alternatively, when monitoring the paging channel and observing that the device identifier of device 207 is being paged with a pre-configured paging allocation, device 207 may attempt to register with the network.

[0077] Once device 207 determines that it wants to connect to the network, device 207 may send a general registration request to the network. The general registration request may include the PEI. The PEI may be the same identifier included in the invitation. Device 207 may not indicate the Network Slice Selection Assistance Information (NSSAI) in this general registration request, or device 207 may provide an NSSAI that includes a single NSSAI (S-NSSAI) that includes well-known Slice / Service Type (SST) or Slice Differentiator (SD) values that indicate that device 207 wants to connect to the network and obtain network credentials. Device 207 may provide an indication in the general registration request to indicate that it is registering in response to an invitation and for the purpose of obtaining network credentials. The invitation may have been received via the paging channel, broadcast, or system information message. The general registration message may be partially encrypted, and the encryption applied may be partially based on the SDI. For example, the general registration message may include the unencrypted device identifier, and then the remainder of the general registration message may include encrypted information. The encryption may be based on the information in the SDI. The encrypted information may include a new device identifier for device 207, information about the location and / or settings of device 207. The L-AMF 202 may decrypt the message and use the fact that the message has been successfully decrypted to consider device 207 to be authorized and authenticated. The general registration response from the L-AMF 202 to device 207 may also be encrypted and may include the new identifier(s) (e.g., 5G-GUTI) of device 207. Device 207 may use the new identifier(s) to identify itself in subsequent messages towards the L-AMF 202.

[0078] Credentials can be supplied to device 207, for example, via the control plane. When the network (i.e., L-AMF 202) receives a registration request, it can authorize device 207 by verifying that the device identifier is invited to connect and that a registration request is being received within a time window. The network can authenticate device 207 by issuing a challenge value to device 207. Device 207 can hash the challenge value with the SDI of device 207 and can respond to the network with the result of the hashing operation. When the response matches the expected response, the network can consider device 207 to be authenticated. The authentication request from the network can indicate which hashing function device 207 should use.

[0079] Once the network has authenticated and authorized device 207, the network can provide the following information to device 207 in a registration acceptance message.

[0080] (1) A locally unique temporary identifier (LUTI) that can be considered unique within the LAN system 200. When device 207 is within the LAN system 200, device 207 can treat the LUTI like a GUTI. However, when connected to any other network, device 207 cannot use the LUTI.

[0081] (2) A local subscription identifier (LSI), which can be the subscription identifier of device 207 to the LAN system 200. When device 207 is within the LAN system 200, device 207 can treat it like a subscription permanent identifier (SUPI). However, when connected to any other network, device 207 cannot use the LSI.

[0082] (3) One or more security parameters or one or more credentials.

[0083] (4) The network identifier to which device 207 should register. Assume that the credentials are associated with all the provided network identifiers. The network identifiers can include, for example, a PLMN identifier, a TA-NID, a TB-NID, etc. They can be provided in a priority order.

[0084] Once device 207 has obtained credentials from an authentication and authorization (AA) server or L-UDM 206a or L-UDR 206b, device 207 can deregister and perform a new general registration using the credentials.

[0085] Figure 3 is a diagram of an example process 300 for loading a device into a type b network according to an example, which can be used in conjunction with any of the embodiments described herein. Figure 3 The example process 300 demonstrates a device that is supplied with type b network credentials.

[0086] Reference Figure 3 , as described above, the onBoard_Device API can be used by AF 307 to provide device credentials in the network via onboard_Device_Request (step 311). This API can be used to supply the L-UDR 305 with information for one or more devices, including but not limited to the following information: identification information, connection time, and geographical information.

[0087] The L-NEF 306 can use L-UDR services such as the Nudr_DM_Create service to supply device credentials in the L-UDR 305 (step 312). At this time, the L-NEF 306 can distribute the information to the AMF in the network so that the AMF can notify the RAN node which types of devices or which device identities are allowed to attach to the network, and the RAN node knows what information should be broadcast.

[0088] The L-UDR 305 can respond to the call to the Nudr_DM_Create service of the N-NEF 306 with a provisioning credential response indicating whether the provisioning was successful (step 313).

[0089] The L-NEF 306 can respond to the call to the onBoard_Device service (via onboard_Device_Request) with an onboard_Device response indicating whether the provisioning was successful (step 314).

[0090] An initiation event on the UE 301 (which can be any device described herein) causes the UE 301 to start attempting to connect to the network without any pre-provisioned network credentials (step 315). Examples of initiation events are the UE 301 being powered on, the UE 301 being powered on and off in a specific sequence, human-machine interaction with a user interface (such as a button or GUI), or the UE 301 not finding a network for which it has been provisioned with network credentials.

[0091] The UE 301 may start reading the MIB or SIB1 broadcast by the (R)AN node 302 or other system information indicated by SIB1 (step 316). The UE 301 may be pre-provisioned to search for some default information in the SIB or MIB information. For example, the UE 301 may search for an indication that the network provides certain types of services. In another example, the UE 301 may search for an indication that the network is capable of supplying network credentials to the device. The UE 301 may also search for an indication that the network can accept certain types of system information requests (e.g., a system information request for the network to broadcast invitation information). The UE 301 may search for the RAN node that is broadcasting the PEI of the UE 301 or a part of the PEI of the UE 301. Alternatively, the UE 301 may search for the RAN node that is paging the PEI of the UE 301.

[0092] The UE 301 may send a system information request to the network via the (R)AN 302 (step 317). The system information request may include the identification information of the UE 301 or an invitation tag. The system information request is a request for the network to broadcast information, including but not limited to:

[0093] An indication that the network provides certain types of services;

[0094] An indication that the network is capable of providing network credentials to the device;

[0095] The PEI of the device being invited to connect or any device associated with the provided invitation tag; and

[0096] An indication that the network is capable of inviting the device to connect via paging.

[0097] The network may broadcast the requested information via the (R)AN 302 (step 318).

[0098] The UE 301 may send a general registration request to the L-AMF 303 (step 319). The request may include the PEI and / or may include the SDI.

[0099] The L-AMF 303 may invoke the Nudm_SDM_Get service to retrieve the device credentials provided by the onBoard_Device API in step 311 via the L-UDM 304 and the L-UDR 305 (steps 320a, 320b, and 320c).

[0100] The L-AMF 303 can check whether the device identifier has been invited to connect and is receiving a registration request within a time window, and the L-AMF 303 can then authenticate and authorize the UE 301 by sending a challenge value to the UE 301 and checking whether the response matches the value expected based on the SDI of the UE 301 (step 321). As described above, if the UE 301 encrypts a part of the general registration message, then the L-AMF 303 can use the fact that the L-AMF 303 can decrypt the message as a reason for authenticating and authorizing the UE 301. Therefore, this step may not require interaction with the UE 301.

[0101] Assuming that the UE 301 has been authenticated and authorized, the network can send a registration acceptance message to the UE 301 (step 322). The network can provide the UE 301 with the information in the registration acceptance message, including but not limited to the following information:

[0102] (1) LUTI.

[0103] (2) LSI.

[0104] (3) (One or more) security parameters and (one or more) credentials.

[0105] (4) Network identifier. It may not be necessary to provide the network identifier to the UE 301 in the registration acceptance message because the UE 301 can obtain it from the MIB. After receiving the network credentials, the UE 301 can store the network credentials and the network identifier for future attempts to connect to the network.

[0106] (5) Other information that can assist the UE 301 in discovering the LAN network, such as:

[0107] (a) Operating parameters of the LAN network. For example, downlink frequency, bandwidth, etc.

[0108] (b) Geographical location of the RAN node providing services to the LAN network.

[0109] (c) Access restrictions of the LAN network. For example, the LAN network can only provide services during regular working hours (from 8 AM to 5 PM).

[0110] The UE 301 can send a registration completion message indicating that the credentials have been successfully provisioned to the network (step 323). The registration completion message can include an indication that the UE 301 will log off and re-register with the network using the newly provisioned credentials.

[0111] Alternatively, the credential may be supplied to the UE 301 via the user plane. For example, when the network (L-AMF 303) receives a registration request in step 319, it may authorize the UE 301 to access only the default S-NSSAI for obtaining access to the AA server. The registration acceptance message from the L-AMF 303 sent during step 322 may provide the S-NSSAI to the UE 301. Then, the UE 301 may connect to the AA server and obtain the same information (e.g., LUTI, LSI, one or more security keys, one or more certificates, and network identifier) sent in the registration acceptance message in step 322 as described above. Once the UE 301 obtains the credential from the AA server, the UE 301 may deregister and perform a new general registration using the credential.

[0112] The device may perform LAN discovery according to another example, which may be used in combination with any of the embodiments described herein. The device may discover a LAN for which it has been supplied with network credentials and information. In a conventional system, the device discovers the network by receiving a network ID (PLMN-ID) broadcast by a RAN node. This method may not always be applicable to a LAN, and it may not be desirable for the LAN to always broadcast its network identifier.

[0113] Alternatively, the LAN RAN node may broadcast partial identification information about itself. Examples of the partial identification information may include a network identifier (e.g., MCC and MNC), a network type indication (e.g., secure, industrial, private, home, vehicle, edge computing, etc.), and the like.

[0114] When the device is searching for a network to connect to, it may receive the partial identification information being broadcast by the RAN node, and if the partial identification information corresponds to the network it desires to connect to, then it may decide to perform a further check to determine whether it should attempt to connect. Examples of the partial identification information may include any combination of MCC, MNC, service identifier, operator identifier, network identifier, digits, etc.

[0115] When the device wants to further check the identifier of the network, it may send a system information request that includes an indication that it wants the RAN node to broadcast a system information message with more details about the network. The additional details may be the complete network identifier or a part of the network identifier, which may form the complete network identifier when combined with the information already received in the MIB or SIB. The request from the UE to the RAN node may include information previously pre-supplied by the network in the UE, such as an invitation label.

[0116] Figure 4 FIG. is a diagram of an example process 400 for network discovery according to an example, which may be used in conjunction with any of the embodiments described herein. Figure 4 The process of Figure 3 describes how steps 315 - 318 may be performed.

[0117] Referring to Figure 4 , the device may start searching for a network (step 410). The initiating event or trigger that causes the device to start searching for a network may come from an indication of a change in position of a user interface (e.g., a button or GUI), the UE entering a specific location, losing connection to the network, etc.

[0118] The device may detect nearby networks and, based on conditions such as signal strength, may decide to start a process of determining whether the device should connect to the network (step 411).

[0119] The device may receive broadcast information from the network and determine that the network may be the network it wants to associate with (step 412). For example, the device may determine that the associated network operator is the network operator it wants to associate with. If the broadcast information does not indicate the network operator with which the device wants to associate, then the device will return to step 411. The device may also check other MIB or SIB information to determine what services the network offers, what types of devices should be connected to the network, and / or whether the network is willing to respond to a system information request to obtain more details about the services it offers.

[0120] The device may send a system information request to the network to query whether the network supports specific services, devices, etc. (step 413). The request may also be an indication or request that the network should broadcast more identification information about the network. The request may include an invitation tag or identification information for the device so that the RAN node can determine whether the device should receive additional information.

[0121] The network may start broadcasting, and the device may start receiving and analyzing more information about the network (step 414). For example, the network may broadcast more identification information about the network, information about what services it offers, and what types of devices it can support. If the device determines that it does not want to associate with the network, then the device will return to step 411.

[0122] The device sends a registration request to the network (step 415).

[0123] Alternatively, when the device discovers a RAN node broadcasting a PLMN identifier with the same MCC and MNC as the LAN it wants to connect to, the UE may register with the PLMN (via Figure 3 (general registration request in step 319 thereof), and the PLMN may provide the device with additional details of the LAN that can be reached via the same RAN node (via Figure 3 (general registration request in step 319 thereof). The LAN information provided to the UE may depend on the subscription information of the device. When the device obtains the additional information, it may register with the LAN. Before registering with the LAN, the device may choose to re-register with the PLMN. The PLMN may indicate to the UE whether it should deregister before connecting to the LAN. The LAN information may be delivered to the device by the AMF in the Figure 3 NAS general registration acceptance message in step 322. Alternatively, the information may be provided to the UE by the RAN in an RRC message. When the RAN node provides the information to the device, the AMF may first provide the RAN node with information associated with the LAN that permits the device to connect.

[0124] Before the device registers with the LAN, it may want to check whether the LAN offers a particular service. The RAN node may broadcast an indication of its support for certain services in the MOB or SIB, or it may broadcast an indication of an indication of its support for a particular service when queried. The device may then send a system information request to the RAN node to cause the RAN to broadcast a system information message indicating which services can be reached via the network. The device may then make a decision on whether to connect based on the response from the RAN node.

[0125] According to another example, the device may be connected to two AMFs via the same RAN node, which may be used in combination with any of the embodiments described herein. The device may use a single RAN node to reach both the 3GPP wide area cellular network and the 3GPP LAN simultaneously. In such a scenario, the wide area cellular network and the LAN may be served by different AMFs. In such a scenario, when the device has connected to the LAN or the PLMN and attempts to register with the other network, the device may indicate to the RAN node that the registration request is a new registration request for the other network.

[0126] When the device attempts to register with the other of the wide area cellular network or the LAN, the device may provide the RAN with an indication that the request is for a new NAS connection and that the existing NAS connection should not be torn down. For example, the AN parameter field of the registration request may include an indication that the request to the RAN is for a new NAS connection and that the existing connection should not be torn down. The AN parameter field may also indicate the wide area cellular network or the LAN to which the device is attempting to register. The 5G-GUTI or SUCI provided to the RAN in the AN parameter field may be the 5G-GUTI or SUCI associated with the wide area network or the LAN to which the UE is attempting to connect.

[0127] A LAN operator may have policies or rules associated with each user or group. The policies can be used to determine which other devices a user or group can discover. When the LAN receives a discovery request, the network can check if the device is allowed to discover the type of device indicated in the request. However, it is more efficient if the device already knows what types of devices it is allowed to discover to prevent it from sending requests that will be rejected. Thus, according to another example, the LAN can include a PCF, and the PCF can send a discovery policy to the UE, which can be used in conjunction with any of the embodiments described herein. The discovery policy can detail what types of devices can be discovered, what groups of devices can be discovered, and what device identifiers can be discovered. The policy can also indicate that certain devices or services are discoverable, but the device may not be allowed to communicate with them without performing an additional request and authorization process with the network. The UE configuration update procedure for transparent UE policy delivery can be used to deliver the policy to the UE.

[0128] Once the discovery policy is provided to the device, the device can display the policy information on the GUI so that the user of the device can browse what devices, types of devices, or groups of devices it is allowed to discover.

[0129] Once the discovery policy is received, the UE can trigger a discovery request based on user input (e.g., from the GUI), based on the receipt of the policy, or based on an application request. The discovery request can include an indication of what to discover (e.g., a device, a device type, a group of devices, etc.). The network can respond with a list of available devices.

[0130] When the device selects a discovered device to communicate with, the device can attempt to initiate communication with the device by directly contacting the discovered device based on the information provided in the discovery response. Alternatively, the device can send a control plane message to the network, thereby requesting that a trigger be sent to the device. The trigger can contain information on how the discovered device can contact the device.

[0131] As discussed above, it may be necessary to move the PDN connection from the LAN to the PLMN and vice versa. For example, a device can have two PDN connections. The first PDN connection can be used to carry traffic from sensors in a car, for example, and the second PDN connection can be used to carry traffic for streaming audio and video, for example. When the vehicle arrives at a factory, the first PDN connection associated with the sensor data may need to be moved to the LAN, while the second PDN connection can remain connected to the PLMN.

[0132] During the handover process between N2 of NG-RAN nodes in a conventional system, this type of handover where some PDU sessions are handed over while some are not is not currently supported. During the handover process between N2 of NG-RAN nodes in a conventional system, all PDU sessions (i.e., all existing PDU sessions with active UP connections) are handed over from the source RAN (S-RAN) to the target RAN (T-RAN). When the device moves towards or away from a LAN, only certain PDU sessions should be moved. To support only the movement of selected PDU sessions between the S-RAN and the T-RAN, the following enhancements to the handover process are described herein.

[0133] The S-RAN can determine that only certain PDU sessions are candidates for handover to a specific T-RAN based on any of the following:

[0134] When the UE reports measurements to the S-RAN and the measurements are related to a T-RAN (i.e., a LAN) that should only support some of the UE's PDU sessions, the UE can report to the S-RAN that the T-RAN is a LAN network and that only the handover of certain PDU sessions is supported. The UE can also indicate which PDU sessions can be handed over to the T-RAN and which PDU sessions cannot be handed over to the T-RAN. The UE can know which LANs and T-RAN identifiers the PDU sessions can be handed over to based on the SM policies received from the PCF.

[0135] When a PDU session is established, the SMF can report to the (R)AN node in the N2 SM information (via the AMF) that the PDU session is allowed to be handed over to a T-RAN that is a LAN network. In addition, the N2 SM information can report the identity of the (one or more) LANs and the associated (one or more) T-RANs to which the PDU session can be transferred.

[0136] This document also describes enhancements to the "Handover Required" message. The "Handover Required" message from the S-RAN to the S-AMF can be enhanced to indicate to the S-AMF that only certain PDU sessions (and the PDU session IDs that should be handed over) should be handed over.

[0137] Based on the SM policies provided by the PCF, the UE can become aware that certain PDU sessions can be moved to the LAN. The policy can also indicate whether a PDU session should be handed over to a specific LAN if possible, or whether it should never be handed over to a wide area network (e.g., a PLMN). The UE can provide the associated PDU session ID to the RAN so that the RAN can use this information when determining whether to hand over the UE to the target RAN. The RAN can also use this information to determine whether to hand over certain PDU sessions and to terminate PDU sessions that are not suitable to be moved to the target RAN. The PDU sessions to be terminated can be indicated in the handover message to the T-RAN. When a PDU session is established, the UE can also indicate that the PDU session should be associated only with a specific LAN. The SMF can then provide this information to the RAN node in the N2 SM information.

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

[0139] 3GPP has identified various use cases that are expected to be supported by NR, leading to a wide variety of user experience requirements for data rate, latency, and mobility. The use cases include the following general categories: enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), massive machine type communication (mMTC), network operations (e.g., network slicing, routing, handover, and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communication, which can include vehicle-to-vehicle communication (V2V), vehicle-to-infrastructure communication (V2I), vehicle-to-network communication (V2N), vehicle-to-pedestrian communication (V2P), and vehicle communication with other entities. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive emergency call (eCall), disaster alerts, real-time gaming, multi-person video calls, autonomous driving, augmented reality, tactile internet, virtual reality, home automation, robotics, and aerial drones, among others. All of these use cases and other use cases are expected in this document.

[0140] Figure 5A An example communication system 100 is illustrated, in which the systems, methods, and apparatuses described and claimed herein can be used. The communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g, which can generally or collectively be referred to as WTRU 102 or WTRUs 102. The communication system 100 can include radio access networks (RANs) 103 / 104 / 105 / 103b / 104b / 105b, core networks 106 / 107 / 109, public switched telephone networks (PSTNs) 108, the Internet 110, other networks 112, and network services 113. The network services 113 can include, for example, V2X servers, V2X functions, ProSe servers, ProSe functions, IoT services, video streaming, and / or edge computing, among others.

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

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

[0143] TRP 119a and 119b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks (e.g., core network 106 / 107 / 109, Internet 110, network services 113, and / or other networks 112). RSU 120a and 120b can be any type of device configured to wirelessly interface with at least one of the WTRUs 102e or 102f to facilitate access to one or more communication networks (such as core network 106 / 107 / 109, Internet 110, other networks 112, and / or network services 113). By way of example, base stations 114a, 114b can be base transceiver stations (BTSs), Node Bs, eNode Bs, home Node Bs, home eNode Bs, next generation Node Bs (gNode Bs), satellites, site controllers, access points (APs), wireless routers, etc.

[0144] Base station 114a can be part of the 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. Similarly, base station 114b can be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as BSCs, RNCs, relay nodes, etc. Base station 114a can be configured to transmit and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). Similarly, base station 114b can be configured to transmit and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). A cell can be further divided into cell sectors. For example, the cell associated with base station 114a can be divided into three sectors. Thus, for example, base station 114a can include three transceivers, e.g., one transceiver for each sector of the cell. Base station 114a can employ multiple-input multiple-output (MIMO) technology and thus can use multiple transceivers for, e.g., each sector of the cell.

[0145] Base station 114a can communicate with one or more of the WTRUs 102a, 102b, 102c, and 102g 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, cmWave, mmWave, etc.). Any suitable radio access technology (RAT) can be used to establish the air interfaces 115 / 116 / 117.

[0146] The base station 114b can communicate with one or more of the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b via a wired or air interface 115b / 116b / 117b. The air interface 115b / 116b / 117b can be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). Any suitable RAT can be used to establish the air interface 115b / 116b / 117b.

[0147] The RRHs 118a, 118b, the TRPs 119a, 119b, and / or the RSUs 120a and 120b can communicate with one or more of the WTRUs 102c, 102d, 102e, 102f via an air interface 115c / 116c / 117c. The air interface 115c / 116c / 117c can be any suitable wireless communication link (e.g., RF, microwave, IR, UV, visible light, cmWave, mmWave, etc.). Any suitable RAT can be used to establish the air interface 115c / 116c / 117c.

[0148] The WTRUs 102 can communicate with each other via a direct air interface 115d / 116d / 117d, such as sidelink communication, which can be any suitable wireless communication link (e.g., RF, microwave, IR, ultraviolet UV, visible light, cmWave, mmWave, etc.). Any suitable RAT can be used to establish the air interface 115d / 116d / 117d.

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

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

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

[0152] For example, Figure 5A the base station 114c in can be a wireless router, a home Node B, a home eNode B, or an access point, and can utilize any suitable RAT to facilitate wireless connections in a localized area such as a business premise, a home, a vehicle, a train, an antenna, a satellite, a factory, a campus, etc. The base station 114c and the WTRU 102 (e.g., the WTRU 102e) can implement a radio technology such as IEEE802.11 to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRU 102 (e.g., the WTRU 102d) can implement a radio technology such as IEEE 802.15 to establish a Wireless Personal Area Network (WPAN). The base station 114c and the WTRU 102 (e.g., the WRTU 102e) can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a pico cell or a femto cell. As Figure 5A shown in, the base station 114c can have a direct connection to the Internet 110. Thus, it may not be required for the base station 114c to access the Internet 110 via the core network 106 / 107 / 109.

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

[0154] Although not shown in Figure 5A it should be appreciated that RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b and / or core networks 106 / 107 / 109 may communicate directly or indirectly with other RANs that employ the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b that may utilize E-UTRA radio technology, core networks 106 / 107 / 109 may also communicate with another RAN (not shown) that employs GSM or NR radio technology.

[0155] Core networks 106 / 107 / 109 may also serve as gateways for the WTRUs 102 to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that use common communication protocols (such as the Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Internet Protocol (IP) in the TCP / IP Internet protocol suite). Other networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include any type of packet data network (e.g., an IEEE 802.3 Ethernet network) or another core network connected to one or more RANs, which may employ the same RAT as RAN 103 / 104 / 105 and / or RAN 103b / 104b / 105b, or a different RAT.

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

[0157] Although not shown in Figure 5A it will be appreciated that the user equipment may establish a wired connection to a gateway. The gateway may be a residential gateway (RG). The RG may provide connectivity to the core network 106 / 107 / 109. It will be appreciated that many of the concepts contained herein may be equally applicable to the UE of the WTRU and to the UE that uses a wired connection to connect to the network. For example, the concepts applicable to the wireless interfaces 115, 116, 117, and 115c / 116c / 117c may be equally applicable to the wired connection.

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

[0159] As Figure 5B As shown, Node Bs 140a, 140b can communicate with RNC 142a. In addition, Node B 140c can communicate with RNC 142b. Node Bs 140a, 140b, and 140c can communicate with the 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 the respective Node Bs 140a, 140b, and 140c to which it is connected. In addition, each of RNCs 142a and 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0160] Figure 5B The core network 106 shown in [Figure] can include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the foregoing elements is depicted as part of the core network 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the core network operator.

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

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

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

[0164] Figure 5C It is a system diagram of exemplary RAN 104 and core network 107. As described above, RAN 104 can adopt E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with core network 107.

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

[0166] Each of eNode-Bs 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, scheduling of users in the uplink and / or downlink, etc. As Figure 5C shown, eNode-Bs 160a, 160b, and 160c can communicate with each other via the X2 interface.

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

[0168] MME 162 can be connected to each of eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface and can act as a control node. For example, 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. MME162 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.

[0169] The serving gateway 164 can be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via the S1 interface. The serving gateway 164 can generally route user data packets to and forward user data packets from the WTRUs 102a, 102b, and 102c. The serving gateway 164 can also perform other functions, such as anchoring the user plane during handover between eNode Bs, triggering paging when downlink data is available for the WTRUs 102a, 102b, and 102c, managing and storing the contexts of the WTRUs 102a, 102b, and 102c, and so on.

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

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

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

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

[0174] The N3IWF 199 may include non-3GPP access points 180c. It will be appreciated that the N3IWF 199 may include any number of non-3GPP access points. The non-3GPP access point 180c may include one or more transceivers for communicating with the WTRU 102c via the air interface 198. The non-3GPP access point 180c may use the 802.11 protocol to communicate with the WTRU102c via the air interface 198.

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

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

[0177] In Figure 5D the example of, the 5G core network 109 may include an Access and Mobility Management Function (AMF) 172, a Session Management Function (SMF) 174, User Plane Functions (UPF) 176a and 176b, a User Data Management Function (UDM) 197, an Authentication Server Function (AUSF) 190, a Network Exposure Function (NEF) 196, a Policy Control Function (PCF) 184, a Non-3GPP Interworking Function (N3IWF) 199, and a User Data Repository (UDR) 178. Although each of the foregoing elements is depicted as part of the 5G core network 109, it will be appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator. It will also be appreciated that the 5G core network may not include all of these elements, may include additional elements, and may include multiple instances of each of these elements. Figure 5D The figure shows network functions directly connected to each other, however, it should be appreciated that they may communicate via a routing agent such as a diameter routing agent or a message bus.

[0178] In Figure 5D the example of, the connectivity between network functions is implemented via a set of interfaces or reference points. It will be appreciated that network functions may be modeled, described, or implemented as a set of services invoked or called by other network functions or services. The invocation of network function services may be achieved via direct connections between network functions, message exchanges on a message bus, invoking software functions, etc.

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

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

[0181] The UPFs 176a and 176b can provide the WTRUs 102a, 102b, and 102c with access to a packet data network (PDN) (such as the Internet 110) to facilitate communication between the WTRUs 102a, 102b, and 102c and other devices. The UPFs 176a and 176b can also provide the WTRUs 102a, 102b, and 102c with access to other types of packet data networks. For example, the other network 112 can be an Ethernet network or any type of network that exchanges data packets. The UPFs 176a and 176b can receive traffic steering rules from the SMF 174 via the N4 interface. The UPFs 176a and 176b can provide access to the packet data network by connecting the packet data network to the N6 interface or by connecting to each other and to other UPFs via the N9 interface. In addition to providing access to the packet data network, the UPF 176 can also be responsible for packet routing and forwarding, policy rule enforcement, quality of service handling for user plane traffic, and downlink packet buffering.

[0182] The AMF 172 can also be connected to the N3IWF 199 via the N2 interface, for example. The N3IWF facilitates the connection between the WTRU 102c and the 5G core network 170 via a radio interface technology not defined by 3GPP, for example. The AMF can interact with the N3IWF 199 in a manner that is the same as or similar to the way it interacts with the RAN 105.

[0183] The PCF 184 can be connected to the SMF 174 via the N7 interface, to the AMF 172 via the N15 interface, and to the application function (AF) 188 via the N5 interface. The N15 and N5 interfaces are not Figure 5D As shown. The PCF 184 can provide policy rules to control plane nodes such as the AMF 172 and the SMF 174, thereby allowing the control plane nodes to execute these rules. The PCF 184 can send policies for the WTRUs 102a, 102b, and 102c to the AMF 172, such that the AMF can deliver the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies can then be enforced or applied at the WTRUs 102a, 102b, and 102c.

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

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

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

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

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

[0189] Network slicing is a mechanism that mobile network operators can use to support one or more "virtual" core networks behind the operator's air interface. This involves "slicing" the core network into one or more virtual networks to support different RANs or different service types operating across a single RAN. Network slicing enables operators to create networks customized to provide optimized solutions for different market scenarios with different requirements (e.g., in terms of functionality, performance, and isolation).

[0190] 3GPP has designed the 5G core network to support network slicing. Network slicing is a good tool for network operators to support various collections of 5G use cases that require very diverse and sometimes extreme requirements (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband). Without using network slicing technology, the network architecture may be inflexible and not scalable enough to efficiently support a wide range of traffic demands when each use case has its own specific set of performance, scalability, and availability. In addition, the introduction of new network services should be made more efficient.

[0191] Refer again to Figure 5D , in a network slicing scenario, the WTRU 102a, 102b, or 102c can be connected to the AMF 172 via the N1 interface. The AMF can logically be part of one or more slices. The AMF can coordinate the connection or communication of the WTRU 102a, 102b, or 102c with one or more UPFs 176a and 176b, the SMF 174, and other network functions. Each of the UPFs 176a and 176b, the SMF 174, and other network functions can be part of the same slice or different slices. When they are part of different slices, they can be isolated from each other in the sense that they may utilize different computing resources, security credentials, etc.

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

[0193] Described herein and in Figure 5A , 5C The core network entities shown in FIGS. 5D and 5E are identified by the names given to those entities in certain existing 3GPP specifications, but it will be understood that in the future those entities and functions may be identified by other names, and that certain entities or functions may be combined in future 3GPP specifications (including future 3GPP NR specifications) published by 3GPP. Thus, the specific network entities and functions described and shown in Figure 5A , 5B , 5C, 5D and 5E are provided by way of example only, and it should be understood that the subject matter disclosed and claimed herein may be implemented or realized in any similar communication system, whether currently defined or future defined.

[0194] Figure 5E FIG. 11 illustrates an example communication system 111 in which the systems, methods, and apparatuses described herein may be used. The communication system 111 may include wireless transmit / receive units (WTRUs) A, B, C, D, E, F, a base station gNB 121, a V2X server 124, and roadside units (RSUs) 123a and 123b. In practice, the concepts presented herein may be applied to any number of WTRUs, base stations gNB, V2X networks, and / or other network elements. One or several or all of the WTRUs A, B, C, D, E, and F may not be within the access network coverage area 131. WTRUs A, B, and C form a V2X group, where WTRU A is the group leader and WTRUs B and C are group members.

[0195] If WTRUs A, B, C, D, E, and F are within the access network coverage area 131, then they may communicate with each other via gNB 121 over the Uu interface 129. In Figure 5E example, WTRUs B and F are shown within the access network coverage area 131. WTRUs A, B, C, D, E, and F may communicate directly with each other via a sidelink interface such as interfaces 125a, 125b, or 128 (e.g., PC5 or NR PC5), whether they are within the access network coverage area 131 or outside the access network coverage area 131. For example, in Figure 5E example, WRTU D, which is outside the access network coverage area 131, communicates with WTRU F, which is within the coverage area 131.

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

[0197] Figure 5F is a block diagram of an exemplary apparatus or device, a WTRU 102, which may be configured to wirelessly communicate and operate in accordance with the systems, methods, and apparatuses described herein, such as Figure 5A , 5B , 5C, 5D, or 5E of WTRU102. As Figure 5F shown, the exemplary WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripheral devices 138. It should be appreciated that the WTRU 102 may include any sub-combination of the foregoing elements. Moreover, base stations 114a and 114b, and / or the nodes that base stations 114a and 114b may represent (such as, but not limited to, transceiver stations (BTSs), Node Bs, site controllers, access points (APs), home Node-Bs, evolved home Node-Bs (eNodeBs), home evolved Node-Bs (HeNBs), home evolved Node B gateways, next generation Node Bs (gNode Bs), and proxy nodes, etc.) may include Figure 5F some or all of the elements depicted and described herein.

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

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

[0200] In addition, although the transmission / reception element 122 is depicted as a single element in Figure 5F , the WTRU 102 may include any number of transmission / reception elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmission / reception elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via the air interface 115 / 116 / 117.

[0201] The transceiver 120 may be configured to modulate the signals to be transmitted by the transmission / reception element 122 and demodulate the signals received by the transmission / reception element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs (e.g., NR and IEEE 802.11 or NR and E-UTRA), or communicate with the same RAT via multiple beams to different RRHs, TRPs, RSUs, or nodes.

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

[0203] The processor 118 may receive power from a power supply 134 and may be configured to distribute power to and / or control 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.

[0204] The processor 118 may also be coupled to a GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to or instead of information from the GPS chipset 136, the WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) via an 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 appreciated that the WTRU 102 may obtain location information by any suitable location determination method.

[0205] 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, functionality, and / or wired or wireless connectivity. For example, the peripheral devices 138 may include various sensors, such as an accelerometer, a biometric (e.g., fingerprint) sensor, an electronic compass, a satellite transceiver, a digital camera (for photos or videos), a universal serial bus (USB) port or other interconnect interfaces, a vibration device, a television transceiver, a hands-free headset, Modules, FM radio units, digital music players, media players, video game player modules, Internet browsers, etc.

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

[0207] Figure 5G is a block diagram of an exemplary computing system 90 in which one or more apparatuses of the communication networks shown in Figure 5A , 5C , 5D and 5E, such as certain nodes or functional entities in the RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, other networks 112 or network services 113. The computing system 90 may include a computer or a server and may be mainly controlled by computer-readable instructions which may be in the form of software, wherever and by whatever means such software is stored or accessed. Such computer-readable instructions may be executed within the processor 91 to cause the computing system 90 to operate. The processor 91 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), 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 function that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor different from the main processor 91 which may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate and process data related to the methods and apparatuses disclosed herein.

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

[0209] The memory coupled to the system bus 80 includes random access memory (RAM) 82 and read-only memory (ROM) 93. Such memory includes circuitry that allows for the storage and retrieval of information. The ROM 93 generally contains stored data that is not easily modified. The data stored in the RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to the RAM 82 and / or ROM 93 can be controlled by the memory controller 92. The memory controller 92 can provide an address translation function that translates virtual addresses into physical addresses when executing instructions. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Thus, a program running in the first mode can only access the memory mapped by its own process virtual address space; it cannot access the memory within the virtual address space of another process unless memory sharing between processes has been set up.

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

[0211] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output can 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 signal sent to the display 86.

[0212] Additionally, the computing system 90 can include communication circuitry such as, for example, a wireless or wired network adapter 97 that can be used to connect the computing system 90 to an external communication network or device (such as Figure 5A 、 5B , RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110, WTRU 102, or other network 112) so that the computing system 90 can communicate with other nodes or functional entities of those networks. Alone or in combination with the processor 91, the communication circuitry can be used to perform the transmission and reception steps of certain devices, nodes, or functional entities described herein.

[0213] It should be understood that any one or all of the devices, systems, methods, and processes described herein can be implemented in the form of computer-executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor (such as processor 118 or 91), cause the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any step, operation, or function described herein can be implemented in the form of such computer-executable instructions executed on a processor of a device or computing system configured for wireless and / or wired network communication. The computer-readable storage medium includes volatile and non-volatile, removable and non-removable media implemented in any non-transitory (e.g., tangible or physical) method or technology for storing information, but such computer-readable storage medium does not include signals. The computer-readable storage medium includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage device, magnetic tape cassette, magnetic tape, disk storage or other magnetic storage device, or any other tangible or physical medium that can be used to store the desired information and that can be accessed by a computing system.< / mnc> < / mcc> < / guami> < / guami>

Claims

1. A wireless transmit / receive unit (WTRU) includes a transceiver and one or more processors, the one or more processors being configured to: Supply identification information to the WTRU; Receive from a network a broadcast message including an indication that the network is capable of supplying network credentials to the WTRU; Send a registration request to the network based on the broadcast message, the registration request including the identification information previously supplied to the WTRU and an indication that the WTRU is registering in response to the indication in the broadcast message to obtain the network credentials; Perform a registration process with the network, wherein performing the registration process with the network is based on the broadcast message; Receive the network credentials; Perform a deregistration process with the network; And Use the network credentials to perform a second registration process.

2. The WTRU according to claim 1, wherein the network credentials include at least one of the following: A network identifier, A local subscription identifier, and One or more security parameters or security credentials.

3. The WTRU according to claim 1, wherein the WTRU starts attempting to connect to a network based on an event including at least one of the following operations: The WTRU is powered on, The WTRU is powered on and off in sequence, Receiving an indication from a user interface such as a button or GUI, or The WTRU does not find a network for which it has been supplied with network credentials; and The WTRU starts searching for a network based on a change in the location of the WTRU.

4. The WTRU according to claim 1, wherein the network credentials are received in a NAS message.

5. The WTRU according to claim 1, wherein the network credentials are received during a user plane procedure with a server.

6. The WTRU according to claim 3, wherein the registration process further Includes: Receiving single network slice selection assistance information (S-NSSAI) from the network, and Using the S-NSSAI to connect to a server.

7. The WTRU according to claim 1, wherein the WTRU includes a user equipment (UE).

8. A method used in a wireless transmit / receive unit (WTRU), the method Includes: Causing identification information to be supplied to the WTRU; Receiving from a network a broadcast message including an indication that the network is capable of supplying network credentials to the WTRU; Sending a registration request to the network based on the broadcast message, the registration request including the identification information previously supplied in the WTRU and an indication that the WTRU is registering in response to the indication in the broadcast message to obtain the network credentials; Performing a registration process with the network, wherein performing the registration process with the network is based on the broadcast message; Receiving the network credentials; Performing a deregistration process with the network; And Using the network credentials to perform a second registration process.

9. The method according to claim 8, wherein the network credentials include at least one of the following: A network identifier, A local subscription identifier, and One or more security parameters or security credentials.

10. The method according to claim 8, wherein the WTRU starts attempting to connect to a network based on an event comprising at least one of the following operations: the WTRU is powered on, the WTRU is powered on and off in sequence, receives an indication from a user interface such as a button or GUI, or the WTRU does not find a network for which it has been supplied with network credentials; and the WTRU starts searching for a network based on a change in the location of the WTRU.

Images