3GPP private lans

Abstract

To provide enhanced methods and apparatuses for securely connecting to 3GPP private networks.SOLUTION: For securely connecting to a private local area network (LAN), an apparatus is configured to: receive, from a private LAN that has been provisioned with first identifying information associated with the apparatus, a first broadcast message comprising an invitation to connect to the private LAN and the first identifying information; send, based on the first broadcast message comprising the first identifying information, a request for system information and second identifying information associated with the apparatus; receive, from the private LAN, the requested system information; send, based on the requested system information, a registration request and third identifying information associated with the apparatus; and receive, from the private LAN, acceptance of the registration request.SELECTED DRAWING: Figure 3

Description

[Technical field]

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

[0002] When packaging devices with wireless communication capabilities, device manufacturers have no way of knowing what network information the devices need to be provisioned with, and therefore these devices need to be configured after the initial purchase. Furthermore, broadcasting a network identifier by a private network (R)AN node may be considered a security risk, and unnecessary overhead is added if this information is broadcast periodically by the (R)AN node. Although an (R)AN node may provide connectivity to both private LANs and public cellular networks, it is currently not possible for a UE to have two Non-Access Stratum (NAS) connections through the same (R)AN node.

[0003] Therefore, there is a need for an enhanced method and apparatus for securely connecting to a 3GPP private network.

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Moreover, the claimed subject matter is not subject to limitations that address any or all of the disadvantages noted in any part of the present disclosure. Summary of the Invention

[0005] A method and apparatus for securely connecting to a private Local Area Network (LAN) is described herein. According to one embodiment, the apparatus may receive a first broadcast message from a private LAN where a first identity associated with the apparatus is provisioned, the first broadcast message including an invitation to connect to the private LAN and the first identity. The apparatus may transmit a first message including a request for system information and a second identity associated with the apparatus based on the first broadcast message including the first identity. The apparatus may receive a second broadcast message from the private LAN including the requested system information. The apparatus may transmit a second message including a registration request and a third identity associated with the apparatus based on the requested system information. The apparatus may receive a third message from the private LAN indicating acceptance of the registration request. [Brief description of the drawings]

[0006] In order to facilitate a better understanding of the present application, reference is made to the accompanying drawings, in which like elements are referenced with like numerals, which drawings should not be construed as limiting in application and are intended to be illustrative only, in which: [Figure 1] FIG. 1 illustrates an exemplary procedure for obtaining system information. [Diagram 2] FIG. 2 is a diagram of a LAN system having a device credential panel according to one embodiment. [Diagram 3] FIG. 3 is a diagram of an example procedure for a device onboarding onto a type-b network in accordance with one embodiment. [Figure 4] FIG. 4 is a diagram of an exemplary procedure for network discovery according to one embodiment. [Figure 5A] FIG. 5A illustrates an exemplary communication system. [Figure 5B] FIG. 5B is a system diagram of an example RAN and core network. [Figure 5C] FIG. 5C is a system diagram of an example RAN and core network. [Figure 5D] FIG. 5D is a system diagram of an example RAN and core network. [Figure 5E] FIG. 5E illustrates another exemplary communication system. [Figure 5F] FIG. 5F is a block diagram of an example apparatus or device, such as a Wireless Transmit / Receive Unit (WTRU). [Figure 5G] FIG. 5G is a block diagram of an exemplary computing system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0007] 3rd Generation Partnership Project (3GPP®) networks provide local area network (LAN)-like services to subscribers using networks called 3GPP LANs, which may also be referred to herein as private LANs. Methods and apparatus are described herein for enabling devices that do not have 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 whether it is the intended recipient of the invitation. The request includes information that the network can use to identify the device. Once a device is provisioned with network credentials, it can provide the credentials to an (R)AN node, which are used to discover the LAN using the credentials, identify the LAN as a candidate for connection, and request that the network broadcast a network identifier.

[0008] For example, a Radio Access Network (RAN) node may broadcast only partial identification information. When a device detects an (R)AN node broadcasting a 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 prove to the (R)AN node that the device is authorized to associate with the network.

[0009] As the term is used herein, a type-a network refers to a 3GPP Local Area Network (LAN) that is not for public use and that allows service continuity and roaming with a Public Land Mobile Network (PLMN).

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

[0011] The PLMN identifier is used to identify a 3GPP mobile network. The PLMN ID may also be used to identify private networks such as a LAN.

[0012] The embodiments described herein refer to various actions that a device, such as a User Equipment (UE), may perform. In this specification, the terms device and UE may be used interchangeably. 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.

[0013] As the term is used herein, LAN or private LAN refers to a 3GPP LAN.

[0014] Type a networks or type b networks are sometimes called non-public networks.

[0015] Type b networks are also sometimes called standalone non-public networks.

[0016] Table 1 below provides a list of abbreviations associated with technologies that may be used in the examples described herein.

[0017] [Table 1]

[0018] The embodiments described herein may apply to a variety of use cases. One exemplary use case includes device management and onboarding. For example, a factory worker may install 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 the network operator. In this example, the devices 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 secure mechanism for an operator to provision 3GPP credentials to industrial IoT devices for 5G LAN type services.

[0019] Another exemplary use case may relate to device discovery mechanisms. For example, a user may be browsing the Internet on a tablet and attempt to print out an article. Initially, the printer is not plugged in, and as a result, the tablet does not detect the printer. If the user plugs in the printer, the tablet can subsequently detect the printer and send the article to the printer. The embodiments described herein support LAN discovery mechanisms.

[0020] Another example use case is when a technician's UE has an application built into a piece of equipment that is designed to communicate with an application hosted on the UE. Since the equipment is not always reachable, the application on the technician's UE needs to be able to determine when the UE in the equipment is reachable. The embodiments described herein support being able to know whether a particular UE in the same 5G LAN set is reachable or not, regardless of whether the UE is roaming or not, based on operator policy and user permission.

[0021] In another example, local operators may want to operate devices in their vicinity rather than looking through a list of many (possibly thousands) of devices installed in the plant. The embodiments described herein support auto-discovery of 5G devices belonging to a predefined group, such as devices in the plant that are in the immediate vicinity (e.g., within a predefined radius) of the user, and provide the user with a list of all detected 5G devices. For example, a service technician with no prior knowledge of the plant may want to connect to a predefined device in their vicinity. However, due to obstacles in the plant, the device may not be directly accessible. Using the auto-discovery feature described herein, the device may be easily detected.

[0022] Another exemplary use case includes a plug-and-produce feature for field devices that allows the 5G system to easily connect devices to the 5G system. For example, constrained devices (such as battery-powered field devices) may not be delivered with 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.

[0023] Another example use case includes type-a network-PLMN interworking where a UE communicates simultaneously on a PLMN as well as within a type-a network, including service continuity when the UE moves from a PLMN to a type-a network. For example, a UE may be handed over from a PLMN to a type-a network in a factory when within range of the type-a network in the factory. The embodiments described herein support various handover scenarios.

[0024] The embodiments described herein may apply various enhancements made to 5G systems to support 5G LAN services. Examples of these enhancements include enhanced service exposure (e.g., information about the geographic location of the coverage areas of type-a / type-b networks) via Application Programming Interfaces (APIs) for third parties to use the functionality, support for type-b networks, support for UEs registered in both type-b networks and PLMNs, where the UE supports the credentials required for type-b networks and the credentials required for PLMNs and can maintain both registrations independently, support for type-a networks and interworking, roaming between public networks and type-a networks, and support for roaming, mobility, and service continuity between PLMNs and type-a networks (e.g., mobility from type-a networks to PLMNs) with direct interaction between type-a networks and PLMNs.

[0025] A type-a network may be uniquely identified by a combination of a PLMN identifier and a Type-A Network Identifier (TA-NID). The UE may be assumed to be configured with one or more tuples of PLMN identifiers and TA-NIDs corresponding to type-a networks for which the UE is authorized to register. Next Generation Radio Access Network (NG-RAN) nodes that support access to type-a networks may broadcast one or more tuples of PLMN identifiers and TA-NIDs to indicate to the UE which type-a networks are supported.

[0026] A type-b network may be identified by a Type-B Network Identifier (TB-NID). In a given region, the TB-NID may be centrally managed and assigned (and therefore considered unique in that region) or may be assigned by an individual type-b network operator (i.e., unmanaged and therefore not unique). Both allocation strategies may exist in the same region. It is assumed that the UE is configured with a TB-NID corresponding to the type-b network with which the UE is authorized to register.

[0027] NG-RAN nodes that support access to type-b networks may broadcast one or more TB-NIDs to indicate to the UE the type-b networks they support. The UE may automatically select and attempt to register on the type-a and type-b networks for which it is authorized and configured.

[0028] The 5G Globally Unique Temporary Identifier (5G-GUTI) may have the following structure: <5G-GUTI>:= <guami><5G-TMSI> Here, GUAMI identifies the assigned Access and Mobility Function (AMF), and 5G Temporary Mobile Subscriber Identity (5G-TMSI) uniquely identifies the UE within the AMF.

[0029] The Globally Unique AMF ID (GUAMI) may have the following structure: <guami> := <mcc> <mnc><AMF Region ID><AMF Set ID><AMF Pointer> Here, the AMF Area ID identifies the area, the AMF Set ID uniquely identifies the AMF set within the AMF area, and the AMF Pointer uniquely identifies an AMF within the AMF set. The AMF Area ID addresses the case where there are more AMFs in the network than can be supported by the AMF Set ID and AMF Pointer, by allowing operators to reuse the same AMF Set ID and AMF Pointer in different areas.

[0030] 5G-S-TMSI may be a shortened form of GUTI to enable more efficient over-the-air signaling procedures (e.g., during paging and service requests) and may be defined as follows: <5G-S-TMSI>:=<AMF Set ID><AMF Pointer> <5G-TMSI>

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

[0032] Handover procedures between 3GPP access networks are used to hand over a UE from a Source Radio Access Network (S-RAN) node to a Target RAN (T-RAN) node. The first type may be based on the availability of an Xn interface between the S-RAN node and the T-RAN node. If the Xn interface is not available, an N2-based handover may be performed in which the S-RAN node communicates a handover request to the target network via the source AMF. Handover between 3GPP access networks may be initiated by the RAN.

[0033] FIG. 1 is a diagram of an example procedure 50 for system information acquisition. In this example, UE 51 may acquire system information from NR(R)AN node 52. A MasterInformationBlock (MIB) is always sent by (R)AN node 52 and contains information that UE 51 uses to acquire SIB1 (step 53). SystemInformationBlockType1 (SIB1) is sent periodically and contains information such as scheduling information and availability information of other SIBs (step 54). A System Information Request (SI Request) may be used by UE 51 to request (R)AN node 52 to broadcast a specific SIB (step 55), which then transmits a SystemInformation message (step 56).

[0034] In a factory automation scenario or plug-and-produce scenario as described above, devices (e.g., sensors, actuators, and controllers) need to be provisioned to know which TA-NID (or TB-NID) to associate with. This can be problematic in scenarios where devices are purchased "off the shelf." If the device is packaged, the device manufacturer may have no way of knowing which TA-NID (or TB-NID) the device needs to be provisioned with. Thus, devices that often do not have a user interface need to have the TA-NID configured after initial purchase. Additionally, devices may need to be provisioned with subscriptions or certificates used to access the network.

[0035] When a UE decides to connect to a TA-NID or TB-NID, the UE needs to discover RAN nodes that can provide connectivity to the identified network. A potential solution is to have the RAN node broadcast the TA-NID or TB-NID to which it can provide access. However, this type of solution may be undesirable because broadcasting the TA-NID or TB-NID by the RAN node may be considered a security risk. Furthermore, periodic broadcasting of the TA-NID or TB-NID by the RAN node may add unnecessary overhead.

[0036] As mentioned above, a UE needs to be able to connect to a PLMN and a type-a network simultaneously. If the same RAN node is used to connect to both a PLMN and a type-a network, the UE needs to have two NAS connections, one for the AMF of each network.

[0037] As mentioned above, when connected to a network, a device must be able to discover other devices in the LAN and establish communications, and the network should be able to restrict the devices that can be discovered by a given device. For security and signaling efficiency, it is important that the network can effectively restrict the devices that can be discovered by a given device. Furthermore, it may not be desirable to allow a device to ascertain certain other devices in the network, and there is no need to allow a device to discover devices with which it is not authorized to establish a communications session.

[0038] As mentioned 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 determine that the UE 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.

[0039] 2 to 4 (described later in this specification) illustrate various embodiments associated with 3GPP Private LANs that enhance 5G networks to address the use cases described above. In these figures, various steps or operations are illustrated that are performed by one or more nodes, apparatuses, devices, servers, functions, or networks. For example, the apparatuses may operate alone or in combination with each other to realize the methods described herein. In this specification, the terms apparatus, network apparatus, node, server, device, entity, network function, and network node may be used interchangeably. It is understood that the nodes, devices, servers, functions, or networks illustrated 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 a memory of a node of such a network and executed on a processor of the node, which may constitute one of the architectures illustrated in FIG. 5A or FIG. 5B described later. That is, the methods illustrated in Figures 2 through 4 may be implemented in the form of software (e.g., computer-executable instructions) stored in a memory of a network node, such as the node or computer system illustrated in Figure 5C or Figure 5D, which may store computer-executable instructions that, when executed by a processor of the node, perform the steps illustrated in the figures and described herein. It is also understood that any transmission and reception steps illustrated in these figures may be performed by the node's communications circuitry (e.g., circuitry 34 or 97 of Figures 5C and 5D, respectively) under control of the node's processor and the computer-executable instructions (e.g., software) it executes. It is further understood that the nodes, devices, and functions described herein may be implemented as virtualized network functions.

[0040] A method and apparatus for securely connecting a device without pre-provisioned network credentials to a LAN is described herein. According to one embodiment, a device that is provisioned without local area network credentials at the time of manufacture may detect or discover the LAN, review an invitation to connect to the LAN, request a connection to the network, determine whether it is the network the device is supposed to connect to, and upon finding the correct network, receive a network credential. A LAN operator may use an API exposed by a Network Exposure Function (NEF) to provision the network with information about devices that are allowed to connect to the network. The network may use the provisioned information to broadcast an invitation for the device to connect to the network. The device may receive the invitation and request that the network broadcast additional information so that it can determine whether the device is the intended recipient of the invitation. Once the device has confirmed that it is the intended recipient of the invitation, the device may attempt to register with the network, and the network may authenticate and authorize the device using the device information provisioned by the network operator. The device may then be provisioned with a network credential.

[0041] According to another embodiment, the system may allow devices provisioned with LAN credentials to discover a LAN without requiring the RAN node(s) of the LAN to continually broadcast network identification information. This allows the UE to use the broadcast information to discover that a nearby RAN node may provide access to the LAN to which it wishes to connect. The (R)AN node may broadcast partial identification information (e.g., a combination of MCC, MNC, service identifier, operator identifier, network identifier, number, etc.). When the UE detects a RAN node broadcasting partial identification information corresponding to a network it wishes to associate with, it may decide to send a request to the (R)AN node to broadcast additional information about the network. The request may include an invitation tag that helps prove to the (R)AN node that the UE is authorized to associate with the network. When the UE determines that it may wish to connect to a LAN, the UE may present an identifier to the RAN node indicating that it has previously been invited to connect to the LAN. Upon receiving the identifier, the RAN node may broadcast the remaining part of the identification information, such as its network identifier.

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

[0043] According to another embodiment, a device may be provisioned with policies to recognize the types of devices it is permitted to detect and communicate with, which may allow the detection process to be more efficient. The policies may also help prevent the device from attempting to detect devices that it is not permitted to detect or communicate with. The device may filter detection requests received on a user interface to limit requests to the network to those that the policies indicate are acceptable.

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

[0045] 2 is a diagram of a LAN system 200 with a device credential panel according to one embodiment, which may be used in combination with any of the embodiments described herein. The LAN system 200 may be used to onboard devices that do not have pre-provisioned credentials, such as factory automation, home automation, and home security devices, onto a LAN, which may include, for example, a type-b network. In the example LAN system 200 of FIG. 2, a device that may not have been provisioned with LAN credentials at the time of manufacture may discover the LAN, review an invitation to connect to the LAN, request to connect to the LAN, determine if it is the LAN it is supposed to connect to, and if it finds it to be the correct network, receive the network credentials.

[0046] As shown in the example of FIG. 2, the UE 207 accesses the Access and Mobility Management Function (AMF) of the LAN (L-AMF 202) via the N1 interface 211 via the Radio Access Network ((R)AN) 208. The (R)AN 208 accesses the L-AMF 202 via the N2 interface 212. The (R)AN 208 accesses the User Plane Function (UPF) (L-UPF 209) of the LAN via the N3 interface 213. The L-UPF 209 accesses the Session Management Function (SMF) of the LAN (L-SMF) 203 via the N4 interface 214. The L-UPF 209 accesses the Data Network (DN) 210 via the N6 interface 215. The Policy Control Function (PCF) (L-PCF) 201 of the LAN accesses the L-AMF 202 via the N15 interface 219. The L-AMF 202 accesses the L-SMF 203 via an N11 interface 218. The L-SMF 203 accesses a Unified Data Management (UDM) (L-UDM 206a) of the LAN via an N10 interface 217.

[0047] The LAN's NEF (L-NEF 204) may expose an API via a Nnef interface 221 that allows an Application Function (AF) 205 to provision device credentials via a device credential portal 222 in the LAN's User Data Repository (UDR) (L-UDR 206b). The L-UDR 206b is accessed by the L-NEF 204 via a Nudr interface 220. This API may be referred to as the onBoard_Device API and is described further below.

[0048] A device (which in this example may include UE 207 of FIG. 2) may be marked or packaged with identification information. The identification information may include a device identifier (e.g., a Permanent Equipment Identifier (PEI)) and a Secret Device Identifier (SDI). The PEI and SDI may be in a well-known format. As described herein, well-known refers to values ​​that are standardized in a specification and known to be suitable for a connection to obtain network credentials. The identification information may also include an indication of the format of the PEI and SDI. The identification information may also include an invite request tag, which is further described below. The identification information may also include the type of device, service requirements (e.g., Ultra-Reliable Low Latency Communication (URLLC)), subscriptions, security certificates, security keys, etc.

[0049] Before a device (e.g., UE 207) is turned on for the first time and is within range of a type-b network, the network operator may provide the device's identification information to the network using the device credential portal 222. Note that there is an implicit assumption that the network has been provisioned with the device information before the device 207 is turned on for the first time. For example, the onBoard_Device API exposed by the L-NEF 204 may enable the device credential portal 222 (acting as the AF 205) to provide the device 27's identification information and a time to connect parameter to the network. The time to connect parameter may indicate the amount of time the device 207 is given to connect to the network or a time window when the device 207 is expected to connect. The onBoard_Device API may also be used to provide the network with geographical information used by the network to derive or determine which RAN node(s) 208 the device 207 is expected to initially connect to. Alternatively, the geographical information may include the identity of the candidate RAN node 208 to which the device 207 is expected to initially connect. It should also be noted that an API exposed by the L-NEF 204 may also allow the AF 205 to indicate that a given device or device type is not allowed to access the LAN at a particular time. The L-NEF 204 may deliver this information to the RAN node 208 directly or via the L-AMF 202 and its N2 interface 212.

[0050] Once the device information is provided to the network via its API and the current time is within the time to connect, the network may begin broadcasting invitation information to help determine whether the device 207 should attempt to connect to the network. If the network has geographic information of the device, this may be used to help determine the specific RAN node(s) 208 within the device's expected geographic area (e.g., tracking area) to which the invitation should be broadcast. The network's RAN node(s) 208 may broadcast the network's invitation information consisting of any combination of the following information: (1) An indication that the network is willing to accept a new device. This indication may further indicate that the network is willing to accept a device of a certain device type, or that requires a certain service, a certain QoS level, etc. This indication may be a reserved PLMN identifier. The device may receive an indication that the network is a LAN (e.g., a reserved network identifier) ​​and use this indication to determine whether to request that the RAN node 208 broadcast more information about the network (whether the network is willing to accept a device of a certain device type, a certain service, a certain QoS level, etc.). (2) The PEIs of devices that the network is willing to allow to connect. (3) The portion of the PEI that the network is willing to allow to connect to it. (4) PEI or any portion of PEI to which connection is not currently permitted or prohibited.

[0051] The RAN node 208 may broadcast the invitation information as part of a 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 a System Information (SI) message(s). If the invitation information is part of a System Information message(s), the device may send a System Information Request to the RAN node 208 to have the RAN node 208 broadcast the System Information message(s) for the device to receive. The System Information Request may include an indication that the device 207 wants to broadcast the invitation information and / or an invitation tag. The invitation tag may be a value used to help ensure that the RAN node 208 is responding to a device 207 that has been invited to connect to the network. For example, the invitation tag may be an identifier or device type that the device 207 was provisioned with at manufacture. This indication may also be transmitted as part of a second message of the initial random access procedure (i.e., a response from the RAN 208) over a Random Access Channel (RACH) between the device 207 and the RAN 208. Alternatively, the invitation tag may be a device identifier (e.g., the PEI of the device 207).

[0052] Alternatively, a paging channel may be defined that allows the network to page devices based on device identifiers and their format. A Core Network (CN) typically pages only connected / registered devices. However, in this scenario, the CN knows that it needs to contact the device 207 based on information provided through the portal. If the network is provided with the device 207's identification information and the current time is within the time to connection, the network may attempt to page the device 207 in the area specified by the geographic information. A page may be sent to the device 207 via a pre-configured paging opportunity, i.e., time-frequency resources and / or spatial information, even though the device 207 has not previously registered with the network. If a device 207 that has not previously registered with the network blind decodes its paging indication during the time window to connection and subsequently receives a paging message indicating the device 207's identifier and device identifier format, the device 207 may interpret the message as an invitation to connect.

[0053] When the device 207 turns on and network credentials have not been previously provisioned in the device 207 or the device 207 detects that there is no network for which it has provisioned credentials, the device 207 may begin reading the Master Information Block (MIB) or System Information Block 1 (SIB1) or other system information indicated in SIB1 for invitation information. Alternatively or additionally, the device 207 may send a system information request to the RAN node to cause the RAN to broadcast a system information message including the invitation information so that the device 207 can receive the invitation information. The system information request may include an invitation tag. When the device 207 receives the invitation information and verifies that the invitation includes an identifier for the device 207, the device 207 may request to connect to the network.

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

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

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

[0057] Once the network has authenticated and authorized the device 207, the network may provide the following information to the device 207 in a registration accept message: (1) A Locally Unique Temporary Identifier (LUTI), which may be considered unique within the LAN system 200. The LUTI may be treated like a GUTI by the device 207 when the device 207 is within the LAN system 200. However, the device 207 may not use the LUTI when connecting to other networks. (2) A Local Subscription Identifier (LSI), which may be the subscription identifier of the device 207 with the LAN system 200. When the device 207 is in the LAN system 200, it may be treated by the device 207 as a Subscription Permanent Identifier (SUPI). However, when the device 207 connects to any other network, the LSI may not be used. (3) security parameter(s) or certificate(s); (4) Network identifiers with which the device 207 should register. It is assumed that the credentials are associated with all network identifiers provided. The network identifiers may include, for example, PLMN identifiers, TA-NIDs, TB-NIDs, etc. These may be provided in a prioritized order.

[0058] Once the device 207 obtains credentials from an Authentication and Authorization (AA) server or from the L-UDM 206a or L-UDR 206b, the device 207 may de-register and may perform a new general registration using the credentials.

[0059] 3 is a diagram of an example procedure 300 for onboarding a device to a type-b network according to one embodiment that may be used in combination with any of the embodiments described herein. The example procedure 300 of FIG. 3 shows a device being provisioned with type-b network credentials.

[0060] 3, as described above, the onBoard_Device API may be used by the AF 307 to provision device credentials in the network via the onboard_Device_Request (step 311). The API may be used to provision the L-UDR 305 with information about one or more devices, including, but not limited to, identity information, time to connection, and geographic information.

[0061] The L-NEF 306 may use an L-UDR service, such as the Nudr_DM_Create service, to provision device credentials in the L-UDR 305 (step 312). At this time, the L-NEF 306 may distribute information to the AMF in the network so that the AMF can inform the RAN nodes what types of devices or device identities are allowed to connect to the network and so that the RAN nodes know what information to broadcast.

[0062] The L-UDR 305 may return a provisioning credential response indicating whether the provisioning was successful or not to the invocation of the Nudr_DM_Create service to the L-NEF 306 (step 313).

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

[0064] An initiating event in the UE 301 (which may be any of the devices described herein) causes the UE 301 to initiate an attempt to connect to a network without pre-provisioned network credentials (step 315). An example of an initiating event is the UE 301 powering on, a predefined sequence of the UE 301 powering on and off, human interaction with a user interface such as a button or GUI, or the UE 301 not detecting a network for which it has already been provisioned with network credentials.

[0065] The UE301 may start reading the MIB or SIB1 broadcasted from the (R)AN node 302, or other system information indicated by SIB1 (step 316). The UE301 may be pre-provisioned to search for some default information in the SIB or MIB information. For example, the UE301 may search for an indication that the network is providing a certain type of service. In another example, the UE301 may search for an indication that the network can provision the device with network credentials. The UE301 may also search for an indication that the network can accept a certain type of system information request (e.g., a system information request for the network to broadcast invitation information). The UE301 may search for a RAN node that is broadcasting the UE301's PEI or a portion of the UE301's PEI. Alternatively, the UE301 may search for a RAN node that is paging the UE301's PEI.

[0066] 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 an identification or an invitation tag of the UE 301. The system information request is a request for the network to broadcast information including, but not limited to: An indication that the network offers a given type of service; An indication that the network is capable of providing network credentials to the device; The PEI of the device inviting the connection, or any device associated with the invitation tag provided, and An indication that the network can invite the device to connect via paging.

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

[0068] 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.

[0069] L-AMF303 may invoke the Nudm_SDM_Get service to obtain the device credentials provided in step 311 by the onBoard_Device API (steps 320a, 320b, and 320c) via L-UDM304 and L-UDR305.

[0070] The L-AMF 303 may check that the device identifier is invited to connect and that the registration request is received within a time window, and then the L-AMF 303 may authenticate and authorize the UE 301 by issuing a challenge value to the UE 301 and checking that the response matches what is expected based on the UE 301's SDI (step 321). As mentioned above, if the UE 301 encrypted part of the general registration message, the L-AMF 303 may use the fact that the L-AMF 303 can decrypt the message as justification to authenticate and authorize the UE 301. Thus, this step may not require interaction with the UE 301.

[0071] Provided that the UE 301 is authenticated and authorized, the network may send a registration accept message to the UE 301 (step 322). The network may provide the device with information in the registration accept message, including, but not limited to, the following: (1)LUTI. (2) LSI. (3) security parameter(s) and certificate(s); (4) Network Identifier. The network identifier does not need to be provided to UE 301 in the registration accept message because UE 301 may obtain it from the MIB. Upon receiving the network credentials, UE 301 may store the network credentials and the network identifier for future attempts to connect to the network. (5) Other information that may assist UE 301 in detecting a LAN network, such as: (a) The operating parameters of a LAN network, e.g., downlink frequency, bandwidth, etc. (b) The geographic location of the RAN nodes that serve the LAN network. (c) Restricting access to a LAN network. For example, a LAN network may provide service only during normal business hours, from 8:00 a.m. to 5:00 p.m.

[0072] The UE 301 may send a registration complete message to the network indicating that the credentials have been successfully provisioned (step 323). The registration complete message may include an indication that the UE 301 will de-register and re-register with the network using the just provisioned credentials.

[0073] Alternatively, the UE301 may be provisioned with credentials via the user plane. For example, the network (L-AMF303) may authorize the UE301 to access only the default S-NSSAI used to gain access to the AA server when it receives the registration request in step 319. The registration accept message from the L-AMF303 sent during step 322 may provide the S-NSSAI to the UE301. The UE301 may then connect to the AA server to obtain the same information (e.g., LUTI, LSI, security key(s), certificate(s), and network identifier) ​​sent in the registration accept message of step 322 described above. Once the UE301 has obtained the credentials from the AA server, the UE301 may deregister and perform a new general registration using the credentials.

[0074] The device may perform LAN discovery according to another example that may be used in combination with any of the embodiments described herein. The device may discover a LAN for which it has already been provided with provisioned network credentials and information. In conventional systems, the device discovers a network by receiving a network ID (PLMN-ID) broadcast by a RAN node. This approach is not necessarily suitable for LANs, and it may not be desirable for the LAN to always broadcast a network identifier.

[0075] Alternatively, RAN nodes in a LAN may broadcast partial identity information about themselves. Examples of partial identity information may include a network identifier (e.g., MCC and MNC), an indication of network type (e.g., safety, industrial, private, home, vehicular, edge computing, etc.), etc.

[0076] When searching for a network to connect to, the device may receive partial identity information broadcast by a RAN node, and if the partial identity corresponds to a network it wishes to connect to, it may decide to check further to determine whether to attempt a connection. Examples of partial identity information may include any combination of MCC, MNC, service identifier, operator identifier, network identifier, number, etc.

[0077] When the device wants to check further for the network's identifier, it may send a system information request that includes an indication that it wants the RAN node to broadcast a system information message that includes details about the network. The additional details may be the complete network identifier, or parts of the network identifier, which when combined with information already received in the MIB or SIB may form the complete network identifier. The request from the UE to the RAN node may include information previously provisioned to the UE by the network, such as an invite tag.

[0078] 4 is a diagram of an example procedure 400 for network discovery that may be used in combination with any of the embodiments described herein. The procedure of FIG. 4 describes how steps 315-318 of FIG. 3 may be performed.

[0079] 4, the device may initiate a search for a network (step 410). The initiating event, or trigger, that causes the device to initiate a search for a network may be an indication from a user interface (e.g., a button or GUI), the UE entering a particular location, losing connectivity with a network, etc.

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

[0081] The device may receive broadcast information from the network and determine that the network may be one with which it wishes to associate (step 412). For example, the device may determine that the associated network operator is one with which it wishes to associate. If the broadcast information does not indicate a network operator with which the device wishes to associate, the device then returns to step 411. The device may further check other MIB or SIB information to determine what services the network offers, what types of devices should connect to the network, and / or whether it is willing to respond to system information requests for details of the services it offers.

[0082] The device may send a system information request to the network to inquire whether the network supports a particular service, device, etc. (step 413). The request may also be an indication or a request that the network should broadcast more identifying information about the network. The request may include an invitation tag or identifying information of the device so that the RAN node can determine whether the device should receive the additional information.

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

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

[0085] Alternatively, when the device detects a RAN node broadcasting a PLMN identifier with the same MCC and MNC as the LAN to which the device wishes to connect, the UE may register with the PLMN (via a general registration request in step 319 of FIG. 3 ), and the PLMN may provide the device with additional details of the LANs that can be reached through the same RAN node (via a general registration request in step 319 of FIG. 3 ). The LAN information provided to the UE may depend on the subscription information of the device. Once the device has obtained the additional information, it may then register with the LAN. The device may choose to re-register with the PLMN before registering with the LAN. 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 a NAS general registration accept message in step 322 of FIG. 3 . Alternatively, this information may be delivered to the UE by the RAN in an RRC message. When the RAN node provides the device with the information, the AMF may first provide the RAN node with information associated with the LANs to which the device is allowed to connect.

[0086] Before registering with a LAN, a device may want to check whether the LAN offers a particular service. The RAN node may broadcast an indication in the MOB or SIB that it supports a given service, or can broadcast an indication that it supports a particular service if requested. The device may then send a system information request to the RAN node to cause it to broadcast a system information message indicating what services the RAN can reach over the network. Based on the response from the RAN node, the device can decide whether to connect or not.

[0087] A device may connect to two AMFs via the same RAN node according to another example, which may be used in combination with any of the embodiments described herein. A single RAN node may be used by the device to reach both a 3GPP wide area cellular network and a 3GPP LAN. In such a scenario, the wide area cellular network and the LAN may be provided by different AMFs. In such a scenario, when the device is already connected to a LAN or PLMN and is attempting to register to the other network, the device may indicate to the RAN node that the registration request is a new registration request for the other network.

[0088] When the device attempts to register with the wide area cellular network or the other of the LAN, the device may provide an indication to the RAN 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 to the RAN that the request 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 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 LAN to which the UE is attempting to connect.

[0089] A LAN operator may have policies or rules associated with each user or group. The policies may be used to determine other devices that may be detected by the user or group. When the LAN receives a discovery request, the network may check whether the device is authorized to discover devices of the type indicated in the request, but it would be more efficient if the device knew in advance what types of devices it is authorized to discover to prevent issuing a request that is rejected. Thus, the LAN may include a PCF, which may send a discovery policy to the UE according to another example that may be used in combination with any of the embodiments described herein. The discovery policy may detail what types of devices are to be discovered, what device groups are to be discovered, what device identifiers are to be discovered. The policy may further indicate that a given device or service is discoverable, but that the device may not be authorized to communicate with it without performing additional request and authorization procedures with the network. The UE configuration update procedure for transparent UE policy delivery may be used to deliver the policy to the UE.

[0090] Once a discovery policy has been provided to a device, the device may display the policy information on a GUI so that a user of the device can view the devices, device types, or groups of devices that are allowed to be discovered.

[0091] Once a discovery policy is received, the UE may trigger a discovery request based on user input (e.g., from a GUI), based on receipt of the policy, or based on an application request. The discovery request may include an indication of what is to be discovered (e.g., devices, device types, groups of devices, etc.). The network may respond with a list of available devices.

[0092] When a device selects a discovered device to communicate with, the device may 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 may send a control plane message to the network requesting that the network send a trigger to the device. The trigger may include information on how the discovered device should contact the device.

[0093] As mentioned above, a PDN connection may need to move from a LAN to a PLMN or vice versa. For example, a device may have two PDN connections. The first PDN connection may be used to carry traffic from sensors, for example, located within the vehicle, and the second PDN connection may be used to carry traffic, for example, used for streaming audio and video. When the vehicle arrives at the factory, the first PDN connection associated with the sensor data may need to move to the LAN, while the second PDN connection may remain connected to the PLMN.

[0094] This type of handover, where some PDU sessions are handed over and some are not, is not currently supported in the NG-RAN inter-node N2-based handover procedure of the conventional system. In the NG-RAN inter-node N2-based handover procedure of the 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 a device moves towards or away from a LAN, only certain PDU sessions should be moved. To support moving only selected PDU sessions between the S-RAN and the T-RAN, the following enhancements to the handover procedure are described herein.

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

[0096] When the UE reports measurements to the S-RAN and the measurements relate to a T-RAN, i.e., a LAN, that should support only some of the UE's PDU sessions, the UE may report to the S-RAN that the T-RAN is a LAN network and may only support handover of certain PDU sessions. The UE may further indicate which PDU sessions may be moved to the T-RAN and which PDU sessions may not be moved to the T-RAN. The UE may know the identities of the LANs and T-RANs to which the PDU sessions may be handed over based on the SM policy received from the PCF.

[0097] When the PDU session is established, the SMF may report to the (R)AN node (via the AMF) in the N2 SM information that the PDU session is allowed to be handed over to the T-RAN, which is a LAN network. Furthermore, the N2 SM information may report the identity of the LAN(s) and associated T-RAN(s) to which the PDU session may be transferred.

[0098] An enhancement of the HANDOVER REQUESTED message is also described herein: The HANDOVER REQUESTED message from the S-RAN to the S-AMF may be enhanced to indicate to the S-AMF that only certain PDU sessions should be handed over (together with the PDU session IDs to be handed over).

[0099] The UE may know that a given PDU session may be moved to a LAN based on the SM policy provided by the PCF. The policy may further indicate whether the PDU session should be handed over to a specific LAN if possible or never to a wide area network (e.g., PLMN). The UE may provide the associated PDU session ID to the RAN so that the RAN can use this information when making a decision whether to handover the UE to the target RAN. The RAN may also use this information to decide whether to handover a given PDU session and terminate PDU sessions that are not eligible to be moved to the target RAN. The PDU sessions to be terminated may be indicated in a handover message to the T-RAN. The UE may also indicate that the PDU session should only be associated with a specific LAN when the PDU session is established. The SMF may then provide this information to the RAN node in the N2 SM information.

[0100] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular communication network technologies, including radio access, core transport networks, and service capabilities, including work on codecs, security, and quality of service. Recent Radio Access Technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), LTE-Advanced standards, and New Radio (NR), also known as "5G". Development of the 3GPP NR standard is expected to continue, including the definition of next-generation radio access technologies (New RATs). This 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. Flexible radio access consists of new radio access in new frequency bands below 7 GHz that are not backward compatible, and is expected to include different operating modes that may be multiplexed in the same frequency band to address a wide range of 3GPP NR use cases with different requirements. Ultra Mobile Broadband is expected to include cmWave and mmWave frequency bands that provide opportunities for ultra mobile broadband access, for example, indoor applications and hotspots. Ultra Mobile Broadband in particular is expected to share a common design framework with sub-7 GHz flexible wireless access, with cmWave and mmWave dedicated design optimizations.

[0101] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements in terms of data rates, latency, and mobility. Use cases include the following general categories: Enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communication (URLLC), Massive Machine Type Communications (mMTC), network operations (e.g., network slicing, routing, migration and interworking, energy saving), and Enhanced Vehicle-To-Everything (eV2X) communications, which may include any of Vehicle-To-Vehicle Communication (V2V), Vehicle-To-Infrastructure Communication (V2I), Vehicle-To-Network Communication (V2N), Vehicle-To-Pedestrian Communication (V2P), and vehicular communications with other entities. Specific services and applications in these categories include, for example, monitoring and sensor networks, remote control of devices, two-way remote control, personal cloud computing, video streaming, wireless cloud-based office, first responder connectivity, automotive emergency notification systems, disaster alerts, real-time gaming, multi-party video calling, autonomous driving, augmented reality, touch internet, virtual reality, home automation, robotics, and aerial drones, to name just a few. All of these and other use cases are contemplated herein.

[0102] 5A illustrates an example communication system 100 in which the systems, methods, and apparatus described and claimed herein may be used. The communication system 100 may include Wireless Transmit / Receive Units (WTRUs) 102a, 102b, 102c, 102d, 102e, 102f, and / or 102g (which may be referred to generally or collectively as WTRUs 102 or WTRUs 102). The communication system 100 may include a Radio Access Network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a Public Switched Telephone Network (PSTN) 108, the Internet 110, other networks 112, and network services 113. The network services 113 may include, for example, a V2X server, a V2X function, a ProSe server, a ProSe function, an IoT service, video streaming, and / or edge computing.

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

[0104] The communication system 100 may also include a base station 114a and a base station 114b. In the example of FIG. 5A, each base station 114a and 114b is illustrated as a single element. In practice, the base stations 114a and 114b may include any number of interconnected base stations and / or network elements. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, and 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or other networks 112. Similarly, the base station 114b may be any type of device configured to interface wired and / or wirelessly with at least one of the Remote Radio Heads (RRHs) 118a, 118b, the Transmission and Reception Points (TRPs) 119a, 119b, or the Roadside Units (RSUs) 120a, 120b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the other networks 112, and / or the network services 113. The RRHs 118a, 118b may be any type of device configured to interface wirelessly with at least one of the WTRUs 102, e.g., the WTRU 102c, to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, the network services 113, and / or the other networks 112.

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

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

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

[0108] The base station 114b may 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, which may be any suitable wired (e.g., cable, optical fiber, etc.) or wireless communication links (e.g., RF, microwave, IR, UV, visible light, centimeter wave, millimeter wave, etc.). The air interface 115b / 116b / 117b may be established using any suitable RAT.

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

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

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

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

[0113] The base station 114a and the WTRUs 102a, 102b, 102c, and 102g in the RAN 103 / 104 / 105, or the RRHs 118a and 118b, the TRPs 119a and 119b, and / or the RSUs 120a and 120b and the WTRUs 102c, 102d, 102e, and 102f in the RAN 103b / 104b / 105b may be compliant with any of the following standards: 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), and / or IEEE 802.16 (e.g., WiMAX (Worldwide Interoperability for Microwave Access ... 856 (IS-856), GSM (Global System for Mobile communication), EDGE (Enhanced Data rates for GSM Evolution), GERAN (GSM EDGE), and other wireless technologies may be implemented.

[0114] The base station 114c of FIG. 5A may be, for example, a wireless router, a Home NodeB, a Home eNodeB, or an access point, and may utilize any suitable RAT to facilitate wireless connectivity in a local area, such as an office, a home, a vehicle, a train, an airborne, a satellite, a manufacturing plant, a campus, etc. The base station 114c and the WTRU 102, e.g., the WTRU 102e, may implement a radio technology, such as IEEE 802.11, to establish a Wireless Local Area Network (WLAN). Similarly, the base station 114c and the WTRU 102, e.g., the WTRU 102d, may implement a radio technology, such as IEEE 802.15, to establish a Wireless Personal Area Network (WPAN). The base station 114c and the WTRU 102, e.g., the WRTU 102e, may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, NR, etc.) to establish a picocell or femtocell. 5A, the base station 114c may have a direct connection to the Internet 110. Thus, the base station 114c may not need to access the Internet 110 through the core network 106 / 107 / 109.

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

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

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

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

[0119] Although not shown in FIG. 5A, it will be appreciated that the user equipment may have 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 ideas contained herein may be applied to UEs that are WTRUs and UEs that connect to a network using a wired connection as well. For example, ideas that apply to the radio interfaces 115, 116, 117 and 115c / 116c / 117c may be applied to a wired connection as well.

[0120] FIG. 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 over the air interface 115. The RAN 103 may also be in communication with the core network 106. As shown in FIG. 5B, the RAN 103 may include Node Bs 140a, 140b, and 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node Bs 140a, 140b, and 140c may each be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node Bs and Radio Network Controllers (RNCs).

[0121] As shown in FIG. 5B, Node Bs 140a, 140b may communicate with RNC 142a. Additionally, Node B 140c may communicate with RNC 142b. Node Bs 140a, 140b, and 140c may communicate with their respective RNCs 142a, 142b via an Iub interface. RNCs 142a and 142b may communicate with each other via an Iur interface. Each of RNCs 142a, 142b may be configured to control the respective Node Bs 140a, 140b, and 140c to which it is connected. Additionally, each of RNCs 142a and 142b may be configured to perform or support other functionalities, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, and the like.

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

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

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

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

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

[0127] The RAN 104 may include eNodeBs 160a, 160b, and 160c, although it will be understood that the RAN 104 may include any number of eNodeBs. The eNodeBs 160a, 160b, and 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 116. For example, the eNodeBs 160a, 160b, and 160c may implement MIMO technology. Thus, the eNodeB 160a may transmit wireless signals to and receive wireless signals from the WTRU 102a, for example, using multiple antennas.

[0128] Each of the eNodeBs 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users on the uplink and / or downlink, etc. As shown in FIG. 5C, the eNodeBs 160a, 160b, and 160c may communicate with one another via an X2 interface.

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

[0130] The MME 162 may be connected to each of the eNodeBs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may function as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, and 102c, activating / deactivating bearers, selecting a particular serving gateway during initial attachment of the WTRUs 102a, 102b, and 102c, etc. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies, such as GSM or WCDMA.

[0131] The serving gateway 164 may be connected to each of the eNodeBs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, and 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during eNodeB handover, triggering paging when downlink data is available at the WTRUs 102a, 102b, and 102c, and managing and storing the context of the WTRUs 102a, 102b, and 102c.

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

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

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

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

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

[0137] Each of the g Node 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 on the uplink and / or downlink, etc. As shown in FIG. 5D, the g Node Bs 180a and 180b may communicate with each other, for example, via an Xn interface.

[0138] The core network 109 shown in FIG. 5D may be a 5G Core Network (5GC). The core network 109 may provide a number of communication services to customers interconnected by a radio access network. The core network 109 is composed of a number of entities that perform the functionality of a core network. As used herein, the term "core network entity" or "network function" refers to any entity that performs one or more functionality of a core network. It is understood that such a core network entity may be a logical entity implemented in the form of computer-executable instructions (software) stored in a memory and executed on a processor of a device or computer system configured for wireless and / or network communication, such as that of the system 90 illustrated in FIG. 5G.

[0139] In the example of Figure 5D, the 5G core network 109 may include an Access and Mobility Management Function (AMF) 172, a Session Management Function (SMF) 174, a User Plane Function (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 illustrated as part of the 5G core network 109, it will be understood that any one of these elements may be owned and / or operated by an entity other than the core network operator. It will also be understood that the 5G core network may not be comprised of all of these elements, may be comprised of additional elements, and may be comprised of multiple instances of each of these elements. Although Figure 5D shows the network functions directly connected to each other, it should be understood that they may communicate through a routing agent, such as a diameter routing agent or a message bus.

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

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

[0142] The SMF 174 may be connected to the AMF 172 via an N11 interface. Similarly, the SMF may be connected to the PCF 184 via an N7 interface and to the UPFs 176a and 176b via an N4 interface. The SMF 174 may function as a control node. For example, the SMF 174 may be responsible for session management, allocation of IP addresses 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.

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

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

[0145] The PCF 184 may be connected to the SMF 174 via an N7 interface, to the AMF 172 via an N15 interface, and to an Application Function (AF) 188 via an N5 interface. The N15 and N5 interfaces are not shown in FIG. 5D. The PCF 184 may provide policy rules to control plane nodes, such as the AMF 172 and the SMF 174, so that the control plane nodes can enforce these rules. The PCF 184 may send policies to the AMF 172 for the WTRUs 102a, 102b, and 102c, so that the AMF can distribute the policies to the WTRUs 102a, 102b, and 102c via the N1 interface. The policies may then be enforced or applied at the WTRUs 102a, 102b, and 102c.

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

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

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

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

[0150] The application functions 188 may interact with network functions of the 5G core network 109. The interaction between the application functions 188 and the network functions may be via a direct interface or may occur via the NEF 196. The application functions 188 may be considered part of the 5G core network 109 or may be external to the 5G core network 109 and deployed by companies that have business relationships with the mobile network operators.

[0151] 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. It involves "slicing" the core network into one or more virtual networks to support different service types running across different RANs or across a single RAN. Network slicing allows operators to create networks that are tailored to provide optimal solutions for different market scenarios with diverse requirements for functionality, performance, and isolation.

[0152] 3GPP is designing the 5G core network to support network slicing. Network slicing is a great tool that network operators can use to support a diverse set of 5G use cases with very diverse and sometimes extreme requirements (e.g., massive IoT, critical communications, V2X, and enhanced mobile broadband). Without network slicing technology, the network architecture may not be flexible and scalable enough to efficiently support a wider range of use cases, where each use case has its own set of performance, scalability, and availability requirements. In addition, the introduction of new network services should be more efficient.

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

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

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

[0156] 5E illustrates an example communication system 111 in which systems, methods, and apparatus as 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 road side units (RSUs) 123a and 123b. In practice, the concepts presented herein may apply to any number of WTRUs, base stations gNBs, V2X networks, and / or other network elements. One or some or all of WTRUs A, B, C, D, E, and F may be outside the range of access network coverage 131. WTRUs A, B, and C form a V2X group, of which WTRU A is the group lead and WTRUs B and C are group members.

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

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

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

[0160] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a Digital Signal Processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, other types of Integrated Circuits (ICs), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although FIG. 5F illustrates the processor 118 and the transceiver 120 as separate components, it will be understood that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

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

[0162] 5F as a single element, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

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

[0164] The processor 118 of the WTRU 102 may be coupled to and may receive user input data from a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a Liquid Crystal Display (LCD) display unit or an Organic Light-Emitting Diode (OLED) display unit). The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. Furthermore, 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 a Random-Access Memory (RAM), a Read-Only Memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 132 may include a Subscriber Identity Module (SIM) card, a memory stick, a Secure Digital (SD) memory card, etc. The processor 118 may access information from and store data in memory that is not physically located in the WTRU 102, such as on a server hosted on a cloud or edge computing platform or on a home computer (not shown).

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

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

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

[0168] The WTRU 102 may be included within other apparatus or devices, such as sensors, appliances, wearable devices such as a smart watch or smart wear, medical or electronic health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or planes, etc. The WTRU 102 may connect to other components, modules, or systems of such apparatus or devices via one or more interconnection interfaces, such as an interconnection interface that may constitute one of the peripherals 138.

[0169] FIG. 5G is a block diagram of an exemplary computing system 90, which may be embodied in one or more devices of the communications networks shown in FIGS. 5A, 5C, 5D, and 5E, in the RAN 103 / 104 / 105, the core network 106 / 107 / 109, the PSTN 108, the Internet 110, other networks 112, or particular nodes or functional entities in the network services 113, etc. The computing system 90 may be comprised of computers or servers and may be controlled primarily by computer-readable instructions, which may be in the form of software or wherever such software is stored or accessed by whatever means. 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 special purpose processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, other types of integrated circuits (ICs), a state machine, etc. The processor 91 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the computing system 90 to operate in a telecommunications network. The coprocessor 81 is an optional processor that is distinct from the main processor 91 and may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0170] In operation, the processor 91 fetches, decodes, and executes instructions and transfers information to and from other resources via a system bus 80, which is the computing system's primary data transfer path. Such a system bus connects components within 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 operating the system bus. One example of such a system bus 80 is a Peripheral Component Interconnect (PCI) bus.

[0171] The memories coupled to the system bus 80 include a Random Access Memory (RAM) 82 and a Read Only Memory (ROM) 93. Such memories include circuits that can store and retrieve information. The ROM 93 generally includes stored data that cannot be easily altered. Data stored in the RAM 82 can be read or altered by the processor 91 or other hardware devices. Access to the RAM 82 and / or the ROM 93 may be controlled by a memory controller 92. The memory controller 92 may provide an address translation function that converts virtual addresses to physical addresses when instructions are executed. The memory controller 92 may also provide a memory protection function that separates processes in the system and separates system processes from user processes. Thus, a program running in the first mode may only access memory mapped by the virtual address space of its process and cannot access memory in the virtual address space of another process unless memory sharing between the processes is set up.

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

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

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

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

Claims

1. 1. An apparatus comprising a processor, a memory, and communication circuitry, the apparatus coupled to a network via the communication circuitry, the apparatus further comprising computer-executable instructions stored in the memory of the apparatus, the computer-executable instructions, when executed by the processor of the apparatus, causing the apparatus to: receiving a first broadcast message from a private Local Area Network (LAN) in which a first identity associated with the device is provisioned, the first broadcast message including an invitation to connect to the private LAN and the first identity; transmitting a first message based on the first broadcast message including the first identification information, the first message including a request for system information and a second identification information associated with the device; receiving a second broadcast message from the private LAN that includes the requested system information; and sending a second message including a registration request and a third identification associated with the device based on the requested system information; receiving a third message from the private LAN indicating acceptance of the registration request; and An apparatus for causing an operation including

2. 2. The apparatus of claim 1, wherein the first identification information includes at least one of a device identifier, a device type, a portion of a device identifier, a Permanent Equipment Identifier (PEI), a portion of a PEI, and a Secret Device Identifier (SDI).

3. The apparatus of claim 2 , wherein the second identification information comprises the first identification information.

4. The apparatus of claim 1 , wherein the second identification information comprises an invitation tag.

5. The device of claim 4 , wherein the invitation tag comprises a value provisioned within the device.

6. The device of claim 5 , wherein the invitation tag is a Persistent Equipment Identifier (PEI) associated with the device or a portion of a PEI associated with the device.

7. The apparatus of claim 2 , wherein the third identification information comprises the first identification information.

8. The apparatus of claim 1 , wherein the third identification information comprises a Persistent Equipment Identifier (PEI).

9. The apparatus of claim 1 , wherein the third identification information comprises a secret device identifier (SDI).

10. The apparatus of claim 1 , wherein the third identification information includes a Persistent Equipment Identifier (PEI) and a Secret Device Identifier (SDI).

11. The apparatus of claim 1 , wherein the invitation indicates that the private LAN accepts registrations, that the network can provision credentials to devices, or that the network can accept system information requests of a predetermined type.

12. The apparatus of claim 1 , wherein the invitation includes an identification associated with a device that is not authorized to connect to the private LAN.

13. The apparatus of claim 1 , wherein the invitation includes an identification associated with a device type that is not permitted to connect to the private LAN.

14. The apparatus of claim 1 , wherein the invitation is included in a Master Information Block (MIB) or a System Information Block (SIB).

15. The apparatus of claim 1 , wherein the second message is encrypted.

16. The apparatus of claim 1 , wherein the third message includes network credentials.

17. 17. The apparatus of claim 16, wherein the network credentials include at least one of a Locally Unique Temporary Identifier (LUTI), a Local Subscription Identifier (LSI), a security parameter, a security certificate, and a network identifier.

18. 20. The apparatus of claim 17, wherein the network identifier comprises at least one of a Public Land Mobile Network (PLMN) identifier, a Type-A Network Identifier (TA-NID), or a Type-B Network Identifier (TB-NID).

19. 20. The apparatus of claim 18, wherein the at least one of a Public Land Mobile Network (PLMN) Identifier, a Type-a Network Identifier (TA-NID), or a Type-b Network Identifier (TB-NID) is associated with a priority.

20. 2. The apparatus of claim 1, wherein the third message includes an indication of Single-Network Slice Selection Assistance Information (S-NSSAI) to enable receiving network credentials.

21. and computer-executable instructions stored in a memory of the device, the computer-executable instructions, when executed by the processor of the device, causing the device to: receiving network credentials from a server associated with the S-NSSAI; The apparatus of claim 20 further comprising the steps of:

22. 22. The apparatus of claim 21, wherein the network credentials include at least one of a Locally Unique Temporary Identifier (LUTI), a Local Subscription Identifier (LSI), a security parameter, a security certificate, and a network identifier.

23. 23. The apparatus of claim 22, wherein the network identifier comprises at least one of a public land mobile network (PLMN) identifier, a type-a network identifier (TA-NID), or a type-b network identifier (TB-NID).

24. 24. The apparatus of claim 23, wherein the at least one of a Public Land Mobile Network (PLMN) Identifier, a Type-a Network Identifier (TA-NID), or a Type-b Network Identifier (TB-NID) is associated with a priority.

25. 2. The apparatus of claim 1, wherein the private LAN is provisioned with a first identity via an Application Function (AF) that invokes an Application Programming Interface (API) exposed by a Network Exposure Function (NEF).

26. The apparatus of claim 1 , wherein the first broadcast message or the second broadcast message is received on a paging channel.

27. The device further comprises computer-executable instructions stored in the memory of the device, the computer-executable instructions, when executed by the processor of the device, causing the device to: receiving a third broadcast message from the private LAN, the third broadcast message including an identification associated with the private LAN; transmitting a fourth message based on the third broadcast message including the identification information associated with the private LAN, the fourth message including a second request for system information and the second identification information; receiving a fourth broadcast message from the private LAN that includes the requested system information; and sending a fifth message to connect the device to the private LAN based on the requested system information; and The apparatus of claim 1 , further comprising:

28. 30. The apparatus of claim 27, wherein the identification information associated with the private LAN partially identifies the private LAN and includes a Mobile Country Code (MCC), a Mobile Network Code (MNC), a service identifier, an operator identifier, a network identifier, or a number.

29. 28. The device of claim 27, wherein the identification information associated with the private LAN was provided to the device in the third message.

30. The apparatus of claim 1 , wherein the apparatus comprises a wireless communication device.

31. The apparatus of claim 1 , wherein the apparatus comprises User Equipment (UE).

32. The apparatus of claim 1 , wherein the apparatus comprises a computing device.

33. The device of claim 1 , wherein the device comprises a smartphone.

34. The apparatus of claim 1 , wherein the apparatus comprises a gateway.

35. receiving a first broadcast message from a private Local Area Network (LAN) in which a first identity associated with a device is provisioned, the first broadcast message including an invitation to connect to the private LAN and the first identity; transmitting a first message based on the first broadcast message including the first identification information, the first message including a request for system information and a second identification information associated with the device; receiving a second broadcast message from the private LAN that includes the requested system information; and sending a second message including a registration request and a third identification associated with the device based on the requested system information; receiving a third message from the private LAN indicating acceptance of the registration request; and A method comprising:

Images