CN116830793A - Small base station configuration and control in 5G networks - Google Patents

Abstract

A computer-readable storage medium stores instructions for execution by one or more processors of an evolved residential gateway (eRG). The instructions configure eRG to operate and control in a 5G NR network and cause eRG to perform operations. The operations include establishing a communication link from a residential radio access station (PRAS) to an application server of a 5G NR network. The profile of the PRAS received from the application server via the communication link is decoded. The registration of PRAS to the 5G NR network is performed based on the profile. The profile is encoded for transmission to PRAS. The profile includes PRAS configuration information. Data received from the PRAS is encoded for retransmission to the application server based on the PRAS configuration information.

Description

Small base station configuration and control in 5G networks

Priority statement

The present application claims the benefit of priority from the following U.S. provisional patent applications:

U.S. provisional patent application No. 63/159,931 entitled "ENABLING SMALL BASE STATION FOR OPERATION AND CONTROL BY A G NETWORK" filed on day 3 and 11 of 2021;

U.S. provisional patent application No. 63/168,734 entitled "TRIGGERING REMOTE PROVISIONING FOR SMALL BASE STATION FOR OPERATION AND CONTROL BY A G NETWORK" filed on 3/31/2021; and

U.S. provisional patent application No. 63/177,312 entitled "METHODS OF CONFIGURING SMALL BASE STATION AS INTEGRATED ACCESS AND BACKHAUL (IAB) NODE FOR OPERATION AND CONTROL BY A G NETWORK" filed on 4/20/2021.

Each of the patent applications listed above is incorporated herein by reference in its entirety.

Technical Field

Aspects relate to wireless communications. Some aspects relate to wireless networks, including 3GPP (Third Generation Partnership Project ) networks, 3GPP LTE (Long Term Evolution, long term evolution) networks, 3GPP LTE-A (LTE Advanced) networks, (MulteFire, LTE-U), and fifth generation (5G) networks and beyond, including 5G New Radio (NR) (or 5G NR) networks, 5G-LTE networks, such as 5G NR unlicensed spectrum (NR unlicensed spectrum, NR-U) networks, and other unlicensed networks, including Wi-Fi, CBRS (OnGo), and the like. Other aspects are directed to techniques to configure and enable small base stations for operation and control by 5G NR (and above) networks. For example, the disclosed techniques may be used to configure a small base station as an integrated access and backhaul (Integrated Access and Backhaul, IAB) node for operation and control by a 5G network.

Background

Mobile communications have evolved greatly from early voice systems to today's highly sophisticated integrated communication platforms. With the increase of different types of devices communicating with various network devices, the use of 3GPP LTE systems has increased. Penetration of mobile devices (user equipment or UEs) in contemporary society continues to drive the need for a wide variety of networking devices in many different environments. Fifth generation (5G) wireless systems are forthcoming and are expected to enable even higher speeds, connectivity and availability. The next generation 5G network (or NR network) is expected to increase throughput, coverage and robustness and reduce latency and operating and infrastructure costs. The 5G-NR network will continue to evolve on the basis of 3GPP LTE advanced and there are additional potential new radio access technologies (radio access technology, RATs) to enrich people's lives by providing a fast, rich content and service seamless wireless connectivity solution. As current cellular network frequencies are saturated, higher frequencies, such as millimeter wave (mmWave) frequencies, may be beneficial due to their high bandwidth.

Potential LTE operations in unlicensed spectrum include (but are not limited to): LTE operation in unlicensed spectrum via dual connectivity (dual connectivity, DC), or DC-based LAA; and a stand-alone LTE system in unlicensed spectrum, according to which LTE-based technology operates only in unlicensed spectrum, without requiring "anchoring" in licensed spectrum, known as multewire. Further enhanced operation of LTE and NR systems in licensed spectrum as well as unlicensed spectrum is expected in future releases and 5G (and above) systems. Such enhanced operation may include techniques to configure and enable small base stations for operation and control by 5G NR (and above) networks.

Drawings

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings generally illustrate by way of example, and not by way of limitation, various aspects discussed in the present document.

Fig. 1A illustrates an architecture of a network, according to some aspects.

Fig. 1B and 1C illustrate a non-roaming 5G system architecture, according to some aspects.

Fig. 2, 3, and 4 illustrate various systems, devices, and components that may implement aspects of the disclosed embodiments.

FIG. 5 illustrates a reference diagram of an IAB architecture, according to some aspects.

Fig. 6 illustrates Central Unit (CU) -Distributed Unit (DU) splitting and signaling in an IAB architecture, according to some aspects.

Fig. 7 illustrates a Customer Premise Network (CPN) using a Premise Radio Access Station (PRAS) configured for communication with a 5G network, in accordance with some aspects.

Fig. 8 illustrates a high level procedure that enables an off-the-shelf PRAS connected to eRG for operation and control by a 5G network, according to some aspects.

Fig. 9 illustrates a high level procedure of configuring eRG as a gateway UE for PRAS registration, according to some aspects.

Fig. 10 illustrates a high level procedure of configuring eRG to invoke Remote Provisioning Procedure (RPP) for PRAS, according to some aspects.

Fig. 11 illustrates PRAS operation configuration and provisioning procedures in the case where PRAS and eRG have 3GPP subscriptions from the same HPLMN provided by the same network operator, according to some aspects.

Fig. 12 illustrates UDM-initiated PRAS configuration updates, according to some aspects.

Fig. 13 illustrates configuration functionality when HPLMN triggered PRAS operation grant revocation (non-roaming), according to some aspects.

Fig. 14 illustrates PRAS operation grant revocation (roaming) triggered by VPLMN configuration functionality in accordance with some aspects.

Fig. 15 illustrates the overall architecture of the gNB, errg, and PRAS, according to some aspects.

Fig. 16 illustrates the overall architecture of an IAB with eRG and PRAS, according to some aspects.

Fig. 17 illustrates the overall architecture of eRG and PRAS as IAB nodes, according to some aspects.

Fig. 18 illustrates a block diagram of a communication device, such as an evolved node B (eNB), a next generation node B (gNB) (or another RAN node or base station), a transmit-receive point (TRP), an Access Point (AP), a wireless Station (STA), a Mobile Station (MS), or a User Equipment (UE), in accordance with some aspects.

Detailed Description

The following description and the drawings fully illustrate the aspects to enable those skilled in the art to practice them. Other aspects may involve structural, logical, electrical, procedural, and other changes. Portions and features of some aspects may be included in, or substituted for, those of others. The aspects outlined in the claims cover all available equivalents of those claims.

Fig. 1A illustrates an architecture of a network, according to some aspects. Network 140A is shown to include User Equipment (UE) 101 and UE 102. The UEs 101 and 102 are shown as smart phones (e.g., handheld touch screen mobile computing devices connectable to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as personal data assistants (Personal Data Assistant, PDAs), pagers, laptop computers, desktop computers, wireless handsets, drones, or any other computing device including wired and/or wireless communication interfaces. The UEs 101 and 102 may be collectively referred to herein as UE 101, and UE 101 may be configured to perform one or more of the techniques disclosed herein.

Any of the radio links described herein (e.g., for use in network 140A or any other illustrated network) may operate in accordance with any of the exemplary radio communication techniques and/or standards.

LTE and LTE advanced are standards for wireless communication of high-speed data for UEs such as mobile phones. In LTE-advanced and various wireless systems, carrier aggregation is one such technique: according to this technique, multiple carrier signals operating on different frequencies may be used to carry communications for a single UE, thereby increasing the bandwidth available to a single device. In some aspects, carrier aggregation may be used where one or more component carriers operate on unlicensed frequencies.

Aspects described herein may be used in the context of any spectrum management scheme, including, for example, dedicated licensed spectrum, unlicensed spectrum, (licensed) shared spectrum (e.g., licensed shared access (Licensed Shared Access, LSA) in 2.3-2.4GHz, 3.4-3.6GHz, 3.6-3.8GHz, and more frequencies, and spectrum access systems (Spectrum Access System, SAS) in 3.55-3.7GHz and more frequencies).

Aspects described herein may also be applied to different single carrier or OFDM forms (CP-OFDM, SC-FDMA, SC-OFDM, filter bank-based multicarrier, FBMC), OFDMA, etc.) and in particular 3GPP NR (New Radio) by allocating OFDM carrier data bit vectors to corresponding symbol resources.

In some aspects, either of the UEs 101 and 102 may include an internet of things (Internet of Things, ioT) UE or a cellular IoT (CIoT) UE, which may include a network access layer designed for low power IoT applications that utilize short term UE connections. In some aspects, either of the UEs 101 and 102 may include Narrowband (NB) IoT UEs (e.g., enhanced NB-IoT (eNB-IoT) UEs and further enhanced (FeNB-IoT) UEs). IoT UEs may utilize technologies such as machine-to-machine (M2M) or machine-to-Machine (MTC) communication to exchange data with MTC servers or devices via public land mobile networks (public land mobile network, PLMNs), proximity-Based services (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine initiated data exchange. IoT networks include interconnecting IoT UEs with short-term connections, which may include uniquely identifiable embedded computing devices (within the internet infrastructure). The IoT UE may execute a background application (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

In some aspects, either of the UEs 101 and 102 may include an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

The UEs 101 and 102 may be configured to connect, e.g., communicatively couple, with a radio access network (radio access network, RAN) 110. RAN 110 may be, for example, a universal mobile telecommunications system (Universal Mobile Telecommunications System, UMTS), an evolved universal terrestrial radio access network (Evolved Universal Terrestrial Radio Access Network, E-UTRAN), a next generation RAN (NextGen RAN, NG RAN), or some other type of RAN. The UEs 101 and 102 utilize connections 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in more detail below); in this example, connections 103 and 104 are shown as air interfaces to enable communicative coupling, and may conform to cellular communication protocols, such as the Global System for Mobile communications (Global System for Mobile Communications, GSM) protocol, code division multiple Access (code-division multiple access, CDMA) network protocol, push-to-Talk (PTT) protocol, cellular PTT (PTT over Cellular, POC) protocol, universal mobile telecommunications system (Universal Mobile Telecommunications System, UMTS) protocol, 3GPP Long Term Evolution (LTE) protocol, fifth generation (5G) protocol, new Radio (NR) protocol, and so forth.

In an aspect, the UEs 101 and 102 may also exchange communication data directly via the ProSe interface 105. ProSe interface 105 may alternatively be referred to as a side link interface including one or more logical channels, including, but not limited to, a physical side link control channel (Physical Sidelink Control Channel, PSCCH), a physical side link shared channel (Physical Sidelink Shared Channel, PSSCH), a physical side link discovery channel (Physical Sidelink Discovery Channel, PSDCH), and a physical side link broadcast channel (Physical Sidelink Broadcast Channel, PSBCH).

UE 102 is shown configured to access an Access Point (AP) 106 via a connection 107. Connection 107 may comprise a local wireless connection, such as a connection conforming to any IEEE 802.11 protocol, according to which AP 106 may comprise a wireless fidelity (wireless fidelity,) And a router. In this example, the AP 106 is shown connected to the internet, rather than to the core network of the wireless system (described in more detail below).

RAN 110 may include one or more access nodes that enable connections 103 and 104. These Access Nodes (ANs) may be referred to as Base Stations (BSs), nodebs, evolved nodebs (enbs), next generation nodebs (gnbs), RAN network nodes, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a certain geographic area (e.g., cell). In some aspects, communication nodes 111 and 112 may be transmission/reception points (TRPs). In the case where the communication nodes 111 and 112 are nodebs (e.g., enbs or gnbs), one or more TRPs may operate within the communication cell of the NodeB. RAN 110 may include one or more RAN nodes, such as macro RAN node 111, for providing macro cells and one or more RAN nodes, such as Low Power (LP) RAN node 112 or unlicensed spectrum based secondary RAN node 112, for providing femto cells or pico cells (e.g., cells with smaller coverage area, smaller user capacity, or higher bandwidth than macro cells).

Either of the RAN nodes 111 and 112 may terminate the air interface protocol and may be the first point of contact for the UEs 101 and 102. In some aspects, any of RAN nodes 111 and 112 may perform various logical functions for RAN 110 including, but not limited to, radio network controller (radio network controller, RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling, and mobility management. In one example, any of nodes 111 and/or 112 may be a new generation node B (gNB), an evolved node B (eNB), or another type of RAN node.

RAN 110 is shown communicatively coupled to a Core Network (CN) 120 via an S1 interface 113. In an aspect, the CN 120 may be an evolved packet core (evolved packet core, EPC) network, a next generation packet core (NextGen Packet Core, NPC) network, or some other type of CN (e.g., as shown with reference to fig. 1B-1C). In this aspect, the S1 interface 113 is split into two parts: an S1-U interface 114 that carries user traffic data between RAN nodes 111 and 112 and serving gateway (S-GW) 122, and an S1 mobility management entity (mobility management entity, MME) interface 115 that is a signaling interface between RAN nodes 111 and 112 and MME 121.

In this aspect, the CN 120 includes an MME 121, an S-GW 122, a packet data network (Packet Data Network, PDN) gateway (P-GW) 123, and a home subscriber server (home subscriber server, HSS) 124.MME 121 may be similar in function to the control plane of a legacy serving general packet radio service (General Packet Radio Service, GPRS) support node (Serving GPRS Support Node, SGSN). MME 121 may manage mobility aspects in the access such as gateway selection and tracking area list management. HSS124 may include a database for network users including subscription-related information to support the handling of communication sessions by network entities. The CN 120 may include one or several HSS124 depending on the number of mobile subscribers, the capacity of the device, the organization of the network, etc. For example, HSS124 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location compliance, and so on.

S-GW 122 may terminate S1 interface 113 towards RAN 110 and route data packets between RAN 110 and CN 120. Further, S-GW 122 may be a local mobility anchor point for inter-RAN node handover and may also provide anchoring for inter-3 GPP mobility. Other responsibilities of S-GW 122 may include lawful interception, charging, and some policy enforcement.

The P-GW 123 may terminate the SGi interface towards the PDN. The P-GW 123 may route data packets between the EPC network 120 and external networks, such as a network that includes an application server 184 (alternatively referred to as an application function (application function, AF)), via an Internet Protocol (IP) interface 125. The P-GW 123 may also communicate data to other external networks 131A, which may include the internet, IP multimedia subsystem (IP multimedia subsystem, IPs) networks, and others. In general, the application server 184 may be an element that provides an application (e.g., a UMTS Packet Service (PS) domain, an LTE PS data Service, etc.) that uses IP bearer resources with the core network. In this aspect, P-GW 123 is shown communicatively coupled to application server 184 via IP interface 125. The application server 184 may also be configured to support one or more communication services (e.g., voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UEs 101 and 102 via the CN 120.

The P-GW 123 may also be a node for policy enforcement and charging data collection. Policy and charging rules function (Policy and Charging Rules Function, PCRF) 126 is a policy and charging control element of CN 120. In a non-roaming scenario, in some aspects, there may be a single PCRF in the home public land mobile network (Home Public Land Mobile Network, HPLMN) associated with an internet protocol connectivity access network (Internet Protocol Connectivity Access Network, IP-CAN) session of the UE. In a roaming scenario with local bursts of traffic, there may be two PCRFs associated with the IP-CAN session of the UE: a Home PCRF (H-PCRF) within the HPLMN, and a Visited PCRF (V-PCRF) within the Visited public land mobile network (Visited Public Land Mobile Network, VPLMN). PCRF 126 may be communicatively coupled to application server 184 via P-GW 123.

In some aspects, the communication network 140A may be an IoT network or a 5G network, including a 5G new radio network that uses communication in licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current contributors to IoT is the narrowband-IoT (NB-IoT).

The NG system architecture may include RAN 110 and 5G network core (5G network core,5GC) 120.NG-RAN 110 may include multiple nodes, such as a gNB and a NG-eNB. The core network 120 (e.g., a 5G core network or 5 GC) may include access and mobility functions (access and mobility function, AMF) and/or user plane functions (user plane function, UPF). The AMF and UPF may be communicatively coupled to the gNB and the NG-eNB via an NG interface. More specifically, in some aspects, the gNB and NG-eNB may connect to the AMF over a NG-C interface and to the UPF over a NG-U interface. The gNB and NG-eNB may be coupled to each other via an Xn interface.

In some aspects, the NG system architecture may use reference points between various nodes as specified by 3GPP technical specifications (Technical Specification, TS) 23.501 (e.g., V15.4.0, 2018-12). In some aspects, each of the gNB and NG-eNB may be implemented as a base station, a mobile edge server, a small cell, a home eNB, a RAN network node, and so on. In some aspects, the gNB may be a Master Node (MN) in a 5G architecture, and the NG-eNB may be a Secondary Node (SN). In some aspects, the primary node may operate in a licensed frequency band and the secondary node may operate in an unlicensed frequency band.

Fig. 1B illustrates a non-roaming 5G system architecture, according to some aspects. Referring to FIG. 1B, a 5G system architecture 140B is illustrated in terms of reference points. More specifically, UE 102 may communicate with RAN 110 and one or more other 5G core (5 GC) network entities. The 5G system architecture 140B includes a plurality of Network Functions (NF), such as an access and mobility management function (access and mobility management function, AMF) 132, a location management function (location management function, LMF) 133, a session management function (session management function, SMF) 136, a policy control function (policy control function, PCF) 148, an application function (application function, AF) 150, a user plane function (user plane function, UPF) 134, a network slice selection function (network slice selection function, NSSF) 142, an authentication server function (authentication server function, AUSF) 144, and a Unified Data Management (UDM)/home subscriber server (home subscriber server, HSS) 146. The UPF 134 may provide a connection to a Data Network (DN) 152, which may include, for example, operator services, internet access, or third party services. The AMF 132 may be used to manage access control and mobility and may also include network slice selection functionality. The SMF 136 may be configured to set up and manage various sessions according to network policies. The UPF 134 can be deployed in one or more configurations depending on the type of service desired. PCF 148 may be configured to provide a policy framework (similar to PCRF in 4G communication systems) with network slicing, mobility management, and roaming. The UDM may be configured to store subscriber profiles and data (similar to HSS in a 4G communication system).

LMF 133 may be used in connection with the 5G location function. In some aspects, the LMF 133 receives measurement and assistance information from the next generation radio access network (next generation radio access network, NG-RAN) 110 and the mobile device (e.g., UE 101) via the AMF 132 over the NLs interface to calculate the location of the UE 101. In some aspects, NR positioning protocol a (NR positioning protocol A, NRPPa) may be used to carry positioning information between NG-RAN and LMF 133 over a next generation control plane interface (NG-C). In some aspects, the LMF 133 configures the UE via the AMF 132 using an LTE positioning protocol (LTE positioning protocol, LPP). NG RAN 110 configures UE 101 using a radio resource control (radio resource control, RRC) protocol over the LTE-Uu and NR-Uu interfaces.

In some aspects, the 5G system architecture 140B configures different reference signals to enable positioning measurements. Example reference signals that may be used for positioning measurements include positioning reference signals in the downlink (positioning reference signal, NR PRS) and sounding reference signals for positioning in the uplink (sounding reference signal, SRS). The downlink Positioning Reference Signal (PRS) is a reference signal configured to support a downlink-based positioning method.

In some aspects, the 5G system architecture 140B includes an IP multimedia subsystem (IP multimedia subsystem, IMS) 168B and a plurality of IP multimedia core network subsystem entities, such as call session control functions (IP multimedia subsystem, CSCFs). More specifically, the IMS168B includes a CSCF that may act as a proxy CSCF (P-CSCF) 162BE, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not shown in FIG. 1B), or an interrogating CSCF (I-CSCF) 166B. P-CSCF 162B may be configured as a first point of contact for UE 102 within IM Subsystem (IMs) 168B. S-CSCF 164B may be configured to handle session states in the network and E-CSCF may be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. I-CSCF 166B may be configured to act as a point of contact within an operator's network for all IMS connections intended for subscribers of the network operator or roaming subscribers currently located within the service area of the network operator. In some aspects, I-CSCF 166B may be connected to another IP multimedia network 170E, such as an IMS operated by a different network operator.

In some aspects, the UDM/HSS146 may be coupled to an application server 160E, which may include a telephony application server (telephony application server, TAS) or another application server (application server, AS). AS160B may be coupled to IMS168B via S-CSCF 164B or I-CSCF 166B.

The reference point representation indicates that interactions may exist between corresponding NF services. For example, fig. 1B illustrates the following reference points: n1 (between UE 102 and AMF 132), N2 (between RAN 110 and AMF 132), N3 (between RAN 110 and UPF 134), N4 (between SMF136 and UPF 134), N5 (between PCF 148 and AF 150, not shown), N6 (between UPF 134 and DN 152), N7 (between SMF136 and PCF 148, not shown), N8 (between UDM146 and AMF132, not shown), N9 (between two UPF 134, not shown), N10 (between UDM146 and SMF136, not shown), N11 (between AMF132 and SMF 136), N12 (between AUSF144 and AMF132, not shown), N13 (between AUSF144 and UDM146, not shown), N14 (between PCF 132, not shown), N15 (between PCF 148 and AMF132 in a non-roaming scenario, or between AMF132 and N16, and nsf 142 (between AMF 142, not shown), and N15 (between AMF132, not shown) in a non-roaming scenario. Other reference point representations not shown in fig. 1B may also be used.

FIG. 1C illustrates a 5G system architecture 140C and service-based representation. In addition to the network entities shown in fig. 1B, the system architecture 140C may also include a network exposure function (network exposure function, NEF) 154 and a network warehouse function (network repository function, NRF) 156. In some aspects, the 5G system architecture may be service-based, and interactions between network functions may be represented by respective point-to-point reference points Ni or as service-based interfaces.

In some aspects, as shown in fig. 1C, the service-based representation may be used to represent network functions within the control plane that enable other authorized network functions to access their services. In this regard, 5G system architecture 140C may include the following service-based interfaces: namf158H (service-based interface presented by AMF 132), nspf 158I (service-based interface presented by SMF 136), nnef 158B (service-based interface presented by NEF 154), npcf 158D (service-based interface presented by PCF 148), nudm 158E (service-based interface presented by UDM 146), naf 158F (service-based interface presented by AF 150), nnrf 158C (service-based interface presented by NRF 156), nnssf 158A (service-based interface presented by NSSF 142), nausf 158G (service-based interface presented by AUSF 144). Other service-based interfaces not shown in fig. 1C (e.g., nudr, N5g-eir, and Nudsf) may also be used.

Fig. 2, 3, and 4 illustrate various systems, devices, and components that may implement aspects of the disclosed embodiments in different communication systems (e.g., 5G-NR (and above) networks). The UE, base station (e.g., the gNB), and/or other nodes discussed in connection with fig. 1A-4 (e.g., satellite or other NTN nodes) may be configured to perform the disclosed techniques.

Fig. 2 illustrates a network 200 in accordance with various embodiments. Network 200 may operate in a manner consistent with the 3GPP technical specifications of LTE or 5G/NR systems. However, the example embodiments are not limited thereto and the described embodiments may be applied to other networks that benefit from the principles described herein, such as future 3GPP systems, and the like.

Network 200 may include a UE 202, which may include any mobile or non-mobile computing device designed to communicate with RAN 204 via an over-the-air connection. The UE 202 may be, but is not limited to being, a smart phone, tablet computer, wearable computing device, desktop computer, laptop computer, in-vehicle infotainment device, in-vehicle entertainment device, dashboard, heads-up display device, in-vehicle diagnostic device, dashboard mobile device, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine type communication device, M2M or D2D device, ioT device, etc.

In some embodiments, the network 200 may include a plurality of UEs that are directly coupled to each other via a side link interface. The UE may be an M2M/D2D device that communicates using a physical side link channel, such as, but not limited to PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.

In some embodiments, UE 202 may also communicate with AP 206 via an over-the-air connection. The AP 206 may manage WLAN connections that may be used to offload some/all network traffic from the RAN 204. The connection between the UE 202 and the AP 206 may conform to any IEEE 802.11 protocol, where the AP 206 may be wireless fidelityAnd a router. In some embodiments, the UE 202, RAN 204, and AP 206 may utilize cellular-WLAN aggregation (e.g., LWA/LWIP). cellular-WLAN aggregation may involve the UE 202 being configured by the RAN 204 to utilize both cellular radio resources and WLAN resources.

RAN 204 may include one or more access nodes, e.g., access Node (AN) 208.AN 208 may terminate the air interface protocol for UE 202 by providing access plane protocols including RRC, packet data convergence protocol (Packet Data Convergence Protocol, PDCP), radio link control (Radio Link Control, RLC), MAC, and L1 protocols. In this way, the AN 208 may enable data/voice connectivity between the Core Network (CN) 220 and the UE 202. In some embodiments, the AN 208 may be implemented in a separate device or as one or more software entities running on a server computer as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. AN 208 is referred to as BS, gNB, RAN node, eNB, ng-eNB, nodeB, RSU, TRxP, TRP, etc. The AN 208 may be a macrocell base station or a low power base station for providing a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than the macrocell.

In embodiments where the RAN 204 includes multiple ANs, they may be coupled to each other via AN X2 interface (if the RAN 204 is AN LTE RAN) or AN Xn interface (if the RAN 204 is a 5G RAN). The X2/Xn interface (which may be separated into control/user plane interfaces in some embodiments) may allow the AN to communicate information related to handoff, data/context transfer, mobility, load management, interference coordination, and so on.

The ANs of the RAN 204 may each manage one or more cells, cell groups, component carriers, etc. to provide the air interface for network access to the UE 202. The UE 202 may be connected to multiple cells provided by the same or different ANs of the RAN 204 at the same time. For example, the UE 202 and RAN 204 may use carrier aggregation to allow the UE 202 to connect with multiple component carriers, each component carrier corresponding to one Pcell or Scell. In a dual connectivity scenario, the first AN may be a primary node providing AN MCG and the second AN may be a secondary node providing AN SCG. The first/second AN may be any combination of eNB, gNB, ng-enbs, etc.

RAN 204 may provide the air interface over licensed spectrum or unlicensed spectrum. To operate in unlicensed spectrum, a node may use CA technology based LAA, eLAA, and/or feLAA mechanisms with PCell/Scell. Prior to accessing the unlicensed spectrum, the node may perform medium/carrier sense operations based on, for example, listen-before-talk (LBT) protocols.

In a V2X scenario, the UE 202 or AN 208 may be or act as a roadside unit (RSU), which may refer to any traffic infrastructure entity for V2X communications. The RSU may be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by a UE may be referred to as a "UE-type RSU"; an RSU implemented in or by an eNB may be referred to as an "eNB-type RSU"; an RSU implemented in or by a gNB may be referred to as a "gNB-type RSU"; etc. In one example, the RSU is a computing device coupled with a roadside-located radio frequency circuit that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic flow statistics, media, and applications/software to sense and control ongoing vehicle and pedestrian traffic flow. The RSU may provide extremely low latency communications required for high speed events such as collision avoidance, traffic alerts, and the like. Additionally, or alternatively, the RSU may provide other cellular/WLAN communication services. The components of the RSU may be enclosed in a weather-proof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., ethernet) to a traffic flow signal controller or a backhaul network.

In some embodiments, the RAN 204 may be an LTE RAN 210 with an eNB, e.g., eNB 212. The LTE RAN 210 may provide an LTE air interface with the following characteristics: subcarrier spacing (SCS) of 15 kHz; a CP-OFDM waveform for Downlink (DL) and an SC-FDMA waveform for Uplink (UL); turbo coding for data and TBCCs for control; etc. The LTE air interface can rely on the CSI-RS for CSI acquisition and beam management; PDSCH/PDCCH demodulation by means of PDSCH/PDCCH DMRS; and rely on CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operate in the frequency band below 6 GHz.

In some embodiments, RAN 204 may be a NG-RAN 214 with a gNB, e.g., gNB 216, or a NG-RAN 214 with a NG-eNB, e.g., NG-eNB 218. The gNB 216 may connect with 5G enabled UEs using a 5G NR interface. The gNB 216 may connect with the 5G core through a NG interface, which may include an N2 interface or an N3 interface. The NG-eNB 218 may also connect with the 5G core over the NG interface, but may connect with the UE via the LTE air interface. The gNB 216 and the ng-eNB 218 may be connected via an Xn interface.

In some embodiments, the NG interface may be split into two parts, one being a NG user plane (NG-U) interface that carries traffic data between the node of NG-RAN 214 and UPF 248 (e.g., an N3 interface), and the other being a NG control plane (NG-C) interface that is a signaling interface between the node of NG-RAN 214 and AMF 244 (e.g., an N2 interface).

The NG-RAN 214 may provide a 5G-NR air interface with the following characteristics: a variable SCS; CP-OFDM for DL, CP-OFDM for UL and DFT-s-OFDM; polar codes for control, repetition codes, simplex codes, and Reed-Muller codes, and LDPC codes for data. The 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS, similar to the LTE air interface. The 5G-NR air interface may not use CRS but may use PBCH DMRS for PBCH demodulation; PTRS is used for phase tracking of PDSCH and tracking reference signal is used for time tracking. The 5G-NR air interface may operate on an FR1 band including a band below 6GHz or an FR2 band including a band from 24.25GHz to 52.6 GHz. The 5G-NR air interface may include synchronization signals and physical broadcast channel (synchronization signal and physical broadcast channel, SS/PBCH) blocks (SSB), which is a region of a downlink resource grid including PSS/SSs/PBCH.

In some embodiments, the 5G-NR air interface may utilize BWP (bandwidth part) for various purposes. For example, BWP may be used for dynamic adaptation of SCS. For example, UE 202 may be configured with multiple BWP, where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 202, the SCS of the transmission is also changed. Another example of use of BWP relates to power saving. In particular, the UE 202 may be configured with multiple BWPs having different amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. BWP containing a smaller number of PRBs may be used for data transmission with small traffic load while allowing power saving at UE 202 and in some cases at gNB 216. BWP containing a larger number of PRBs may be used for scenarios with higher traffic load.

RAN 204 is communicatively coupled with CN 220, which includes network elements to provide various functions to support data and telecommunications services to clients/subscribers (e.g., users of UE 202). The components of the CN 220 may be implemented in one physical node or in a separate physical node. In some embodiments, NFV may be utilized to virtualize any or all of the functionality provided by the network elements of CN 220 onto physical computing/storage resources in servers, switches, and the like. The logical instantiation of the CN 220 may be referred to as a network slice, and the logical instantiation of a portion of the CN 220 may be referred to as a network sub-slice.

In some embodiments, CN 220 may be connected to the LTE radio network as part of an enhanced packet system (Enhanced Packet System, EPS) 222, which may also be referred to as EPC (or enhanced packet core). EPC 222 may include MME 224, SGW 226, SGSN 228, HSS230, PGW 232, and PCRF 234, which are coupled to each other through interfaces (or "reference points"), as shown. The function of the elements of EPC 222 may be briefly described as follows.

The MME 224 may implement mobility management functions to track the current location of the UE 202 to facilitate paging, bearer activation/deactivation, handover, gateway selection, authentication, and so forth.

SGW 226 may terminate the S1 interface towards the RAN and route data packets between the RAN and EPC 222. SGW 226 may be a local mobility anchor point for inter-RAN node handover and may also provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful interception, charging, and some policy enforcement.

The SGSN 228 may track the location of the UE 202 and perform security functions and access control. Furthermore, SGSN 228 may perform EPC inter-node signaling for mobility between different RAT networks; select PDN and S-GW as specified by MME 224; selecting an MME for handover; etc. The S3 reference point between MME 224 and SGSN 228 may be an inter-3 GPP access network mobility-enabled user and bearer information exchange in an idle/active state.

HSS230 may include a database for network users including subscription-related information to support the handling of communication sessions by network entities. HSS230 may provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location compliance, and so on. The S6a reference point between HSS230 and MME 224 may enable the transfer of subscription and authentication data to authenticate/authorize user access to LTE CN 220.

PGW 232 may terminate an SGi interface towards a Data Network (DN) 236, which may include an application/content server 238.PGW 232 may route data packets between LTE CN 220 and data network 236. PGW 232 may be coupled with SGW 226 through an S5 reference point to facilitate user plane tunneling and tunnel management. PGW 232 may also include nodes (e.g., PCEFs) for policy enforcement and charging data collection. Furthermore, the SGi reference point between PGW 232 and data network 236 may be an external public, private PDN of the operator or an intra-operator packet data network, e.g. for provisioning of IMS services. PGW 232 may be coupled with PCRF 234 via a Gx reference point.

PCRF 234 is a policy and charging control element of LTE CN 220. PCRF 234 may be communicatively coupled with application/content server 238 to determine appropriate QoS and charging parameters for the service flows. PCRF 234 may provision the associated rules into a PCEF with the appropriate TFTs and QCIs (via Gx reference points).

In some embodiments, CN 220 may be 5gc 240. The 5gc 240 may include AUSF 242, AMF 244, SMF 246, UPF 248, NSSF 250, NEF 252, NRF 254, PCF 256, UDM 258, and AF 260, coupled to each other through interfaces (or "reference points"), as shown. The function of the elements of the 5gc 240 may be briefly described as follows.

AUSF 242 may store data for authentication of UE 202 and handle authentication related functions. AUSF 242 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5gc 240 through a reference point as shown, the AUSF 242 may also present a Nausf service-based interface.

AMF 244 may allow other functions of 5gc 240 to communicate with UE 202 and RAN 204 and subscribe to notifications regarding mobility events for UE 202. AMF 244 may be responsible for registration management (e.g., for registering UE 202), connection management, reachability management, mobility management, lawful interception of AMF related events, and access authentication and authorization. AMF 244 may provide transport for SM messages between UE 402 and SMF 246 and act as a transparent proxy for routing SM messages. AMF 244 may also provide transmission for SMS messages between UE 202 and SMSF. AMF 244 may interact with AUSF 242 and UE 202 to perform various security anchoring and context management functions. Furthermore, AMF 244 may be an end point of the RAN CP interface, which may include or may be an N2 reference point between RAN 204 and AMF 244; and AMF 244 may be the termination point for NAS (N1) signaling and perform NAS encryption and integrity protection. AMF 244 may also support NAS signaling with UE 202 over the N3IWF interface.

The SMF 246 may be responsible for SM (e.g., session establishment, tunnel management between UPF 248 and AN 208); UE IP address assignment and management (including optional authorization); selection and control of the UP function; configuring traffic manipulation at the UPF 248 to route traffic to the appropriate destination; terminating the interface facing the strategy control function; policy enforcement, charging, and QoS control; lawful interception (for SM events and interfaces to LI systems); terminating the SM portion of the NAS message; downlink data notification; initiate AN specific SM information sent to AN 208 over N2 via AMF 244; and determining the SSC mode of the session. SM may refer to the management of PDU sessions, while PDU sessions or "sessions" may refer to PDU connectivity services that provide or enable the exchange of PDUs between UE 202 and data network 236.

UPF 248 may serve as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected to data network 236, and a branching point to support multi-homing PDU sessions. UPF 248 may also perform packet routing and forwarding, perform packet inspection, perform policy rules user plane part, lawful interception packets (UP collection), perform traffic usage reporting, perform QoS treatment for the user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF to QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. The UPF 248 may include an uplink classifier to support routing traffic flows to the data network.

NSSF 250 may select a set of network slice instances to serve UE 202. NSSF 250 may also determine the allowed NSSAI and the mapping to subscribed S-NSSAI, if desired. NSSF 250 may also determine the set of AMFs, or list of candidate AMFs, to be used to serve UE 202 based on the appropriate configuration and possibly by querying NRF 254. The selection of a set of network slice instances for UE 202 may be triggered by AMF 244 with which UE 202 registers by interacting with NSSF 250, which may result in a change in AMF. NSSF 250 may interact with AMF 244 via an N22 reference point; and may communicate with another NSSF in the visited network via an N31 reference point (not shown). Furthermore, NSSF 250 may present an Nnssf service-based interface.

NEF 252 may securely expose services and capabilities provided by 3GPP network functions for third parties, internal exposure/re-exposure, AF (e.g., AF 260), edge computing or fog computing systems, and so forth. In such embodiments, NEF 252 may authenticate, authorize or throttle AF. The NEF 252 may also translate information exchanged with the AF 260 and information exchanged with internal network functions. For example, the NEF 252 may translate between an AF service identifier and internal 5GC information. The NEF 252 may also receive information from other NFs based on their exposed capabilities. This information may be stored as structured data at NEF 252 or at data store NF using a standardized interface. The stored information may then be re-exposed by NEF 252 to other NF and AF, or used for other purposes, such as resolution. Furthermore, NEF 252 may present an Nnef service-based interface.

NRF 254 may support a service discovery function, receive NF discovery requests from NF instances, and provide information of the discovered NF instances to the NF instances. NRF 254 also maintains information about available NF instances and the services it supports. As used herein, the term "instantiation" and the like may refer to the creation of an instance, and "instance" may refer to a specific occurrence of an object, which may occur, for example, during execution of program code. Furthermore, NRF 254 may exhibit an Nnrf service-based interface.

PCF 256 may provide policy rules to control plane functions to enforce them and may also support a unified policy framework to constrain network behavior. PCF 256 may also implement a front end to access subscription information related to policy decisions in the UDR of UDM 258. In addition to communicating with functions through reference points as shown, PCF 256 may also present an Npcf service-based interface.

The UDM 258 may handle subscription related information to support handling of communication sessions by network entities, and may store subscription data for the UE 202. For example, subscription data may be communicated via an N8 reference point between UDM 258 and AMF 244. UDM 258 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for UDM 258 and PCF 256, and/or store structured data and application data for exposure for NEF 252 (including PFD for application detection, application request information for multiple UEs 202). The Nudr service-based interface may be exposed by the UDR to allow UDM 258, PCF 256, and NEF 252 access to a particular set of stored data, as well as notifications of relevant data changes in read, update (e.g., add, modify), delete, and subscribe to the UDR. The UDM may include a UDM-FE that is responsible for handling credentials, location management, subscription management, and so forth. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs through reference points as shown, the UDM 258 may also present a Nudm service-based interface.

The AF 260 may provide application impact on traffic routing, provide access to the NEF, and interact with the policy framework for policy control.

In some embodiments, the 5gc 240 may enable edge computation by selecting an operator/third party service to be geographically close to the point where the UE 202 attaches to the network. This may reduce latency and load on the network. To provide edge computing implementations, the 5gc 240 may select the UPF 248 close to the UE 202 and perform traffic manipulation from the UPF 248 to the data network 236 via the N6 interface. This may be based on the UE subscription data, the UE location, and information provided by AF 260. Thus, AF 260 may affect UPF (re) selection and traffic routing. Based on the operator deployment, the network operator may allow the AF 260 to interact directly with the associated NF when the AF 260 is considered a trusted entity. Further, AF 260 may present a Naf service-based interface.

The data network 236 may represent various network operator services, internet access, or third party services, which may be provided by one or more servers, including, for example, an application/content server 238.

Fig. 3 schematically illustrates a wireless network 300 in accordance with various embodiments. The wireless network 300 may include a UE 302 in wireless communication with AN 304. The UE 302 and the AN 304 may be similar to, and substantially interchangeable with, similarly-named components described elsewhere herein.

UE 302 may be communicatively coupled with AN 304 via connection 306. Connection 306 is illustrated as an air interface to enable communicative coupling and may conform to a cellular communication protocol, such as the LTE protocol or the 5G NR protocol operating at frequencies below mmWave or 6 GHz.

UE 302 may include a host platform 308 coupled with a modem platform 310. Host platform 308 may include application processing circuitry 312, which may be coupled with protocol processing circuitry 314 of modem platform 310. The application processing circuitry 312 may run various applications that source/sink application data for the UE 302. The application processing circuitry 312 may further implement one or more layer operations to send and receive application data to and from the data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

Protocol processing circuitry 314 may implement one or more layers of operations to facilitate sending or receiving data over connection 306. Layer operations implemented by the protocol processing circuitry 314 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.

Modem platform 310 may also include digital baseband circuitry 316, which may implement one or more layer operations in the network protocol stack that are "lower" than the layer operations performed by protocol processing circuitry 314. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/demapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding (which may include one or more of space-time, space-frequency, or space coding), reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

Modem platform 310 may also include transmit circuitry 318, receive circuitry 320, RF circuitry 322, and RF front end (RFFE) 324, which may include or be connected to one or more antenna panels 326. Briefly, the transmit circuitry 318 may include digital-to-analog converters, mixers, intermediate Frequency (IF) components, and the like; the receive circuitry 320 may include digital-to-analog converters, mixers, intermediate Frequency (IF) components, and the like; the radio frequency circuitry 322 may include low noise amplifiers, power tracking components, and the like; RFFE 324 may include filters (e.g., surface/bulk acoustic wave filters), switches, antenna tuners, beam forming components (e.g., phased array antenna components), and so forth. The selection and arrangement of the components of the transmit circuitry 318, receive circuitry 320, RF circuitry 322, RFFE 324, and antenna panel 326 (commonly referred to as "transmit/receive components") may depend on the specifics of the particular implementation, e.g., whether the communication is TDM or FDM, frequencies below mmWave or 6GHz, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be arranged in the same or different chips/modules, and so on.

In some embodiments, protocol processing circuitry 314 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.

UE reception may be established by and via antenna panel 326, RFFE 324, RF circuitry 322, receive circuitry 320, digital baseband circuitry 316, and protocol processing circuitry 314. In some embodiments, the antenna panel 326 may receive transmissions from the AN 304 through receive beamformed signals received by multiple antennas/antenna elements of one or more antenna panels 326.

UE transmissions may be established by and via protocol processing circuitry 314, digital baseband circuitry 316, transmit circuitry 318, RF circuitry 522, RFFE 324, and antenna panel 326. In some embodiments, the transmit component of the UE 302 may apply a spatial filter to the data to be transmitted to form a transmit beam that is transmitted by the antenna elements of the antenna panel 326.

Similar to UE 302, AN 304 may include a host platform 328 coupled with a modem platform 330. Host platform 328 may include application processing circuitry 332 coupled with protocol processing circuitry 334 of modem platform 330. The modem platform may also include digital baseband circuitry 336, transmit circuitry 338, receive circuitry 340, RF circuitry 342, RFFE circuitry 344, and antenna panels 346. The components of AN 304 may be similar to similarly named components of UE 302 and are substantially interchangeable. In addition to performing data transmission/reception as described above, the components of the AN 304 may perform various logic functions including, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.

Fig. 4 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methods discussed herein, according to some example embodiments. In particular, FIG. 4 shows a diagrammatic representation of hardware resources 400, including one or more processors (or processor cores) 410, one or more memory/storage devices 420, and one or more communication resources 430, each of which may be communicatively coupled via a bus 440 or other interface circuitry. For embodiments that utilize node virtualization (e.g., NFV), hypervisor (hypervisor) 402 may be executed to provide an execution environment for one or more network slices/sub-slices utilizing hardware resources 400.

Processor 410 may include, for example, processor 412 and processor 414. The processor 410 may be, for example, a central processing unit (central processing unit, CPU), a reduced instruction set computing (reduced instruction set computing, RISC) processor, a complex instruction set computing (complex instruction set computing, CISC) processor, a graphics processing unit (graphics processing unit, GPU), DSP, ASIC, FPGA such as a baseband processor, a radio-frequency integrated circuit (radio-frequency integrated circuit, RFIC), another processor (including those discussed herein), or any suitable combination of these.

Memory/storage 420 may include main memory, disk storage, or any suitable combination of these. Memory/storage 420 may include, but is not limited to, any type of volatile, nonvolatile, or semi-volatile memory, such as dynamic random access memory (dynamic random access memory, DRAM), static random access memory (static random access memory, SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (electrically erasable programmable read-only memory), flash memory, solid state storage, and the like.

Communication resources 430 may include an interconnection or network interface controller, component, or other suitable device to communicate with one or more peripheral devices 404 or one or more databases 406 or other network elements via network 408. For example, communication resources 430 may include wired communication components (e.g., for coupling via USB, ethernet, etc.), cellular communication components, NFC components, and so forth,(or low energy consumption->) Assembly (S)>Components, and other communication components.

The instructions 450 may include software, programs, applications, applets, apps, or other executable code for causing at least any one of the processors 410 to perform any one or more of the methods discussed herein. The instructions 450 may reside, completely or partially, within at least one of the processors 410 (e.g., within a cache memory of the processor), within the memory/storage device 420, or any suitable combination of these. Further, any portion of instructions 450 may be transferred from any combination of peripherals 404 or databases 406 to hardware resource 400. Accordingly, the memory of the processor 410, the memory/storage device 420, the peripherals 404, and the database 406 are examples of computer readable and machine readable media.

For one or more embodiments, at least one of the components outlined in one or more of the foregoing figures may be configured to perform one or more of the operations, techniques, procedures, and/or methods outlined in the example section that follows. For example, baseband circuitry associated with one or more of the foregoing figures may be configured to operate in accordance with one or more examples set forth below. As another example, circuitry associated with a UE, base station, satellite, network element, etc., described above in connection with one or more of the preceding figures, can be configured to operate in accordance with one or more of the examples set forth in the examples section below.

The term "application" may refer to a complete, deployable packaging environment for implementing a function in an operating environment. The term "AI/ML application" or similar terms may be an application that contains some artificial intelligence (artificial intelligence, AI)/Machine Learning (ML) model and application level description. In some embodiments, an AI/ML application can be used to configure or implement one or more of the disclosed aspects.

The term "machine learning" or "ML" refers to the use of a computer system implementing algorithms and/or statistical models to perform a particular task(s), without the use of explicit instructions, but rather relies on patterns and reasoning. The ML algorithm builds or estimates mathematical model(s) (referred to as "ML model" or the like) based on sample data (referred to as "training data", "model training information" or the like) to make predictions or decisions without being explicitly programmed to perform such tasks. Generally, an ML algorithm is a computer program that learns from experience with a certain task and a certain performance metric, and an ML model may be an object or data structure created after training the ML algorithm with one or more training data sets. After training, the ML model can be used to make predictions on the new dataset. Although the term "ML algorithm" refers to a different concept than the term "ML model", these terms may be used interchangeably for the purposes of this disclosure as described herein.

The terms "machine learning model", "ML model" or similar terms may also refer to ML methods and concepts used by ML-assisted solutions. An "ML-assisted solution" is a solution that uses an ML algorithm to solve a particular use case during operation. The ML model includes supervised learning (e.g., linear regression, K-nearest neighbor (KNN), decision tree algorithms, support machine vectors, bayesian algorithms, lumped algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal component analysis (principal component analysis, PCA), etc.), reinforcement learning (e.g., Q-learning, multi-arm robbery learning, deep RL, etc.), neural networks, and the like. Depending on the implementation, a particular ML model may have many sub-models as components, and the ML model may train all sub-models together. During reasoning, separately trained ML models can also be chained together in the ML pipeline. An "ML pipeline" is a set of functions, or functional entities that depend on an ML auxiliary solution; the ML pipeline may include one or several of a data source in a data pipeline, a model training pipeline, a model evaluation pipeline, and an actor. An "actor" is an entity that uses the output of ML model reasoning to host ML auxiliary solutions. The term "ML training host" refers to an entity, such as a network function, that hosts model training. The term "ML inference host" refers to an entity, such as a network function, that hosts a model during an inference mode (which includes both model execution and any online learning (if applicable)). The ML host informs the actor of the output of the ML algorithm and the actor makes a decision for the action (the "action" is performed by the actor as a result of the output of the ML assistance solution). The term "model inference information" refers to information that is used as input to the ML model to determine inference(s); the data used to train the ML model and the data used to determine reasoning may overlap, however, "training data" and "reasoning data" refer to different concepts.

FIG. 5 illustrates a reference diagram of an IAB architecture, according to some aspects. Referring to fig. 5, an IAB architecture 500 may include a Core Network (CN) 502 coupled with an IAB donor (donor) node 503. The IAB donor node 503 may include a control unit control plane (control unit control plane, CU-CP) function 504, a control unit user plane (control unit user plane, CU-UP) function 506, other functions 508, and Distributed Unit (DU) functions 510 and 512. The DU function 510 may be coupled to the IAB nodes 514 and 516 via a wireless backhaul link. The DU function 512 is coupled to the IAB node 518 via a wireless backhaul link. The IAB node 514 is coupled to the UE 520 via a radio access link and the IAB node 516 is coupled to the IAB nodes 522 and 524. The IAB node 522 is coupled to the UE 528 via a radio access link. The IAB node 518 is coupled to the UE 526 via a radio access link.

Each IAB node illustrated in fig. 5 may include a mobile termination (mobile termination, MT) function and a DU function. MT functions may be defined as components of a mobile device and may be referred to as functions residing on an IAB node terminating a radio interface layer towards the backhaul Uu interface of an IAB donor or other IAB node.

Fig. 5 shows a reference diagram of an IAB in standalone mode, which contains one IAB donor 503 and multiple IAB nodes (e.g., 514, 516, 518, 522, and 524). The IAB donor 503 is considered a single logical node that includes a set of functions such as gNB-DU, gNB-CU-CP 504, gNB-CU-UP 506, and potentially other functions 508. In deployment, the IAB donor 503 may be partitioned according to these functions, which may or may not be co-located as allowed by the 3GPP NG-RAN architecture. When such segmentation is exercised, IAB related aspects may occur. In some aspects, some functions currently associated with an IAB donor may eventually be moved outside the donor in case they do not significantly perform an IAB-specific task.

Fig. 6 illustrates Central Unit (CU) -Distributed Unit (DU) splitting and signaling in an IAB architecture 600, according to some aspects. Referring to fig. 6, an IAB architecture 600 includes an IAB donor 601, a parent IAB node 603, an IAB node 605, a child IAB node 607, and a child UE 609. The IAB donor 601 includes a CU function 602 and a DU function 604. The parent IAB node 603 includes a parent MT (P-MT) function 606 and a parent DU (P-DU) function 608. The IAB node 605 includes an MT function 610 and a DU function 612. The child IAB node 607 includes a child MT (C-MT) function 614 and a child DU (C-DU) function 616.

As shown in fig. 6, RRC signaling may be used for communication between CU function 602 and MT functions 606, 610, and 614 of IAB donor 601, as well as between CU function 602 and child UE (C-UE) 609. Furthermore, F1 access protocol (F1-AP) signaling may be used for communication between CU function 602 of IAB donor 601 and DU functions of parent IAB node 603 and IAB node 605.

IAB resource allocation techniques.

In some aspects, in IAB network 600, IAB node 605 may be connected to its parent node (IAB donor 601 or another IAB node, e.g., parent IAB node 603) via a Backhaul (BH) link, and to child UE 609 via a child Access (AC) link, and to child IAB node 607 via a child BH link, as shown in fig. 6.

In some aspects, central Unit (CU)/Distributed Unit (DU) fragmentation may be utilized, with each IAB node holding both DU and MT functions. MT functions may be used to connect an IAB node 605 to its parent IAB node 603 or an IAB donor 601 like a UE. The DU function may be used for communication between the IAB node 605 and the UE (e.g., 609) and the MT of a child IAB node like a base station (e.g., 614 of node 607). Signaling between an MT on an IAB node or UE and a CU on an IAB donor uses the RRC protocol, while signaling between a DU on an IAB node and a CU on an IAB donor uses the F1-AP protocol.

One example of an IAB CU/DU fragmentation architecture and signaling is illustrated in FIG. 6, where MTs and DUs in the parent IAB node 603 are indicated as P-MT/P-DUs; MT and DU in the sub-IAB node are indicated as C-MT/C-DU, while sub-UE 609 is indicated as C-UE.

In some aspects, regarding time domain resources, from the MT/UE perspective, downlink/uplink/flexible (D/U/F) time resources may be indicated for the parent link as in the Rel-15 specification.

In some aspects, the IAB node 605 may use the Rel-15 NR design for semi-static time domain resource allocation (D/U/F time domain resource indication), which may be done centrally at the CU 602 and notified to the MT/UE via RRC signaling. For example, in fig. 6, D/U/F time resources indicated from CU 602 to MT 610 via RRC signaling would be used for the parent BH link; D/U/F time resources indicated from CU 602 to C-MT 614 via RRC signaling will be used for the sub-BH link between nodes 607 and 605; while the D/U/F time resources indicated from CU 602 to C-UE 609 via RRC signaling will be used for the sub-AC link between C-UE 609 and node 605.

In some embodiments, the disclosed techniques may be used in connection with a UE, a base station, or another computing node using the configurations discussed in connection with fig. 1A-6.

Fig. 7 illustrates an illustration 700 of a customer premises network (customer premises network, CPN) using a premises radio access station (premises radio access station, PRAS) configured for communication with a 5G network, in accordance with some aspects.

In some aspects, enhancements to the residential 5G network may be configured to support the following enhancements for indoor small base stations.

In some aspects, the disclosed techniques may be used to improve the use of indoor small base stations in 5G residential use cases and to determine the suitability of combining indoor small base stations in 5G residential use cases for concepts specified by non-public networks such as private slice, SNPN, CAG. Indoor small base stations may be replaced with residential radio access stations (PRAS) to support new service requirements.

In some aspects, an enhanced residential gateway (enhanced residential gateway, eRG) connected to a 5G network may be configured to act as a gateway to provide 5G connectivity to its associated entities (e.g., UEs, non-3 GPP devices, and PRAS).

In some aspects, the disclosed techniques may consider an operator to act as an identity provider motivated by a user identity and authentication framework. A framework may be introduced to enable support of federated identity management (federated identity management, FIM) in an operator's 5G network for different data network domains in the cloud, PIN, and Customer Premise Network (CPN) in a residential environment connected to the 5G network. By treating the PIN or residential network connected to the 5G network as a data network domain, an operator acting as an identity provider can enhance the security of the PIN or residential network connected to the 5G network through user authentication, service authorization and access control.

In some aspects, the disclosed techniques may be used in connection with such use cases: this use case illustrates the need to protect the weak link between (off-the-shelf) PRAS (assuming not trusted) and eRG based on a user identification and authentication (user identification and authentication, UIA) framework. In some aspects, the 5G system may enable support to ensure secure end-to-end connectivity from UEs connected to (off-the-shelf) PRAS (with or without 3GPP subscriptions) to eRG and 5G networks.

The disclosed techniques may include service requirements and solutions in 5G systems to enable identification, authentication and authorization of (off-the-shelf) PRAS, where the solutions include: solution #0: use cases and service requirements; solution #1: PRAS operation configuration and high level procedures for enabling PRAS for operation and control by 5G networks; solution #2: PRAS operation configuration provisioning, PRAS operation authorization update, and revocation procedure. Based on a tethered (tethered) connection between eRG and PRAS using non-3 GPP defined technologies (e.g., wi-Fi or wired), the disclosed technology can be used to enable support for off-the-shelf PRAS for the following use cases:

case a:

(a) eRG is a trusted 3GPP device with 3GPP subscriptions.

(b) eRG the association/tethering entity is PRAS with 3GPP subscriptions from the same HPLMN of eRG.

(c) PRAS is a 3GPP device with 5G capability for accessing a 5G network via a connection/tethered eRG based on untrusted non-3 GPP access, based on the UE behind the RG.

Case B: the entity associated/tethered is PRAS without 3GPP subscription:

(a) eRG is a trusted 3GPP device with 3GPP subscriptions.

(b) The associated entity of eRG is PRAS without 3GPP subscription.

(c) PRAS is a non-3 GPP device.

In some aspects, this use case illustrates the need for identification, authentication and authorization of 5G system-supported (off-the-shelf) premise radio access stations in order to ensure secure connectivity for UEs connected to the 5G network via the (off-the-shelf) PRAS behind eRG. This use case is to ensure that there is a 3GPP mechanism to protect the weak link between (off-the-shelf) PRAS (assuming untrusted) and eRG. The disclosed technology also includes a use case that enables a security mechanism to remotely provision a profile for PRAS based on a remote provisioning process (remote provisioning process, RPP). In some aspects, eRG is a trusted 3GPP device having a 3GPP subscription. In some aspects, the association/tethering entity of eRG is a PRAS without a 3GPP subscription. Instead, the eRG subscription is enabled for one or more connection/tethered PRAS. In some aspects, PRAS has 5G capability for accessing 5G networks via connection/tethered eRG based on untrusted non-3 GPP access, based on UEs behind the RG.

The disclosed technology provides a solution (e.g., solutions 7-8) for enabling PRAS to act as an IAB node connected to a gNB as an IAB donor with/without eRG, another co-located PRAS acting as an intermediate IAB node after remote provisioning for the required PRAS operation configuration.

The disclosed techniques may be based on one or more of the following assumptions:

(a) The operator does not provide an (off-the-shelf) Premise Radio Access Station (PRAS) and is therefore considered an untrusted device for the operator's network.

(b) Customer Premises Network (CPN): a network located within a certain premises (e.g., a home, office, or store) is owned, installed, and/or (at least partially) configured by a customer of a public network operator.

(c) Evolved residential gateway (eRG): a gateway between a common carrier network (fixed/mobile/wired) and a customer premises network within a home, office or store.

(d) A residential radio access station (PRAS): the base station installed in the customer premises network is mainly used in houses, offices or shops.

(e) IoT devices: one type of UE or non-3 GPP device is dedicated to a particular set of use cases or services and is allowed to utilize certain functions limited to this type of UE only. IoT devices may be optimized for the specific needs of the services and applications being executed (e.g., smart homes/cities, smart appliances, electronic health, and smart wearable devices). Some IoT devices are not intended for human-type communications.

The disclosed technology may include the following solutions.

(A) Solution #0: use cases and service requirements.

(B) Solution #1: service requirements.

The following use cases can be considered:

eRG is a trusted 3GPP device with 3GPP subscriptions. eRG the association/anchor entity is PRAS without 3GPP subscription. PRAS has 5G capability for accessing 5G networks via connection/tethered eRG based on untrusted non-3 GPP access, based on the UE behind the RG.

In some aspects, this use case illustrates the need for identification, authentication and authorization of 5G system-supported (off-the-shelf) premise radio access stations in order to ensure secure connectivity for UEs connected to the 5G network via the (off-the-shelf) PRAS behind eRG.

In some aspects, the present use case is to ensure that there is a 3GPP mechanism to protect the weaknesses between (off-the-shelf) PRAS (assuming untrusted) and eRG.

Service requirements.

In order to enable a 5G network to support (off-the-shelf PRAS with or without 3GPP subscription, the following service requirements are proposed:

in some aspects, the evolved residential gateway is a trusted 3GPP device with 5G subscription provided by a network operator.

In some aspects, a 5G network operator should be able to provide eRG subscriptions to allow one or more PRAS to connect with it.

In some aspects, the 5G system may provide a mechanism to create identities for off-the-shelf PRAS without 3GPP subscriptions and store profiles for PRAS connected to eRG.

In some aspects, the 5G system may provide a mechanism to identify, authenticate, and authorize the (off-the-shelf PRAS connected to eRG based on the stored PRAS profile when it first connects to the 5G network.

In some embodiments, the 5G system may provide a mechanism to provision authenticated and authorized (off-the-shelf) PRAS connected to eRG with a configuration of operation settings and authorization based on the stored PRAS profile and the subscription of eRG.

In some aspects, the 5G system may be able to update or revoke the authorization of PRAS configuration for (off-the-shelf PRAS connected to eRG.

In some aspects, the 5G system may be able to update the PRAS configuration of the operation settings for (off-the-shelf PRAS connected to eRG.

(C) Solution #2: eRG subscription as an association/tethering entity of PRAS.

For eRG with 3GPP subscriptions, to enable the 5G network to support eRG federated identity management (federated identity management, FIM) of association/anchor entities (e.g. PRAS) without 3GPP subscriptions, the subscription of eRG may include the following:

(a) FIM and authentication supporting 5G for association entities (e.g., PRAS) without 3GPP subscription.

In addition, to enable 5G to support a tethered connection between eRG and PRAS, eRG may have the following 3GPP subscriptions to provide 5G connectivity to an associated/tethered PRAS such that it accesses the 5G network via eRG:

(a) Subscription for IP connectivity is provided for association/anchor entity as PRAS without 3GPP subscription.

(a.1) authorizing a tethered PRAS identifiable with the 5G network.

(a.2) authorizing a maximum number of tethered PRAS.

(a.3) authorizing a maximum total bandwidth of the tethered PRAS.

The above-described techniques may cover the case where eRG and PRAS are co-located, i.e., eRG and PRAS are also considered to be connected via a tethered connection.

For such a tethered grant in a eRG 3GPP subscription, the following information may be further indicated in the eRG subscription to define the 5G features applicable to the tethered PRAS:

(a) Authorized tethered PRAS identified by a user identity and allowed user identifier.

(b) Authorized 5G services such as eMBB, V2X, URLLC, proximity services, MBMS, etc.

(c) Authorized PDU session parameters and access technologies (3 GPP access, non-3 GPP access, or both), such as a combined list of DNN, S-nsai and access technologies.

(d) Validity parameters of the authorization, e.g. validity time/duration, validity location.

(e) One tethered PRAS' authorized maximum bandwidth.

(f) Authorized network and radio resources, such as carrier frequencies, and network slices through NR Uu for serving RAN slices of UEs.

For the user profile of PRAS, the following information may be indicated:

(a) A user identifier.

(b) The authorization identified by the eRG ID is tethered eRG.

(c) Authorized 5G services such as eMBB, V2X, URLLC, proximity services, MBMS, etc.

(d) Authorized PDU session parameters and access technologies (3 GPP access, non-3 GPP access, or both), such as a combined list of DNN, S-nsai and access technologies.

(e) Validity parameters of the authorization, such as validity time/duration, validity location.

(f) One tethered PRAS' authorized maximum bandwidth.

(g) Authorized network and radio resources, e.g., carrier frequencies, and network slices for serving RAN slices of UEs through NR Uu.

(D) Solution #2.1:

according to solution #2, fim is a new 5G network capability that supports the following features:

(a) The identity is provided for an associated entity of a trusted 3GPP device having a 3GPP subscription, while the associated entity has no 3GPP subscription.

(b) A profile is stored for an associated entity of a trusted 3GPP device having a 3GPP subscription.

(c) The associated entity is authenticated based on its profile configuration (including credentials, e.g., identifier, security key, certificate, password, etc.).

In some aspects, the 5G network may provide each PRAS (associated entities) with an identity, i.e., PRAS ID, which is a globally unique number (e.g., a serial number of the PRAS) and configured with one or more PRAS profiles with different operational settings. Each PRAS profile configuration includes the following information:

(a) PRAS identifier, which may identify an association profile of PRAS as an association entity.

(b) PRAS operation settings and parameters, including network parameters (e.g., qoS parameters), specific network and radio resources (e.g., carrier frequency, network slice settings for RAN slices), shared network settings with allowed PLMN lists, operator settings for UACs (unified access control ), etc.

(c) eRG support the necessary capabilities for device (its associated entity) authentication.

(d) Information about the authentication/authorization policy of PRAS.

(e) Enabled specific service settings for supporting 5G network services at PRAS, such as location-based services, multicast and broadcast services, and so on.

In some aspects, PRAS or AMFs in the 5G network may authenticate PRAS IDs based on the requested one or more PRAS identifiers for the PRAS IDs.

In some aspects, PRAS may indicate its PRAS ID and one or more valid PRAS identifiers in the registration request procedure via eRG, and the 5G network may determine which PRAS identifier is an accepted registration and the PRAS profile applied for the PRAS ID.

For example, PRAS may indicate its PRAS ID and one PRAS identifier for PRAS registration, and AMFs in the 5G network may determine whether to accept the registration based on both the PRAS identifier and the PRAS ID. If the request is not accepted by the 5G network, the 5G network may reject PRAS registration with the appropriate cause value and optionally indicate the preferred PRAS identifier for its corresponding PRAS configuration profile.

(E) Solution #3: a remote provisioning procedure triggered by a 5G network.

In accordance with solution #2, fig. 8 shows a eRG subscription based on tethered PRAS (solution # 2), enabling PRAS without 3GPP subscription to be used for high level procedures of operation and control by 5G networks.

Fig. 8 illustrates a diagram 800 of a high-level procedure that enables an (off-the-shelf) PRAS connected to eRG for operation and control by a 5G network, in accordance with some aspects. The following is a brief description of the illustrated steps.

Step 1: eRG provided by the network operator W with 3GPP subscription registers and successfully connects to the 5G network.

Step 2: this step is required for PRAS without 3GPP subscription to allow the 5G network to enable PRAS, i.e. the associated entity of eRG as a trusted device with 3GPP subscription, for its control and management.

Step 2a: manual configuration: a human user logs into his account on the portal of operator W to add a premise radio access station. The 5G network assigns identities to PRAS and creates a profile for PRAS that indicates an association with trusted 3GPP device eRG.

Step 2b: automatic configuration: when PRAS is first turned on, PRAS connects to the application server via 5G connectivity of eRG. The application server requests an application function (application function, AF) via a standardized API through the N33 interface between NEF and AF to add PRAS as an associated entity of eRG.

Step 2c: the 5G network creates an identity (PRAS ID) for the PRAS and one or more profiles for the PRAS, and each profile contains the following information:

(a) PRAS identifier.

(b) An indication of association with a trusted 3GPP device (i.e., eRG identified by its 3GPP identity (e.g., IMSI, SUPI, SUSI or FQDN)).

(c) The credentials of PRAS include PRAS identifier, security key, password, etc.

(d) PRAS operation grants, such as tokens, list of allowed PLMN(s), and validity time of the grant PRAS operation.

(e) The operator has policies for authentication and authorization based on the capabilities of the associated entity and eRG.

(f) Policy of the operator for PRAS operation.

Step 2d: after successfully adding PRAS as an associated entity of eRG and creating a PRAS profile, the 5G network initiates a UE configuration update procedure to eRG, wherein the configuration is for the associated entity (PRAS) and the configuration contains the following information:

(a) PRAS credentials.

(b) Policy of the operator for authentication and authorization of this PRAS.

Step 3: for PRAS without 3GPP subscription, the operator's policy indicates that both authentication and authorization are necessary, eRG registers the associated PRAS with the 5G network in a NAS request message (e.g., via a new NAS request message or registration update request that indicates the following information) that indicates the credentials of the PRAS based on the PRAS configuration:

(a) The credentials of PRAS include a PRAS identifier based on the PRAS profile of the associated entity, and the required security keys, certificates, or passwords.

(b) An indication of a request for a PRAS configuration update with authorization.

(c) PRAS active status.

In some aspects, device authentication of PRAS without 3GPP subscription is used by the 5G network to ensure the authenticity of PRAS, which may use PRAS authorization and apply carrier's configuration for PRAS operation to serve the UE.

Step 4: from the request message from eRG and the stored profile of PRAS in step 3, the 5G network of operator W identifies PRAS and based on the stored operator policy for PRAS:

(a) For device authentication: an AMF in the 5G network receives the registration request for PRAS and the AMF in the 5G network sends an authentication request to the AUSF to perform device authentication based on the PRAS ID, the PRAS identifier indicated for the stored PRAS profile, and the PRAS credentials.

(b) Authorization for PRAS operation: the AMF in the 5G network also checks for authorization from PRAS of the AUSF. If authorization is confirmed, the AMF in the 5G network requests its associated configuration function, such as a PCF or PRAS-capable network function, to initiate the PRAS configuration update procedure.

Step 5: the 5G network (e.g., based on GSMA sgp.22-RSP technical specification, and 5:sgp.21RSP architecture) initiates a profile download preparation procedure to the provisioning server (e.g., SM-dp+ (proxy), SM-DS (default server)).

Step 6: the 5G network triggers the remote provisioning procedure to PRAS via eRG.

Step 7: after successful installation of the set profile, PRAS enables its 5G capability and re-connects to the 5G network via eRG through an untrusted non-3GPP access procedure (UE behind RG over untrusted non-3GPP access procedure) behind the RG based on the UE in TS 23.316.

In some aspects, the configuration function in the registered 5G network may update and revoke PRAS configurations with operational settings and authorizations to PRAS via eRG with the following information:

(a) PRAS operation grants, e.g., tokens, and the validity time of the PRAS operation.

(b) The PRAS operation authorization of the list of PLMN(s) is allowed.

(c) PRAS operation settings of the network and radio resources, such as carrier frequency, network slice settings of RAN slices, RAN sharing supporting PLMN ID lists, UAC (unified access control), TAC lists, and each item including TAC (tracking area code) and PLMN support lists (including PLMN ID, slice support list, NPN support, extended slice support list), etc.

(d) Information about the required 5G service capability at the RAN, e.g. LCS, MBMS.

In some aspects, PRAS may update its active operational status via eRG to a configuration function in the 5G network by indicating its active operational status.

Once this process is complete, the premise radio access station may be re-successfully authenticated, authorized, and connected to the operator W's network via eRG, and is now fully operational.

In some aspects, the 5G network ensures that the E2E connection from the 5G core network to the UE connected to the PRAS behind eRG is secure, since both (off-the-shelf) PRAS connected via eRG of the operator are authenticated, authorized, and managed by the operator.

(F) Solution #3.1.

According to solution #3 (steps 1 to 6), this solution provides an example of invoking Remote Provisioning Procedure (RPP) for PRAS.

The following options are different based on the following factors:

(a) Loading (on-board) method of PRAS registration procedure to 5G network (for steps 3-5 in figure Y):

(a.1) a user plane 5G connection via eRG, i.e., eRG acts as a layer 3 gateway UE and the end point of the PRAS connection is at the 5G network. (option 1). PRAS acts as a 5G device capable of non-3 GPP access.

(a.2) the signalling plane 5G connection via eRG, i.e. eRG acts as a layer 2 gateway UE and the end point of the PRAS connection is at eRG. Option 2.PRAS acts as a non-3 GPP device.

(b) The 5G network triggers a Remote Provisioning Procedure (RPP) according to the registration procedure of PRAS (for step 6).

(c) The RPP may be triggered with or without an activation code issued by the operator. In the former case, the activation code may be provided to the PRAS by the operator directly or via eRG. (for step 6).

(c.1) the 5G network may connect PRAS to the configured provisioning server based on an activation code stored in the user profile of PRAS, for example.

(c.2) PRAS may connect to configured provisioning services based on an activation code sent by the 5G network, for example:

(c.2.1) via a registration accept message to PRAS, in which case PRAS may be a 5G capable device. (option 1).

(c.2.2) via eRG. (option 2). For example, the 5G network informs eRG that the RPR is triggered for its associated entity of PRAS and indicates an activation code, wherein eRG triggers RPP of PRAS by sending the activation code to PRAS using a connection that is not 3GPP specified (e.g., bluetooth, wi-Fi direct).

Option 1: eRG registration for PRAS serves as gateway UE (based on TS 23.316).

The loader is based on a request by PRAS to the 5G network via eRG as gateway UE.

RPP is a eRG based 5G connection.

Fig. 9 illustrates an illustration 900 of a high level procedure of configuring eRG as a gateway UE for PRAS registration, according to some aspects. The following is a brief description of the steps shown in fig. 9.

Step 0: eRG registers with the 5G network and establishes a PDU session. PRAS uses non-3 GPP defined access technologies (e.g. bluetooth, WLAN direct access) to connect with UE-1.

Step 1: based on the authorization configuration for sharing the 3GPP subscription with the authorized PRAS, the user of eRG initiates the sharing of the 3GPP subscription procedure and eRG sends a message to the PRAS to trigger the 5G registration. This step is not within the scope of 3 GPP.

Step 2: PRAS connected to eRG sends a registration request message to the 5G network via gateway UE indicating its PRAS ID and user identifier based on the registration procedure of the UE behind the RG in 3GPP Technical Specification (TS) 23.316 using untrusted non-3 GPP access.

Step 3: based on the PRAS ID, the user identifier and the respective user profile of PRAS for the PRAS-enabled eRG 3GPP subscription, the AMF checks eRG the following grants in the subscription:

(a) Whether PRAS is an authorized association entity of eRG;

(b) eRG has a valid 3GPP subscription to share to its associated entity, e.g. PRAS; and

(c) Whether PRAS is authorized to make tethered connections with PRAS in the 3GPP subscription of eRG; an authorization acknowledgement may be indicated in step 4 to request eRG an authorization acknowledgement.

In some aspects, if PRAS has a valid associated entity grant and eRG for a 3GPP subscription to the PRAS grant, the AMF initiates the remote provisioning procedure in steps 5-7. Otherwise, the AMF denies the registration request and indicates to the PRAS the appropriate reject cause. The reject cause may include:

(a) As an associated entity of eRG, authorization fails;

(b) eRG there is no active subscription to the 3GPP subscription that is tethered to PRAS; and

(c) The grant expires for using the shared subscription from eRG.

Step 4: the AMF may inform eRG about PRAS' registration attempts for eRG 3GPP subscriptions to PRAS. If the user profile of PRAS indicates that authorization confirmation is required, this step may be used to obtain authorization confirmation from eRG to inform eRG about the registration status prior to initiating the remote provisioning procedure for PRAS indicated in eRG subscription to PRAS.

Step 5: the 5G network is based on [4: GSMA sgp.22-RSP specification, and 5: sgp.21rsp architecture ], initiates a profile download preparation procedure towards the provisioning server (e.g. SM-dp+ (proxy), SM-DS (default server)).

Step 6: in response to the registration request message sent in step 2, the 5G network sends a registration accept message to the PRAS via eRG; the registration accept message contains an optional activation code for the RPP. In addition, the 5G network may indicate to eRG to establish the PDU session information required to prepare the remote provisioning procedure of PRAS, e.g., DNN, S-nsai.

Step 7: PRAS initiates the remote configuration process by:

(a) A PDU session is established with the indicated DNN, S-nsai via eRG. The AMF selects a specific SMF configured for the RPP and the SMF may establish a specific PDU session for the RPP.

(b) RPP between PRAS, 5G networks and provisioning servers is based on interfaces and protocols defined in GSMA sgp.22.

(c) During RPP, PRAS indicates its EID if the operator has configured its EID during user identity creation in solution # 3. If not, PRAS indicates its IMEI.

Option 2: eRG RPP is invoked for PRAS.

The loader is based on eRG requests to the 5G network. RPP is based on 5G connectivity of eRG.

Fig. 10 illustrates an illustration 1000 of a high-level procedure configuring eRG to invoke Remote Provisioning Procedure (RPP) for PRAS, in accordance with some aspects. The following is a brief description of the steps shown in fig. 10.

Step 0: the same as step 0 in fig. 9.

Step 1: based on the configuration of eRG authorization of the subscription of PRAS, eRG retrieves PRAS ID, user identifier information from the tethered PRAS based on the connection established in step 0 b.

Step 2: eRG sends a message to enable its 3GPP subscription to PRAS indicating the PRAS ID, the user identifier of UE-2.

Step 3: the same as step 3 in fig. 9.

Step 4: the same as step 5 in fig. 9.

Step 5: the 5G network sends an accept message to eRG for the service request enabling its 3GPP subscription to PRAS, including specific PDU session parameters (DNN, S-nsai) and optionally an activation code for RPP to PRAS.

Step 6: eRG indicates to the PRAS to trigger a remote provisioning procedure for the PRAS based on the connection established in step 0b, wherein a remote provisioning procedure container is provided. If eRG receives information from a 5G network in step 5, the remote provisioning container includes the following information:

(a) Specific PDU session parameters (DNN, S-NSSAI) of RPP;

(b) An activation code of the RPP; and

(c) Allowed access technologies for triggering RPP registration, such as 3GPP access or non-3 GPP access.

Step 7: the PRAS connected to eRG sends a registration request message indicating its PRAS ID and user identifier to the 5G network via eRG based on the registration procedure of the UE in TS23.316 behind the RG using untrusted non-3 GPP access and the PDU session establishment request procedure for the specific DNN and S-nsai (if received from eRG in step 6), which is for the connection to the configured provisioning server based on the information contained in the activation code.

With a specific PDU session, the RPP between PRAS, 5G network and provisioning server is based on the interface and protocol defined in GSMA sgp.22.

During RPP, PRAS indicates its EID if the operator has configured its EID during user identity creation in solution # 2. If not, PRAS indicates its IMEI.

(G) Solution #4.

Following the remote provisioning procedure (fig. 8, steps 1-6), there are two cases based on network operator policy for PRAS registration and PRAS configuration update for authenticated and authorized PRAS, which provides 3GPP subscription for eRG and PRAS connected to eRG, according to solution # 3. In some aspects, the PRAS operation configuration provisioning procedure is performed in the following scenario:

(a) If PRAS does not have valid PRAS operation authorization information, then before starting to serve the UE (as shown in solution #2- # 3); or alternatively

(b) When PRAS has begun operation to serve the UE and the connected eRG changes its registered PLMN and there is no valid PRAS operation authorization information for the newly registered PLMN.

(c) When the PRAS operation authorization expires.

In this solution, the following configuration is applied (fig. 8, step 7):

(a) The configuration function may be a PCF or a new network function for PRAS configuration.

(b) In the case of PCF, eRG sends a NAS message to request PRAS configuration. In this case, a UE configuration update procedure is used in step 2 to provide PRAS configuration. The procedure may refer to TS23.502:4.2.4, ue configuration update.

(c) In the case of new network functions, such as provisioning servers/proxies, a new interface is used between eRG and the provisioning function; the PRAS configuration is requested using a new request message and the PRAS configuration is delivered using a new response message.

(c.1) if eRG has a 3GPP subscription to provide an IP connection with the associated entity for PRAS, then the address of the PRAS configuration function is assigned eRG as part of eRG configuration.

To enable PRAS connected to the 5G network via eRG for operation and control by the 5G network, the 5G network provides a PRAS operation configuration via eRG, wherein the PRAS configuration includes the following information:

(a) PRAS operation grants, e.g., tokens, and validity times of PRAS operations;

(b) PRAS operation authorization for the list of allowed PLMN(s);

(c) PRAS operation settings of the network and radio resources, such as carrier frequency, network slice settings of RAN slices, RAN sharing supporting PLMN ID lists, UAC (unified access control), TAC lists, and each item including TAC (tracking area code) and PLMN support lists (including PLMN ID, slice support list, NPN support, extended slice support list), etc.

(d) Information about the required 5G service capability at the RAN, e.g. LCS, MBMS.

In some aspects, when PRAS connects to a 5G network via eRG, PRAS may send a NAS message for the PRAS setup request or piggyback the PRAS setup request in a NAS message sent via eRG and indicate its associated errg ID. The message includes the following information:

(a) PRAS name.

(b) PRAS node ID.

(c) One or more PRAS identifiers.

(d) Supported RAT information.

(H) Solution #4.1.

After RPP, eRG and PRAS are assumed to have 3GPP subscriptions from the same network operator.

For PRAS with 3GPP subscription from the same PLMN of eRG, the 5G network provides PRAS operation configuration via eRG, as shown in fig. 11.

Fig. 11 illustrates an illustration 1100 of a PRAS operation configuration provisioning procedure in the case where PRAS and eRG have 3GPP subscriptions from the same HPLMN provided by the same network operator, in accordance with some aspects. The following is a brief description of the steps shown in fig. 11.

In some aspects, the configuration is retrieved and delivered using an "IP-based" mechanism, and only the IP connectivity provided by eRG is required to allow PRAS to access this configuration function in the 5G network via eRG.

Step 1: PRAS is connected to the errg, which has an IP connection to the 5G network.

Step 2: eRG requests configuration information (identified by PRAS identifier) of PRAS from a configuration function in the 5G network.

Step 3: the configuration function at the serving PLMN requests PRAS operation configuration information for the requested PRAS.

The PRAS operation configuration information provided to the PRAS is applicable to the serving PLMN and PLMNs determined by the HPLMN to be the home PLMN (e.g., based on the serving PLMN) and thus available for use by the PRAS. PRAS securely stores the operating configuration obtained from this configuration function. The PRAS operation authorization may be revoked by a configuration function in the home PLMN or VPLMN or a configuration function in the HPLMN if needed at any point in time.

For eRG/PRAS non-roaming case: the configuration function of the HPLMN requests UDM for PRAS configuration of PRAS identified by a PRAS identifier. PRAS configuration information is provided to eRG by the configuration function.

For eRG/PRAS roaming case: based on the PRAS identifier (which contains information of the home PLMN ID of the PRAS), the configuration function at the registered VPLMN of eRG requests a PRAS configuration for the PRAS identified by the PRAS identifier from the configuration function at the home PLMN of the PRAS.

Step 4: eRG delivers PRAS configuration information to PRAS.

Step 5: PRAS installs configuration information and stores configuration.

(I) Solution #4.2: the update is authorized.

The allowed PLMN list authorized by pras operation may be updated by the UDM or configuration function at any point in time, per solution #4. And the configuration function may be in the HPLMN, VPLMN or home PLMN. The addition of PLMNs to the allowed PLMN list authorized by the PRAS operation is triggered by the UDM.

Before the PRAS operation grant validity time expires, the configuration function uses a PRAS operation notification message to immediately send the updated PRAS operation grant to the PRAS connected to eRG or to wait for the next communication with the configuration function according to the operator's policy.

The UDM initiated PRAS operation configuration update procedure is shown in fig. 12. Fig. 12 illustrates UDM-initiated PRAS configuration updates, according to some aspects. A brief description of the steps in fig. 12 is provided below.

Step 1: the UDM triggers a subscription data update notification message to the PRAS operation of the HPLMN configuration function.

Step 2 (optional): the HPLMN configuration function sends a PRAS operation configuration update notification to the PRAS through the new interface or via NAS message, wherein a notification message indicating that the PRAS is the destination endpoint is sent from the HPLMN configuration function to the VPLMN configuration function, and the VPLMN configuration function forwards the message to the AMF through the NAS message or the new interface towards eRG. eRG forwards the message to PRAS.

Step 3: subscriber data updates may be sent directly from the UDM to the VPLMN configuration function (step 3 a) or from the HPLMN configuration function to the VPLMN configuration function (step 3 b).

Step 3a: the HPLMN UDM sends an updated insert subscriber (PRAS) data message (PRAS identifier, updated PRAS subscription data) with PRAS operation information and authorization to the VPLMN configuration function.

Step 3b: the HPLMN configuration function sends a subscriber data update message (PRAS identifier, updated PRAS subscription data) to the VPLMN configuration function.

Step 4: the VPLMN configuration function sends a PRAS configuration update message to eRG, either through a non-access stratum (NAS) message or a new interface towards eRG, indicating PRAS as the destination endpoint. eRG forwards the message to PRAS.

(J) Solution #4.3: the PRAS operation authorizes the revoked configuration update.

An example process for the non-roaming case is illustrated in fig. 13. Fig. 13 illustrates configuration functionality when HPLMN triggered PRAS operation grant revocation (non-roaming), according to some aspects. A brief description of the steps of fig. 13 is provided below.

Step 1: the HPLMN configuration function triggers a subscription data update notification message for PRAS operation to the PRAS via eRG. In step 1b, PRAS may stop accepting new arriving UEs and start directing UEs to other PRAS or gnbs and set a timer to release the RRC connection with the current PRAS. The UE may initiate a cell reselection procedure or wait for a timer to expire and the RRC connection to be released. When the timer expires, the RRC connection of the UE is released from the current PRAS.

Step 2-3: the HPLMN configuration function sends PRAS operation configuration update notifications to UDMs and eRG through new interfaces or via NAS messages, wherein notification messages indicating PRAS as destination endpoints are sent from the HPLMN configuration function to eRG through NAS messages or new interfaces towards eRG via AMFs.

Step 4: eRG forwards the message to PRAS.

Step 5: PRAS stores configuration information for operations and performs configuration to apply new configuration settings or to cease operations due to authorized revocation.

An example process of the roaming case is illustrated in fig. 14. Fig. 14 illustrates PRAS operation grant revocation (roaming) triggered by VPLMN configuration functionality in accordance with some aspects. A brief description of the steps in fig. 14 is provided below.

Step 1: the VPLMN configuration function triggers a PRAS configuration update notification message to PRAS for PRAS operations via eRG. In step 1b, PRAS may stop accepting new arriving UEs and start directing UEs to other PRAS or gnbs and set a timer to release the RRC connection with the current PRAS. The UE may initiate a cell reselection procedure or wait for a timer to expire and the RRC connection to be released. When the timer expires, the RRC connection of the UE is released from the current PRAS.

Step 2-3: the VPLMN configuration function sends a PRAS operation configuration update notification to the HPLMN configuration function and the UDM.

Step 4: the VPLMN configuration function sends a PRAS configuration update message to eRG over the new interface or via a NAS message indicating that the destination endpoint is PRAS, where the message is sent from the VPLMN configuration function to eRG via the AMF over the NAS message or towards the new interface of eRG.

Step 5: eRG forwards the message to PRAS.

Step 6: PRAS stores configuration information for operations and performs configuration to apply new configuration settings or to cease operations due to authorized revocation.

(K) Solution #5: example service flows.

Service flow example:

(a) And (5) pre-condition.

Alicia (Alicia) obtained a promotional agreement from her smart phone operator wallower to upgrade her home network with a bundle that included a eRG and a PRAS. Upon receiving these two devices, alicia installs eRG and PRAS on the second floor and connects both via a wireline. Alicia energizes both devices. Both devices are registered with the 5G network and are configured with configuration of operation settings and authorizations from the 5G network. eRG and PRAS both start and perform well providing 5G coverage in alicia's home.

Later, alicia found that there were some coverage holes in the corners of the first floor, so she decided to purchase an off-the-shelf Premise Radio Access Station (PRAS) without 5G subscription, i.e., these devices were not provided by the operator and were thus considered untrusted devices for the operator's network.

After coming home, alicia logs in her account on the portal of the operator Wallowa to upgrade eRG subscription to allow connection of two PRAS, and then adds this off-the-shelf resident radio access station by manually configuring the device settings or by scanning the QR code of PRAS and associating it to the trusted 3GPP device eRG (to which it will connect with a tethered connection).

Alicia installs PRAS on first floor and connects PRAS to the 5G network via eRG of the operator.

(b) Service flow

(b.1) the 5G network of operator Wallowa creates an identity for an off-the-shelf PRAS device and stores the PRAS profile based on alicia's input.

(b.2) alicia turns on PRAS and connects PRAS to eRG. PRAS connects to 5G networks via eRG. Based on eRG subscription to associated/tethered PRAS(s) and the profile of ready PRAS, the operator's wallow 5G network identifies, authenticates and authorizes PRAS.

(b.3) the 5G network updates the PRAS profile and configures PRAS to the PRAS via eRG, e.g., PRAS operation authorization, operator settings, etc.

(b.4) when PRAS completes installation, it reconnects to the 5G network of operator wallow via eRG based on the provisioned PRAS configuration.

(b.5) the 5G network of operator Wallowa may identify an existing PRAS, authenticate its identity, and authorize PRAS operations based on the PRAS' profile and configuration.

(b.6) once this process is completed, the off-the-shelf premise radio access station is successfully authenticated, authorized, configured and connected to the operator wallwa's network via eRG and is now fully operational.

(c) And (5) post-setting conditions.

The 5G network ensures that the E2E connection from the 5G core network to the UE connected to the off-the-shelf PRAS behind the operator's PRAS and eRG is secure because both PRAS connected via eRG of the operator are authenticated, authorized and managed by the operator.

Alicia may now connect her UE to both premise radio access stations. She is satisfied because she can talk on the phone while she is walking in the house, with good 5G service coverage.

(L) solution #6: after remote provisioning, the 5G capability of PRAS is enabled.

PRAS enabled 5G capability according to solution #4 or #5 and connect to eRG or gNB based on operator policy, provisioned PRAS profile configuration, eRG subscription, and PRAS eRG capability. There are the following options:

option 1: the tethered connection between PRAS and eRG is via a non-3 GPP access technology, e.g., wi-Fi, or wired.

Fig. 15 illustrates a diagram 1500 of the overall architecture of the gNB, errg, and PRAS, in accordance with some aspects.

Option 2: the tethered connection between PRAS and eRG uses a 5G NR over the NR Uu interface, i.e., an IAB node connection between PRAS and eRG, whereby the gNB serves as an IAB donor for eRG, is co-located with another PRAS serving as an intermediate IAB node, and PRAS is a terminating IAB node.

Fig. 16 illustrates an illustration 1600 of the overall architecture of an IAB with eRG and PRAS, according to some aspects. As shown in fig. 16:

(a) This option requires that both PRAS (co-located with eRG) support the IAB node capability.

(b) Both PRAS are configured with the following parameters:

(b.1) authorizing the tethered connection to use NR Uu between eRG and PRAS; and

(b.2) authorizing network and radio resources, such as carrier frequencies, and network slice settings for RAN slices.

(M) solution #6.1: the enabled 5G capability of PRAS directly connected to the IAB donor after remote provisioning.

In some aspects, the following processing may be performed in accordance with solutions # 4-5:

option 3: the connection between PRAS and gNB is via an IAB node connection, whereby the gNB acts as an IAB donor for PRAS as terminating IAB nodes. eRG do not act as IAB nodes and PRAS may be connected to the same or different gnbs as shown in fig. 17.

Fig. 17 illustrates an illustration 1700 of the overall architecture of eRG and PRAS as IAB nodes, according to some aspects.

This option requires PRAS to support IAB node capabilities and contain authorization for the IAB node, including:

(a) Granting use of radio resources, e.g. carrier frequencies, of NR Uu for a connection between PRAS and IAB donors;

(b) Authorizing network slice settings of the RAN slice for a connection between the PRAS and the IAB donor; and

(c) In addition to PRAS operation settings for the network and radio (e.g., carrier frequency), for serving UEs through NR Uu (as shown in solution # 2).

The eRG subscription of PRAS does not need to indicate sharing of bandwidth for a tethered connection between eRG and PRAS.

In some aspects, to enable 5G support for a direct connection between the gNB and PRAS, eRG needs to have the following subscription to share its 3GPP subscription with PRAS and have PRAS directly connected to gNR through NR Uu using 5G radio resources:

(a) An IP connection subscribing to PRAS with IAB node capability and without 3GPP subscription:

(a.1) authorizing a 3GPP subscription sharing eRG with PRAS identifiable by the 5G network;

(b) The maximum number of PRAS authorized to share 3GPP subscriptions; and

(c) The maximum total bandwidth of PRAS for which the 3GPP subscription is authorized to be shared.

(N) solution #6.2.

According to solution #6.1, the eRG may have a 3GPP subscription that is authorized for PRAS (solution # 6.1) capable of sharing IAB nodes of its 3GPP subscription, and for PRAS (solution #2 and solution # 6) using a tethered connection via eRG.

For PRAS to act as an IAB node and the gNB to act as an IAB donor, the relevant mechanisms follow TS 38.401 and TS 38.300.

(O) solution #7.

According to solutions #6 and #6.1, for subscriptions with PRAS(s), based on the 3GPP subscription of eRG, the following information may be further indicated in the subscription of eRG to define the 5G characteristics applicable for each PRAS:

(a) Authorized PRAS identified by the user identity and allowed user identifier.

(b) Authorized 5G services such as eMBB, V2X, URLLC, proximity services, MBMS, etc.

(c) Authorized PDU session parameters and access technologies (3 GPP access, non-3 GPP access, or both), such as a combined list of DNN, S-nsai and access technologies.

(d) Validity parameters of the authorization, e.g. validity time/duration, validity location.

(e) The authorized maximum bandwidth of PRAS.

(f) Authorized radio resources, such as carrier frequencies, and network slices through Uu for serving RAN slices of UEs.

(g) The authorized PRAS type for backhaul is e.g. connected to eRG via non-3 GPP access (option 1), connected to the IAB node of eRG via 3GPP access (option 2), and directly connected to the IAB node of the gNB as an IAB donor (option 3).

(h) Authorized radio resources, such as carrier frequencies, and network slices for serving as RAN slices for the IAB nodes connected to the backhaul through NR Uu with eRG and gNB (option 2) or directly with gNB (option 3).

For the user profile of PRAS, the following information may be indicated:

(a) A user identifier.

(b) Authorization eRG identified by the eRG ID of the shared 3GPP subscription.

(c) Authorized 5G services such as eMBB, V2X, URLLC, proximity services, MBMS, etc.

(d) The authorized PDU session parameters and access technologies (3 GPP access, non-3 GPP access, or both) for serving the UE, e.g., a combined list of DNN, S-nsai and access technologies.

(e) Validity parameters of the authorization, such as validity time/duration, validity location.

(f) PRAS grants an authorized maximum bandwidth of radio resources, e.g., carrier frequency, and network slices through NR Uu for serving RAN slices of UEs.

(g) The authorized PRAS type for backhaul is e.g. connected to eRG via a non-3 GPP access (option # 1) and to eRG IAB node via a 3GPP access (option # 2) or directly connected to the nb as IAB donor (option # 3). Each PRAS may be only able to indicate one type for the backhaul.

(h) Authorized radio resources, such as carrier frequencies, and network slices for serving as RAN slices for the IAB nodes connected to the backhaul through NR Uu with eRG and gNB (option # 2) or directly with gNB (option # 3).

The following example processes may be performed using the disclosed techniques.

A method for triggering remote provisioning for a small base station for operation and control by a 5G network. In some aspects, PRAS can have 5G capability without 3GPP subscription and connect to an evolved residential gateway (eRG) via a tethered connection. In some aspects, eRG has 3GPP subscriptions and provides IP connectivity for its associated/tethered entities (including one or more PRAS). In some aspects, eRG is considered a trusted device when it is authenticated and authorized by the 5G network.

In some aspects, the 5G network identifies a residential radio access station without a 3GPP subscription connected to authenticated and authorized eRG based on its configured PRAS ID.

Example processing associated with solutions #6 and #2 (eRG subscription) includes the following. In some aspects, for eRG with 3GPP subscription, to enable eRG association/anchor entities (e.g., PRAS) without 3GPP subscription to obtain 5G network support, the subscription of eRG may include subscription to FIM with 5G enabled and authentication to associated entities (e.g., PRAS) without 3GPP subscription.

In some aspects, eRG may have a 3GPP subscription that is authorized for PRAS (solution # 6.1) of the IAB node that is able to share its 3GPP subscription, and for PRAS (solution #2 and solution # 6) using a tethered connection via eRG.

In some aspects, after remote provisioning of PRAS configuration, PRAS enables 5G capability and connects to eRG or gNB base stations based on operator policy, provisioned PRAS profile configuration, eRG subscription, and PRAS eRG capability.

In some aspects, the tethered connection between PRAS and eRG is via a non-3 GPP access technology, e.g., wi-Fi, or wired. In some aspects, the tethered connection between PRAS and eRG uses a 5G NR over the NR Uu interface, i.e., an IAB node connection between PRAS and eRG, whereby the gNB serves as an IAB donor for eRG, is co-located with another PRAS serving as an intermediate IAB node, and the PRAS is a terminating IAB node.

In some aspects, both PRAS (co-located with eRG) support the IAB node capability and are configured with the following parameters: the licensed tethered connection uses the NR Uu between eRG and PRAS, as well as licensed network and radio resources, such as carrier frequencies, and network slice settings for RAN slices.

In some aspects, the connection between PRAS and gNB is via an IAB node connection. In some aspects, the gNB acts as an IAB donor for the PRAS terminating the IAB node. In some aspects, eRG does not act as an IAB node, and PRAS may be connected to the same or different gnbs.

In some aspects, PRAS supports IAB node capabilities and includes IAB node grants, including, in addition to PRAS operation settings for a network and radio (e.g., carrier frequency) used to serve UEs through NR Uu: granting use of radio resources, e.g. carrier frequencies, of NR Uu for a connection between PRAS and IAB donors; and authorizing network slice settings of the RAN slice for the connection between the PRAS and the IAB donor.

In some aspects, the eRG subscription of PRAS does not require that bandwidth sharing be indicated for the tethered connection between eRG and PRAS.

In some aspects, to enable 5G support for a direct connection between the gNB and PRAS, eRG needs to have the following subscription to share its 3GPP subscription with PRAS, and have PRAS directly connected to gNR through NR Uu using the following 5G radio resources: for the subscription of an IP connection of PRAS with IAB node capability and without 3GPP subscription, this includes the following information: authorizing a 3GPP subscription sharing eRG with PRAS identifiable by the 5G network; the maximum number of PRAS authorized to share 3GPP subscriptions; and authorizing a maximum total bandwidth of PRAS subscribed to by the shared 3 GPP.

An example process of contacting solution #7 (eRG subscription for supporting PRAS as an IAB node using NR Uu) includes the following. In some aspects, the eRG 3GPP subscription to PRAS(s) further includes at least one of the following information for defining 5G features applicable to each PRAS: an authorized PRAS identified by a user identity and an allowed user identifier; authorized 5G services such as eMBB, V2X, URLLC, proximity services, MBMS, etc.; authorized PDU session parameters and access technologies (3 GPP access, non-3 GPP access, or both), e.g., a combined list of DNN, S-nsai and access technologies; validity parameters of the authorization, e.g. validity time/duration, validity location; the authorized maximum bandwidth of PRAS; authorized radio resources, such as carrier frequencies, and network slices for serving RAN slices of UEs over Uu; an authorized PRAS type for backhaul, e.g., connected to eRG via a non-3 GPP access (option 1), and connected to an IAB node of eRG via a 3GPP access (option 2), and directly connected to a gNB as an IAB donor (option 3); and authorized radio resources, such as carrier frequencies, and network slices for serving as RAN slices for the IAB nodes connected to the backhaul through NR Uu with eRG and gNB (option 2) or directly with gNB (option 3).

In some aspects, PRAS stores a user profile that includes at least one of the following information: a user identifier; an authorization eRG identified by the eRG ID of the shared 3GPP subscription; authorized 5G services such as eMBB, V2X, URLLC, proximity services, MBMS, etc.; authorized PDU session parameters and access technologies (3 GPP access, non-3 GPP access, or both) for serving the UE, e.g., a combined list of DNN, S-nsai and access technologies; validity parameters of the authorization, e.g. validity time/duration, validity location; PRAS grants an authorized maximum bandwidth of radio resources, e.g., carrier frequency, and network slice for serving RAN slices of UEs through NR Uu; the authorized PRAS type for backhaul is e.g. connected to eRG via a non-3 GPP access (option 1) and to eRG IAB node via a 3GPP access (option 2) or directly connected to the gbb as IAB donor (option 3). Each PRAS may be only able to indicate one type for the backhaul; and authorized radio resources, such as carrier frequencies, and network slices for serving as RAN slices for the IAB nodes connected to the backhaul through NR Uu with eRG and gNB (option 2) or directly with gNB (option 3).

Fig. 18 illustrates a block diagram of a communication device, such as an evolved node B (eNB), a next generation node B (gNB) (or another RAN node or base station), a transmit-receive point (TRP), an Access Point (AP), a wireless Station (STA), a Mobile Station (MS), or a User Equipment (UE), in accordance with some aspects. In alternative aspects, the communication device 1800 may operate as a standalone device or may be connected (e.g., networked) to other communication devices.

A circuit (e.g., a processing circuit) is a collection of circuits implemented in a tangible entity comprising hardware (e.g., simple circuitry, gates, logic, etc.) apparatus 1800. Circuit membership may be flexible over time. The circuitry includes members that when operated on can perform specified operations, either alone or in combination. In an example, the hardware of the circuit may be permanently designed to perform a particular operation (e.g., hardwired). In an example, hardware of the circuit may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.), including a machine readable medium of instructions physically modified (e.g., magnetic modification, electrical modification, removable placement of unchanged aggregated particles, etc.) to encode a specific operation.

When the physical components are connected, the underlying electrical properties of the hardware components are changed, for example from an insulator to a conductor, or vice versa. The instructions enable embedded hardware (e.g., execution units or loading mechanisms) to create members of the circuit with hardware via variable connections to perform portions of certain operations when operated on. Thus, in an example, a machine-readable medium element is part of a circuit or other component communicatively coupled to the circuit when the device is operating. In an example, any physical component may be used in more than one member of more than one circuit. For example, in operation, an execution unit may be used in a first circuit of a first circuitry system at one point in time and reused by a second circuit in the first circuitry system or by a third circuit in the second circuitry system at a different time. Additional examples of these components for device 1800 are as follows.

In some aspects, device 1800 may operate as a standalone device or may be connected (e.g., networked) to other devices. In a networked deployment, the communication device 1800 may operate in the capacity of a server-client network environment, as a server communication device, a client communication device, or both. In an example, the communication device 1800 may act as a peer-to-peer (P2P) (or other distributed) communication device in a peer-to-peer (P2P) network environment. The communication device 1800 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smart phone, web appliance, network router, switch or bridge, or any communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by that communication device. In addition, while only a single communication device is illustrated, the term "communication device" should also be understood to include any collection of communication devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein, such as cloud computing, software as a service (software as a service, saaS), and other computer cluster configurations.

Examples as described herein may include or may operate on logic or several components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing specified operations and that can be configured or arranged in a manner. In an example, the circuitry may be arranged as modules in a specified manner (e.g., internally or to an external entity, such as other circuitry). In an example, all or a portion of one or more computer systems (e.g., stand-alone, client, or server computer systems) or one or more hardware processors may be configured by firmware or software (e.g., instructions, application portions, or applications) as modules that operate to perform specified operations. In an example, the software may reside on a communication device readable medium. In one example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.

Thus, the term "module" is understood to encompass a tangible entity, whether physically constructed, specially configured (e.g., hardwired) or temporarily (e.g., transient) configured (e.g., programmed) to operate in a specified manner or to perform some or all of any of the operations described herein. Considering the example of temporarily configuring modules, it is not necessary to instantiate each module at any one time. For example, where a module includes a general-purpose hardware processor configured with software, the general-purpose hardware processor may be configured as each of the different modules at different times. The software may accordingly configure the hardware processor to constitute a particular module at one time and to constitute a different module at a different time, for example.

The communication device (e.g., UE) 1800 may include a hardware processor 1802 (e.g., a central processing unit (central processing unit, CPU), a graphics processing unit (graphics processing unit, GPU), a hardware processor core, or any combination of these), a main memory 1804, a static memory 1806, and a storage device 1807 (e.g., a hard disk drive, a tape drive, a flash memory device, or other block or storage device), some or all of which may communicate with each other via an interconnection link (e.g., bus) 1808.

The communication device 1800 may also include a display device 1810, an alphanumeric input device 1812 (e.g., a keyboard), and a User Interface (UI) navigation device 1814 (e.g., a mouse). In an example, display device 1810, input device 1812, and UI navigation device 1814 may be a touch screen display. The communication device 1800 may also include a signal generating device 1818 (e.g., a speaker), a network interface device 1820, and one or more sensors 1821, such as a global positioning system (global positioning system, GPS) sensor, a compass, an accelerometer, or another sensor. The communication device 1800 may include an output controller 1828, such as a serial (e.g., universal serial bus (universal serial bus, USB)), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (near field communication, NFC), etc.) connection to communicate with or control one or more peripheral devices (e.g., printer, card reader, etc.).

The storage 1807 may include a communication device readable medium 1822 on which is stored one or more sets of data structures or instructions 1824 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. In some aspects, the registers of the processor 1802, the main memory 1804, the static memory 1806, and/or the storage device 1807 may be or may include (be wholly or at least partially included) a device readable medium 1822 having stored thereon one or more sets of data structures or instructions 1824 embodying or utilized by any one or more of the techniques or functions described herein. In an example, one or any combination of the hardware processor 1802, the main memory 1804, the static memory 1804, or the mass storage 1816 may constitute a device-readable medium 1822.

The term "device-readable medium" is used interchangeably with "computer-readable medium" or "machine-readable medium" as used herein. While the communication device-readable medium 1822 is illustrated as a single medium, the term "communication device-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 1824. The term "communication device-readable medium" encompasses the term "machine-readable medium" or "computer-readable medium" and may include any medium capable of storing, encoding or carrying instructions (e.g., instructions 1824) for execution by the communication device 1800 and that cause the communication device 1800 to perform any one or more of the techniques of this disclosure, or capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting examples of communication device readable media may include solid state memory, as well as optical and magnetic media. Specific examples of a communication device readable medium may include non-volatile Memory, such as a semiconductor Memory device (e.g., an electrically programmable read-Only Memory (EPROM), an electrically erasable programmable read-Only Memory (Electrically Erasable Programmable Read-Only Memory), and a flash Memory device; magnetic disks, such as internal hard disks and removable disks; magneto-optical disk; random access memory (Random Access Memory, RAM); CD-ROM and DVD-ROM discs. In some examples, the communication device readable medium may include a non-transitory communication device readable medium. In some examples, the communication device readable medium may include a communication device readable medium that is not a transitory propagating signal.

The instructions 1824 may also be transmitted or received over the communications network 1826 using a transmission medium via the network interface device 1820 using any of a number of transfer protocols. In an example, the network interface device 1820 may include one or more physical jacks (e.g., ethernet, coaxial, or telephone jacks) or one or more antennas to connect to the communications network 1826. In an example, the network interface device 1820 may include multiple antennas to communicate wirelessly using at least one of single-input-multiple-output (SIMO), MIMO, or multiple-input-single-output (MISO) technologies. In some examples, network interface device 1820 may communicate wirelessly using multi-user MIMO technology.

The term "transmission medium" shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the communication device 1800, and includes digital or analog communication signals or another intangible medium to facilitate communication of such software. In this regard, a transmission medium in the context of the present disclosure is a device-readable medium.

The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" are synonymous and may be used interchangeably in this disclosure. These terms are defined to include both machine storage media and transmission media. Thus, these terms include storage devices/media and carrier waves/modulated data signals.

Implementations of the described subject matter may include one or more features, alone or in combination, as illustrated by way of example below.

Example 1 is an apparatus in a residential radio access station (PRAS) for configuration for operation in a fifth generation new radio (5G NR) network, the apparatus comprising: processing circuitry, wherein to configure the PRAS for operation and control by the 5G NR network, the processing circuitry: establishing a communication link to an application server of the 5G NR network via an evolved residential gateway (eRG), the establishment of the communication link causing the PRAS to be configured as an association entity of the eRG, generating a profile of the PRAS, and registering the PRAS in the 5G NR network; decoding signaling received from an application server of the 5G NR network via the eRG, the signaling comprising a profile of the PRAS; determining PRAS configuration information using the profile of the PRAS; and reestablishing a communication link to the application server via eRG of the 5G NR network based on the PRAS configuration information; and a memory coupled with the processing circuit and configured to store a profile of the PRAS.

In example 2, the subject matter as described in example 1 includes the following subject matter: wherein the processing circuitry is configured to establish the communication link via a tethered connection to the eRG.

In example 3, the subject matter described in examples 1-2 includes: the PRAS configuration information includes a PRAS identifier of the PRAS, an indication of an association of the PRAS with the eRG, and PRAS authorization information for communication with an application server of the 5G NR network via a reestablished communication link.

Example 4 is an apparatus in an evolved residential gateway (eRG) configured for operation in a fifth generation new radio (5G NR) network, the apparatus comprising: processing circuitry, wherein to configure the eRG for operation and control by the 5G NR network, the processing circuitry is to: establishing a communication link from a residential radio access station (PRAS) to an application server of the 5G NR network; decoding a profile of the PRAS received from the application server via the communication link; performing registration of the PRAS with the 5G NR network based on the profile; encoding the profile for transmission to the PRAS, the profile including PRAS configuration information; and encode data received from the PRAS for retransmission to the application server based on the PRAS configuration information, and a memory coupled with the processing circuitry and configured to store a profile of the PRAS.

In example 5, the subject matter of example 4 includes the PRAS configuration information including a PRAS identifier of the PRAS, an indication of an association of the PRAS with the eRG, and PRAS authorization information for communication with an application server of the 5G NR network via a reestablished communication link.

In example 6, the subject matter as described in example 5 includes the following subject matter: wherein the PRAS authorization information includes a list of allowed Public Land Mobile Networks (PLMNs), a validity time of an authorization operation of the PRAS, and at least one configuration of an authorization operation of the PRAS.

In example 7, the subject matter of examples 5-6 includes a 5G NR network, the processing circuitry configured to encode a non-access stratum (NAS) message for transmission to the application server, the NAS message requesting registration for the PRAS.

In example 8, the subject matter of example 7 includes the NAS message including the PRAS identifier and a request to authorize the PRAS to communicate within the 5G NR network.

In example 9, the subject matter of examples 5-8 includes a 5G NR network, the processing circuitry configured to encode a registration update request message to transmit to the application server, the registration update request message requesting registration of the PRAS.

In example 10, the subject matter described in examples 4-9 includes the following subject matter: wherein the processing circuitry is configured to decode an update to the PRAS configuration information, the update received from a configuration function of the 5G NR network; and encoding the update for transmission to the PRAS via the communication link.

In example 11, the subject matter of example 10 includes the updating deregistering the PRAS with the 5G NR network.

In example 12, the subject matter described in examples 4-11 includes the following subject matter: wherein the processing circuitry is configured to perform registration of the PRAS with the 5G NR network via one of a user plane 5G connection or a signaling plane 5G connection of the eRG.

Example 13 is a computer-readable storage medium storing instructions for execution by one or more processors of an evolved residential gateway (eRG), the instructions configuring the eRG for operation and control in a fifth generation new radio (5G NR) network and causing the eRG to perform operations comprising: establishing a communication link from a residential radio access station (PRAS) to an application server of the 5G NR network; decoding a profile of the PRAS received from the application server via the communication link; performing registration of the PRAS with the 5G NR network based on the profile; encoding the profile for transmission to the PRAS, the profile including PRAS configuration information; and encoding data received from the PRAS for retransmission to the application server based on the PRAS configuration information,

In example 14, the subject matter of example 13 includes the PRAS configuration information including a PRAS identifier of the PRAS, an indication of an association of the PRAS with the eRG, and PRAS authorization information for communication with an application server of the 5G NR network via a reestablished communication link.

In example 15, the subject matter as described in example 14 includes the following subject matter: wherein the PRAS authorization information includes a list of allowed Public Land Mobile Networks (PLMNs), a validity time of an authorization operation of the PRAS, and at least one configuration of an authorization operation of the PRAS.

In example 16, the subject matter of examples 14-15 includes the 5G NR network further comprising: a non-access stratum (NAS) message is encoded for transmission to the application server, the NAS message requesting registration of the PRAS.

In example 17, the subject matter of example 16 includes the NAS message including the PRAS identifier and a request to authorize the PRAS to communicate within the 5G NR network.

In example 18, the subject matter of examples 14-17 includes the 5G NR network further comprising: a registration update request message is encoded for transmission to the application server, the registration update request message requesting registration of the PRAS.

In example 19, the subject matter of examples 13-18 include, the operations further comprising decoding an update to the PRAS configuration information, the update received from a configuration function of the 5G NR network; and encoding the update for transmission to the PRAS via the communication link.

In example 20, the subject matter of example 19 includes the updating deregistering the PRAS with the 5G NR network.

Example 21 is at least one machine-readable medium comprising instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any one of examples 1-20.

Example 22 is an apparatus comprising means for implementing any of examples 1-20.

Example 23 is a system to implement any of examples 1-20.

Example 24 is a method to implement any of examples 1-20.

While an aspect has been described with reference to specific exemplary aspects, it will be evident that various modifications and changes may be made thereto without departing from the broader scope of the disclosure. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. This detailed description is, therefore, not to be taken in a limiting sense, and the scope of various aspects is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

Claims (20)

1. An apparatus for use in a residential radio access station (PRAS) configured for operation in a fifth generation new radio (5G NR) network, the apparatus comprising:

processing circuitry, wherein to configure the PRAS for operation and control by the 5G NR network, the processing circuitry is to:

-establishing a communication link to an application server of the 5G NR network via an evolved residential gateway (eRG), the establishment of the communication link being such that: configuring the PRAS as an association entity of the eRG, generating a profile of the PRAS, and registering the PRAS in the 5G NR network;

decoding signaling received from an application server of the 5G NR network via the eRG, the signaling comprising a profile of the PRAS;

determining PRAS configuration information using the profile of the PRAS; and is also provided with

Reestablishing a communication link to the application server via the eRG of the 5G NR network based on the PRAS configuration information; and

a memory coupled with the processing circuit and configured to store a profile of the PRAS.

2. The apparatus of claim 1, wherein the processing circuit is configured to:

The communication link is established via a tethered connection to the eRG.

3. The apparatus of claim 1, wherein the PRAS configuration information comprises: a PRAS identifier of the PRAS, an indication of an association of the PRAS with the eRG, and PRAS authorization information for communication with an application server of the 5G NR network via a reestablished communication link.

4. An apparatus for use in an evolved residential gateway (eRG), the eRG configured to operate in a fifth generation new radio (5G NR) network, the apparatus comprising:

processing circuitry, wherein to configure the eRG for operation and control by the 5G NR network, the processing circuitry is to:

establishing a communication link from a residential radio access station (PRAS) to an application server of the 5G NR network;

decoding a profile of the PRAS received from the application server via the communication link;

performing registration of the PRAS with the 5G NR network based on the profile;

encoding the profile for transmission to the PRAS, the profile including PRAS configuration information; and is also provided with

Encoding data received from the PRAS for retransmission to the application server based on the PRAS configuration information; and

A memory coupled with the processing circuit and configured to store a profile of the PRAS.

5. The apparatus of claim 4, wherein the PRAS configuration information comprises: a PRAS identifier of the PRAS, an indication of an association of the PRAS with the eRG, and PRAS authorization information for communication with an application server of the 5G NR network via a reestablished communication link.

6. The apparatus of claim 5, wherein the PRAS authorization information comprises: a list of allowed Public Land Mobile Networks (PLMNs), a validity time of an authorization operation of the PRAS, and at least one configuration of an authorization operation of the PRAS.

7. The apparatus of claim 5, wherein to perform registration of the PRAS with the 5GNR network, the processing circuit is configured to:

a non-access stratum (NAS) message is encoded for transmission to the application server, the NAS message requesting registration of the PRAS.

8. The apparatus of claim 7, wherein the NAS message comprises: the PRAS identifier, and a request to authorize the PRAS to communicate within the 5G NR network.

9. The apparatus of claim 5, wherein to perform registration of the PRAS with the 5GNR network, the processing circuit is configured to:

A registration update request message is encoded for transmission to the application server, the registration update request message requesting registration of the PRAS.

10. The apparatus of claim 4, wherein the processing circuit is configured to:

decoding an update for the PRAS configuration information, the update received from a configuration function of the 5GNR network; and is also provided with

The update is encoded for transmission to the PRAS via the communication link.

11. The apparatus of claim 10, wherein the update deregisters the PRAS with the 5G NR network.

12. The apparatus of claim 4, wherein the processing circuit is configured to:

registration of the PRAS with the 5G NR network is performed via one of a user plane 5G connection or a signaling plane 5G connection of the eRG.

13. A computer-readable storage medium storing instructions for execution by one or more processors of an evolved residential gateway (eRG), the instructions for configuring the eRG to operate and control in a fifth generation new radio (5G NR) network and causing the eRG to perform operations comprising:

Establishing a communication link from a residential radio access station (PRAS) to an application server of the 5G NR network;

decoding a profile of the PRAS received from the application server via the communication link;

performing registration of the PRAS with the 5G NR network based on the profile;

encoding the profile for transmission to the PRAS, the profile including PRAS configuration information; and is also provided with

Data received from the PRAS is encoded for retransmission to the application server based on the PRAS configuration information.

14. The computer-readable storage medium of claim 13, wherein the PRAS configuration information comprises: a PRAS identifier of the PRAS, an indication of an association of the PRAS with the eRG, and PRAS authorization information for communication with an application server of the 5G NR network via a reestablished communication link.

15. The computer-readable storage medium of claim 14, wherein the PRAS authorization information comprises: a list of allowed Public Land Mobile Networks (PLMNs), a validity time of an authorization operation of the PRAS, and at least one configuration of an authorization operation of the PRAS.

16. The computer-readable storage medium of claim 14, wherein the operations for performing registration of the PRAS with the 5G NR network further comprise:

A non-access stratum (NAS) message is encoded for transmission to the application server, the NAS message requesting registration of the PRAS.

17. The computer-readable storage medium of claim 16, wherein the NAS message comprises: the PRAS identifier, and a request to authorize the PRAS to communicate within the 5G NR network.

18. The computer-readable storage medium of claim 14, wherein the operations for performing registration of the PRAS with the 5G NR network further comprise:

a registration update request message is encoded for transmission to the application server, the registration update request message requesting registration of the PRAS.

19. The computer-readable storage medium of claim 13, the operations further comprising:

decoding an update for the PRAS configuration information, the update received from a configuration function of the 5GNR network; and is also provided with

The update is encoded for transmission to the PRAS via the communication link.

20. The computer-readable storage medium of claim 19, wherein the updating deregisters the PRAS with the 5G NR network.