High precision localization in cellular systems

Abstract

A computer readable storage medium stores instructions for execution by one or more processors of a UE to configure the UE for high precision positioning in 5G NR and above networks and to cause the UE to perform operations including decoding configuration messages received from an LMF server. The configuration message indicates at least one DL PRS resource. The DL PRS received from the base station during the DL PRS resource is decoded. At least one positioning measurement is performed using the DL PRS. At least one positioning measurement is encoded for transmission to a base station.

Description

[0001] Priority claim

[0002] This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 495,056, filed on April 7, 2023, entitled “SYSTEMS AND METHODS FOR HIGHACCURACY POSITIONING IN CELLULAR SYSTEMS.” Background Art

[0003] Mobile communications have evolved significantly from early voice-based systems to today's highly complex, integrated communications platforms. As the number of different types of devices communicating with various network devices increases, so too has the use of 3GPP LTE systems. The penetration of mobile devices (user equipment, or UE) in modern society continues to drive demand for a wide range of connected devices in many different environments. Fifth-generation (5G) wireless systems are about to be launched, promising even higher speeds, connectivity, and availability. Next-generation 5G networks (or NR networks) and beyond (e.g., 6G networks) are expected to improve throughput, coverage, and robustness, while reducing latency, operational, and capital expenditures. 5G-NR (and beyond) networks will continue to evolve based on 3GPP LTE-Advanced, with the addition of potential new radio access technologies (RATs) to enrich people's lives with seamless wireless connectivity solutions that deliver fast, rich content and services. As current cellular network frequencies are saturated, higher frequencies (e.g., millimeter wave (mmWave) frequencies) are beneficial due to their high bandwidth.

[0004] It is expected that future releases and 5G and beyond will further enhance the operation of LTE and NR systems in both licensed and unlicensed spectrum. Such enhanced operation may include techniques for high-precision positioning. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals with different letter suffixes may represent different instances of similar components. These figures generally illustrate various aspects discussed in this document by way of example, and not by way of limitation.

[0006] Figure 1A A network architecture according to some aspects is shown.

[0007] Figure 1B and Figure 1C A non-roaming 5G system architecture is shown in accordance with some aspects.

[0008] Figure 2 、 Figure 3 、 Figure 4 and Figure 5 Various systems, architectures, devices, and components are shown in which aspects of the disclosed embodiments may be implemented.

[0009] Figure 6

[0014] An example artificial intelligence (AI) assisted communication architecture for communications between a UE and a RAN according to some aspects is shown.

[0010] Figure 7 An example RAN split architecture according to some aspects is shown.

[0011] Figure 8 A cellular system using sounding reference signal (SRS) transmissions from a positioning reference unit (PRU) and a target UE in the context of uplink carrier phase positioning (UL CPP) or uplink time difference of arrival (UL TDOA) positioning is shown in accordance with some aspects.

[0012] Figure 9 A block diagram of a communication device, such as an evolved Node B (eNB), a next-generation Node B (gNB) (or another RAN node), an NCR, an access point (AP), a wireless station (STA), a mobile station (MS), or a user equipment (UE), is shown in accordance with some aspects. DETAILED DESCRIPTION

[0013] The following description and accompanying drawings sufficiently illustrate the various aspects to enable those skilled in the art to implement them. Other aspects may incorporate structural, logical, electrical, process, and other variations. Portions and features of some aspects may be included in or substituted for portions and features of other aspects. Aspects outlined in the claims encompass all available equivalents of those claims.

[0014] Figure 1A-9 Various systems, devices, and components are shown that can implement aspects of the disclosed embodiments in different communication systems, such as 5G-NR (and above) networks. UEs, base stations (e.g., gNBs), and / or other nodes (e.g., satellites or other computing nodes) discussed herein can be configured to perform the disclosed techniques.

[0015] Figure 1AThe architecture of a network according to some aspects is shown. Communication network 140A is shown as including user equipment (UE) 101 and UE 102. UE 101 and UE 102 are shown as smartphones (e.g., handheld touchscreen mobile computing devices that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as a personal digital assistant (PDA), a pager, a laptop computer, a desktop computer, a wireless phone, a drone, or any other computing device that includes a wired and / or wireless communication interface. UE 101 and UE 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.

[0016] Any radio links described herein (eg, as used in communication network 140A or any other illustrated network) may operate according to any exemplary radio communication technology and / or standard.

[0017] 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 a technique by which multiple carrier signals operating on different frequencies can be used to carry communications for a single UE, thereby increasing the bandwidth available to a single device. In some aspects, carrier aggregation can be used when one or more component carriers operate on unlicensed frequencies.

[0018] The 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 (LSA) in 2.3-2.4 GHz, 3.4 GHz-3.6 GHz, 3.6-3.8 GHz and further frequencies, and Spectrum Access System (SAS) in 3.55-3.7 GHz and further frequencies).

[0019] The aspects described herein can also be applied to different single carrier or OFDM flavors (CP-OFDM, SC-FDMA, SC-OFDM, filter bank based multi-carrier (FBMC), OFDMA, etc.), in particular to 3GPP NR (New Radio) by assigning OFDM carrier data bit vectors to corresponding symbol resources.

[0020] In some aspects, either UE 101 or UE 102 may comprise an Internet of Things (IoT) UE or a Cellular IoT (CIoT) UE, which may include a network access layer designed for low-power IoT applications utilizing short-lived UE connections. In some aspects, either UE 101 or UE 102 may comprise a narrowband (NB) IoT UE (e.g., such as an enhanced NB-IoT (eNB-IoT) UE and a further enhanced (FeNB-IoT) UE). The IoT UE may utilize technologies such as machine-to-machine (M2M) or machine-type communication (MTC) to exchange data with an MTC server or device via a public land mobile network (PLMN), proximity services (ProSe), or device-to-device (D2D) communication, a sensor network, or an IoT network. The M2M or MTC data exchange may be machine-initiated data exchange. The IoT network includes interconnected IoT UEs (which may include embedded computing devices that are uniquely identifiable (within the Internet infrastructure)) with short-lived connections. The IoT UE may execute background applications (e.g., keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0021] In some aspects, either of UE 101 and UE 102 may comprise an enhanced MTC (eMTC) UE or a further enhanced MTC (FeMTC) UE.

[0022] UE 101 and UE 102 may be configured to connect (e.g., be communicatively coupled) to a radio access network (RAN) 110. RAN 110 may be, for example, a Universal Mobile Telecommunications System (UMTS), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a Next Generation RAN (NG RAN), or some other type of RAN. UE 101 and UE 102 utilize connections 103 and 104, respectively, each of which includes a physical communication interface or layer (discussed in further detail below). In this example, connections 103 and 104 are shown as air interfaces that enable the communicative coupling and may conform to cellular communication protocols, such as a Global System for Mobile Communications (GSM) protocol, a Code Division Multiple Access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a Fifth Generation (5G) protocol, a New Radio (NR) protocol, and the like.

[0023] In one aspect, the UE 101 and the UE 102 may also directly exchange communication data via the ProSe interface 105. The ProSe interface 105 may alternatively be referred to as a sidelink interface, which includes one or more logical channels including, but not limited to, a physical sidelink control channel (PSCCH), a physical sidelink shared channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).

[0024] UE 102 is shown as being configured to access access point (AP) 106 via connection 107. Connection 107 may comprise a local wireless connection, such as one conforming to any IEEE 802.11 protocol, according to which AP 106 may comprise a Wireless Fidelity (WiFi®) router. In this example, AP 106 is shown connected to the Internet, rather than to the core network of the wireless system (described in further detail below).

[0025] The RAN 110 may include one or more access nodes that facilitate 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., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). In some aspects, communication nodes 111 and 112 may be transmit / receive points (TRPs). Where communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may function within the NodeB's communication cell. The RAN 110 may include one or more RAN nodes (e.g., macro RAN nodes) for providing macro cells, and one or more RAN nodes (e.g., low-power (LP) RAN nodes or secondary RAN nodes based on unlicensed spectrum) for providing femto cells or pico cells (e.g., cells with smaller coverage areas, lower user capacity, or higher bandwidth than macro cells).

[0026] Either of the communication nodes 111 and 112 may terminate the air interface protocol and may be the first point of contact for the UE 101 and the UE 102. In some aspects, either of the communication nodes 111 and 112 may implement various logical functions for the RAN 110, including but not limited to 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 an example, either of the communication nodes 111 and / or 112 may be a new generation NodeB (gNB), an evolved NodeB (eNB), or another type of RAN node.

[0027] The RAN 110 is shown as being communicatively coupled to a core network (CN) 120 via an S1 interface 113. In some aspects, the CN 120 may be an evolved packet core (EPC) network, a next generation packet core (NPC) network, or some other type of CN (e.g., Figures 1B-1C In this regard, the S1 interface 113 is divided into two parts: an S1-U interface 114, which carries user traffic data between the communication nodes 111 and 112 and the serving gateway (S-GW) 122; and an S1-mobility management entity (MME) interface 115, which is a signaling interface between the communication nodes 111 and 112 and the MME 121.

[0028] In this regard, CN 120 includes MME 121, S-GW 122, Packet Data Network (PDN) Gateway (P-GW) 123, and Home Subscriber Server (HSS) 124. MME 121 may be functionally similar to the control plane of a legacy Serving General Packet Radio Service (GPRS) Support Node (SGSN). MME 121 may manage mobility aspects of access, such as gateway selection and tracking area list management. HSS 124 may include a database for network users (including subscription-related information) to support network entities in handling communication sessions. CN 120 may include one or several HSSs 124, depending on the number of mobile subscribers, device capacity, network organization, and the like. For example, HSS 124 may provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, and the like.

[0029] The S-GW 122 may terminate the S1 interface 113 towards the RAN 110 and route data packets between the RAN 110 and the CN 120. Furthermore, the S-GW 122 may be the local mobility anchor point for handovers between RAN nodes and may also provide an anchor for inter-3GPP mobility. Other responsibilities of the S-GW 122 may include lawful interception, charging, and some policy enforcement.

[0030] P-GW 123 can terminate the SGi interface toward the PDN. P-GW 123 can route data packets between the EPC network (e.g., CN 120) and external networks (e.g., networks including application server 184 (alternatively referred to as application function (AF))) via Internet Protocol (IP) interface 125. P-GW 123 can also deliver data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Generally, application server 184 can be an element that provides applications (e.g., UMTS packet service (PS) domain, LTE PS data services, etc.) that use IP bearer resources with the core network. In this regard, P-GW 123 is shown as being communicatively coupled to application server 184 via IP interface 125. Application server 184 can 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 UE 101 and UE 102 via CN 120.

[0031] P-GW 123 can also be a node for policy enforcement and charging data collection. Policy and Charging Rules Function (PCRF) 126 is the policy and charging control element of CN 120. In non-roaming scenarios, in some aspects, there can be a single PCRF associated with the UE's Internet Protocol Connectivity Access Network (IP-CAN) session in the Home Public Land Mobile Network (HPLMN). In roaming scenarios where service is off-premises, there can be two PCRFs associated with the UE's IP-CAN session: the Home PCRF (H-PCRF) in the HPLMN and the Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). PCRF 126 can be communicatively coupled to application server 184 via P-GW 123.

[0032] In some aspects, the communication network 140A may be an IoT network or a 5G network, including a 5G New Radio network that uses communications in both licensed (5G NR) and unlicensed (5G NR-U) spectrum. One of the current implementers of IoT is narrowband IoT (NB-IoT).

[0033] The NG system architecture may include the RAN 110 and a 5G core network (e.g., CN 120). The RAN 110 in an NG system may be referred to as the NG-RAN. The RAN 110 may include multiple nodes, such as gNBs and NG-eNBs. The CN 120 (also known as the 5G core network or 5GC) may include an access and mobility function (AMF) and / or a user plane function (UPF). The AMF and UPF may be communicatively coupled to the gNBs and NG-eNBs via an NG interface. More specifically, in some aspects, the gNBs and NG-eNBs may be connected to the AMF via an NG-C interface and to the UPF via an NG-U interface. The gNBs and NG-eNBs may be coupled to each other via an Xn interface.

[0034] In some aspects, the NG system architecture may utilize reference points between various nodes as provided in 3GPP Technical Specification (TS) 23.501 (e.g., V15.4.0, December 2018). 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, etc. In some aspects, the gNB may be a master node (MN) in the 5G architecture, while the NG-eNB may be a secondary node (SN). In some aspects, the primary / master node may operate in a licensed frequency band, while the secondary node may operate in an unlicensed frequency band.

[0035] Figure 1B A non-roaming 5G system architecture is shown according to some aspects. Figure 1B, a 5G system architecture 140B is shown with reference points. More specifically, UE 102 can communicate with RAN 110 and one or more other 5G core (5GC) network entities. 5G system architecture 140B includes multiple network functions (NFs), such as access and mobility management function (AMF) 132, location management function (LMF) 133, session management function (SMF) 136, policy control function (PCF) 148, application function (AF) 150, user plane function (UPF) 134, network slice selection function (NSSF) 142, authentication server function (AUSF) 144, and unified data management (UDM) / home subscriber server (HSS) 146. UPF 134 can provide connectivity to data network (DN) 152, which can include, for example, operator services, internet access, or third-party services. AMF 132 can be used to manage access control and mobility, and may also include network slice selection functionality. SMF 136 can be configured to establish and manage various sessions based on network policy. UPF 134 can be deployed in one or more configurations depending on the desired service type. PCF 148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to the PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to the HSS in 4G communication systems).

[0036] LMF 133 can be used in conjunction with 5G positioning functionality. In some aspects, LMF 133 receives measurement and assistance information from RAN 110 and mobile devices (e.g., UE 101) via AMF 132 over the NLs interface to calculate the location of UE 101. In some aspects, positioning information can be carried between the NG-RAN and LMF 133 over the Next Generation Control Plane Interface (NG-C) using NR Positioning Protocol A (NRPPa). In some aspects, LMF 133 configures the UE using the LTE Positioning Protocol (LPP) via AMF 132. RAN 110 configures UE 101 using the Radio Resource Control (RRC) protocol over the LTE-Uu and NR-Uu interfaces.

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

[0038] In some aspects, the 5G system architecture 140B includes an IP multimedia subsystem (IMS) 168B and multiple IP multimedia core network subsystem entities (e.g., call session control functions (CSCFs)). More specifically, the IMS 168B includes CSCFs that can act as proxy CSCFs (P-CSCFs) 162B, serving CSCFs (S-CSCFs) 164B, emergency CSCFs (E-CSCFs) ( Figure 1B 168B). The P-CSCF 162B may be configured as the first point of contact for the UE 102 within the IMS 168B. The S-CSCF 164B may be configured to handle session state in the network, and the E-CSCF may be configured to handle certain aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF 166B may be configured to serve as the point of contact within the operator's network for all IMS connections destined for subscribers of the network operator or for roaming subscribers currently located within the service area of ​​the network operator. In some aspects, the I-CSCF 166B may be connected to another IP multimedia network 170, such as an IMS operated by a different network operator.

[0039] In some aspects, the UDM / HSS 146 may be coupled to an application server (AS) 160B, which may include a telephony application server (TAS) or another AS. The AS 160B may be coupled to an IMS 168B via an S-CSCF 164B or an I-CSCF 166B.

[0040] Reference point representation indicates that there can be interaction between corresponding NF services. For example, Figure 1B132), N7 (between SMF 136 and PCF 148), N8 (between UDM / HSS 146 and AMF 132), N9 (between both UPFs), N10 (between UDM / HSS 146 and SMF 136), N11 (between AMF 132 and SMF 136), N12 (between AUSF 144 and AMF 132), N13 (between AUSF 144 and UDM / HSS 146), N14 (between SMF 136 and PCF 148), N15 (between UDM / HSS 146 and AMF 132), N16 (between SMF 136 and PCF 148), N17 (between SMF 136 and PCF 148), N18 (between UDM / HSS 146 and AMF 132), N19 (between both UPFs), N20 (between UDM / HSS 146 and SMF 136), N21 (between AMF 132 and SMF 136), N22 (between AUSF 144 and AMF 132), N23 (between SMF 136 and PCF 148), N24 (between SMF 136 and PCF 148), N25 146), N14 (between two AMFs), N15 (between PCF 148 and AMF 132 in the case of non-roaming scenario, or between PCF 148 and the visited network and AMF 132 in the case of roaming scenario), N16 (between two SMFs, not shown), and N22 (between AMF 132 and NSSF 142). Figure 1B Other reference points not shown are indicated.

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

[0042] In some aspects, such as Figure 1CAs shown, a service-based representation can be used to represent network functions within the control plane that enable other authorized network functions to access their services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf 158H (a service-based interface exposed by AMF 132), Nsmf 158I (a service-based interface exposed by SMF 136), Nnef 158B (a service-based interface exposed by NEF 154), Npcf 158D (a service-based interface exposed by PCF 148), Nudm 158E (a service-based interface exposed by UDM / HSS 146), Naf 158F (a service-based interface exposed by AF 150), Nnrf 158C (a service-based interface exposed by NRF 156), Nnssf 158A (a service-based interface exposed by NSSF 142), and Nausf 158G (a service-based interface exposed by AUSF 144). Figure 1C Other service-based interfaces not shown (e.g., Nudr, N5g-eir, and Nudsf).

[0043] Figure 2 An example network architecture 200 is depicted. Network 200 can operate in a manner consistent with 3GPP technical specifications for LTE or 5G / NR systems and can implement the disclosed techniques (e.g., the disclosed techniques can be configured / implemented by one or more devices operating within network architecture 200). However, example embodiments are not limited in this regard, and the described examples can be applied to other networks (e.g., future 3GPP systems, etc.) that benefit from the principles described herein.

[0044] The network 200 includes a UE 202, which is any mobile or non-mobile computing device designed to communicate over an air connection with a RAN 204. The UE 202 is communicatively coupled to the RAN 204 via a Uu interface, which may be applicable to both LTE and NR systems. Examples of UE 202 include, but are not limited to, smartphones, tablet computers, wearable devices (e.g., smart watches, fitness trackers, smart glasses, smart clothing / fabrics, head-mounted displays, smart displays, etc.), desktop computers, workstations, laptop computers, in-vehicle infotainment systems, in-vehicle entertainment systems, instrument clusters, heads-up display (HUD) devices, on-board diagnostic devices, instrument cluster mobile devices, mobile data terminals, electronic engine management systems, electronic / engine control units, electronic / engine control modules, embedded systems, sensors, microcontrollers, control modules, engine management systems, connected home appliances, machine type communication devices, machine-to-machine (M2M), device-to-device (D2D), machine type communication (MTC) devices, Internet of Things (IoT) devices, smart home appliances, flying drones or unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, electronic signs, single board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel Edison, etc.), plug-and-play computers, and / or any type of computing device (e.g., any of those discussed herein).

[0045] Additionally or alternatively, UE 202 may be a reduced capability (RedCap) UE, which is a UE with reduced capabilities as specified in clause 4.2.21.1 of 3GPP TS 38.306 v17.4.0 (2023-03-30) ("[TS38306]").

[0046] The network 200 may include a set of UEs 202 that are directly coupled to each other via D2D, ProSe, PC5, and / or SL interfaces and / or any other suitable interface (e.g., any of the interfaces discussed herein). These UEs 202 may be M2M / D2D / MTC / IoT devices and / or vehicle-mounted systems that communicate using physical sidelink channels (e.g., but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.). The UEs 202 may perform blind decoding attempts on the SL channels / links according to various examples described herein.

[0047] In some examples, UE 202 can also communicate with AP 206 via an over-the-air (OTA) connection. AP 206 manages a WLAN connection, which can be used to offload some / all network traffic from RAN 204. The connection between UE 202 and AP 206 can conform to any IEEE 802.11 protocol. In addition, UE 202, RAN 204, and AP 206 can utilize cellular-WLAN aggregation / integration (e.g., LWA / LWIP). Cellular-WLAN aggregation can involve UE 202 being configured by RAN 204 to utilize both cellular radio resources and WLAN resources.

[0048] RAN 204 includes one or more access network nodes (ANs) 208. AN 208 terminates the air interface for UE 202 by providing access to access stratum protocols, including RRC, PDCP, RLC, MAC, and PHY / L1 protocols. In this manner, AN 208 facilitates data / voice connectivity between CN 220 and UE 202. AN 208 can be a macrocell base station, or a low-power base station for a femtocell, picocell, or other similar cell with a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell, or some combination thereof. In these implementations, AN 208 may be referred to as a base station (BS), gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, etc.

[0049] One example implementation is a "CU / DU split" architecture, in which the AN 208 is embodied as a gNB Central Unit (CU) communicatively coupled to one or more gNB Distributed Units (DUs), each of which may be communicatively coupled to one or more Radio Units (RUs) (also known as RRHs, RRUs, etc.) (see, for example, [TS38401]). In some implementations, one or more RUs may be separate RSUs. In some implementations, the CU / DU split may include one ng-eNB-CU and one or more ng-eNB-DUs, respectively, instead of or in addition to the gNB-CU and gNB-DU, respectively. The AN 208 acting as a CU may be implemented in a discrete device or as one or more software entities running on a server computer, for example, as part of a virtual network, including a virtual baseband unit (BBU) or BBU pool, cloud RAN (CRAN), radio equipment controller (REC), radio cloud center (RCC), centralized RAN (C-RAN), virtualized RAN (vRAN), etc. (although these terms may refer to different implementation concepts). Any other type of architecture, arrangement, and / or configuration may be used.

[0050] The set of ANs may be coupled to each other via an X2 interface (if RAN 204 is an LTE RAN or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 210) or an Xn interface (if RAN 204 is an NG-RAN 214). The X2 / Xn interface (which, in some examples, may be separated into control / user plane interfaces) may allow the ANs to communicate information related to handover, data / context transfer, mobility, load management, interference coordination, etc.

[0051] Each AN of the RAN 204 may manage one or more cells, cell groups, component carriers, etc., to provide an air interface for network access to the UE 202. The UE 202 may be simultaneously connected to a group of cells provided by the same or different ANs 208 of the RAN 204. For example, the UE 202 and the RAN 204 may use carrier aggregation to allow the UE 202 to connect to a group of component carriers, each corresponding to a PCell or an Scell. In a dual connectivity scenario, the first AN 208 may be a primary node providing an MCG, while the second AN 208 may be a secondary node providing an SCG. The first and second ANs 208 may be any combination of eNBs, gNBs, ng-eNBs, etc.

[0052] The RAN 204 can provide an air interface over licensed or unlicensed spectrum. To operate in unlicensed spectrum, a node can use LAA, eLAA, and / or feLAA mechanisms based on carrier aggregation with PCell / Scell. Before accessing the unlicensed spectrum, the node can perform medium / carrier sensing operations based on, for example, a listen-before-talk (LBT) protocol.

[0053] Additionally or alternatively, each UE 202 provides radio information to one or more ANs 208 and / or one or more edge computing nodes (e.g., edge servers / hosts, etc.). The radio information may be in the form of one or more measurement reports and may include, for example, signal strength measurements, signal quality measurements, etc. Each measurement report is marked with a timestamp and the location of the measurement (e.g., the current location of the UE 202).As an example, the measurement results collected by the UE 202 and / or included in the measurement report may include one or more of the following: bandwidth (BW), network or cell load, latency, jitter, round trip time (RTT), number of interruptions, out-of-order delivery of data packets, transmission power, bit error rate, bit error rate (BER), block error rate (BLER), packet error rate (PER), packet loss rate, packet reception rate (PRR), data rate, peak data rate, end-to-end (e2e) delay, signal-to-noise ratio (SNR), signal-to-noise-and-distortion ratio (SINR), signal-to-noise-and-distortion (SINAD) ratio, carrier-to-interference-and-noise ratio (CINR), additive white Gaussian noise (AWGN), energy per bit to noise power density ratio (Eb / N0), and power density per chip. Energy to interference power density ratio (Ec / I0), energy to noise power density ratio per chip (Ec / N0), peak to average power ratio (PAPR), reference signal received power (RSRP), reference signal received path power (RSRPP), reference signal received quality (RSRQ), received signal strength indication (RSSI), received channel power indication (RCPI), received signal to noise ratio indication (RSNI), received signal code power (RSCP), reference signal carrier phase (RSCP), reference signal carrier phase difference (RSCPD), carrier phase location (CPP), reference signal time difference (RSTD), sidelink synchronization signal block (S-SSB) measurement (including SSB_RP (bearing NR measured at the UE antenna connector or radiating interface boundary) Received (linear) average power of resource elements of SSB signals and channels, etc.), relative time difference (RTD), receiver (Rx) time delay, Rx timing error, transmitter (Tx) time delay, Tx timing error, NR E-CID, observed time difference of arrival (OTDOA), average noise plus interference (ANPI), GNSS timing of cell frames for UE positioning for E-UTRAN or 5G / NR (e.g., timing between the AP or RAN node reference time and the GNSS-specific reference time for a given GNSS), GNSS code measurements (e.g., GNSS code phase (integer and fractional parts) of the spreading code of the i-th GNSS satellite signal), GNSS carrier phase measurements (e.g., the number of carrier-phase cycles (integer and fractional parts) of the i-th GNSS satellite signal measured since lock to the signal; also known as accumulated delta range (ADR)), channel interference measurements, thermal noise power measurements, received interference power measurements, power histogram measurements, channel load measurements, STA statistics, and / or other similar measurements.RSRP, RSSI and / or RSRQ measurements may include RSRP, RSSI and / or RSRQ measurements of cell-specific reference signals, channel state information reference signals (CSI-RS) and / or synchronization signals (SS) or SS blocks for 3GPP networks (e.g., LTE or 5G / NR), and RSRP, RSSI, RSRQ, RCPI, RSNI and / or ANPI measurements of various beacons, fast initial link setup (FILS) discovery frames or probe response frames for WLAN / WiFi (e.g., [IEEE80211]) networks. Other measurements may additionally or alternatively be used, such as those discussed in 3GPP TS 36.214 v17.0.0 (2022-03-31) (“[TS36214]”), 3GPP TS 38.215 v17.3.0 (2023-03-30) (“[TS38215]”), 3GPP TS 38.314 v17.2.0 (2023-01-13) (“[TS38314]”), IEEE Standard for Information Technology--Telecommunications and Information Exchange between Systems--Local and Metropolitan Area Networks--Specific Requirements - Part 11:Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std 802.11-2020, pp. 1-4379 (26 Feb. 2021) ("[IEEE 80211]"), etc. Additionally or alternatively, any of the above measurements (or combinations of measurements) may be collected by one or more ANs 208 and provided to the edge computing nodes.

[0054] Additionally or alternatively, the measurements may include one or more of the following measurements: measurements related to data radio bearers (DRBs) (e.g., the number of DRBs attempted to be established, the number of DRBs successfully established, the number of active DRBs released, the intra-session activity time of DRBs, the number of DRBs attempted to be recovered, the number of DRBs successfully recovered, etc.); measurements related to radio resource control (RRC) (e.g., the average number of RRC connections, the maximum number of RRC connections, the average number of stored inactive RRC connections, the maximum number of stored inactive RRC connections, the number of attempted, successful and / or failed RRC connection establishments, etc.); measurements related to UE context (UECNTX); measurements related to radio resource utilization (RRU) (e.g., DL total PRB usage, UL total PRB usage, distribution of DL total PRB usage, distribution of UL total PRB usage, DL PRBs used for data services, UL PRBs used for data services PRB, total available DL PRB, total available UL PRB, etc.); measurements related to registration management (RM); measurements related to session management (SM) (e.g., number of PDU sessions requested to be established; number of PDU sessions successfully established; number of PDU sessions failed to be established, etc.); measurements related to GTP management (GTP); measurements related to IP management (IP); measurements related to policy association (PA); measurements related to mobility management (MM) (e.g., for inter-RAT, intra-RAT and / or intra-frequency / inter-frequency handover and / or conditional handover); : Number of requested, successful and / or failed handover preparations; Number of requested, successful and / or failed handover resource allocations; Number of requested, successful and / or failed handover executions; Average and / or maximum time of requested handover executions; Number of successful and / or failed handover executions per beam pair, etc.); Measurements related to virtualized resources (VR); Measurements related to carriers (CARR); Measurements related to QoS flows (QF) (e.g., number of active QoS flows released, number of QoS flows attempted to be released, intra-session activity time of QoS flows, UE 202, the number of QoS flows attempted to be established, the number of QoS flows successfully established, the number of QoS flows that failed to be established, the number of initial QoS flows attempted to be established, the number of initial QoS flows successfully established, the number of initial QoS flows that failed to be established, the number of QoS flows attempted to be modified, the number of QoS flows successfully modified, the number of QoS flows that failed to be modified, etc.); measurements related to application triggering (AT); measurements related to short message service (SMS); measurements related to power, energy and environment (PEE); measurements related to NF service (NFS); measurements related to packet flow description (PFD); measurements related to random access channel (RACH); measurements related to measurement report (MR);Measurements related to Layer 1 Measurements (L1M); measurements related to Network Slice Selection (NSS); measurements related to Paging (PAG); measurements related to Non-IP Data Transfer (NIDD); measurements related to External Parameter Provisioning (EPP); measurements related to Traffic Impact (TI); measurements related to Connection Establishment (CE); measurements related to Service Parameter Provisioning (SPP); measurements related to Background Data Transfer Policy (BDTP); measurements related to Data Management (DM); and / or any other performance measurements, such as those discussed in 3GPP TS 28.552 v17.3.1 (2021-06-24) ("[TS28552]"), 3GPP TS 32.425 v17.1.0 (2021-06-24) ("[TS32425]"), etc.;

[0055] Radio information may be reported in response to a trigger event and / or in a periodic manner. Additionally or alternatively, each UE 202 reports radio information with a low period or a high period based on an upcoming data transmission and / or other information about the data transmission. Additionally or alternatively, the edge computing node may request measurements from the AN 208 with a low period or a high period, or the AN 208 may provide measurements to the edge computing node with a low period or a high period. Additionally or alternatively, the edge computing node may obtain other relevant data (e.g., key performance indicators (KPIs)) from other edge computing nodes, core network functions (NFs), application functions (AFs), and / or other UEs 202, together with or separately from the measurement reports.

[0056] Additionally or alternatively, in the event that observed data from one or more UEs, one or more RAN nodes, and / or core network NFs exhibit discrepancies (e.g., missing reports, erroneous data, etc.), simple padding can be performed to supplement the acquired observed data, such as replacing values ​​from previous reports and / or historical data, applying extrapolation filtering, etc. Additionally or alternatively, acceptable boundaries for observed data can be pre-determined or configured. For example, CQI and MCS measurement values ​​can be configured to fall only within the ranges defined by the appropriate 3GPP standard. In the event that reported data values ​​are meaningless (e.g., the value falls outside the acceptable range / bounds, etc.), such values ​​can be discarded for the current learning / training round or cycle. For example, in the case of packet delivery, delay boundaries can be defined or configured, and packets determined to be received after the packet delivery delay boundary can be discarded.

[0057] UE 202 may also perform reference signal (RS) measurement and reporting procedures to provide information to the network regarding the quality of one or more wireless channels and / or the communication medium in general, and this information may be used to optimize various aspects of the communication system. As examples, the measurement and reporting procedures performed by the UE 202 may include those discussed in 3GPP TS 38.211 v17.4.0 (2023-01-04) (“[TS38211]”), 3GPP TS 38.212 v17.4.0 (2023-01-04) (“[TS38212]”), 3GPP TS 38.213 v17.4.0 (2023-01-04) (“[TS38213]”), 3GPP TS 38.214 v17.4.0 (2023-01-04) (“[TS38214]”), 3GPP TS 38.101-1 (“[TS38215]”). v18.0.0 (2023-01-12) ("[TS38.101-1]"), 3GPP TS 38.104 v18.0.0 (2023-01-10) ("[TS38104]"), 3GPP TS 38.133 v18.0.0 (2023-01-12) ("[TS38133]"), [TS38331], etc. The physical signals and / or RSs may include a demodulation reference signal (DM-RS), a phase tracking reference signal (PT-RS), a positioning reference signal (PRS), a channel state information reference signal (CSI-RS), a synchronization signal block (SSB), a primary synchronization signal (PSS), a secondary synchronization signal (SSS), and a sounding reference signal (SRS).

[0058] In any of the examples discussed herein, any suitable data collection and / or measurement mechanism can be used to collect observation data. For example, data tagging (e.g., sequence numbering, etc.), packet tracking, signal measurement, data sampling, and / or timestamp techniques can be used to determine any of the above metrics / observations. The collection of data can be based on the occurrence of an event that triggers data collection. Additionally or alternatively, data collection can be performed when an event is initiated or terminated. Data collection can be continuous, discontinuous, and / or have a start and stop time. The data collection techniques / mechanisms can be specific to the HW configuration / implementation, or non-HW specific, or can be based on various software parameters (e.g., OS type and version, etc.). Various configurations can be used to define any of the above data collection parameters. Such configurations may be defined by suitable specifications / standards, such as 3GPP (e.g., [SA6Edge]), ETSI (e.g., [MEC]), O-RAN (e.g., [O-RAN]), Intel® Smart Edge Open (formerly OpenNESS) (e.g., [ISEO]), IETF (e.g., MAMS [RFC8743]), IEEE / WiFi (e.g., [IEEE80211], [WiMAX], [IEEE16090], etc.), and / or any other similar standards (e.g., those discussed herein).

[0059] In a V2X scenario, the UE 202 or AN 208 can be or act as a roadside unit (RSU). An RSU can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable AN or a fixed (or relatively fixed) UE. An RSU implemented in or by a UE can be referred to as a "UE-type RSU," an eNB as an "eNB-type RSU," a gNB as a "gNB-type RSU," or other similar terms. In one example, an RSU is a computing device coupled to radio frequency circuitry located on the roadside that provides connectivity support to passing vehicular UEs. The RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for monitoring and controlling ongoing vehicular and pedestrian traffic. The RSU can provide the very low-latency communications required for high-speed events (e.g., collision avoidance, traffic warnings, etc.). Additionally or alternatively, the RSU can provide other cellular / WLAN communication services. The components of the RSU can be enclosed in a weatherproof enclosure suitable for outdoor installation and can include a network interface controller for providing a wired connection (e.g., Ethernet) to a traffic signal controller or backhaul network. Furthermore, one or more V2X RATs can be employed, allowing V2X nodes to communicate directly with each other, with infrastructure equipment (e.g., AN 208), and / or with other devices / nodes. In some implementations, at least two different V2X RATs can be used, including a WLAN V2X (W-V2X) RAT based on IEEE V2X technology (e.g., DSRC in the United States and ITS-G5 in Europe) and a cellular V2X (C-V2X) RAT based on 3GPP V2X technology (e.g., LTE V2X, 5G / NR V2X, and beyond). In one example, the C-V2X RAT can utilize a C-V2X air interface, while the WLAN V2X RAT can utilize a W-V2X air interface.

[0060] The W-V2X RAT includes, for example, the IEEE Wireless Access to Vehicular Environments (WAVE) Architecture Guide, IEEE Standards Association, IEEE 1609.0-2019 (April 10, 2019) (“[IEEE 16090]”), the V2X Communication Message Set Dictionary, SAE Int'l (July 23, 2020) (“[J2735_202007]”), Intelligent Transportation Systems in the 5 GHz Band (ITS-G5), [IEEE 80211p] (which is the Layer 1 (L1) and Layer 2 (L2) portions of WAVE, DSRC, and ITS-G5), and / or the IEEE Standard for the Air Interface of Broadband Wireless Access Systems, IEEE Std 802.16-2017, pages 1-2726 (March 2, 2018) (“[WiMAX]”). The term "DSRC" refers to vehicular communications using the 5.9 GHz band commonly used in the United States, while "ITS-G5" refers to vehicular communications using the 5.9 GHz band in Europe. Because any number of different RATs (including the [IEEE80211p] RAT) may be used in any geographic or political region, the terms "DSRC" (used in regions such as the United States) and "ITS-G5" (used in regions such as Europe) are used interchangeably throughout this disclosure. The access layer for the ITS-G5 interface is outlined in ETSI EN 302 663 V1.3.1 (2020-01) (hereinafter referred to as "[EN302663]"), which describes the access layer of the ITS-S reference architecture. The ITS-G5 access layer includes features of [IEEE80211] (now incorporated into [IEEE80211p]), as well as the Decentralized Congestion Control (DCC) approach discussed in ETSI TS 102 687 V1.2.1 (2018-04) ("[TS102687]"). The access stratum based on the 3GPP LTE-V2X interface is outlined in particular in ETSI EN 303 613 V1.1.1 (2020-01), 3GPP TS 23.285 v16.2.0 (2019-12); and 3GPP 5G / NR-V2X is outlined in particular in 3GPP TR 23.786 v16.1.0 (2019-06) and 3GPP TS 23.287 v18.0.0 (2023-03-31) ("[TS23287]").

[0061] In an example where the RAN 204 is an E-UTRAN 210 having one or more eNBs 212, the E-UTRAN 210 provides an LTE air interface (Uu) having parameters and characteristics as discussed at least in 3GPP TS 36.300 v17.2.0 (2022-09-30) ("[TS36300]"). In an example where the RAN 204 is a next-generation (NG)-RAN 214 having a set of gNBs 216, each gNB 216 connects to a 5G-capable UE 202 using a 5G-NR air interface (also referred to as a Uu interface) having parameters and characteristics as discussed in [TS38300] and many other 3GPP standards. In the case where the NG-RAN 214 includes a set of ng-eNBs 218, one or more ng-eNBs 218 connect to the UE 202 via a 5G Uu and / or LTE Uu interface. The gNB 216 and ng-eNB 218 are connected to the 5GC 240 via corresponding NG interfaces (including N2 interfaces, N3 interfaces, and / or other interfaces). The gNB 216 and ng-eNB 218 are connected via Xn interfaces. In addition, each gNB 216 is connected via a corresponding Xn interface, and each ng-eNB 218 is connected via a corresponding Xn interface. In some examples, the NG interface can be divided into two parts: an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 214 and the UPF 248 (e.g., N3 interface); and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN 214 and the AMF 244 (e.g., N2 interface).

[0062] NG-RAN 214 can provide a 5G-NR air interface (also referred to as a Uu interface) with the following features: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar codes, repetition codes, simplex codes, and Reed-Muller codes for control; and LDPC for data. Similar to the LTE air interface, the 5G-NR air interface can rely on CSI-RS and PDSCH / PDCCH DMRS. The 5G-NR air interface may not use CRS but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking of the PDSCH; and tracking reference signals for time tracking. The 5G-NR air interface can operate in either FR1, which includes sub-6 GHz bands, or FR2, which includes bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface can include SSBs, which are regions of the downlink resource grid that include the PSS / SSS / PBCH.

[0063] The 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used to dynamically adapt the SCS. For example, a UE 202 can be configured with multiple BWPs, each configured with a different SCS. When a BWP change is indicated to the UE 202, the transmitted SCS also changes. Another example use case for BWPs relates to power conservation. Specifically, a UE 202 can be configured with multiple BWPs with varying amounts of frequency resources (e.g., PRBs) to support data transmission in different traffic load scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with light traffic load, while allowing power conservation at the UE 202 and, in some cases, at the gNB 216. A BWP containing a larger number of PRBs can be used in scenarios with higher traffic loads.

[0064] In some implementations, each gNB 216 may include a gNB-CU and a set of gNB-DUs. Additionally or alternatively, the gNB 216 may include one or more RUs. In these implementations, the gNB-CU may be connected to each gNB-DU via a corresponding F1 interface. In the case of network sharing with multiple cell ID broadcasts, each cell ID associated with a PLMN subset corresponds to a gNB-DU, and the gNB-CUs are connected to share cell resources on the same physical layer. For resiliency, a gNB-DU can be connected to multiple gNB-CUs through appropriate implementation. Furthermore, the gNB-CU may be separated into gNB-CU control plane (gNB-CU-CP) and gNB-CU user plane (gNB-CU-UP) functionality. The gNB-CU-CP connects to the gNB-DU via the F1 control plane interface (F1-C), the gNB-CU-UP connects to the gNB-DU via the F1 user plane interface (F1-U), and the gNB-CU-UP connects to the gNB-CU-CP via the E1 interface. In some implementations, a gNB-DU is connected to only one gNB-CU-CP, and a gNB-CU-UP is connected to only one gNB-CU-CP. For resiliency, a gNB-DU and / or gNB-CU-UP can be connected to multiple gNB-CU-CPs with appropriate implementation. A gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and a gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP. Xn-U can support data forwarding between gNB-CU-UPs during intra-gNB-CU-CP handover within a gNB.

[0065] Similarly, each ng-eNB 218 may include an ng-eNB-CU and a set of ng-eNB-DUs. In these implementations, the ng-eNB-CU and each ng-eNB-DU are connected via a corresponding W1 interface. The ng-eNB may include an ng-eNB-CU-CP, one or more ng-eNB-CU-UPs, and one or more ng-eNB-DUs. The ng-eNB-CU-CP and the ng-eNB-CU-UPs are connected via the E1 interface. The ng-eNB-DU is connected to the ng-eNB-CU-CP via the W1-C interface and to the ng-eNB-CU-UP via the W1-U interface. The general principles described herein with respect to the gNB aspect also apply to the ng-eNB aspect and the corresponding E1 and W1 interfaces unless otherwise specified.

[0066] The node hosting the user plane portion of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and, for EN-DC, the MeNB or SgNB, depending on the bearer split) performs user inactivity monitoring. Furthermore, it notifies the nodes with control plane connectivity to the core network (e.g., via E1, X2, etc.) of its inactivity or (re)activation. The node hosting the RLC protocol layer (e.g., gNB-DU) can perform user inactivity monitoring and further notify the node hosting the control plane (e.g., gNB-CU or gNB-CU-CP) of its inactivity or (re)activation.

[0067] In these implementations, the NG-RAN 214 is layered into the Radio Network Layer (RNL) and the Transport Network Layer (TNL). The NG-RAN 214 architecture (e.g., NG-RAN logical nodes and the interfaces between them) is part of the RNL. For each NG-RAN interface (e.g., NG, Xn, F1, etc.), the relevant TNL protocols and functions are specified in [TS38401], for example. The TNL provides services for user plane transport and / or signaling transport. In an NG-Flex configuration, each NG-RAN node is connected to all AMFs, where the 244 AMFs represent the set of AMFs within an AMF area, supporting at least one slice also supported by the NG-RAN node. AMF sets and AMF areas are defined in [TS23501].

[0068] RAN 204 is communicatively coupled to CN 220, which includes network elements and / or network functions (NFs) for providing various functions to support data and telecommunication services for customers / subscribers (e.g., UE 202). The components of CN 220 may be implemented in a single physical node or in separate physical nodes. In some examples, NFV may be used to virtualize any or all functions provided by the network elements of CN 220 onto physical compute / storage resources such as servers, switches, etc. A logical instantiation of CN 220 may be referred to as a network slice, while a logical instantiation of a portion of CN 220 may be referred to as a network sub-slice.

[0069] CN 220 may be an LTE CN 222 (also referred to as an Evolved Packet Core (EPC) 222). EPC 222 may include MME 224, SGW 226, SGSN 228, HSS 230, PGW 232, and PCRF 234, which are coupled to each other via interfaces (or "reference points") as shown. The NFs in EPC 222 are briefly described below.

[0070] MME 224 implements mobility management functions to track the current location of UE 202 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, etc. SGW 226 terminates the S1 interface toward RAN 210 and routes data packets between RAN 210 and EPC 222. SGW 226 can be the local mobility anchor for inter-RAN node handovers and can also provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful interception, charging, and certain policy enforcement. SGSN 228 tracks the location of UE 202 and performs security functions and access control. SGSN 228 also performs inter-EPC node signaling for mobility between different RAT networks; MME 224-specified PDN and S-GW selection; MME 224 selection for handovers; etc. The S3 reference point between MME 224 and SGSN 228 enables the exchange of user and bearer information for inter-3GPP onboard mobility in idle / active states. The HSS 230 includes a database for network users (including subscription-related information) to support network entities in handling communication sessions. The HSS 230 can provide support for routing / roaming, authentication, authorization, naming / addressing resolution, location dependencies, and more. The S6a reference point between the HSS 230 and the MME 224 facilitates the transfer of subscription and authentication data for authenticating and authorizing users to access the EPC 222. The PGW 232 terminates the SGi interface toward a data network (DN) 236, which may include application (app) / content servers 238. The PGW 232 routes data packets between the EPC 222 and the data network 236. The PGW 232 is coupled to the SGW 226 via the S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 232 may also include nodes (e.g., PCEF) for policy enforcement and charging data collection. Furthermore, the SGi reference point communicatively couples the PGW 232 to the same or different data networks 236. The PGW 232 can be communicatively coupled to the PCRF 234 via the Gx reference point. The PCRF 234 is the policy and charging control element of the EPC 222. The PCRF 234 is communicatively coupled to the app / content server 238 to determine the appropriate QoS and charging parameters for the service flow. The PCRF 234 also distributes the associated rules to the PCEF (via the Gx reference point) with the appropriate TFT and QCI.

[0071] CN 220 may be 5GC 240, which includes AUSF 242, AMF 244, SMF 246, UPF 248, NSSF 250, NEF 252, NRF 254, PCF 256, UDM 258, and AF 260, which are coupled to each other through various interfaces as shown. The NFs in 5GC 240 are briefly introduced as follows.

[0072] The AUSF 242 stores data used for authentication of the UE 202 and handles authentication-related functions. The AUSF 242 may facilitate a common authentication framework for various access types.

[0073] The AMF 244 allows other functions of the 5GC 240 to communicate with the UE 202 and the RAN 204 and to subscribe to notifications about mobility events specific to the UE 202. The AMF 244 is also responsible for registration management (e.g., for registering the UE 202), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 244 provides transport for SM messages between the UE 202 and the SMF 246 and acts as a transparent proxy for routing SM messages. The AMF 244 also provides transport for SMS messages between the UE 202 and the SMSF. The AMF 244 interacts with the AUSF 242 and the UE 202 to perform various security anchoring and context management functions. Furthermore, the AMF 244 is the termination point for the RAN-CP interface, which includes the N2 reference point between the RAN 204 and the AMF 244. The AMF 244 is also the termination point for NAS (N1) signaling and performs NAS encryption and integrity protection.

[0074] The AMF 244 also supports NAS signaling with the UE 202 over the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF can be the termination point for the N2 interface between the (R)AN 204 and the AMF 244 for the control plane, and the N3 reference point between the (R)AN 214 and the UPF 248 for the user plane. Thus, the AMF 244 handles N2 signaling from the SMF 246 and the AMF 244 for PDU sessions and quality of service, encapsulates / decapsulates packets for IPSec and N3 tunnels, marks N3 user plane packets in the uplink, and enforces quality of service corresponding to N3 packet markings, taking into account quality of service requirements linked to such markings received over N2. The N3IWF may also relay UL and DL control plane NAS signaling between the UE 202 and the AMF 244, and relay uplink and downlink user plane packets between the UE 202 and the UPF 248 via the N1 reference point between the UE 202 and the AMF 244. The N3IWF also provides a mechanism for establishing an IPsec tunnel with the UE 202. The AMF 244 may expose an interface based on Namf services and may be used for the N14 reference point between two AMFs 244 and for communication between the AMF 244 and the 5G-EIR ( Figure 2 The termination point of the N17 reference point between the two reference points (not shown).

[0075] SMF 246 is responsible for SM (e.g., session establishment, tunnel management between UPF 248 and AN 208); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring traffic steering at UPF 248 to route traffic to the correct destination; terminating the interface towards the policy control function; controlling part of policy enforcement, billing, and quality of service; lawful interception (for SM events and interface to the LI system); terminating the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information sent to AN 208 via AMF 244 over N2; and determining the SSC mode for the session. SM refers to the management of PDU sessions, and PDU sessions or "sessions" refer to PDU connection services that provide or enable the exchange of PDUs between UE 202 and DN 236. The SMF 246 may also include the following functions to support edge computing enhancements (see, for example, [TS23548]): select the EASDF 261 and provide its address to the UE as the DNS server for the PDU session; use the EASDF 261 services defined in [TS23548]; and provide and update ECS address configuration information to the UE in support of the application layer architecture defined in [TS23558]. The discovery and selection process for the EASDF 261 is discussed in [TS23501] §6.3.23.

[0076] The UPF 248 serves as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point for interconnection to the data network 236, and a branching point to support multi-homed PDU sessions. The UPF 248 also performs packet routing and forwarding, packet inspection, enforces the user plane portion of policy rules, performs lawful interception of packets (UP collection), performs service usage reporting, performs user plane quality of service processing (e.g., packet filtering, gating, UL / DL rate enforcement), performs uplink service validation (e.g., SDF to QoS flow mapping), transport-level packet marking in the uplink and downlink, and performs downlink packet buffering and downlink data notification triggering. The UPF 248 may include an uplink classifier to support routing of service flows to the data network.

[0077] The NSSF 250 selects a set of network slice instances to serve the UE 202. The NSSF 250 also determines the allowed NSSAIs and the mapping to the subscribed S-NSSAIs (if required). The NSSF 250 also determines the set of AMFs or a list of candidate AMFs 244 to be used to serve the UE 202 based on appropriate configuration and possibly by querying the NRF 254. The selection of a set of network slice instances for the UE 202 can be triggered by the AMF 244 with which the UE 202 is registered, through interaction with the NSSF 250, which may result in a change of the AMF 244. The NSSF 250 interacts with the AMF 244 via the N22 reference point and can communicate with another NSSF in the visited network via the N31 reference point (not shown).

[0078] The NEF 252 securely exposes the services and capabilities provided by the 3GPP NF to third parties, internal exposure / re-exposure, the AF 260, edge computing or fog computing systems (e.g., edge computing nodes), and the like. In such examples, the NEF 252 can authenticate, authorize, or restrict the AF. The NEF 252 can also convert information exchanged with the AF 260 and information exchanged with internal network functions. For example, the NEF 252 can convert between AF service identifiers and internal 5GC information. The NEF 252 can also receive information from other NFs based on the capabilities exposed by other NFs. This information can be stored as structured data at the NEF 252 or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 252 to other NFs and AFs or used for other purposes (e.g., analysis).

[0079] The NRF 254 supports service discovery functionality, receives NF discovery requests from NF instances, and provides information about the discovered NF instances to the requesting NF instances. The NRF 254 also maintains information about available NF instances and the services they support. The NRF 254 also supports service discovery functionality, where the NRF 254 receives NF discovery requests from NF instances or SCPs (not shown) and provides information about the discovered NF instances to the NF instances or SCPs.

[0080] The PCF 256 provides policy rules to the control plane functions and enforces them, and it can also support the unified policy framework to manage network behavior. The PCF 256 can also implement a front end to access subscription information related to policy decisions in the UDR of the UDM 258. In addition to communicating with functions through reference points as shown, the PCF 256 also exposes an interface based on the Npcf service.

[0081] The UDM 258 processes subscription-related information to support network entities handling communication sessions and stores subscription data for the UE 202. For example, subscription data may be transferred via the N8 reference point between the UDM 258 and the AMF 244. The UDM 258 may include two components: an application front-end and a User Defined Response (UDR). The UDR may store subscription data and policy data for the UDM 258 and PCF 256, and / or open structured data and application data for the NEF 252 (including PFDs for application detection and application request information for multiple UEs 202). The UDR may expose a Nudr service-based interface that allows the UDM 258, PCF 256, and NEF 252 to access a specific set of stored data, as well as read, update (e.g., add, modify), delete, and subscribe to notifications of changes to relevant data in the UDR. The UDM 258 may include a UDM-FE, which is responsible for handling credentials, location management, subscription management, and the like. 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 handling, user identity handling, access authorization, registration / mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 258 can also expose interfaces based on Nudm services.

[0082] Edge Application Server Discovery Function (EASDF) 261 exposes a Neasdf service-based interface and connects to SMF 246 via the N88 interface. One or more EASDF instances can be deployed within the PLMN, and interactions between 5GC NFs and EASDF 261 occur within the PLMN. EASDF 261 includes one or more of the following functions: registering with NRF 254 for EASDF 261 discovery and selection; processing DNS messages based on instructions from SMF 246; and / or terminating DNS security (if used). Processing DNS messages according to instructions from SMF 246 includes one or more of the following functions: receiving DNS message handling rules and / or BaselineDNSPattern from SMF 246; exchanging DNS messages from / with UE 202; forwarding DNS messages to C-DNS or L-DNS for DNS queries; adding the EDNS Client Subnet (ECS) option to DNS queries for FQDNs; reporting information related to received DNS messages to SMF 246; and / or buffering / discarding DNS messages from UE 202 or a DNS server. The EASDF has direct user plane connectivity (e.g., without any NAT) with the PSA UPF over N6 for transporting DNS signaling exchanged with the UE. Deployment of NAT between EASDF 261 and PSA UPF 248 may or may not be supported. Other aspects of the EASDF 261 are discussed in [TS23548].

[0083] The AF 260 provides application influence over service routing, provides access to the NEF 252, and interacts with the policy framework for policy control. The AF 260 can influence the (re)selection and service routing of the UPF 248. Based on operator deployment, network operators may allow the AF 260 to interact directly with relevant NFs if the AF 260 is considered a trusted entity. In some implementations, the AF 260 is used in edge computing implementations.

[0084] 5GC 240 can enable edge computing by selecting operator / third-party services that are geographically close to the point where UE 202 attaches to the network. This can reduce latency and load on the network. In an edge computing implementation, 5GC 240 can select a UPF 248 close to UE 202 and perform traffic steering from UPF 248 to DN 236 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by AF 260, allowing AF 260 to influence UPF (re)selection and traffic routing.

[0085] Data network (DN) 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, application (app) / content server 238). DN 236 may be an external public operator, a private PDN, or an intra-operator packet data network (e.g., for providing IMS services). In this example, app server 238 may be coupled to the IMS via an S-CSCF or I-CSCF. In some implementations, DN 236 may represent one or more local area DNs (LADNs), which are DNs 236 (or DN names (DNNs)) accessible to UE 202 in one or more specific areas. Outside of these specific areas, UE 202 cannot access LADN / DN 236.

[0086] Additionally or alternatively, DN 236 may be an edge DN 236, which is a (local) DN that supports an architecture for implementing edge applications. In these examples, app server 238 may represent a physical hardware system / device that provides app server functionality and / or application software residing in the cloud or at an edge computing node that performs server functionality. In some examples, app / content server 238 provides an edge hosting environment that provides the necessary support for the execution of edge application servers.

[0087] In some examples, the 5GS may use one or more edge computing nodes to provide interfaces and offload processing for wireless communication services. In these examples, the edge computing nodes may be included in or co-located with one or more RANs 210, 214. For example, the edge computing nodes may provide connectivity between the RAN 214 and the UPF 248 in the 5GC 240. The edge computing nodes may use one or more NFV instances instantiated on a virtualized infrastructure within the edge computing nodes to handle wireless connectivity to and from the RAN 214 and the UPF 248.

[0088] In some implementations, edge computing nodes provide a distributed computing environment for application and service hosting, and also provide storage and processing resources, enabling data and / or content to be processed close to subscribers (e.g., users of UE 202) for faster response times. Edge computing nodes also support multi-tenant runtime and hosting environments for applications, including virtual appliance applications that can be delivered as packaged virtual machine (VM) images, middleware applications and infrastructure services, content delivery services (including content caching), mobile big data analytics, and compute offloading. Computation offloading involves offloading computing tasks, workloads, applications, and / or services from UE 202, CN 220, data network DN 236, and / or servers 238 to edge computing nodes, and vice versa. For example, a device application or client application operating in UE 202 can offload application tasks or workloads to one or more edge computing nodes. In another example, an edge computing node can offload application tasks or workloads to a group of UEs 202 (e.g., for distributed machine learning computations, etc.).

[0089] An edge computing node may include or be part of an edge system that employs one or more edge computing technologies (ECTs) (also referred to as an "edge computing framework," etc.). An edge computing node may also be referred to as an "edge host" or "edge server." The edge system comprises a collection of edge servers and an edge management system (not shown) required to run edge computing applications within a carrier network or a subset of a carrier network. An edge server is a physical computer system (which may include an edge platform and / or virtualized infrastructure) that provides computing resources, storage resources, and network resources to edge computing applications. Each edge server is deployed at the edge of a corresponding access network and is arranged to provide computing resources and / or various services (e.g., computing task and / or workload offloading, cloud computing capabilities, IT services, and other similar resources and / or services discussed herein) relatively close to the UE 202. The edge computing node's virtualization interface (VI) provides a virtualized environment and virtualized resources for the edge host, and edge computing applications can run on the VI as VMs and / or application containers.

[0090] In one example implementation, the ECT is in accordance with and / or operates in accordance with a MEC framework as discussed in: ETSI GR MEC 001 v3.1.1 (2022-01), ETSI GS MEC 003 v3.1.1 (2022-03), ETSI GSMEC 009 v3.1.1 (2021-06), ETSI GS MEC 010-1 v1.1.1 (2017-10), ETSI GS MEC 010-2 v2.2.1 (2022-02), ETSI GS MEC 011 v2.2.1 (2020-12), ETSI GS MEC 012 V2.2.1 (2022-02), ETSI GS MEC 013 V2.2.1 (2022-01), ETSI GS MEC 014 v2.1.1 (2021-03), ETSI GSMEC 015 v2.1.1 (2020-06), ETSI GS MEC 016 v2.2.1 (2020-04), ETSI GS MEC 021v2.2.1 (2022-02), ETSI GR MEC 024 v2.1.1 (2019-11), ETSI GS MEC 028 V2.2.1 (2021-07), ETSI GS MEC 029 v2.2.1 (2022-01), ETSI MEC GS 030 v2.1.1 (2020-04), ETSI GRMEC 031 v2.1.1 (2020-10), U.S. Provisional Application No. filed April 1, 2020 63 / 003,834 ("[US'834]") and International Application No. PCT / US2020 / 066969, filed December 23, 2020 ("[PCT'696]") (collectively referred to herein as "[MEC]"), the contents of each of which are incorporated herein by reference in their entirety.This example implementation (and / or any other example implementations discussed herein) may also include NFV and / or other similar virtualization technologies, such as those discussed in: ETSI GR NFV 001 V1.3.1 (2021-03), ETSI GS NFV 002 V1.2.1 (2014-12), ETSI GRNFV 003 V1.6.1 (2021-03), ETSI GS NFV 006 V2.1.1 (2021-01), ETSI GS NFV-INF 001 V1.1.1 (2015-01), ETSI GS NFV-INF 003 V1.1.1 (2014-12), ETSI GS NFV-INF 004 V1.1.1 (2015-01), ETSI GS NFV-MAN 001 V1.1.1 (2015-01), v1.1.1 (December 2014), and / or Israel et al., OSM Release FIVE Technical Overview, ETSI Open Source MANO, OSM White Paper, 1st. (January 2019), https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf (collectively, “[ETSI NFV]”), the contents of each of which are incorporated herein by reference in their entirety. Other virtualization technologies and / or service orchestration and automation platforms may be used, such as those discussed in: E2ENetwork Slicing Architecture, GSMA, Official Doc. NG.127, v1.0 (June 3, 2021), https: / / www.gsma.com / newsroom / wp-content / uploads / / NG.127-v1.0-2.pdf, OpenNetwork Automation Platform (ONAP) documentation, Release Istanbul, v9.0.1 (February 17, 2022), https: / / docs.onap.org / en / latest / index.html (“[ONAP]”), 3GPP Service-Based Management Architecture (SBMA) discussed in 3GPP TS28.533 v17.1.0 (2021-12-23) (“[TS28533]”), the contents of each of which are incorporated herein by reference in their entirety.

[0091] In another example implementation, the ECT operates according to and / or in accordance with the O-RAN framework. Typically, front-end and back-end equipment vendors and operators work closely to ensure compatibility. The downside of this operating model is that it can be difficult to plug and play with other equipment, which can hinder innovation. To address this issue and promote openness and interoperability at all levels, key players with an interest in wireless (e.g., operators, equipment manufacturers, academic institutions, etc.) established the Open RAN Alliance ("O-RAN") in 2018. The O-RAN network architecture is the building block for designing a virtualized RAN on programmable hardware, with radio access control driven by AI / ML. Various aspects of the O-RAN architecture are described in the following: O-RAN Architecture Description v07.00, O-RAN Alliance WG1 (October 2022) (“[O-RAN.WG1.O-RAN-Architecture-Description]”); O-RAN Operations and Maintenance Architecture Specification v04.00, O-RAN Alliance WG1 (February 2021) (“[O-RAN.WG1.OAM-Architecture]”); O-RAN Operations and Maintenance Interface Specification v04.00, O-RAN Alliance WG1 (February 2021) (“[O-RAN.WG1.O1-Interface.0]”); O-RAN Information Model and Data Models Specification v01.00, O-RAN Alliance WG1 (February 2021); O-RAN Working Group 1 Slicing Architecture v08.00 (October 2022); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1interface: Application Protocol v03.02 (July 2021); O-RAN Working Group 1 UseCases Detailed Specification v09.00 (October 2022) (“[O-RAN.WG1.O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: General Aspects and Principles v03.00 (October 2022) (“[O-RAN.WG2.A1GAP]”); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Type Definitions v04.00 (October 2021); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Transport Protocol v02.00 (October 2022); O-RAN Working Group 2 AI / ML workflow description and requirements v01.03 O-RAN Alliance WG2 (October 2021) (“[O-RAN.WG2.AIML]”); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) Non-RT RIC Architecture v02.01 (October 2022); O-RAN Working Group 2 Non-RT RIC: Functional Architecturev01.01, O-RAN Alliance WG2 (June 2021); O-RAN Working Group 2 (Non-RT RIC and A1 interface WG): R1 interface: General Aspects and Principles v03.00, O-RAN Alliance WG2 (October 2022); O-RAN Working Group 3 Near-Real-time RAN IntelligentController Architecture & E2 General Aspects and Principles v02.02 (July 2022) ("[O-RAN.WG3.E2GAP]"); O-RAN Working Group 3 Near-Real-time IntelligentController E2 Service Model (E2SM) v02.01 (March 2022) ("[O-RAN.WG3.E2SM]"); E2 Service Model (E2SM) KPM v02.03 (October 2022) ("[O-RAN.WG3.E2SM-KPM]"); O-RAN WorkingGroup 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RANFunction Network Interface (NI) v01.00 (February 2020) ("[ORAN-WG3.E2SM-NI]"); O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model(E2SM) RAN Control v01.03 (October 2022) (“[O-RAN.WG3.E2SM-RC]”); O-RAN Working Group 3, Near-Real-time Intelligent Controller, E2 Application Protocol(E2AP) v02.03 (October 2022) (“[O-RAN.WG3.E2AP]”); O-RAN Working Group 3 (Near-Real-time RAN Intelligent Controller and E2 Interface Working Group): Near-RT RIC Architecture v03.00 (October 2022) (“[O-RAN.WG3.RICARCH]”); O-RAN Working Group 4 (Open Fronthaul Interface WG) Control, User and Synchronization Plane Specification v09.00 (July 2022) (“[O-RAN-WG4.CUS.0]”); O-RAN Fronthaul Working Group 4 Cooperative Transport Interface Transport Control Plane Specification v02.00, O-RAN Alliance WG4 (June 2021); O-RAN Fronthaul Working Group 4 Cooperative Transport Interface Transport Management Plane Specification v02.00 (June 2021); O-RAN Fronthaul Working Group 4 (Open Fronthaul Interface WG): Management Plane Specification v09.00 (July 2022) (“[O-RAN.WG4.MP.0]”); O-RAN Alliance Working Group 5 O1 Interface specification for O-CU-UP and O-CU-CP v04.00 (October 2022); O-RAN Alliance Working Group 5 O1 Interface specification for O-DU v05.00 (October 2022); O-RAN Open F1 / W1 / E1 / X2 / Xn Interfaces Working Group Transport Specification v01.00, O-RAN Alliance WG5 (April 2020); O-RAN Working Group 6 (Cloudification and Orchestration) Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN v04.00 (October 2022) (“[O-RAN.WG6.CADS]”); O-RAN Cloud Platform Reference Designs v02.00, O-RAN Alliance WG6 (February 2021); O-RAN Working Group 6 O2 Interface General Aspects and Principles v02.00 (October 2022); O-RAN Working Group 6 (Cloudification and Orchestration Working Group); O-RAN Acceleration Abstraction Layer General Aspects and Principles v04.00 (October 2022); O-RAN Working Group 6: O-Cloud Notification API Specification for Event Consumers v03.00 (“[O-RAN.WG6.O-Cloud Notification API]”); O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Indoor Pico Cell with Fronthaul Split Option 6 v02.00, O-RAN Alliance WG7 (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt6]”); O-RAN WG7 Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 7-2 v03.00, O-RAN Alliance WG7 (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt7-2]”); O-RAN WG7 Hardware Reference Design Specification for Indoor Picocell (FR1) with Split Architecture Option 8 v03.00 (October 2021) (“[O-RAN.WG7.IPC-HRD-Opt8]”); O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Outdoor Micro Cell with Split Architecture Option 7.2 v03.00, O-RAN Alliance WG7 (October 2022) (“[O-RAN.WG7.OMC-HRD-Opt7-2]”); O-RAN White Box Hardware Working Group Hardware Reference Design Specification for Outdoor Macro Cell with Split Architecture Option 7.2 v03.00, O-RAN Alliance WG7 (July 2022) (“[O-RAN.WG7.OMAC-HRD]”); O-RAN Open X-haul Transport Working Group Management interfaces for Transport Network Elements v04.00, O-RAN Alliance WG9 (July 2022); O-RAN Open X-haul Transport Working Group Synchronization Architecture and Solution Specification v02.00, O-RAN Alliance WG9 (March 2022); O-RAN Open Xhaul Transport WG9 WDM-based Fronthaul Transport v2.0, O-RAN Alliance WG9 (March 2022); O-RAN Open Transport Working Group 9 Xhaul Packet Switched Architectures and Solutions v03.00, O-RAN Alliance WG9 (July 2022) (“[O-RAN.WG9.XPSAAS]”); O-RAN Operations and Maintenance Architecture v07.00, O-RAN Alliance WG10 (July 2022) (“[O-RAN.WG10.OAM-Architecture]”); O-RAN Operations and Maintenance Interface Specification v07.00, O-RAN Alliance WG10 (July 2022); O-RAN Operations and Maintenance Interface Specification v08.00, O-RAN Alliance WG10 (October 2022) (“[O-RAN.WG10.O1-Interface.0]”); O-RAN: Towards an Open and Smart RAN, O-RAN Alliance, White Paper (October 2018); and U.S. application No. 17 / 484,743, filed September 24, 2021 (collectively, “[O-RAN]”), the contents of each of which are incorporated herein by reference in their entirety.

[0092] In another example implementation, the ECT is in accordance with and / or operates in accordance with the 3rd Generation Partnership Project (3GPP) System Aspects Working Group 6 (SA6) architecture for implementing edge applications (referred to as "3GPP edge computing"), as discussed in: 3GPP TS 23.558 v18.1.0 (2022-12-23) ("[TS23558]"), 3GPP TS 23.501 v18.0.0 (2022-12-21) ("[TS23501]"), 3GPP TS 23.548 v17.4.0 (2022-09-22) ("[TS23548]"), 3GPP TR 23.700-98 v18.0.0 (2022-12-23) ("[TR23700-98]"), 3GPP TS 23.222-1 v18.0.0 (2022-12-23) ("[TS23222]"), TS 33.122 v18.0.0 (2022-12-16) ("[TS33122]"), and 3GPP TS29.222 v17.1.0 (2021-06-25) ("[TS29222]"), 3GPP TS 23.502 v18.0.0 (2022-12-21) ("[TS23502]"), 3GPP TS 29.522 v18.0.0 (2022-12-16) ("[TS29522]"), 3GPP TS 29.122v18.0.0 (2022-12-16) ("[TS29122]"), 3GPP TS 23.682 v17.3.0 (2022-06-15) ("[TS23682]"), 3GPP TS 23.434 v18.3.0 (2022-12-23) ("[TS23434]"), and 3GPP TS 23.401 v18.0.0 (2022-12-21) (collectively, "[SA6Edge]"), the contents of each of which are incorporated herein by reference in their entirety.

[0093] In another example implementation, the ECT is based on the Intel® Smart Edge Open framework (formerly known as OpenNESS) and / or operates in accordance with it, as discussed in the Intel® Smart Edge Open DeveloperGuide, version 21.09 (September 30, 2021), available at: https: / / smart-edge-open.github.io / (“[ISEO]”), the contents of which are incorporated herein by reference in their entirety.

[0094] In another example implementation, the ECT operates according to a Multiple Access Management Service (MAMS) framework, as discussed in Kanugovi et al., Multi-Access Management Services (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (March 2020) (“[RFC8743]”), Ford et al., TCP Extensions for Multipath Operation with Multiple Addresses, IETF RFC 8684 (March 2020), De Coninck et al., Multipath Extensions for QUIC (MP-QUIC), IETF draft-deconinck-quic-multipath-07, IETA, QUIC Working Group (May 3, 2021), Zhu et al., User-Plane Protocols for Multiple Access Management Service, IETF draft-zhu-intarea-mams-user-protocol-09, IETA, INTAREA (March 4, 2020), and Zhu et al., Generic Multi-Access (GMA) Convergence Encapsulation Protocols, IETF RFC 9188 (February 2022) (collectively, “[MAMS]”), the contents of each of which are incorporated herein by reference in their entirety.

[0095] It should be understood that the aforementioned edge computing framework / ECT and service deployment examples are merely illustrative examples of ECTs, and that the present disclosure is applicable to many other or additional edge computing / network technologies, including the various edge computing networks / systems described herein, for various combinations and configurations of devices located at the network edge. Furthermore, the techniques disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be applicable to the present disclosure. Examples of such edge computing / networking technologies include: [MEC]; [O-RAN]; [ISEO]; [SA6Edge]; content delivery networks (CDNs) (also known as "content distribution networks," etc.); mobile service provider (MSP) edge computing and / or mobility as a service (MaaS) provider systems (e.g., for use in AECC architectures); Nebula edge cloud systems; fog computing systems; cloudlet edge cloud systems; mobile cloud computing (MCC) systems; data center reconfigured central office (CORD), mobile CORD (M-CORD), and / or converged multi-access and core (COMAC) systems; and so on. Furthermore, the techniques disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also be used for the purposes of the present disclosure.

[0096] The interfaces of the 5GC 240 include reference points and service-based interfaces. Reference points include N1 (between UE 202 and AMF 244), N2 (between RAN 214 and AMF 244), N3 (between RAN 214 and UPF 248), N4 (between SMF 246 and UPF 248), N5 (between PCF 256 and AF 260), N6 (between UPF 248 and DN 236), N7 (between SMF 246 and PCF 256), N8 (between UDM 258 and AMF 244), N9 (between two UPFs 248), N10 (between UDM 258 and SMF 246), N11 (between AMF 244 and SMF 246), N12 (between AUSF 242 and AMF 244), N13 (between AUSF 242 and UDM 258), N14 (between two AMFs 244; not shown), N15 (between PCF 256 and AMF 244 in the case of non-roaming scenario; or between PCF 256 and AMF 244 in the visited network in the case of roaming scenario), N16 (between two SMFs 246; not shown), and N22 (between AMF 244 and NSSF 250). Figure 2 Other reference points not shown are indicated. Figure 2The service-based representation represents the NFs within the control plane that enable other authorized NFs to access their services. The service-based interfaces (SBIs) include Namf (SBI exposed by AMF 244), Nsmf (SBI exposed by SMF 246), Nnef (SBI exposed by NEF 252), Npcf (SBI exposed by PCF 256), Nudm (SBI exposed by UDM 258), Naf (SBI exposed by AF 260), Nnrf (SBI exposed by NRF 254), Nnssf (SBI exposed by NSSF 250), and Nausf (SBI exposed by AUSF 242). You can also use Figure 2 Other service-based interfaces not shown in FIG (e.g., Nudr, N5g-eir, and Nudsf). In some examples, the NEF 252 can provide an interface with the edge computing nodes 236x, which can be used to handle wireless connections with the RAN 214.

[0097] In some implementations, the system 200 may include an SMSF that is responsible for SMS subscription checking and verification, and relaying SM messages from the UE 202 to other entities (e.g., SMS-GMSC / IWMSC / SMS router) / from other entities to the UE 202. The SMS may also interact with the AMF 242 and the UDM 258 for notification procedures that the UE 202 is available for SMS transmission (e.g., setting a UE unreachable flag and notifying the UDM 258 when the UE 202 is available for SMS).

[0098] 5GS may also include an SCP (or instances of an SCP) that supports indirect communication (see, for example, 3GPP TS 23.501, Section 7.1.1); delegated discovery (see, for example, 3GPP TS 23.501, Section 7.1.1); message forwarding and routing to destination NFs / NF services; communication security (e.g., authorizing NF service consumers to access NF service producer APIs) (see, for example, 3GPP TS 33.501); load balancing, monitoring, overload control, etc.; and discovery and selection functions for the UDM 258, AUSF 242, UDR 259, and PCF 256, with access to subscription data stored in the UDR based on the UE's SUPI, SUCI, or GPSI (see, for example, [TS 23501] §6.3). The load balancing, monitoring, and overload control functions provided by the SCP may be implementation-specific. SCPs may be deployed in a distributed manner. More than one SCP may be present in the communication path between various NF services. Although not NF instances, SCPs may also be deployed in a distributed, redundant, and scalable manner.

[0099] Figure 3 Schematically illustrated is a wireless network 300 according to various embodiments. The wireless network 300 may include a UE 302 in wireless communication with an AN 304. The UE 302 and the AN 304 may be similar to, and substantially interchangeable with, similarly named components described elsewhere herein.

[0100] UE 302 may be communicatively coupled to AN 304 via connection 306. Connection 306 is shown as an air interface enabling the communicative coupling and may conform to a cellular communication protocol, such as the LTE protocol or a 5G NR protocol operating at mmWave or sub-6 GHz frequencies.

[0101] UE 302 may include a host platform 308 coupled to a modem platform 310. Host platform 308 may include application processing circuitry 312, which may be coupled to protocol processing circuitry 314 of modem platform 310. Application processing circuitry 312 may run various applications for application data transmitted to and from UE 302. Application processing circuitry 312 may also implement one or more layer operations to send and receive application data to and from a data network. These layer operations may include transport (e.g., UDP) and internet (e.g., IP) operations.

[0102] Protocol processing circuitry 314 may implement one or more layer operations to facilitate sending or receiving data over connection 306. The layer operations implemented by protocol processing circuitry 314 may include, for example, MAC, RLC, PDCP, RRC, and NAS operations.

[0103] The modem platform 310 may also include digital baseband circuitry 316, which may implement one or more layer operations that are "lower" layer operations in the network protocol stack performed by the protocol processing circuitry 314. These operations may include, for example, PHY operations, including one or more of the following: HARQ-ACK functionality, 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 spatial coding), reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and other related functions.

[0104] Modem platform 310 may also include transmit circuitry 318, receive circuitry 320, RF circuitry 322, and an RF front end (RFFE) 324, which may include or be connected to one or more antenna panels 326. Briefly, transmit circuitry 318 may include digital-to-analog converters, mixers, intermediate frequency (IF) components, etc.; receive circuitry 320 may include analog-to-digital converters, mixers, IF components, etc.; RF circuitry 322 may include low-noise amplifiers, power amplifiers, power tracking components, etc.; and RFFE 324 may include filters (e.g., surface / bulk acoustic wave filters), switches, antenna tuners, beamforming components (e.g., phased array antenna components), etc. The selection and arrangement of the components of transmit circuitry 318, receive circuitry 320, RF circuitry 322, RFFE 324, and one or more antenna panels 326 (generally referred to as "transmit / receive components") may be specific to the details of a particular implementation, such as whether the communication is TDM or FDM, at mmWave or sub-6 GHz frequencies, etc. In some embodiments, the transmit / receive components may be arranged in multiple parallel transmit / receive chains, may be provided in the same or different chips / modules, etc.

[0105] In some embodiments, the protocol processing circuitry 314 may include one or more instances of control circuitry (not shown) for providing control functionality for the transmit / receive components.

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

[0107] UE transmission may be established by and via protocol processing circuitry 314, digital baseband circuitry 316, transmit circuitry 318, RF circuitry 322, RFFE 324, and one or more antenna panels 326. In some embodiments, the transmit component of UE 302 may apply spatial filtering to the data to be transmitted to form transmit beams emitted by the antenna elements of one or more antenna panels 326.

[0108] Similar to UE 302, AN 304 may include a host platform 328 coupled to a modem platform 330. Host platform 328 may include application processing circuitry 332 coupled to 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 an antenna panel 346. The components of AN 304 may be similar to and substantially interchangeable with the similarly named components of UE 302. In addition to performing data transmission / reception as described above, the components of AN 304 may also perform various logical functions, including, for example, RNC functions (e.g., radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling).

[0109] Figure 4 is a block diagram illustrating components according to some example embodiments that are 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 methodologies discussed herein. Specifically, Figure 4 A diagrammatic representation of hardware resources 400 is shown, 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 can be communicatively coupled via a bus 440 or other interface circuitry. For embodiments utilizing node virtualization (e.g., NFV), a hypervisor 402 can be executed to provide an execution environment for one or more network slices / subslices to utilize hardware resources 400.

[0110] The one or more processors 410 may include, for example, a processor 412 and a processor 414. The one or more processors 410 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP (e.g., a baseband processor), an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

[0111] The memory / storage device 420 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 420 may include, but is not limited to, any type of volatile, non-volatile, or semi-volatile memory, such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, etc.

[0112] The one or more communication resources 430 may include interconnect or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 404 or one or more databases 406 or other network elements via the network 408. For example, the one or more communication resources 430 may include a wired communication component (e.g., for coupling via USB, Ethernet, etc.), a cellular communication component, an NFC component, a Bluetooth® (or Bluetooth® Low Energy) component, a Wi-Fi® component, and other communication components.

[0113] The instructions 450 may include software, a program, an application, an applet, an app, or other executable code for causing at least one of the one or more processors 410 to perform any one or more of the methodologies discussed herein. The instructions 450 may reside, in whole or in part, within at least one of the one or more processors 410 (e.g., within a cache memory of a processor), the memory / storage device 420, or any suitable combination thereof. Furthermore, any portion of the instructions 450 may be transferred to the hardware resources 400 from any combination of the one or more peripheral devices 404 or the one or more databases 406. Thus, the memory of the one or more processors 410, the memory / storage device 420, the one or more peripheral devices 404, and the one or more databases 406 are examples of computer-readable and machine-readable media.

[0114] Figure 5 Another example network architecture 500 is shown. Network 500 can operate in a manner consistent with 3GPP technical specifications or technical reports for 6G systems. In some examples, network 500 can operate concurrently with network 200. For example, in some examples, network 500 can share one or more frequency or bandwidth resources with network 200. As a specific example, a UE (e.g., UE 502) can be configured to operate in both network 500 and network 200. This configuration can be based on the UE including circuitry configured to communicate using the frequency and bandwidth resources of both networks 200 and 500. In general, several elements of network 500 may share one or more characteristics with elements of network 200. For the sake of brevity and clarity, these elements may not be repeated in the description of network 500.

[0115] The network 500 may include a UE 502, which may include any mobile or non-mobile computing device designed to communicate with the RAN 508 via a wireless connection. The UE 502 may be similar to, for example, the UE 202. The UE 502 may be, but is not limited to, a smartphone, a tablet computer, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment system, an in-vehicle entertainment device, an instrument cluster, a head-up display device, an on-board diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine type communication device, an M2M or D2D device, an IoT device, or the like.

[0116] Although Figure 5 Although not explicitly shown in FIG, in some examples, the network 500 may include a set of UEs directly coupled to each other via a sidelink interface. The UEs may be M2M / D2D devices that communicate using physical sidelink channels (e.g., but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.). Similarly, although in Figure 5 It is not explicitly shown in FIG, but UE 502 can communicate with AP (e.g., Figure 2 described AP 206) are communicatively coupled. In addition, although Figure 5 Although not explicitly shown, in some examples, the RAN 508 may include one or more ANs (e.g., Figure 2 The RAN 508 and / or the AN of the RAN 508 may be referred to as a base station (BS), a RAN node, or by other terminology or nomenclature.

[0117] The UE 502 and the RAN 508 may be configured to communicate via an air interface that may be referred to as a sixth generation (6G) air interface. The 6G air interface may include one or more features (e.g., communication in the terahertz (THz) or sub-THz bandwidth, or joint communication and detection). As used herein, the term "joint communication and detection" may refer to a system that allows wireless communication and radar-based detection via various types of multiplexing. As used herein, THz or sub-THz bandwidth may refer to communication in the frequency range of 80 GHz and above. This frequency range may additionally or alternatively be referred to as the "millimeter wave" or "mmWave" frequency range.

[0118] The RAN 508 may enable communication between the UE 502 and the 6G core network (CN) 510. Specifically, the RAN 508 may facilitate the transmission and reception of data between the UE 502 and the 6G CN 510. The 6G CN 510 may include various functions (e.g., NSSF 250, NEF 252, NRF 254, PCF 256, UDM 258, AF 260, SMF 246, and AUSF 242). The 6G CN 510 may also include a UPF 248 and a DN 236, as shown in FIG. Figure 5 shown.

[0119] Additionally, RAN 508 may include various additional functions in addition to or in place of those of legacy cellular networks (e.g., 4G or 5G networks). Two such functions may include a compute control function (Comp CF) 524 and a compute service function (Comp SF) 536. Comp CF 524 and Comp SF 536 may be parts or functions of the compute service plane. Comp CF 524 may be a control plane function that provides functions such as management of Comp SF 536, generation and management of compute task contexts (e.g., creation, reading, modification, and deletion), and interaction with the underlying compute infrastructure for compute resource management. Comp SF 536 may be a user plane function that acts as a gateway between compute service users (e.g., UE 502) and the compute nodes behind the Comp SF instance. Some of the functions of Comp SF 536 may include parsing compute service data received from users to compute tasks executable by compute nodes; maintaining a service mesh ingress gateway or service API gateway; service and billing policy enforcement; performance monitoring and telemetry collection; and more. In some examples, a Comp SF 536 instance can act as a user plane gateway for a cluster of compute nodes. A Comp CF 524 instance can control one or more Comp SF 536 instances.

[0120] Two other such functions may include a communication control function (Comm CF) 528 and a communication service function (CommSF) 538, which may be part of the communication service plane. Comm CF 528 may be a control plane function for managing Comm SF 538, communication session creation / configuration / release, and managing communication session context. Comm SF 538 may be a user plane function for data transmission. Comm CF 528 and Comm SF 538 may be viewed as components of a communication service plane. Figure 2The upgrades provided by CommCF 528 and CommSF 538 enable service-aware transport. For legacy (e.g., 4G or 5G) data transport, SMF 246 and UPF 248 can still be used.

[0121] Two other such functions may include the Data Control Function (Data CF) 522 and the Data Service Function (DataSF) 532, which may be part of the data service plane. The Data CF 522 may be a control plane function and provide functions such as Data SF 532 management, data service creation / configuration / release, and data service context management. The Data SF 532 may be a user plane function and act as a gateway between data service users (e.g., UE 502 and various functions of 6G CN 510) and data service endpoints behind the gateway. Specific functions may include parsing data service user data and forwarding it to the corresponding data service endpoints, generating billing data, and reporting data service status.

[0122] Another such function may be the Service Orchestration and Chaining Function (SOCF) 520, which can discover, orchestrate, and chain communication / computing / data services provided by functions in the network. Upon receiving a service request from a user, SOCF 520 may interact with one or more of Comp CF 524, Comm CF 528, and Data CF 522 to identify Comp SF 536, Comm SF 538, and Data SF 532 instances, configure service resources, and generate a service chain, which may include multiple Comp SF 536, Comm SF 538, and Data SF 532 instances and their associated compute endpoints. Workload processing and data movement can then occur within the generated service chain. SOCF 520 may also be responsible for maintaining, updating, and releasing the created service chain.

[0123] Another such function may be a service registration function (SRF) 514, which may act as a registry for system services provided in the user plane, such as services provided by service endpoints behind the Comp SF 536 and Data SF 532 gateways and services provided by the UE 502. The SRF 514 may be considered a peer to the NRF 254, which may act as a registry for network functions.

[0124] Other such functions include the evolved service communication proxy (eSCP) and the service infrastructure control function (SICF) 526, which provides service communication infrastructure for control plane and user plane services. The eSCP is related to the 5G service communication proxy (SCP), with the addition of user plane service communication proxy capabilities. Therefore, the eSCP is represented as two components: eCSP-C 512 and eSCP-U 534, for control plane service communication proxy and user plane service communication proxy, respectively. The SICF 526 controls and configures the eCSP instance with respect to service traffic routing policies, access rules, load balancing configuration, and performance monitoring.

[0125] Another such function is AMF 544. AMF 544 may be similar to 244, but with additional functionality. Specifically, AMF 544 may include potential functional resplitting (e.g., moving message forwarding functionality from AMF 544 to RAN 508).

[0126] Another such function is the Service Orchestration Exposure Function (SOEF) 518. The SOEF may be configured to expose service orchestration and link services to external users (eg, applications).

[0127] The UE 502 may include an additional functionality called a compute client service function (comp CSF) 504. The Comp CSF 504 may have both control plane and user plane functions and may interact with corresponding network-side functions (e.g., SOCF 520, Comp CF 524, Comp SF 536, Data CF 522, and / or Data SF 532) for service discovery, request / response, computing task workload exchange, etc. The Comp CSF 504 may also work with network-side functions to decide whether computing tasks should be run on elements of the UE 502, the RAN 508, and / or the 6G CN 510.

[0128] UE 502 and / or Comp CSF 504 may include a service mesh proxy 506. Service mesh proxy 506 may act as a proxy for service-to-service communication in the user plane. The capabilities of service mesh proxy 506 may include one or more of addressing, security, load balancing, etc.

[0129] Figure 6 Depicted is an example artificial intelligence (AI)-assisted communication architecture for communications between a UE 605 and a RAN 610. More specifically, as described in further detail below, an AI / machine learning (ML) model can be used or leveraged to facilitate over-the-air communications between the UE 605 and the RAN 610.

[0130] In this example, UE 605 and RAN 610 operate in a manner consistent with 3GPP technical specifications and / or technical reports for 6G systems. In some examples, wireless cellular communications between UE 605 and RAN 610 may be part of, or operate concurrently with, networks 500, 200, and / or some other network described herein.

[0131] UE 605 may be similar to UE 202, 202a, 202t, 2021, UE 302, UE 502, UE 702, hardware resource 400, and / or some other UE or device (e.g., any of those described herein), and share one or more features therewith. UE 605 may be, but is not limited to, a smartphone, a tablet computer, a wearable computer device, a desktop computer, a laptop computer, an in-vehicle infotainment system, an in-car entertainment device, an instrument cluster, a head-mounted display device, an onboard diagnostic device, a dashboard mobile device, a mobile data terminal, an electronic engine management system, an electronic / engine control unit, an electronic / engine control module, an embedded system, a sensor, a microcontroller, a control module, an engine management system, a networked appliance, a machine type communication device, an M2M or D2D device, an IoT device, etc. RAN 610 may be similar to RAN 214, RAN 508, and / or some other RAN described herein, and share one or more features therewith.

[0132] like Figure 6 As can be seen in FIG6 , the AI-related elements of the UE 605 can be similar to the AI-related elements of the RAN 610. For the purposes of this discussion, descriptions of the various elements will be provided from the perspective of the UE 605. However, it should be understood that such discussion or description will apply to the same named / numbered elements of the RAN 610 unless otherwise explicitly stated.

[0133] As previously described, the UE 605 may include various elements or functionality related to AI / ML. Such elements may be implemented as hardware, software, firmware, and / or some combination thereof. For example, one or more of the elements may be implemented as the same hardware (e.g., a chip or multi-processor chip), software (e.g., a computer program), or as part of the firmware of another element.

[0134] One such component may be a data repository 615. The data repository 615 may be responsible for data collection and storage. Specifically, the data repository 615 may collect and store RAN configuration parameters, measurement data, key performance indicators (KPIs), model performance metrics, and the like for use in model training, updating, and inference. More generally, the collected data is stored in the repository. The stored data can be discovered and retrieved from the data repository 615 by other components. For example, as can be seen, the inference data selection / filtering component 650 may retrieve data from the data repository 615. In various examples, the UE 605 may be configured to discover and request data from the data repository 615 in the RAN, and vice versa. More generally, the data repository 615 of the UE 605 may be communicatively coupled to the data repository 615 of the RAN 610, allowing the respective data repositories of the UE and the RAN to share collected data.

[0135] Another such element may be a training data selection / filtering block 620. The training data selection / filtering block 620 may be configured to generate training, validation, and test datasets for model training. The training data may be extracted from the data repository 615. The data may be selected / filtered based on the specific AI / ML model to be trained. The data may optionally be transformed / augmented / preprocessed (e.g., normalized) before being loaded into the dataset. The training data selection / filtering block 620 may label the data in the dataset for supervised learning. The resulting dataset may then be fed into the model training block 625 for training the model.

[0136] As mentioned above, another such element may be the model training block 625. This block may be responsible for training and updating (retraining) AI / ML models. The selected model may be trained using the datasets (including training, validation, and testing) fed from the training data selection / filtering block. The model training block 625 may generate a trained and tested AI / ML model ready for deployment. The generated trained and tested model may be stored in the model repository 635.

[0137] The model repository 635 may be responsible for storing and exposing AI / ML models (both trained and untrained). Trained / updated models may be stored in the model repository 635. Models and model parameters may be discovered and requested by other functional blocks (e.g., the training data selection / filtering functional block 620 and / or the model training functional block 625). In some examples, the UE 605 may discover and request AI / ML models from the model repository 635 of the RAN 610. Similarly, the RAN 610 may be able to discover and / or request AI / ML models from the model repository 635 of the UE 605. In some examples, the RAN 610 may configure models and / or model parameters in the model repository 635 of the UE 605.

[0138] Another such element may be a model management function block 640. The model management function block 640 may be responsible for the management of the AI / ML models generated by the model training function block 625. Such management functions may include deploying trained models, monitoring model performance, etc. In model deployment, the model management function block 640 may allocate and schedule hardware and / or software resources for inference based on the received trained and tested models. As used herein, "inference" refers to the process of using a trained AI / ML model to generate data analysis, actions, policies, etc. based on input inference data. In performance monitoring, based on wireless performance KPIs and model performance metrics, the model management function block 640 may decide to terminate the running model, initiate model retraining, select another model, etc. For example, the model management function block 640 of the RAN 610 may be able to configure the model management policy in the UE 605, as shown.

[0139] Another such element may be an inference data selection / filtering functional block 650. The inference data selection / filtering functional block 650 may be responsible for generating a data set for model inference at the inference functional block 645, as described below. Specifically, the inference data may be extracted from the data repository 615. The inference data selection / filtering functional block 650 may select and / or filter data based on the deployed AI / ML model. The data may be transformed / augmented / preprocessed in accordance with the same transformations / augmentations / preprocessing as those described with respect to the training data selection / filtering functional block 620. The resulting inference data set may be fed into the inference functional block 645.

[0140] Another such element may be a reasoning function block 645. The reasoning function block 645 may be responsible for performing the reasoning described above. Specifically, the reasoning function block 645 may consume the reasoning data set provided by the reasoning data selection / filtering function block 650 and generate one or more results. Such results may include data analysis, actions, policies, etc. The results may be provided to the performance measurement function block 630.

[0141] The performance measurement function 630 may be configured to measure model performance metrics (eg, accuracy, model bias, runtime latency, etc.) of deployed and executing models based on inference results for monitoring purposes. The model performance data may be stored in the data repository 615 .

[0142] Figure 7 Depicted are example RAN split architecture aspects. Figure 7 An example network deployment is shown, including an example Next Generation Fronthaul (NGF) deployment 700a, in which a user equipment (UE) 702 is connected to a RU 730 (also referred to as a "remote radio unit 730," "remote radio head 730," or "RRH 730") via an air interface. RU 730 is connected to a digital unit (DU) 731 via an NGF interface (NGFI)-I. DU 731 is connected to a central unit (CU) 732 via an NGFI-II. CU 732 is connected to a core network (CN) 742 via a backhaul interface. In a 3GPP NG-RAN implementation (see, for example, [TS 38401]), DU 731 may be a distributed unit (for purposes of this disclosure, the term "DU" may refer to a digital unit and / or a distributed unit unless the context dictates otherwise). UE 702 may be the same as or similar to UE 202 and / or any other UE or user / client device discussed herein.

[0143] In some implementations, the NGF deployment 700a can be arranged in a distributed RAN (D-RAN) architecture, where the CU 732, DU 731, and RU 730 reside at a cell site, and the CN 742 is located at a centralized site. Alternatively, the NGF deployment 700a can be arranged in a centralized RAN (C-RAN) architecture, where one or more baseband units (BBUs) are centrally processed at a centralized site. In a C-RAN architecture, radio components are split into discrete components that can be located in different locations. In one example C-RAN implementation, only the RU 730 is located at the cell site, and the DU 731, CU 732, and CN 742 are centralized or located at a central location. In another example C-RAN implementation, the RU 730 and DU 731 are located at the cell site, and the CU 732 and CN 742 are at a centralized site. In another example of a C-RAN implementation, only the RU 730 is provided at the cell site, the DU 731 and CU 732 are located at the RAN hub site, and the CN 742 is at a centralized site.

[0144] The CU 732 is a central controller that can serve or otherwise connect to one or more DUs 731 and / or multiple RUs 730. The CU 732 is a network (logical) node that hosts the higher / upper layers of the network protocol functional split. For example, in 3GPP P-RAN and / or O-RAN architectures, the CU 732 hosts the Radio Resource Control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) layers of a next-generation NodeB (gNB), or the RRC and PDCP protocol layers when included in or operating as an E-UTRA-NR gNB (en-gNB). The SDAP sublayer performs mapping between quality of service flows and data radio bearers (DRBs) and marks the quality of service flow ID (QFI) in both downlink and uplink packets. The PDCP sublayer performs the following tasks: delivering user plane or control plane data; maintaining PDCP sequence numbers (SNs); header compression and decompression using the Robust Header Compression (ROHC) and / or Ethernet Header Compression (EHC) protocols; ciphering and deciphering; integrity protection and integrity verification; providing timer-based SDU discard; routing for separate bearers; duplication and duplicate discard; reordering and in-sequence delivery; and / or out-of-sequence delivery. In various implementations, the CU 732 terminates the corresponding F1 interface connected to the corresponding DU 731 (see, for example, [TS38401]).

[0145] The CU 732 may include a CU-control plane (CP) entity (referred to herein as "CU-CP 732") and a CU-user plane (UP) entity (referred to herein as "CU-UP 732"). The CU-CP 732 is a logical node that hosts the RRC layer and the control plane portion of the PDCP protocol layer of the CU 732 (e.g., for an en-gNB or a gNB-CU of a gNB). The CU-CP terminates the E1 interface with the CU-UP and the F1-C interface with the DU 731. The CU-UP 732 is a logical node that hosts the user plane portion of the PDCP protocol layer (e.g., for an en-gNB-CU 732 of a gNB), as well as the user plane portion of the PDCP protocol layer and the SDAP protocol layer (e.g., for a gNB-CU 732 of a gNB). The CU-UP 732 terminates the E1 interface with the CU-CP 732 and the F1-U interface with the DU 731.

[0146] The DU 731 locally controls radio resources (e.g., time and frequency band) in real time and allocates resources to one or more UEs. The DU 731 is a network (logical) node that hosts the middle and / or lower layers of the network protocol functional split. For example, in the 3GPP NG-RAN and / or O-RAN architecture, the DU 731 hosts the radio link control (RLC), medium access control (MAC) layer, and higher physical (PHY) layer of the gNB or en-gNB, and its operation is at least partially controlled by the CU 732. The RLC sublayer operates in one or more of the following modes: transparent mode (TM), unacknowledged mode (UM), and acknowledged mode (AM). The RLC sublayer performs delivery of upper layer PDUs; sequence numbering (UM and AM) independent of the sequence numbering in PDCP; error correction through ARQ (AM only); segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs; reassembly of SDUs (AM and UM); duplicate detection (AM only); RLC SDU discard (AM and UM); RLC re-establishment; and / or protocol error detection (AM only). The MAC sublayer performs mapping between logical channels and transport channels; multiplexing / demultiplexing MAC SDUs belonging to one or different logical channels into / from transport blocks (TBs) delivered to / from the physical layer on transport channels; reporting of scheduling information; error correction through HARQ (one HARQ entity per cell in the case of Carrier Aggregation); prioritization between UEs with the help of dynamic scheduling; prioritization between logical channels of a UE with the help of logical channel prioritization; prioritization between overlapping resources of a UE; and / or padding. In some implementations, for example, when the DU 731 is operating as an integrated access and backhaul (IAB) node, the DU 731 may host the Backhaul Adaptation Protocol (BAP) layer (see, for example, 3GPP TS 38.340 v16.5.0 (2021-07-07)) and / or the F1 Application Protocol (F1AP) (see, for example, 3GPP TS 38.470 v16.5.0 (2021-07-01)). One DU 731 supports one or more cells, and one cell is supported by only one DU 731. The DU 731 terminates the F1 interface with the CU 732. Additionally or alternatively, the DU 731 may be connected to one or more RRHs / RUs 730.

[0147] The RU 730 is a transmit / receive point (TRP) or other physical node that handles radio frequency (RF) processing functions. The RU 730 is a network (logical) node that hosts lower layers based on the functional split of lower layers. For example, in the 3GPP NG-RAN and / or O-RAN architecture, the RU 730 hosts the low-PHY layer functions and RF processing of the radio interface based on the functional split of lower layers. The RU 730 can be similar to a 3GPP transmit / receive point (TRP) or RRH, but specifically includes the low-PHY layer. Examples of low-PHY functions include fast Fourier transform (FFT), inverse FFT (IFFT), physical random access channel (PRACH) extraction, etc.

[0148] Each of the CU 732, DU 731, and RU 730 is connected by a corresponding link, which may be any suitable wireless and / or wired (eg, fiber, copper, etc.) link. In some implementations, various combinations of the CU 732, DU 731, and RU 730 may correspond to Figure 2 Additional aspects of the CU 732, DU 731 and RU 730 are discussed in [O-RAN], [TS 38401], [TS 38410] and [TS 38300], the contents of each of which are incorporated herein by reference in their entirety.

[0149] In some implementations, the fronthaul gateway function (FHGW) may be provided between the DU 731 and the RU / RRU 730 ( Figure 7 DU 731 and RU / RRU 730 are interconnected (not shown), where the interface between the DU 731 and the FHGW is an open fronthaul (e.g., option 7-2x) interface, or the interface between the FHGW function and the RU / RRU 730 is an open fronthaul (e.g., option 7-2x) interface or any other suitable interface (e.g., option 7, option 8, etc.), including interfaces that do not support open fronthaul (e.g., option 7-2x). The FHGW may be packaged with one or more other functions (e.g., Ethernet switching, etc.) in a physical device or appliance. In some implementations, a RAN controller may be communicatively coupled to the CU 732 and / or the DU 731.

[0150] NGFI (also known as "xHaul" etc.) is a two-level fronthaul architecture that separates the traditional RRU 730 to BBU connection in the C-RAN architecture into two levels (i.e., Level I and II). Level I connects the RU 730 to the DU 731 via NGFI-I, and Level II connects the DU 731 to the CU 732 via NGFI-II, as shown in the following example. Figure 7700a in FIG. NGFI-I and NGFI-II connections can be wired or wireless, utilizing any suitable RAT (e.g., any of the RATs discussed herein). The purpose of the two-tier architecture is to distribute (split) RAN node protocol functions between the CU 732 and the DU 731, thereby relaxing latency and providing more deployment flexibility. Typically, the NGFI-I interfaces with lower layers in the functional split that have strict latency and data rate requirements. In contrast, the NGFI-II interfaces with higher layers in the functional split relative to the NGFI-I layers, thereby relaxing requirements for the fronthaul link. Examples of NGFI fronthaul interfaces and functional split architectures include O-RAN 7.2x fronthaul (see, for example, [O-RAN. WG9.XPSAAS] and [O-RAN-WG4.CUS.0]), C-RAN fronthaul based on enhanced public radio interface (CPRI) (see, for example, Common Public Radio Interface: eCPRI Interface Specification, eCPRI Specification v2.0 (2019-05-10), Common Public Radio Interface: Requirements for the eCPRI Transport Network, eCPRI Transport Network v1.2 (2018-06-25) and [O-RAN-WG4.CUS.0]), and C-RAN fronthaul based on Radio over Ethernet (RoE) (see, for example, IEEE Standard for Radio over Ethernet Encapsulations and Mappings, IEEE Standards Association, IEEE 1914.3-2018 (October 5, 2018) (“[IEEE1914.3]”)).Additional aspects of NGFI are also discussed in [O-RAN.WG9.XPS AAS], [O-RAN-WG4.CUS.0], IEEE Standard for Packet-based Fronthaul Transport Networks, IEEE Standards Association, IEEE 1914.1-2019 (April 21, 2020) (“[IEEE1914.1]”), [IEEE1914.3], and Nasrallah et al., Ultra-Low Latency (ULL) Networks: A Comprehensive Survey Covering the IEEE TSN Standard and Related ULL Research, arXiv:1803.07673v1[cs.NI] (March 20, 2018) (“[Nasrallah]”), the contents of each of which are incorporated herein by reference in their entirety.

[0151] In one example, deployment 700a can implement a low-level split (LLS) (also known as "Lower Layer Function Split 7-2x" or "Split Option 7-2x") between a RU 730 (e.g., an O-RU in an O-RAN architecture) and a DU 731 (e.g., an O-DU in an O-RAN architecture) (see, e.g., [O-RAN.WG7.IPC-HRD-Opt7-2], [O-RAN.WG7.OMAC-HRD], [O-RAN.WG7.OMC-HRD-Opt7-2], [O-RAN.WG7.OMC-HRD-Opt7-2]). In this example implementation, NGFI-I is the open fronthaul interface described in the O-RAN Open Fronthaul Specification (see, e.g., [O-RAN-WG4.CUS.0]). Other LLS options may be used, such as related interfaces described in other standards or specifications, such as 3GPP NG-RAN functional split (see, for example, [TS38401] and 3GPP TR 38.801 v14.0.0 (2017-04-03)), the Small Cell Forum for Split Option 6 (see, for example, 5G small cell architecture and product definitions: Configurations and Specifications for companies deploying smallcells 2020-2025, Small Cell Forum, document 238.10.01 (July 5, 2020) (“[SCF238]”), 5G NR FR1 Reference Design: The case for a common, modular architecture for 5G NR FR1 small cell distributed radio units, Small Cell Forum, document 251.10.01 (December 5, 2021) ("[SCF251]") and [O-RAN.WG7.IPC-HRD-Opt6], the contents of each of which are incorporated herein by reference in their entirety) and / or related interfaces described in O-RAN white-box hardware Split Option 8 (e.g., [O-RAN.WG7.IPC-HRD-Opt8]).

[0152] Additionally or alternatively, the CU 732, DU 731, and / or RU 730 may be IAB nodes. The IAB implements wireless relay in the NG-RAN, where relay nodes (referred to as "IAB nodes") support access and backhaul via 3GPP 5G / New Radio (NR) links / interfaces. The terminating node for NR backhaul on the network side is referred to as the "IAB donor," which represents a RAN node (e.g., a gNB) with additional functionality to support IAB. Backhaul can occur via a single hop or multiple hops. All IAB nodes connected to the IAB donor via one or more hops form a directed acyclic graph (DAG) topology, with the IAB donor as its root. The IAB donor performs centralized resource, topology, and routing management for the IAB topology. The IAB architecture is shown and described in [TS38300].

[0153] Although the NGF deployment 700a shows the CU 732, DU 731, RRH 730, and CN 742 as separate entities, in other implementations, some or all of these network nodes may be bundled, combined, or otherwise integrated into a single device or element (including collapsing some internal interfaces (e.g., F1-C, F1-U, E1, E2, etc.)). At least the following implementations are possible: (i) integrating CU 732 and DU 731 (e.g., CU-DU), which is connected to RRH 730 via NGFI-I; (ii) integrating DU 731 and RRH 730 (e.g., CU-DU), which is connected to CU 732 via NGFI-II; (iii) integrating RAN controller and CU 732, which is connected to DU 731 via NGFI-II; (iv) integrating CU 732, DU 731, and RU 730, which is connected to CN 742 via a backhaul interface; and (v) integrating network controller (or intelligent controller), CU 732, DU 731, and RU 730. Any of the foregoing example implementations involving CU 732 may also include integrating CU-CP 732 and CP-UP 732.

[0154] Figure 7Also shown is an example RAN split deployment 700b (also referred to as "split RAN 700b"), in which a UE 702 is connected to an RRH 730, and the RRH 730 is communicatively coupled to one or more RAN functions (RANFs) 1-N (where N is a number). RANFs 1-N are split and geographically distributed across several component segments and network nodes. In some implementations, each RANF 1-N is a software (SW) element operated by a physical computing node, and the RRH 730 includes radio frequency (RF) circuitry (e.g., an RF propagation module for a specific RAT). In this example, RANF 1 operates on a physical computing node co-located with RRH 730, while the other RANFs are located further away from RRH 730. Furthermore, in this example, CN 742 is also split into CN NFs 1-x (where x is a number) in the same or similar manner as RANFs 1-N. However, in other implementations, CN 742 is not split.

[0155] Network disaggregation (or disaggregated networking) involves separating networking equipment into functional components and allowing each component to be deployed independently. This can include the separation of SW elements (e.g., NFs) from specific HW elements, and / or the use of APIs to implement software-defined networking (SDN) and / or NF virtualization (NFV). RAN disaggregation involves the separation of various RANFs (e.g., Figure 7 Network disaggregation and virtualization (RANFs 1-N in the RAN) are implemented. RANFs 1-N can be placed at different physical sites in various topologies within a RAN deployment based on use cases. This enables RANF distribution and deployment across diverse geographic areas, allowing for RANF disruption to support various use cases (e.g., low-latency use cases), and flexible RAN implementation. Disaggregation provides a common or unified RAN platform that can adopt different profiles depending on where it is deployed. This allows for fewer fixed-function devices and lower total cost of ownership compared to existing RAN architectures. Example RAN disaggregation frameworks include Telecom Infra Project (TIP) OpenRAN™, Cisco® Open vRAN™, [O-RAN], Open Optical and Packet Transport (OOPT), and Reconfigurable Optical Add / Drop Multiplexers (ROADMs).

[0156] In a first example implementation, RANFs 1-N decompose RAN HW and SW with commercial off-the-shelf (COTS) HW and open interfaces (e.g., NGFI-I and NGFI-II, etc.). In this example implementation, each RANF 1-N can be a virtual BBU or vRANF controller operating on a COTS computing infrastructure with HW acceleration for the BBU / vRANF.

[0157] In a second example implementation, RANFs 1-N decompose layers of one or more RAT protocol stacks. As an example of this implementation, RANF 1 is a DU 731 operating on a first COTS computing infrastructure with HW acceleration for BBU / vRANF, and RANF 2 is a virtual CU 732 operating on a second COTS computing infrastructure.

[0158] In a third example implementation, RANFs 1-N decompose control plane and user plane functions. As an example of this implementation, RANF 1 is a DU 731 operating on a COTS computing infrastructure with HW acceleration for BBU / vRANF, RANF 2 is a virtual CU-CP 732 operating on a COTS computing infrastructure, and a third RANF (e.g., RANF 3 ( Figure 7 Not shown)) is a virtual CU-UP 732 operating on the same or different COTS computing infrastructure as the virtual CU-CP 732. Additionally or alternatively, in this implementation, one or more CN NFs 1-x may be CN-UP functions, and one or more other CN NFs 1-x may be CN-CP functions.

[0159] In a fourth example implementation, RANF 1-N decomposes the layers of the [IEEE 802] RAT. As an example of this implementation, RRH 730 implements the WiFi PHY layer, RANF 1 implements the WiFi MAC sublayer, RANF 1 implements the WiFi logical link control (LLC) sublayer, and RANF 2 implements one or more WiFi upper layer protocols (e.g., network layer, transport layer, session layer, presentation layer, and / or application layer).

[0160] In a fifth example implementation, RANFs 1-N decompose different O-RAN RANFs including E2SM. As an example of this implementation, RANF 1 implements near-RT RIC, RANF 2 implements E2SM-KPM, RANF 3 implements E2SM-CCC, RANF 4 implements E2SM RAN control, RANF 5 implements E2SM-NI, and RANF 6 implements functions for providing A1 services, etc.

[0161] In any of the implementations discussed herein, the lower layers of the RAN protocol stack may be characterized by real-time (RT) functions and relatively complex signal processing algorithms, while the higher layers of the RAN protocol stack may be characterized by non-RT functions. In these implementations, the RT functions and signal processing algorithms may be implemented in the DU 731 and / or RRH 730 using either custom network elements or in COTS hardware enhanced with custom HW accelerators.

[0162] Figure 7Also shown are various functional split options 700c for both the DL and UL directions. Traditional RANs are integrated network architectures based on the distributed RAN (D-RAN) model, where D-RAN integrates all RANFs into a small number of network elements. As previously discussed, disaggregated RAN architectures offer flexible functional split options to overcome the various shortcomings of the D-RAN model. Disaggregated RANs decompose the integrated network system into several functional components, which can then be individually relocated as needed without hindering their ability to work together to provide overall network services. Split options 700c primarily represent a split between the CU 732 and the DU 731, but can also include splits between the CU 732, DU 731, and RU 730. For each option 700c, the protocol entities on the left side of the diagram are included in the RANF that implements the CU 732, while the protocol entities on the right side of the diagram are included in the RANF that implements the DU 731. For example, Option 2 functional split involves splitting non-RT processing (e.g., RRC and PDCP layers) from RT processing (e.g., RLC, MAC, and PHY layers), where the RANF implementing the CU 732 performs network functions for the RRC and PDCP layers, while the RANF implementing the DU 731 performs baseband processing functions for the RLC (including high-RLC and low-RLC), MAC (including high-MAC and low-MAC), and PHY layers. In some implementations, the PHY layer is further split between the DU 731 and the RU 730, where the RANF implementing the DU 731 performs high-PHY layer functions, while the RU 730 handles low-PHY layer functions. In some implementations, the low-PHY entity can be operated by the RU 730 regardless of the selected functional split option. Under Option 2 split, the RANF implementing CU 732 can be connected to multiple DUs 731 (e.g., CU 732 is centralized), which allows for eliminating RRC and PDCP anchor changes during handovers across DUs 731 and allows the centralized CU 732 to pool resources across several DUs 731. In these ways, Option 2 functional split can improve resource efficiency. The specific functional split option used can vary depending on service requirements and network deployment scenarios and can be implementation-specific. It should also be noted that in some implementations, all functional split options can be selected, with each protocol stack entity operated by a corresponding RANF (e.g., a first RANF operating the RRC layer, a second RANF operating the PDCP layer, a third RANF operating the high-RLC layer, and so on, up to an eighth RANF operating the low-PHY layer).Other split options are possible, such as those discussed in [O-RAN.WG7.IPC-HRD-Opt6], [O-RAN.WG7.IPC-HRD-Opt7-2], [O-RAN.WG7.IPC-HRD-Opt8], [O-RAN.WG7.OMAC-HRD] and [O-RAN.WG7.OMC-HRD-Opt7-2].

[0163] For one or more embodiments, at least one component outlined in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods discussed herein (including the examples listed in the Examples section below). For example, baseband circuitry associated with one or more of the preceding figures may be configured to operate according to one or more of the examples described below. As another example, circuitry associated with a UE, base station, satellite, network element, etc., described above in conjunction with one or more of the preceding figures, may be configured to operate according to one or more of the examples described below in the Examples section.

[0164] The term "application" can refer to a complete, deployable package or an environment for implementing specific functionality within an operating environment. The term "AI / ML application" or the like can refer to an application that includes artificial intelligence (AI) / machine learning (ML) models and application-level descriptions. In some embodiments, an AI / ML application can be used to configure or implement one or more of the disclosed aspects.

[0165] The term "machine learning" or "ML" refers to the use of computer systems that implement algorithms and / or statistical models to perform specific tasks without explicit instructions, relying instead on patterns and reasoning. ML algorithms build or estimate mathematical models (referred to as "ML models," etc.) based on sample data (referred to as "training data," "model training information," etc.) 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 certain tasks and certain performance metrics, while an ML model can be any 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 new data sets. Although the term "ML algorithm" refers to a different concept than the term "ML model," these terms discussed herein are used interchangeably for purposes of this disclosure.

[0166] The terms "machine learning model," "ML model," etc., may also refer to the ML methods and concepts used by ML-assisted solutions. An "ML-assisted solution" is a solution that uses ML algorithms to solve specific use cases during operation. ML models include supervised learning (e.g., linear regression, k-nearest neighbors (KNN), decision tree algorithms, support machine learning algorithms, Bayesian algorithms, ensemble algorithms, etc.) and unsupervised learning (e.g., K-means clustering, principal component analysis (PCA)), reinforcement learning (e.g., Q-learning, multi-armed bandit learning, deep RL), neural networks, etc. Depending on the implementation, a specific ML model may have many sub-models as components, and all sub-models of the ML model may be trained together. Separately trained ML models may also be linked together in an ML pipeline during inference. An "ML pipeline" is a set of functions, features, or functional entities specific to an ML-assisted solution; an ML pipeline may include one or more data sources, including a data pipeline, a model training pipeline, a model evaluation pipeline, and actors. An "actor" is an entity that hosts an ML-assisted solution using the output of ML model inference. The term "ML training host" refers to an entity (e.g., a network function) that hosts model training. The term "ML inference host" refers to the entity (e.g., a network function) that hosts a model during inference mode (including both model execution and any online learning (if applicable)). The ML host informs participants of the output of the ML algorithm, and participants decide on actions (an "action" is what a participant performs as a result of the output of the ML-assisted solution). The term "model inference information" refers to the information used as input to the ML model for determining inferences; the data used to train the ML model and the data used to determine inferences may overlap, however, "training data" and "inference data" refer to different concepts.

[0167] The present disclosure defines or otherwise provides UE behaviors and capabilities for supporting high-precision positioning in cellular systems. The following discussion can be applied to any type of UE or base station, such as Figure 1A-8 Any UE or base station in.

[0168] Mobile communications have evolved significantly from early voice-based systems to today's highly complex, integrated communications platforms. The next-generation wireless communication system, 5G or New Radio (NR), will enable a wide range of users and applications to access information and share data anywhere, anytime. NR is expected to be a unified network / system designed to meet widely varying and sometimes conflicting performance requirements and services. This diverse, multi-dimensional demand is driven by different services and applications. NR will generally evolve from 3GPP LTE-Advanced, with the addition of potential new radio access technologies (RATs) to enrich people's lives with seamless wireless connectivity solutions. NR will enable wireless connectivity and deliver fast, rich content and services.

[0169] NR supports high-precision positioning in both vertical and horizontal dimensions, which relies on timing-based, angle-based, power-based, or hybrid techniques to estimate the user's position in the network. Specifically, the following RAT-dependent positioning technologies can be used, which can meet the positioning requirements for various use cases (e.g., indoor, outdoor, and industrial IoT):

[0170] (a) Downlink time difference of arrival (DL-TDOA);

[0171] (b) Uplink time difference of arrival (UL-TDOA);

[0172] (c) Downlink angle of departure (DL-AoD);

[0173] (d) Uplink angle of arrival (UL-AoA);

[0174] (e) multi-cell round trip time (multi-RTT); and

[0175] (f) NR enhanced cell ID (E-CID).

[0176] Leveraging the wide bandwidth and beamforming capabilities of positioning signals in the mmWave frequency band, RAT-based positioning technologies can achieve higher positioning accuracy. In some aspects, the downlink positioning reference signal (DL PRS) and the uplink (UL) positioning sounding reference signal (SRSp), or SRS, can be used as enablers to achieve the target performance characteristics. The terms SRSp and SRS (conventional SRS) are used interchangeably.

[0177] In some aspects, to further improve positioning accuracy, carrier phase positioning (CPP) can be introduced as part of the 5G advanced technologies in the Rel-18 NR evolution. CPP can achieve centimeter-level positioning accuracy based on the reference signal carrier phase (RSCP) measurements on the DL PRS and SRSp reported in the DL and UL, respectively.

[0178] However, for accurate RSCP measurements and their use to determine the target UE position using DL / UL CPP, it is crucial to eliminate the effects of the initial phase at the transmitter and receiver. This can be done through calibration using a Positioning Reference Unit (PRU), which is a UE with known location coordinates at the UE, and a Location Management Function (LMF), which can report measurements on DL PRS or can send SRSp.

[0179] In some aspects, calibration using PRUs can help estimate and compensate for uncalibrated timing errors at the network side or at the target UE for timing-based positioning methods (e.g., ULTDOA, DL RSTD, or Multi-RTT (involving gNB and UE Rx-Tx time difference measurement and reporting)) when targeting high (e.g., sub-meter) accuracy. Similarly, calibration using PRUs can be used on the NW side to estimate and compensate for errors in the Antenna Reference Point (ARP) position or the effects of Phase Center Offset (PCO) (for angle-based positioning methods or also for CPP).

[0180] For example, for a network (NW) based solution for calibration error mitigation, the measurement and compensation of timing error is performed by the LMF using the PRU.

[0181] For UE-based solutions, the target UE may receive estimated timing / phase / ARP position etc. errors from the LMF (which utilizes the PRU for error estimation) for compensation when determining its position.

[0182] In some aspects, considering NW-based solutions, the calibration process using PRU consists of two phases:

[0183] (a) Phase 1: gNB measurement with PRU, where the gNB TX / RX or gNB TX+RX timing error is measured.

[0184] Phase 2: gNB measurements with target (regular) UEs, where UE TX / RX or UE TX+RX timing errors are measured.

[0185] Figure 8 Diagram 800 illustrates a cellular system using sounding reference signal (SRS) transmissions from a positioning reference unit (PRU) and a target UE in the context of uplink carrier phase positioning (UL CPP) or uplink time difference of arrival (UL TDOA) positioning, in accordance with some aspects.

[0186] In some aspects, calibration using the PRU can be based on periodic transmission of SRSp from the PRU or periodic measurement reports from the PRU based on measurements of the DL PRS, and corresponding tracking of timing errors on the network side. This can effectively decouple transmission or measurement scheduling for the PRU and the target UE. However, if the network-side clock is not very stable with minimal clock drift, this option may require very frequent calibration and tracking. This may result in significant use of system resources and undesirable power consumption at the PRU.

[0187] Alternatively, it may be more desirable to ensure that transmissions and measurements are performed simultaneously or sufficiently close in time between the PRU and the target UE. This can ensure more accurate error estimation under time / frequency drift. In addition, particularly for DL / UL CPP, accurately calibrating the initial Tx / Rx phase using a double-differential approach will require measurements to be performed on the same DL PRS resource or on SRSp transmissions that are sufficiently close in time.

[0188] The above scenarios would require the LMF to be able to request or receive information from the serving gNB on specific SRSp opportunities to align across NG-RAN nodes on the UL. Similarly, on the DL, the LMF should be able to instruct the PRU (i.e., typically the UE) to perform measurements on specific PRS resources or resource sets. The current specifications for the NR Positioning Protocol A (NRPPa) between the LMF and NG-RAN nodes and the LTE Positioning Protocol (LPP) between the LMF and the UE do not support such capabilities.

[0189] The disclosed technology includes systems and methods for supporting high-precision positioning by enabling such communication between the LMF and NG-RAN nodes, and between the LMF and the UE. Specifically, the disclosed technology includes functionality that allows the LMF to:

[0190] (a) Requesting the serving gNB to schedule SRSp at specific occasions and requesting the NG-RAN node (here the gNB) to perform measurements at those SRSp occasions or at SRSp occasions within a time window;

[0191] (b) receiving information from the serving gNB on SRSp occasions and requesting the NG-RAN node (here the gNB) to perform measurements on those SRSp occasions or on SRSp occasions within a time window; and

[0192] (c) Requesting the UE to perform measurements on a specific PRS resource / resource set or PRS resources / resource sets within the time window.

[0193] Request SRSp scheduling at a specific time

[0194] In some aspects, for high-precision positioning methods, the LMF may be configured to request the serving gNB to schedule an SRSp at a specific opportunity and to request the NG-RAN node (here, the gNB) to perform measurements at the SRSp opportunity or at an SRSp opportunity within a time window.

[0195] In some aspects, the LMF may optionally indicate to the serving gNB the subframes and timeslots within the subframes in which the SRSp may be scheduled for transmission from the UE as reference timeslots. Alternatively, the LMF may indicate to the serving gNB the subframes and timeslots within the subframes in which the SRSp may be scheduled for transmission from the UE.

[0196] In some aspects, subframes and slots may be indicated via a combination of subframe and slot offsets or only slot offsets for a reference time.In another example, the reference time may correspond to the SFN initialization time carried via a "Relative Time 1900" information element (IE).

[0197] In some aspects, the time slot and / or reference time slot is determined based on a subcarrier spacing (SCS) from an initial or active uplink portion of bandwidth (BWP).

[0198] In some aspects, an indication of the SRSp scheduled subframes and time slots or the SRSp scheduled time slots may be provided by the LMF via the NRPPa as part of the "Requested SRSTransmission Characteristics" IE in the POSITIONING INFORMATION REQUEST message.

[0199] In some aspects, once a SRSp scheduling reference slot is provided, for periodic and semi-persistent SRSp transmissions, the SRSp opportunity is defined to maintain a certain period relative to the reference slot indicated for SRSp scheduling as indicated in the "RequestedSRS Transmission Characteristics" IE. In another example, once a SRSp scheduling reference slot is provided for aperiodic SRSp transmissions, the SRSp opportunity is the same as the SRSp scheduling reference slot.

[0200] In some embodiments, the LMF may optionally indicate to the serving gNB a time window of reference slots in which SRSp transmissions from the UE should be scheduled. In an example, the time window may be defined by a number of consecutive slots, with an indication of the starting slot and the number of slots relative to the reference time. In another example, the reference time may correspond to the SFN initialization time carried via the "Relative Time 1900" IE.

[0201] In some aspects, upon receiving an indication from the LMF regarding a time window in which reference slots for SRSp transmissions from a UE should be scheduled, the gNB is expected to determine a suitable reference slot for SRSp transmissions and optionally indicate the selected reference slot to the LMF as part of a POSITIONING INFORMATION RESPONSE message. This option may provide the serving gNB with some flexibility in determining a suitable slot for SRSp scheduling. Furthermore, if the gNB does not provide an indication of a selected reference slot for SRSp scheduling, the LMF may assume that a specific slot (e.g., the first slot) within the indicated time window has been selected.

[0202] The term "scheduled" is generally used to imply higher layer based configuration and / or both higher layer and lower layer based triggering, as may apply to periodic / semi-persistent / aperiodic SRS transmissions.

[0203] Request the NG-RAN node to perform measurements at specific SRSp opportunities

[0204] In some aspects, for high precision positioning methods, the LMF may be configured to receive information from the serving gNB on SRSp occasions and request the NG-RAN node (gNB) to perform measurements on those SRSp occasions or on SRSp occasions within a time window.

[0205] In some aspects, assuming that the LMF has received confirmation or information about the reference time slot for SRSp scheduling, the LMF may request the NG-RAN node (where the NG-RAN node is the gNB in ​​this work) to perform measurements on the corresponding SRSp resources.

[0206] In some aspects, the LMF may optionally request the NG-RAN node to perform measurements in one or more reference time slots on SRSp resources. The reference time slots for measurements on SRSp resources may be provided to the NG-RAN node using the "SRS Configuration" IE in the MEASUREMENT REQUEST message. Although described herein using "SRSp," the reference time slots may correspond to SRS for Positioning (SRSp) resources or regular SRS resources as indicated in the "SRS Configuration" IE.

[0207] In some aspects, a combination of subframe and slot offsets or a slot offset relative to a reference time may be used to indicate a reference slot for measurements on SRSp resources. In another example, the reference time may be the SFN initialization time.

[0208] In some aspects, for SRSp (or SRS), the resource set indicated for measurement is periodic or semi-persistent, and an indication of the number of SRSp opportunities starting from the indicated first SRSp opportunity may be provided by the LMF. The indication of the number of SRSp opportunities may be provided directly or via a time window starting from the start of a reference time slot for SRSp resource measurement.

[0209] In some aspects, if the NG-RAN node is expected to report carrier phase measurements, the LMF may request the NG-RAN node to perform the measurements in one or more reference time slots on the SRSp resources.

[0210] In some aspects, in response to receiving a request to perform measurements in one or more reference time slots on SRSp resources, the NG-RAN node may optionally report to the LMF in a MEASUREMENT RESPONSE message or a MEASUREMENT REPORT message whether more, fewer, or different SRSp resources than the requested SRSp resources were used to perform the measurements.

[0211] Request the UE to perform measurements at specific DL PRS opportunities

[0212] In some aspects, for high-precision positioning methods, the LMF node may be configured to instruct the UE to perform measurements on specific PRS resources / resource sets or PRS resources / resource sets within a time window.

[0213] In some aspects, the LMF may optionally request the target UE (which may be a PRU) to perform measurements in one or more reference time slots on the DL PRS resources. The reference time slots for measurements on the DL PRS resources may be provided to the UE using the "CommonIEsRequestLocationInformation" IE in the RequestLocationInformation LPP message.

[0214] In some aspects, the reference time slot for measurements on DL PRS resources may be indicated by a time window identified by a starting point corresponding to the start of the reference time slot and a duration of the window. Additionally, the reference time slot may be indicated by using a combination of a subframe and a time slot offset or a time slot offset relative to a reference time.

[0215] In some aspects, the reference time may be the time provided via the nrTime IE in ScheduledLocationTime. Alternatively, it may be provided separately from the nrTime in ScheduledLocationTime for the indicated reference cell.

[0216] In some aspects, the duration of the time window may be indicated in absolute time units or in number of time slots of an indicated SCS value of a reference cell, or where the time slot duration is determined based on the SCS from a configured DL PRS positioning frequency layer.

[0217] In some aspects, the UE may be expected to use all time slots within the time window with DL PRS resources for the indicated DL PRS ID for measurements on the DL PRS. Alternatively, the UE may be expected to use a portion or a lower bound of the number of time slots within the time window with DL PRS resources for the indicated DL PRS ID for measurements on the DL PRS.

[0218] In some aspects, the reference time slot for measurements on DL PRS resources may be indicated by a time window corresponding to a relative time duration provided in CommonIEsRequestLocationInformation regarding when the message was received.

[0219] In some aspects, if the UE is expected to perform carrier phase measurements for UE-assisted or UE-based positioning, the LMF may request the UE to perform the measurements in one or more reference time slots on the DL PRS resources.

[0220] In some aspects, a system and method for wireless communications for a 5G or New Radio (NR) system may include a location management function (LMF) entity that requests at least one of:

[0221] (a) requesting the NG-RAN node to schedule the transmission of an SRS or SRS for positioning from the UE at a specific time instance or within a specific time window;

[0222] (b) requesting the NG-RAN node to perform measurements on specific SRS or SRS for positioning resources at specific time instances or within specific time windows; and

[0223] (c) Requesting the target UE to perform measurements on specific DL PRS resources at a specific time instance or within a specific time window.

[0224] In some aspects, the NG-RAN node is a gNodeB. In some aspects, the UE is a Positioning Reference Unit (PRU). In some aspects, the LMF indicates to the serving gNB a subframe and a time slot in the subframe as a reference time slot in which an SRSp may be scheduled for transmission from the UE.

[0225] In some aspects, subframes and slots are indicated via a combination of subframe and slot offsets or just slot offsets with respect to a reference time.

[0226] In some aspects, the reference time may correspond to the SFN initialization time carried via the "Relative Time 1900" IE.

[0227] In some aspects, the LMF requests the NG-RAN node to perform measurements in one or more reference time slots on the SRS resources provided to the NG-RAN node using the "SRSConfiguration" IE in the MEASUREMENT REQUEST message.

[0228] In some aspects, the LMF requests the UE to perform measurements in one or more reference time slots on the DL PRS resources, wherein the reference time slots for measurements on the DL PRS resources are provided to the UE using "CommonIEsRequestLocationInformation" in the RequestLocationInformation LPP message.

[0229] Figure 9 A block diagram of a communication device (e.g., an evolved Node B (eNB), a next-generation Node B (gNB) (or another RAN node, such as a base station), a network controlled relay (NCR), an access point (AP), a wireless station (STA), a mobile station (MS), or a user equipment (UE)) is shown, in accordance with some aspects and for performing one or more techniques disclosed herein. In alternative aspects, the communication device 900 can operate as a standalone device or can be connected (e.g., networked) to other communication devices.

[0230] A circuit (e.g., a processing circuit) is a collection of circuits implemented in the tangible form of device 900, including hardware (e.g., simple circuits, gates, logic, etc.). Circuit membership can be flexible over time. A circuit includes members that, when in operation, can perform a specified operation, either individually or in combination. For example, circuit hardware can be invariably designed to perform a specific operation (e.g., hardwired). For example, the circuit hardware can include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.), including machine-readable media that can be physically modified (e.g., magnetically, electrically, by movable placement of invariant aggregate particles, etc.) to encode instructions for a specific operation.

[0231] When connecting physical components, the underlying electrical characteristics of the hardware component are changed, such as from an insulator to a conductor, or vice versa. These instructions enable embedded hardware (e.g., an execution unit or a loading mechanism) to create a member of a circuit in hardware via variable connections to perform a portion of a specific operation when in operation. Thus, in examples, the machine-readable medium element is part of a circuit or is communicatively coupled to other components of the circuit when the device is operating. For example, any physical component can be used in more than one member of more than one circuit. For example, during operation, an execution unit can be used in a first circuit of a first circuit at one point in time and reused by a second circuit in the first circuit at a different time, or reused by a third circuit in the second circuit. The following are additional examples of these components of device 900.

[0232] In some aspects, device 900 can operate as a standalone device or can be connected (e.g., networked) to other devices. In a networked deployment, communication device 900 can operate as a server communication device, a client communication device, or both in a server-client network environment. For example, communication device 900 can act as a peer communication device in a peer-to-peer (P2P) (or other distributed) network environment. Communication device 900 can be a UE, an eNB, a PC, a tablet PC, a STB, a PDA, a mobile phone, a smartphone, a network appliance, a network router, a switch, or a bridge, or any other communication device capable of executing (sequentially or otherwise) instructions specifying actions to be taken by the communication device. Furthermore, while only a single communication device is shown, 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 (SaaS), and other computer cluster configurations.

[0233] Examples as described herein may include logic or a number of components, modules, or mechanisms, or may operate on them. A module is a tangible entity (e.g., hardware) that is capable of performing a specified operation and may be configured or arranged in a certain manner. In an example, circuits may be arranged as modules in a specified manner (e.g., internally, or relative to external entities such as other circuits). In an example, all or part 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 components, or applications) as a module that operates to perform a specified operation. In an example, the software may reside on a communication device-readable medium. In an example, the software, when executed by the underlying hardware of the module, causes the hardware to perform the specified operation.

[0234] Thus, the term "module" is understood to encompass a tangible entity, whether physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., provisionally) configured (e.g., programmed) to operate in a specified manner or to perform some or all of the operations described herein. Considering the example of temporarily configured modules, each module need not be instantiated at all times. For example, where the modules comprise a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as corresponding different modules at different times. The software may configure the hardware processor accordingly, for example, to configure a particular module at one instance in time and to configure a different module at a different instance in time.

[0235] The communication device (e.g., UE) 900 may include a hardware processor 902 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 904, a static memory 906, and a storage device 916 (e.g., a hard drive, a tape drive, a flash memory, or other block or storage device), some or all of which may be in communication with each other via an interconnect link 908 (e.g., a bus).

[0236] The communication device 900 may also include a display device 910, an input device 912 (e.g., a keyboard), and a user interface (UI) navigation device 914 (e.g., a mouse). In an example, the display device 910, input device 912, and UI navigation device 914 may be a touchscreen display. The communication device 900 may also include a signal generating device 918 (e.g., a speaker), a network interface device 920, and one or more sensors 921 (e.g., a global positioning system (GPS) sensor, a compass, an accelerometer, or another sensor). The communication device 900 may include an output controller 928 (e.g., a serial connection (e.g., a universal serial bus (USB)), a parallel connection, or other wired or wireless connection (e.g., infrared (IR), near field communication (NFC), etc.)) for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader, etc.).

[0237] The storage device 916 may include a device-readable medium 922 on which is stored one or more sets of data structures or instructions 924 (e.g., software) embodying or utilized by any one or more of the techniques or functionality described herein. In some aspects, registers of the hardware processor 902, main memory 904, static memory 906, and / or the storage device 916 may be or include (in whole or in part) the device-readable medium 922 on which is stored one or more sets of data structures or instructions 924 embodying or utilized by any one or more of the techniques or functionality described herein. In an example, one or any combination of the hardware processor 902, main memory 904, static memory 906, or the storage device 916 may constitute the device-readable medium 922.

[0238] As used herein, the term "device-readable medium" is interchangeable with "computer-readable medium" or "machine-readable medium." Although device-readable medium 922 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 instructions 924. The term "communication device-readable medium" encompasses the terms "machine-readable medium" or "computer-readable medium" and may include any medium capable of storing, encoding, or carrying instructions (e.g., instructions 924) that are executed by the communication device 900 and cause the communication device 900 to perform any one or more of the techniques of this disclosure, or any medium 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 and optical and magnetic media. Specific examples of communication device-readable media may include non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; random access memory (RAM); and CD-ROM and DVD-ROM disks. In some examples, the communication device-readable media may include non-transitory communication device-readable media. In some examples, the communication device-readable media may include communication device-readable media that is not a transient propagating signal.

[0239] Instructions 924 may also be sent or received over the communication network 926 using a transmission medium via the network interface device 920 using any of a number of transmission protocols. In an example, the network interface device 920 may include one or more physical jacks (e.g., Ethernet jacks, coaxial jacks, or telephone jacks) or one or more antennas to connect to the communication network 926. In an example, the network interface device 920 may include multiple antennas to communicate wirelessly using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) technology. In some examples, the network interface device 920 may communicate wirelessly using multi-user MIMO technology.

[0240] The term "transmission medium" should be understood to include any intangible medium capable of storing, encoding, or carrying instructions for execution by the communication device 900, and includes digital or analog communication signals or another intangible medium for facilitating communication of such software. In this regard, a transmission medium in the context of the present disclosure is a device-readable medium.

[0241] The terms "machine-readable medium," "computer-readable medium," and "device-readable medium" mean the same thing and are used interchangeably in this disclosure. These terms are defined to include both machine storage media and transmission media. Thus, these terms include both storage devices / medium and carrier / modulated data signals.

[0242] Implementations of the described subject matter may include one or more of the features shown below by way of example, alone or in combination.

[0243] Example 1 is an apparatus for a user equipment (UE) configured for operation in a fifth generation new radio (5G NR) network, the apparatus comprising: a processing circuit, wherein, in order to configure the UE for high-precision positioning in the 5G NR network, the processing circuit is used to: decode a configuration message received from a location management function (LMF) server of the 5G NR network, the configuration message indicating at least one downlink positioning reference signal (DL PRS) resource; decode a DL PRS received from a base station during the DL PRS resource; perform at least one positioning measurement using the DL PRS; and encode the at least one positioning measurement for transmission to the base station; and a memory, coupled to the processing circuit and configured to store the configuration message.

[0244] In Example 2, the subject matter of Example 1 includes the following subject matter, wherein the configuration message is CommonIEsRequestLocationInformation in a RequestLocationInformation LTE Positioning Protocol (LPP) message.

[0245] In Example 3, the subject matter of Example 2 includes the following subject matter, wherein the RequestLocationInformation LPP message includes the at least one DL PRS resource, wherein the at least one DL PRS resource includes one or more reference time slots on the DL PRS resource, and wherein the processing circuit is used to: decode the DL PRS received from the base station during the one or more reference time slots.

[0246] In Example 4, the subject matter of Examples 1-3 includes the following subject matter, wherein the configuration message indicates a time window, the time window being identified by a starting point corresponding to the start of a reference time slot and a duration of the time window, and wherein the processing circuit is used to: decode a DL PRS received from the base station during the reference time slot.

[0247] In Example 5, the subject matter of Example 4 includes the following subject matter, wherein the configuration message indicates the reference time slot based on a combination of a subframe and a time slot offset or a time slot offset relative to a reference time.

[0248] In Example 6, the subject matter of Example 5 includes the following subject matter, wherein the reference time is a time provided via an nrTime information element (IE) in a ScheduledLocationTime message.

[0249] In Example 7, the subject matter of Examples 5-6 includes the following subject matter, wherein the reference time is a time provided via an information element (IE) in a ScheduledLocationTime message, the IE being separate from an nrTime IE in the ScheduledLocationTime message.

[0250] In Example 8, the subject matter of Examples 4-7 includes the following subject matter, wherein the duration of the time window is indicated in absolute time units or in a number of time slots of an indicated subcarrier spacing (SCS) value of a reference cell.

[0251] In Example 9, the subject matter as described in Examples 3-8 includes the following subject matter, wherein the one or more reference time slots are indicated by a time window corresponding to a relative time duration provided in the CommonIEsRequestLocationInformation relative to the time when the UE receives the configuration message.

[0252] In Example 10, the subject matter of Examples 1-9 includes: transceiver circuitry coupled to the processing circuitry; and two or more antennas coupled to the transceiver circuitry.

[0253] Example 11 is a computer-readable storage medium storing instructions executed by one or more processors of a location management function (LMF) node, the instructions configuring the LMF node for high-precision positioning in fifth-generation new radio (5G NR) and above networks, and causing the LMF node to perform the following operations, including: decoding a first configuration message received from a first base station, the first configuration message indicating a sounding reference signal (SRSp) timing for positioning; and encoding a second configuration message for transmission to a second base station, the second configuration message including instructions for the second base station to perform positioning measurements in one or more reference time slots in the SRSp timing.

[0254] In Example 12, the subject matter of Example 11 includes the following subject matter, wherein the second configuration message is a Measurement Request message, and the one or more reference time slots are configured using an SRS Configuration information element (IE) in the Measurement Request message.

[0255] Example 13 is a computer-readable storage medium storing instructions executed by one or more processors of a user equipment (UE), the instructions configuring the UE for high-precision positioning in fifth-generation new radio (5G NR) and above networks, and causing the UE to perform the following operations, including: decoding a configuration message received from a location management function (LMF) server of the 5G NR network, the configuration message indicating at least one downlink positioning reference signal (DL PRS) resource; decoding a DL PRS received from a base station during the DL PRS resource; performing at least one positioning measurement using the DL PRS; and encoding the at least one positioning measurement for transmission to the base station.

[0256] In Example 14, the subject matter of Example 13 includes the following subject matter, wherein the configuration message is CommonIEsRequestLocationInformation in a RequestLocationInformation LTE Positioning Protocol (LPP) message.

[0257] In Example 15, the subject matter of Example 14 includes the following subject matter, wherein the RequestLocationInformation LPP message includes the at least one DL PRS resource, wherein the at least one DL PRS resource includes one or more reference time slots on the DL PRS resource, and wherein the operation further includes: decoding the DL PRS received from the base station during the one or more reference time slots.

[0258] In Example 16, the subject matter of Examples 13-15 includes the following subject matter, wherein the configuration message indicates a time window, the time window being identified by a starting point corresponding to the start of a reference time slot and a duration of the time window, and wherein the operation further includes: decoding a DL PRS received from the base station during the reference time slot.

[0259] In Example 17, the subject matter of Example 16 includes the following subject matter, wherein the configuration message indicates the reference time slot based on a combination of a subframe and a time slot offset or a time slot offset relative to a reference time.

[0260] In Example 18, the subject matter of Example 17 comprises the subject matter, wherein the reference time is a time provided via an nrTime information element (IE) in a ScheduledLocationTime message.

[0261] In Example 19, the subject matter of Examples 17-18 includes the following subject matter, wherein the reference time is a time provided via an information element (IE) in a ScheduledLocationTime message, the IE being separate from an nrTime IE in the ScheduledLocationTime message.

[0262] In Example 20, the subject matter of Examples 16-19 includes the following subject matter, wherein the duration of the time window is indicated in absolute time units or in a number of time slots of an indicated subcarrier spacing (SCS) value of a reference cell.

[0263] Example 21 is at least one machine-readable medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to perform operations to implement any of Examples 1-20.

[0264] Example 22 is an apparatus comprising means for implementing any of Examples 1-20.

[0265] Example 23 is a system implementing any of Examples 1-20.

[0266] Example 24 is a method of implementing any of Examples 1-20.

[0267] Although one aspect has been described with reference to specific exemplary aspects, it will be apparent that various modifications and changes may be made to these aspects without departing from the broader scope of the present disclosure. The specification and drawings should therefore be regarded as illustrative rather than restrictive. This detailed description should not be construed as limiting, and the scope of the various aspects is to be determined solely by the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. An apparatus for a user equipment (UE) configured to operate in a fifth generation new radio (5G NR) network, the apparatus comprising: Processing circuitry, wherein, in order to configure the UE for high-precision positioning in the 5G NR network, the processing circuitry is configured to: decoding a configuration message received from a location management function (LMF) server of the 5G NR network, the configuration message indicating at least one downlink positioning reference signal (DL PRS) resource; decoding a DL PRS received from a base station during the DL PRS resource; performing at least one positioning measurement using the DL PRS; and encoding the at least one positioning measurement for transmission to the base station; and A memory is coupled to the processing circuit and configured to store the configuration message.

2. The device according to claim 1, wherein The configuration message is CommonIEsRequestLocationInformation in the RequestLocationInformation LTE Positioning Protocol (LPP) message.

3. The device according to claim 2, wherein The RequestLocationInformation LPP message includes the at least one DL PRS resource, The at least one DL PRS resource comprises one or more reference time slots on the DL PRS resource, and Wherein, the processing circuit is used for: A DL PRS received from the base station during the one or more reference time slots is decoded.

4. The device according to any one of claims 1 to 3, wherein The configuration message indicates a time window, the time window being identified by a starting point corresponding to the start of a reference time slot and a duration of the time window, and Wherein, the processing circuit is used for: A DL PRS received from the base station during the reference time slot is decoded.

5. The device according to claim 4, wherein The configuration message indicates the reference time slot based on a combination of a subframe and a time slot offset or a time slot offset relative to a reference time.

6. The device according to claim 5, wherein The reference time is the time provided via the nrTime information element (IE) in the ScheduledLocationTime message.

7. The device according to claim 5, wherein The reference time is a time provided via an information element (IE) in a ScheduledLocationTime message, which is separate from the nrTime IE in the ScheduledLocationTime message.

8. The device according to claim 4, wherein The duration of the time window is indicated in absolute time units or in number of time slots of the indicated subcarrier spacing (SCS) value of the reference cell.

9. The device according to claim 3, wherein The one or more reference time slots are indicated by a time window corresponding to a relative time duration provided in CommonIEsRequestLocationInformation relative to a time when the UE receives the configuration message.

10. The apparatus according to any one of claims 1 to 3, further comprising: transceiver circuitry coupled to the processing circuitry; and Two or more antennas are coupled to the transceiver circuitry.

11. A computer-readable storage medium storing instructions for execution by one or more processors of a location management function (LMF) node, the instructions configuring the LMF node for high-precision positioning in fifth generation new radio (5G NR) and above networks, and causing the LMF node to perform the following operations, including: decoding a first configuration message received from a first base station, the first configuration message indicating a sounding reference signal (SRSp) timing for positioning; as well as A second configuration message is encoded for transmission to a second base station, the second configuration message including an instruction for the second base station to perform positioning measurements in one or more reference time slots in the SRSp opportunity.

12. The computer-readable storage medium of claim 11, wherein: The second configuration message is a Measurement Request message, and the one or more reference time slots are configured using an SRS Configuration Information Element (IE) in the Measurement Request message.

13. A computer-readable storage medium storing instructions for execution by one or more processors of a user equipment (UE), the instructions configuring the UE for high-precision positioning in a fifth generation new radio (5G NR) and above network, and causing the UE to perform the following operations, including: decoding a configuration message received from a location management function (LMF) server of the 5G NR network, the configuration message indicating at least one downlink positioning reference signal (DL PRS) resource; decoding a DL PRS received from a base station during the DL PRS resource; performing at least one positioning measurement using the DL PRS; and The at least one positioning measurement is encoded for transmission to the base station.

14. The computer-readable storage medium of claim 13, wherein: The configuration message is CommonIEsRequestLocationInformation in the RequestLocationInformation LTE Positioning Protocol (LPP) message.

15. The computer-readable storage medium of claim 14, wherein: The RequestLocationInformation LPP message includes the at least one DL PRS resource, wherein the at least one DL PRS resource comprises one or more reference time slots on a DL PRS resource, and The operation further includes: A DL PRS received from the base station during the one or more reference time slots is decoded.

16. The computer-readable storage medium according to any one of claims 13 to 15, wherein: The configuration message indicates a time window, the time window being identified by a starting point corresponding to the start of a reference time slot and a duration of the time window, and The operation further includes: A DL PRS received from the base station during the reference time slot is decoded.

17. The computer-readable storage medium of claim 16, wherein: The configuration message indicates the reference time slot based on a combination of a subframe and a time slot offset or a time slot offset relative to a reference time.

18. The computer-readable storage medium of claim 17, wherein: The reference time is the time provided via the nrTime information element (IE) in the ScheduledLocationTime message.

19. The computer-readable storage medium of claim 17, wherein: The reference time is a time provided via an information element (IE) in a ScheduledLocationTime message, which is separate from the nrTime IE in the ScheduledLocationTime message.

20. The computer-readable storage medium of claim 16, wherein: The duration of the time window is indicated in absolute time units or in number of time slots of the indicated subcarrier spacing (SCS) value of the reference cell.

Images