Discovery and re-selection of anchor UEs for sidelink communication

Abstract

A computer-readable storage medium configures a UE as a target UE for sidelink-based positioning in 5G NR and later networks, and stores instructions to be executed by one or more processors of the UE to cause the UE to perform actions. The actions include encoding a discovery announcement message for broadcasting to multiple anchor UEs. The discovery announcement message includes a sidelink positioning service code and the sidelink positioning capability of the target UE. A discovery response message received from one of the multiple anchor UEs via a direct PC5 communication link established by that anchor UE is decoded. The discovery response message indicates the sidelink positioning capability of that anchor UE. Based on the agreement that the sidelink positioning capability of the anchor UE matches that of the target UE, a positioning session with the anchor UE is initiated.

Description

Background Art

[0001] Mobile communications have evolved from initial voice systems to today's highly sophisticated integrated communication platforms. Along with the increasing number of various types of devices that communicate with a variety of network devices, the use of 3GPP (registered trademark) LTE systems is also increasing. The popularity of mobile devices (user equipment or UE) in modern society continues to drive the demand for a wide range of network devices in diverse environments. The fifth-generation (5G) wireless system is approaching, and is expected to enable even greater speed, connectivity, and usability. Future generations after the next-generation 5G network (or NR network), such as the 6G network, are expected to improve throughput, coverage, and robustness, and reduce latency as well as operation and equipment investment. The 5G NR (and later) network continues to evolve based on 3GPP (registered trademark) LTE-Advanced with additional potential new radio access technologies (RAT) to enrich people's lives with seamless wireless connection solutions, high-speed delivery, and rich content and services. Since the current cellular network frequencies are saturated, higher frequencies such as millimeter wave (mmWave) frequencies may be beneficial due to their high bandwidth.

[0002] Even more enhanced operation of LTE systems and NR systems in licensed spectrum and unlicensed spectrum is expected in future releases of 5G and later systems. Such enhanced operation may include techniques for setting discovery and reselection of user equipment (UE) for sidelink (SL)-based positioning and sensing.

Brief Description of the Drawings

[0003] The diagrams are not necessarily drawn to scale, but the same number may represent similar components in different diagrams. The same number with different letter suffixes may represent different instances of similar components. The diagrams generally represent various aspects described in this document as examples, not limitations.

[0004] [Figure 1A] This represents the network architecture in relation to several aspects. [Figure 1B] This represents a non-roaming 5G system architecture related to several aspects. [Figure 1C] This represents a non-roaming 5G system architecture related to several aspects. [Figure 2] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 3] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 4] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 5] This represents a variety of systems, architectures, devices, and components that may implement aspects of the disclosed embodiments. [Figure 6] This illustrates an example of an artificial intelligence (AI)-assisted communication architecture for communication between the UE and RAN, relating to several aspects. [Figure 7] This illustrates an example of a RAN partitioning architecture that relates to several aspects. [Figure 8] This illustrates an example of an SL positioning architecture relating to several aspects. [Figure 9] This swimlane diagram illustrates an exemplary function for anchor UE selection based on position management function (LMF), relating to several aspects. [Figure 10]This swimlane diagram illustrates exemplary functionality for LMF-assisted anchor UE selection, relating to several aspects. [Figure 11] This swimlane diagram illustrates exemplary functionality for setting up an ongoing SL positioning session after anchor UE re-selection, relating to several aspects. [Figure 12] This diagram shows a block diagram of communication devices such as evolved NodeBs (eNBs), next-generation NodeBs (gNBs) (or other RAN nodes), NCRs, access points (APs), wireless stations (STAs), mobile stations (MSs), or user equipment (UEs), relating to several aspects. [Modes for carrying out the invention]

[0005] The following descriptions and drawings are intended to adequately represent the aspects so that those skilled in the art can implement them. Other aspects may incorporate structural, logical, electrical, process, and other modifications. Some parts and features of certain aspects may be included in other aspects or replaced by those of other aspects. The aspects described in the claims encompass all available equivalents of the claims.

[0006] Figures 1A to 12 represent various systems, devices, and components that may implement aspects of the disclosed embodiments in different communication systems, such as 5G-NR (and later) networks. The UEs, base stations (e.g., gNBs), and / or other nodes (e.g., satellites or other computing nodes) described herein may be configured to perform the disclosed technologies.

[0007] Figure 1A shows the architecture of a network relating to several aspects. The communication network 140A is shown as including user equipment (UE) 101 and UE102. UE101 and UE102 are represented as smartphones (e.g., portable touchscreen mobile computing devices capable of connecting to one or more cellular networks), but may also include any mobile or non-mobile computing devices, such as personal digital assistants (PDAs), pagers, laptop computers, desktop computers, wireless handsets, drones, or any other computing devices including wired and / or wireless communication interfaces. UE101 and UE102 may collectively be referred to as UE101, which can be used to perform one or more of the technologies disclosed herein.

[0008] Any of the wireless links disclosed herein (for example, used in communication network 140A or any other exemplified network) may operate in accordance with any exemplary wireless communication technology and / or standard.

[0009] LTE and LTE-Advanced are standards for high-speed data wireless communication for UEs such as mobile phones. In LTE-Advanced and various wireless systems, carrier aggregation is a technique in 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.

[0010] The aspects described herein may be used in relation to any spectrum management scheme, including, for example, dedicated licensed spectra, unlicensed spectra, and (licensed) shared spectra (e.g., Licensed Shared Access (LSAs) for 2.3–2.4 GHz, 3.4–3.6 GHz, 3.6–3.8 GHz, and higher frequencies, and Spectral Access Systems (SAS) for 3.55–3.7 GHz and higher frequencies).

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

[0012] In some respects, both UE101 and UE102 may include Internet of Things (IoT) UEs or Cellular IoT (CIoT) UEs that include a network access layer designed for low-power IoT applications that utilize short-lived UE connections. In some respects, both UE101 and UE102 may include Narrowband (NB) IoT UEs (e.g., Enhanced NB-IoT (eNB-IoT) UEs and Further Enhanced (FeNB-IoT) UEs). IoT UEs may utilize technologies such as Public Land Mobile Networks (PLMCs), Proximity-Based Services (ProSe), or Device-to-Device (D2D) communications, sensor networks, or Machine-to-Machine (M2M) or Machine-Type Communications (MTC) that exchange data with MTC servers or devices over the IoT network. Data exchange via M2M or MTC may be machine-initiated data exchange. The IoT network may include interconnecting IoT UEs that may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. IoT UE can run background applications (e.g., keep-alive messages, status updates, etc.) to enable IoT network connectivity.

[0013] In some respects, both UE101 and UE102 may include an Enhanced MTC (eMTC) UE or a Further Enhanced MTC (FeMTC) UE.

[0014] UE101 and UE102 may be configured to connect to a radio access network (RAN) 110, for example, to be communicatively coupled. RAN 110 may be, for example, a Universal Mobile Telecommunications System (UMTS), an Evolved Universal Terrestrial Radio Access Network (E-UTRAN), a NextGen RAN (NG RAN), or other types of RAN. UE101 and UE102 utilize connections 103 and 104, respectively. Each of connections 103 and 104 includes a physical communication interface or layer (described in further detail below). In this example, connections 103 and 104 are represented as air interfaces enabling communication coupling and can comply with cellular communication protocols such as Global System for Mobile Communications (GSM) protocol, Code Division Multiple Access (CDMA) network protocol, Push-to-Talk (PTT) protocol, PTT over Cellular (POC) protocol, Universal Mobile Telecommunications System (UMTS) protocol, 3GPP® Long-Term Evolution (LTE) protocol, 5th generation (5G) protocol, and New Radio (NR) protocol.

[0015] In one aspect, UE101 and UE102 may further exchange communication data directly via the ProSe interface 105. The ProSe interface 105 may alternatively be called a sidelink interface that includes one or more logical channels, including (but not limited to) a physical sidelink control channel (PSCCH), a physical sidelink sharing channel (PSSCH), a physical sidelink discovery channel (PSDCH), and a physical sidelink broadcast channel (PSBCH).

[0016] UE102 is shown configured to access access point (AP)106 via connection 107. Connection 107 may include a local radio connection, such as a connection that follows any IEEE 802.11 protocol, and accordingly, AP106 may include Wireless Fidelity (Wi-Fi®). In this example, AP106 is shown to connect to the internet without being connected to the core network of the radio system (described in more detail below).

[0017] RAN110 may include one or more access nodes that enable connections 103 and 104. These access nodes (ANs) may be called base stations (BS), NodeBs, evolved NodeBs (eNBs), next-generation NodeBs (gNBs), RAN network nodes, etc., and may include ground stations (e.g., ground access points) or satellite stations that provide coverage within a geographical range (e.g., a cell). In some aspects, communication nodes 111 and 112 may be transmit / receive points (TRPs). If communication nodes 111 and 112 are NodeBs (e.g., eNBs or gNBs), one or more TRPs may function within the communication cell of the NodeB. RAN110 may include one or more RAN nodes that provide microcells, e.g., macroRAN nodes, and one or more RAN nodes that provide femtocells or picocells (e.g., cells with smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low-power (LP) RAN nodes or secondary RAN nodes based on unlicensed spectrum.

[0018] Either of the communication nodes 111 and 112 can terminate the air interface protocol and can be the first contact point for the UEs 101 and 102. In some aspects, either of the communication nodes 111 and 112 can satisfy 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, data packet scheduling, and mobility management. As an example, either of the communication nodes 111 and / or 112 can be a next-generation NodeB (gNB), an evolved NodeB (eNB), or other types of RAN nodes.

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

[0020] On this side, CN120 includes a Mobility Management Entity (MME) 121, a Serving Gateway (S-GW) 122, a Packet Data Network (PDN) Gateway (P-GW) 123, and a Home Subscriber Server (HSS) 124. The MME 121 may have the same functions as the control plane of the legacy Serving General Packet Radio Service (GPRS) Support Node (SGSN). The MME 121 may manage aspects of mobility in access, such as gateway selection and Tracking Area List management. The HSS 124 may have a database for network users, including subscription-related information that supports the communication session processing of network entities. CN120 may have one or more HSSs 124 depending on the number of mobile subscribers, equipment capacity, network configuration, etc. For example, the HSS 124 can support routing / roaming, authentication, authorization, naming / address resolution, location dependence, etc.

[0021] The S-GW 122 may terminate the S1 interface 113 to the RAN 110 and route data packets between the RAN 110 and the CN 120. Further, the S-GW 122 may be a local mobility anchor point for handovers between RAN nodes and may also provide an anchor for mobility between 3GPP (registered trademark) networks. Other responsibilities of the S-GW 122 may include lawful interception, charging, and enforcement of some policies.

[0022] The P-GW123 may terminate the SGi interface to the PDN. The P-GW123 may route data packets between the EPC network (e.g., CN120) and external networks, such as the network containing the application server 184 (alternatively also called the application function (AF)), via the Internet Protocol (IP) interface 125. The P-GW123 may also communicate data to other external networks 131A, which may include the Internet, IP Multimedia Subsystem (IPS) networks, and other networks. Generally, the application server 184 may be a request providing applications that use IP bearer resources together with the core network (e.g., UMTS Packet Service (PS) domain, LTE PS Data Service, etc.). In this aspect, the P-GW123 is shown as being communicably coupled to the application server 184 via the IP interface 125. The application server 184 may also be configured to support one or more communication services (e.g., Voice over Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for UE101 and UE102 via CN120.

[0023] P-GW123 may also be a node for policy enforcement and billing data collection. The Policy and Billing Rule Function (PCRF)126 is the policy and billing control element of CN120. In non-roaming scenarios, in some aspects, a single PCRF may exist in the Home Public Land Mobile Network (HPLMN) associated with the UE's Internet Protocol Connected Access Network (IP-CAN). In roaming scenarios with localized traffic breakouts, two PCRFs may exist associated with the UE's IP-CAN session: a Home PCRF (H-PCRF) in the HPLMN and a Visited PCRF (V-PCRF) in the Visited Public Land Mobile Network (VPLMN). PCRF126 may be communicably coupled to the application server 184 via P-GW123.

[0024] In some respects, communication network 140A can be a 5G network or IoT network that includes a 5G nu-radio network using communication on the licensed spectrum (5G NR) and the unlicensed spectrum (5G NR-U). One of the current means of implementing IoT is narrowband IoT (NB-IoT).

[0025] The NG system architecture may include a RAN110 and a 5G core network (e.g., CN120). The RAN110 within the NG system may be called NG-RAN. The RAN110 may include multiple nodes such as gNBs and NG-eNBs. The CN120 (also called the 5G core network or 5GC) may include Access and Mobility Functions (AMF) and / or User Plane Functions (UPF). The AMF and UPF may be communicatively coupled to the gNB and NG-eNB via NG interfaces. More specifically, in some aspects, the gNB and NG-eNB may be coupled to the AMF by an NG-C interface and connected to the UPF by an NG-U interface. The gNB and NG-eNB may be coupled to each other via an Xn interface.

[0026] In some respects, the NG system architecture can utilize various internode reference points provided by 3GPP® Technical Specification (TS) 23.501 (e.g., v15.4.0, December 2018). In some respects, gNB and NG-eNB can be implemented as base stations, mobile edge servers, small cells, home eNBs, RAN network nodes, etc. In some respects, a gNB can be a master node (MNH), and an NG-eNB can be a secondary node (SN) in a 5G architecture. In some respects, the master / primary node can operate in licensed bandwidth, and the secondary node can operate in unlicensed bandwidth.

[0027] Figure 1B represents a non-roaming 5G system architecture relating to several aspects. Referring to Figure 1B, the 5G system architecture 140B is represented in reference point representation. More specifically, UE 101 can communicate with RAN 110 and one or more other 5G core (5GC) network entities. The 5G system architecture 140B includes several network functions (NFs), such as Access and Mobility 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. The UPF 134 can provide connectivity to a data network (DN) 152, which may include, for example, operator services, internet access, or third-party services. AMF132 can be used to manage access control and mobility, and may also include network slice selection functionality. SMF136 can be configured to set up and manage various sessions according to network policies. UPF134 can be deployed in one or more configurations according to desired service types. PCF148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in 4G communication systems). UDM can be configured to store subscriber profiles and data (similar to HSS in 4G communication systems).

[0028] The LMF133 can be used in connection with 5G positioning functionality. In some aspects, the LMF133 receives measurement and support information from the RAN110 and mobile device (e.g., UE101) via the AMF132 through the NLs interface to calculate the position of the UE101. In some aspects, the NR Positioning Protocol A (NRPPa) can be used to carry positioning information between the NG-RAN and the LMF133 via the Next Generation Control Plane Interface (NG-C). In some aspects, the LMF133 configures the UE using the LTF Positioning Protocol (LPP) via the AMF132. The RAN110 configures the UE101 using the Radio Resource Control (RRC) protocol via the LTE-Uu interface and the NR-Uu interface.

[0029] In several aspects, the 5G system architecture 140B configures various reference signals to enable positioning measurements. Reference signals that may be used for positioning measurements include, for example, a positioning reference signal (NR PRS) in the downlink and a positioning sounding reference signal (SRS) in the uplink. The downlink positioning reference signal (PRS) is a reference signal configured to support downlink-based positioning methods.

[0030] In several respects, the 5G system architecture 140B includes an IP multimedia subsystem (IMS) 168B and several IP multimedia core network subsystem entities, such as cell session control functions (CSCFs). More specifically, IMS 168B includes CSCFs that can operate as a proxy CSCF (P-CSCF) 162B, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not shown in Figure 1B), or an interrogating CSCF (I-CSCF) 166B. P-CSCF 162B may be configured to be the first contact point for UE 102 within IMS 168B. S-CSCF 164B may be configured to handle session state within the network, and E-CSCF may be configured to handle specific aspects of emergency sessions, such as routing emergency requests to the correct emergency center or PSAP. The I-CSCF166B may be configured to function as a contact point within the network operator's network for all IMS connections directed to the network operator's subscribers or roaming subscribers currently located within the network operator's service area. In some aspects, the I-CSCF166B may connect to other IP multimedia networks 170, for example, IMS operated by different network operators.

[0031] In some respects, the UDM / HSS146 can be coupled to an application server (AS) 160B which may include a telephony application server (TAS) or other ASs. The AS160B can be coupled to the IMS168B via the S-CSCF164B or I-CSCF166B.

[0032] Reference point representations indicate that interactions may exist between corresponding NF services. For example, Figure 1B shows the following reference points: N1 (between UE102 and AMF132), N2 (between RAN110 and AMF132), N3 (between RAN110 and UPF134), N4 (between SMF136 and UPF134), N5 (between PCF148 and AF150, not shown), N6 (between UPF134 and DN152), N7 (between SMF136 and PCF148, not shown), N8 (between UDM / HSS146 and AMF132, not shown), N9 (between two UPFs, not shown), N10 (between UDM / HSS146 and SMF136, Figure 1B). N11 (between AMF132 and SMF136, not shown), N12 (between AUSF144 and AMF132, not shown), N13 (between AUSF144 and UDM / HSS146, not shown), N14 (between two AMFs, not shown), N15 (between PCF148 and AMF132 in a non-roaming scenario, or between PCF148, a visited network and AMF132 in a roaming scenario, not shown), N16 (between two SMFs, not shown), and N22 (between AMF132 and NSSF142, not shown). Other reference point representations not shown in Figure 1B may also be used.

[0033] Figure 1C represents a 5G system architecture 140C and a service-based representation. In addition to the network entities shown in Figure 1B, 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 can be service-based, and interactions between network functions may be represented by corresponding point-to-point reference points Ni or as service-based interfaces.

[0034] In some respects, as shown in Figure 1C, service-based representations can be used to represent network functions within the control plane that enable other authorized network functions to access those services. In this regard, the 5G system architecture 140C may include the following service-based interfaces: Namf158H (service-based interface shown in AMF132), Nsmf158I (service-based interface shown in SMF136), Nnef158B (service-based interface shown in NEF154), Npcf158D (service-based interface shown in PCF148), Nudm158E (service-based interface shown in UDM / HSS146), Naf158F (service-based interface shown in AF150), Nnrf158C (service-based interface shown in NRF156), Nnssf158A (service-based interface shown in NSSF142), and Nausf158G (service-based interface shown in AUSF144). Other service-based interfaces not shown in Figure 1C (e.g., Nudr, N5g-eir, and Nudsf) may also be used.

[0035] Figure 2 shows an example network architecture 200. Network architecture 200 can operate in accordance with 3GPP® technical specifications for LTE or 5G / NR systems and can implement the disclosed technologies (for example, the disclosed technologies may be comprised / implemented by one or more devices operating within network architecture 200). However, the exemplary embodiments are not limited thereto, and the examples described may be applied to other networks that benefit from the principles described herein, such as future 3GPP® systems.

[0036] The network architecture 200 may include a UE202, which is any mobile or non-mobile computing device designed to communicate with the RAN204 via an over-the-air connection. The UE202 is coupled to the RAN204 via a Uu interface. This may be applicable to both LTE and NR systems. Examples of UE202 applications include smartphones, tablet computers, wearable devices (e.g., smartwatches, fitness trackers, smart glasses, smart clothing / fabrics, head-mounted displays, smart shows, etc.), desktop computers, workstations, laptop computers, automotive infotainment systems, in-car entertainment devices, instrument panels, head-up display (HUD) devices, onboard diagnostic devices, dashboard 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, network appliances, machine-type communication devices, machine-to-machine (M2M) or device-to-device (D2D), machine-type communication (MTC) devices, Internet of Things (IoT) devices, smart appliances, flying drones or unmanned aerial vehicles (UAVs), ground drones or autonomous vehicles, robots, digital signage, and single-board computers (SBCs) (e.g., Raspberry Pi, Arduino, Intel). This includes, but is not limited to, Edison, plug computers, and / or any other computing devices described herein.

[0037] Additionally, or alternatively, UE202 can be a RedCap UE. A RedCap UE is a reduced-capacity UE as defined in Section 4.2.21.1 of 3GPP® TS 38.306 v17.4.0 (March 30, 2023) ([TS38306]).

[0038] The network architecture 200 may include a set of UE202 directly coupled to one another via any other suitable interface, such as D2D, ProSe, PC5, and / or SL interfaces, and / or any of those described herein. These UE202 may be M2M / D2D / MTC / IoT devices and / or vehicle systems communicating using physical side channels such as (but not limited to) PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc. The UE202 may attempt blind decoding of SL channels / links according to various examples herein.

[0039] In some examples, the UE202 may also communicate with the AP206 via an over-the-air (OTA) connection. The AP206 manages the WLAN connection. The WLAN connection may help offload some / all network traffic from the RAN204. The connection between the UE202 and the AP206 may follow any IEEE 802.11 protocol. Furthermore, the UE202, RAN204, and AP206 may utilize cellular-WLAN aggregation / integration (e.g., LWA / LWIP). Cellular-WLAN aggregation may involve the RAN204 configuring the UE202 to utilize both cellular radio resources and WLAN resources.

[0040] RAN204 includes one or more access network nodes (ANs). AN208 terminates the air interface protocol for UE202 by providing access stratum protocols including RRC protocol, PDCP protocol, RLC protocol, MAC protocol, and PHY / L1 protocol. In this way, AN208 may be a macrocell base station or low-power base station providing a smaller coverage area, smaller user capacity, or higher bandwidth compared to a femtocell, picocell, or other similar cell, or any combination thereof. In these implementations, AN208 may be called BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, etc.

[0041] One exemplary implementation is a “CU / DU split” architecture in which AN208 can be embodied as a gNB central unit (CU) communicatively coupled to one or more gNB distributed units (DUs), each DU 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 individual RSUs. In some implementations, the CU / DU split may include an NG-eNB-CU and one or more NG-eNB-DUs instead of, or in addition to, a gNB-CU and a gNB-DU, respectively. AN208 used as a CU may be implemented in a discrete device, or as one or more software entities running on a server computer as part of a virtual network including, for example, 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. (note that these terms may refer to different implementation concepts). Other types of architectures, deployments, and / or configurations may be used.

[0042] A pair of ANs can be coupled to each other via an X2 interface (if RAN204 is an LTE RAN or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 210) or an Xn interface (if RAN204 is an NG-RAN 214). In some examples, the X2 / Xn interface may be split into a control / user plane interface, which may allow ANs to communicate information regarding handover, data / context transfer, mobility, load management, interference coordination, etc.

[0043] Each AN of RAN204 may manage one or more cells, cell groups, component carriers, etc., and provide an air interface to UE202 for network access. UE202 may be connected simultaneously to sets of cells provided by the same or different AN208s of RAN204. For example, UE202 and RAN204 may use carrier aggregation to enable UE202 to connect to sets of component carriers corresponding to Pcells or Scells, respectively. In a dual connectivity scenario, the first AN208 may be a master node providing an MCG, and the second AN208 may be a secondary node providing an SCG. The first / second AN208 may be any combination of eNBs, gNBs, ng-eNBs, etc.

[0044] The RAN204 may provide an air interface via a licensed spectrum or an unlicensed spectrum. To operate on the unlicensed spectrum, a node may use LAA, eLAA, and / or feLAA mechanisms based on CA technology by PCell / Scell. Before accessing the unlicensed spectrum, a node may perform a medium / carrier detection operation, for example, based on a listen-before-talk (LBT) protocol.

[0045] Additionally, or alternatively, individual UE202s supply radio information to one or more AN208s and / or one or more edge computing nodes (e.g., edge server hosts). This radio information may take the form of one or more measurement reports, which may include, for example, signal strength measurements, signal quality measurements, and / or similar. Each measurement report is tagged with a timestamp and the location of the measurement (e.g., the current location of the UE202). For example, measurements collected by the UE202 and / or included in measurement reports include: bandwidth (BW), network or cell load, latency, jitter, round-trip time (RTT), number of interrupts, out-of-order delivery of data packets, transmission power, bit error rate, bit error ratio (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 interference ratio (SINR), signal-to-noise-and-distortion ratio (SINAD), carrier-to-interference-and-noise ratio (CINR), and additive white Gaussian noise (AWG). N), Energy per bit to Noise Power Density Ratio (Eb / N0), Energy per chip to Interference Power Density Ratio (Ex / I0), Energy per chip to Noise Power Density Ratio (Ec / N0), Peak vs. Average Power Cost (PAPR), Reference Signal Received Power (RSRP), Reference Signal Received Path Power (PSRPP), Reference Signal Received Quality (RSRQ), Received Signal Strength Indicator (RSSI), Received Channel Power Indicator (RCPI), Received Signal vs. Noise Indicator (RSNI), Received Signal Code Power (RSCP), Reference Signal Carrier Phase (RSCP), Reference Signal Carrier Phase Difference (RSCPD), Carrier Phase Positioning (CPP), Reference Signal Time Difference (RSTD), SSB_RP (Measured at the UE antenna connector or radiated interface boundary, NR Sidelink synchronous signal block (S-SSB) measurements and / or similar, including the received (linear) average power of the resource elements carrying the SSB signal and channel, relative time difference (RTD), receiver (Rx) time delay, Rx timing error, transmitter (Tx) time delay, Tx timing error, NRThis may include one or more of the following measurements: E-CID, Observed Time of Arrival (OTDOA), Mean Noise and Interference (ANPI), GNSS timing of cell frames for UE positioning in E-UTRAN or 5G / NR (e.g., timing between AP or RAN node reference time and GNSS-specific reference time for a given GNSS), GNSS code measurement (e.g., GNSS code phase (integer and fractional parts) of the spreading code of the i-th GNSS satellite signal), GNSS carrier phase measurement (e.g., the number (integer and fractional parts) of the carrier phase period of the i-th GNSS satellite measured since being locked onto the signal, also known as the cumulative delta range (ADR)), channel interference measurement, thermal noise power measurement, received interference power measurement, power histogram measurement, channel load measurement, 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 status information reference signals (CSI-RS), and / or synchronization signals (SS) or SS blocks of 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 of WLAN / Wi-Fi (e.g., [IEEE80211]) networks. Other measurements, for example, 3GPP® TS 36.214 v17.0.0 (March 31, 2022) ([TS36214]), 3GPP® TS 38.215 v17.3.0 (March 30, 2023) ([TS38215]), 3GPP® TS 38.314 v17.2.0 (January 13, 2023) ([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 PhysicalLayer (PHY) Specifications, IEEE Std 802.11-2020, pp.1-4379 (26 Feb. 2021) ([IEEE80211]), and / or similar specifications may be used additionally or alternatively. Additionally or alternatively, any (or combination of) of the above measurements may be collected by one or more AN208s and supplied to the edge computing node.

[0046] In addition, or alternatively, the measurements may include: measurements related to data radio bearers (DRBs) (e.g., number of DRBs attempted to be set up, number of DRBs successfully set up, number of active DRBs released, DRB activity time within a session, number of DRBs attempted to be resumed, number of DRBs successfully resumed, etc.), measurements related to radio resource control (RCC) (e.g., average number of RRC connections, maximum number of RRC connections, average number of inactive RCC connections held, maximum number of inactive RRC connections held, number of RRC connection establishment attempts / successes / failures, etc.), measurements related to UE context, measurements related to radio resource utilization (RRU) (e.g., total PRB usage for DLs, total PRB usage for ULs, distribution of total PRB usage for DLs, distribution of total PRB usage for ULs, DL PRB used for data traffic, UL PRB used for data traffic) Measurements related to Registration Management (RM), Session Management (SM) (e.g., number of PDU sessions requested for setup, number of PDU sessions successfully set up, number of PDU sessions that failed to set up, etc.), GTP Management (GTP), IP Management (IP), Policy Association (PA), Mobility Management (MM) (e.g., InterRAT, IntraRAT, and / or Intra / Interfrequency Handover and / or Conditional Handover, number of Handover Preparation requests / successes / failures, Handover Re Number of source allocation requests / successes / failures, number of handover execution requests / successes / failures, 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 release, activity time of QoS flows in a session, activity time of UE202 in a session, number of QoS flows attempted to set up, number of QoS flows successfully established, number of QoS flows that failed to set up, number of initial QoS flows attempted to set up,Measurements of initial QoS flows (number of successful establishments, number of initial QoS flows that failed to set up, number of QoS flows that were attempted to be modified, number of QoS flows that were successfully modified, number of QoS flows that were not successfully modified, etc.), measurement of application triggering (AT), measurement of short message service (SMS), measurement of power, energy, and environment (PEE), measurement of NF services (NFS), measurement of packet flow description (PFD), measurement of random access channel (RACH), measurement of measurement reports (MR), measurement of Layer 1 measurement (L1M), measurement of network slice selection (NSS), measurement of paging (PAG), measurement of non-IP data delivery, measurement of external parameter provisioning (SPP), measurement of background data forwarding policy (BDTP), measurement of data measurement (DM), and / or 3GPP® TS 28.522 v17.3.1 (June 24, 2021) ([TS28552]), 3GPP® TS 32.425 v17.1.0 (June 24, 2021) ([TS32425]), and / or similar documents may include one or more of any other performance measures, such as those described therein.

[0047] Wireless information may be reported in response to trigger events and / or periodically. Additionally or alternatively, individual UE202s may report wireless information at either a lower or higher frequency depending on the data transfer to be performed and / or other information relating to the data transfer. Additionally or alternatively, edge computing nodes may request measurements from AN208 at a lower or higher frequency, or AN208 may supply measurements to edge computing nodes at a lower or higher frequency. Additionally or alternatively, edge computing nodes may obtain other relevant data, such as key performance indicators (KPIs), from other edge computing nodes, core network functions (CFs), application functions (AFs), and / or other UE202s, either together with or separately from the measurement reports.

[0048] Additionally, or alternatively, if there are discrepancies (e.g., missing reports, erroneous reports, etc.) in the observed data from one or more UEs, one or more RAN nodes, and / or core network NFs, simple imputation may be performed to supplement the acquired observed data, such as substituting values ​​from previous reports and / or historical data or applying extrapolation filters. Additionally, or alternatively, acceptable ranges for observed data may be predetermined or set. For example, CQI and MCS measurements may be set to be within ranges defined by appropriate 3GPP® standards. If reported data values ​​do not make sense (e.g., values ​​exceed acceptable ranges / boundaries, etc.), such values ​​may be skipped for the current learning / training episode or epoch. For example, delay ranges may be defined or set for packet delivery, and packets determined to have been received after the packet delivery delay range may be deleted.

[0049] The UE202 can also determine procedures for measuring and reporting reference signals (RS) to provide the network with information about the quality of one or more radio channels and / or the communication medium in general, and this information can be used to optimize various aspects of the communication system. For example, the measurement and reporting procedures performed by UE202 include 3GPP® TS 38.211 v17.4.0 (January 4, 2023) ([TS38211]), 3GPP® TS 38.212 v17.4.0 (January 4, 2023) ([TS38212]), 3GPP® TS 38.213 v17.4.0 (January 4, 2023) ([TS38213]), 3GPP® TS 32.214 v17.4.0 (January 4, 2023) ([TS38214]), [TS38215], and 3GPP® TS 38.101-1 This may include what is described in v18.0.0 (January 12, 2023) ([TS38.101-1]), 3GPP® TS 38.104 v18.0.0 (January 10, 2023) ([TS38104]), 3GPP® TS 38.133 v18.0.0 (January 12, 2023) ([TS38133]), etc. Physical signals and / or Rscan include demodulation reference signals (DM-RS), phase tracking reference signals (PT-RS), positioning reference signals (PRS), channel status information reference signals (CSI-RS), synchronization signal blocks (SSB), primary synchronization signals (PSS), secondary synchronization signals (SSS), and sounding reference signals (SRS).

[0050] In any of the examples described herein, any suitable data acquisition and / or measurement mechanism may be used to acquire observational data. For example, data marking (e.g., sequence numbering), packet tracing, signal measurement, data sampling, and / or time stamping techniques may be used to determine any of the above metrics / observations. Data acquisition may be based on the occurrence of an event that triggers data acquisition. Additionally or alternatively, data acquisition may occur at the start or end of an event. Data acquisition may be continuous or discontinuous and / or have a start and end point. Data acquisition techniques / mechanisms may be specific to a hardware configuration / implementation or non-hardware configuration, or may be based on various software parameters (e.g., OS type and version, etc.). Various configurations may be used to define any of the above data acquisition parameters. Such settings may be defined by appropriate indicators / 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.,

[80211] , [WiMAX], [IEEE16090], etc.) and / or any other standards described herein.

[0051] In a V2X scenario, UE202 or AN208 may be, or may operate as, a roadside unit (RSU). An RSU can refer to any transport infrastructure entity used for V2X communication. An RSU may be implemented in or by a suitable AN or a fixed (or relatively stationary) UE. An RSU implemented in or by a UE may be called a “UE-type RSU,” an “eNB-type RSU” if it is an eNB, a “gNB-type RSU” if it is a gNB, and so on. For example, an RSU is a computing device coupled to radio frequency circuitry installed on a roadside providing connectivity support to passing vehicle UEs. An RSU may also include built-in data storage circuitry that stores intersection map geometry, traffic statistics, media, and applications / software for detecting and controlling vehicle and pedestrian traffic. An RSU may provide very low-latency communication required for high-speed events such as accident prevention and traffic warnings. Additionally, or alternatively, an RSU may provide other cellular / WLAN communication services. The RSU components may be packaged in a weatherproof enclosure suitable for outdoor installation and may include a network interface controller that provides wired connectivity (e.g., Ethernet®) to a traffic signal controller or backhaul network. Furthermore, one or more V2X RATs may be used, enabling V2X nodes to communicate directly with each other, with infrastructure equipment (e.g., AN208), and / or with other devices / nodes. In some implementations, at least two distinct V2X RATs may be used, including a WLAN V2X (W-V2X) RAT based on IEEE V2X technology (e.g., US DSRC and European ITS-G5) and a cellular V2X (C-V2X) RAT based on 3GPP® V2X technology (e.g., LTE V2X, 5G / NR V2X, and later). In one example, a C-V2X RAT can utilize a C-V2X air interface, and a WLAN V2X RAT can utilize a W-V2X air interface.

[0052] W-V2X RAT includes, for example, the IEEE Guide to Wireless Access (WAVE) Architectures in Vehicle Environments, IEEE 1609.0-2019 (April 10, 2019) ([IEEE16090]), the V2X Message Set Dictionary (July 23, 2020) ([J2735_202007]) published by SAE Int'l, Intelligent Transport Systems (ITS-G5) in the 5GHz frequency band, [IEEE80211p] (which covers WAVE, DSRC, and the Layer 1 (L1) and Layer 2 (L2) portions of ITS-G5), and / or the IEEE Standard for Air Interfaces in Broadband Wireless Access Systems, IEEE Std 802.16-2017, pp. 1-2726 (March 2, 2018) ([WiMAX]). The term "DSRC" refers to vehicle communications in the 5.9 GHz frequency band as commonly used in the United States, while "ITS-G5" refers to vehicle communications in the 5.9 GHz frequency band in Europe. Because any number of different RATs (including [IEEE80211p]RATs) that may be used in any geographical or political region are applicable, the terms "DSRC" (particularly used in the United States) and "ITS-G5" (particularly used in Europe) may be used synonymously throughout this disclosure. The access layer of the ITS-G5 interface is outlined in ETSI EN 302 663 V1.3.1 (January 2020) (hereinafter, [EN302663]), which describes the access layer of the ITS-S reference architecture. The ITS-G5 access layer consists of features of the Distributed Congestion Control (DCC) scheme discussed in ETSI TS 102 687 V1.2.1 (April 2018) (hereinafter referred to as [TS102687]), in addition to [IEEE80211] (now integrated with [IEEE80211p]).The access layer of the 3GPP® LTE-V2X based interface is outlined in ETSI EN 303 613 V1.1.1 (January 2020), 3GPP® TS 23.285 v16.2.0 (December 2019), and so on. 3GPP® 5G / NR-V2X is outlined in 3GPP® TR 23.786 v16.1.0 (June 2019) and 3GPP® TS 23.287 v18.0.0 (March 31, 2023) ([TS23287]), among others.

[0053] In an example where RAN204 is an E-UTRAN210 containing one or more eNB212s, the E-UTRAN210 provides an LTE air interface (Uu) with parameters and characteristics at least as described in 3GPP® TS 36.300 v17.2.0 (September 30, 2022) ([TS36300]). In an example where RAN204 is a next-generation (NG)RAN214 containing a set of gNB216s, each gNB216 connects to a 5G-enabled UE202 using a 5G-NR air interface (also known as a Uu interface) with parameters and characteristics as described in [TS38300] among several 3GPP® standards. If NG-RAN214 contains a set of ng-eNB218s, one or more ng-eNB218s connect to the UE202 via a 5G Uu and / or LTE Uu interface. gNB216 and ng-eNB218 connect to 5GC240 through their respective NG interfaces, which include the N2 interface, N3 interface, and / or other interfaces. gNB216 and ng-eNB218 are connected via the Xn interface. Furthermore, individual gNB216s are connected via their respective Xn interfaces, and individual ng-eNB218s are connected via their respective Xn interfaces. In some examples, the NG interface may be divided into two parts: the NG user interface (NG-U) (e.g., the N3 interface) which carries traffic data between the NG-RAN214 node and the UPF248, and the NG control plane (NG-C) (e.g., the N2 interface) which is the signaling interface between the NG-RAN214 node and the AMF244.

[0054] NG-RAN214 can provide a 5G-NR air interface (also known as a Uu interface) with characteristics such as variable SCS, CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UE, polar codes, repeating codes, single codes, and Reed-Müller codes for control, and LDPC for data. The 5G-NR air interface, like the LTE air interface, may rely on CSI-RS and PDSCH / PDCCH DMRS. While the 5G-NR air interface may not use CRS, it may use PBCH DMRS for PBCH demodulation, PTRS for PDSCH phase tracking, and a tracking reference signal for time tracking. The 5G-NR air interface may operate in the FR1 band, including the sub-6GHz band, or the FR2 band, including the 24.25GHz to 52.6GHz band. The 5G-NR air interface may include SSB, which is an area of ​​the downlink resource grid including PSS / SSS / PBCH.

[0055] The 5G-NR air interface can utilize BWPs for various purposes. For example, BWPs can be used to dynamically adapt the SCS. For instance, UE202 can be configured with multiple BWPs, each BWP configuration having a different SCS. When a change in BWP is instructed to UE202, the SCS of the transmission also changes. Another use case for BWPs relates to power saving. In particular, multiple BWPs can be configured for UE202 with different amounts of frequency resources (e.g., PRBs) to support data transmission under different traffic load scenarios. BWPs with fewer PRBs can be used for data transmission under low traffic loads while allowing power savings on UE202 and, in some cases, gNB216. BWPs with more PRBs can be used for scenarios with higher traffic loads.

[0056] In some implementations, an individual gNB216 may include a set of gNB-CUs and gNB-DUs. Additionally or alternatively, a gNB216 may include one or more RUs. In these implementations, a gNB-CU may be connected to each gNB-DU via its respective F1 interface. In the case of network sharing by broadcast of multiple cell IDs, each cell ID associated with a subset of PLMNs corresponds to a gNB-DU, and the gNB-CUs are connected to share the same physical layer of the cell resources. For resilience, a gNB-DU may be connected to multiple gNB-CUs by appropriate implementation. Furthermore, a gNB-CU may be divided into gNB-CU control plane (gNB-CU-CP) functions and gNB-CU user plane (gNB-CU-UP) functions. A gNB-CU-CP is connected to a gNB-DU via the F1 control plane interface (F1-C), a gNB-CU-UP is connected to a gNB-DU via the F1 user plane interface (F1-U), and a gNB-CU-UP is connected to a gNB-CU-CP via the E1 interface. In some implementations, one gNB-DU is connected to only one gNB-CU-CP, and one gNB-CU-UP is connected to only one gNB-CU-CP. For resilience, a gNB-DU and / or gNB-CU-UP may be connected to multiple gNB-CU-CPs by appropriate implementation. One gNB-DU can be connected to multiple gNB-CU-UPs under the control of the same gNB-CU-CP, and one gNB-CU-UP can be connected to multiple DUs under the control of the same gNB-CU-CP. Data transfer between gNB-CU-UPs during handover between gNB-CU-CPs within a gNB may be supported by Xn-U.

[0057] Similarly, an individual ng-eNB218 may include a set of ng-eNB-CUs and ng-eNB-DUs. In such an implementation, the ng-eNB-CU and each ng-eNB-DU are connected via their respective W1 interfaces. An 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 ng-eNB-CU-UP 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 aspects of the gNB also apply to the ng-eNB and the corresponding E1 and W1 interfaces unless otherwise explicitly specified.

[0058] Nodes hosting the user plane portion of the PDCP protocol layer (e.g., gNB-CU, gNB-CU-UP, and, depending on the bearer partition in the case of EN-DC, MeNB or SgNB) perform user inactivity monitoring. Furthermore, they notify nodes with control plane connections to the core network (e.g., via E1, X2, etc.) of their inactivity or (re)activation. Nodes hosting the RLC protocol layer (e.g., gNB-DU) perform user inactivity monitoring and can also notify nodes hosting the control plane (e.g., gNB-CU or gNB-CU-CP) of their inactivity or (re)activation.

[0059] In these implementations, NG-RAN214 is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The architecture of NG-RAN214 (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 associated TNL protocols and functions are defined, for example, in [TS38401]. 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, 244 of which are AMF sets within the AMF region, supporting at least one slice also supported by the NG-RAN node. AMF sets and AMF regions are defined in [TS23501].

[0060] RAN204 is communicatively coupled to CN220, which includes network elements and / or network functions to provide various functions to support data and telecommunications services to customers / subscribers (e.g., users of UE202). The components of CN220 may be implemented on a single physical node or on separate physical nodes. In some examples, NFV may be used to virtualize some or all of the functions provided by the network elements of CN220 onto physical computing / storage resources such as servers and switches. Logical instantiations of CN220 are sometimes called network slices, and some logical instantiations of CN220 are sometimes called network subslices.

[0061] CN220 may be LTE CN222 (also known as Evolved Packet Core (EPC) 222). EPC222 may include MME224, SGW226, SGSN228, HSS230, PGW232, and PCRF234 coupled to each other via an interface (or "reference point") as shown in the figure. The functional basis (NF) of EPC222 can be briefly introduced as follows:

[0062] The MME224 implements mobility management functions to track the current location of the UE202 to facilitate paging, bearer activation / deactivation, handover, gateway selection, authentication, etc. The SGW226 terminates the S1 interface to the RAN210 and routes data packets between the RAN210 and the EPC222. The SGW226 may be a local mobility anchor point for handovers between RAN nodes and may also provide an anchor for mobility between 3GPP®. Other responsibilities may include lawful interception, billing, and enforcement of certain policies. The SGSN228 tracks the location of the UE202 and performs security functions and access control. The SGSN228 also performs signaling between EPC nodes for mobility between different RAN networks, selection of PDNs and S-GWs specified by the MME224, selection of the MME224 for handover, etc. An S3 reference point between MME224 and SGSN228 enables the exchange of user and bearer information for 3GPP® access network mobility in idle / active states. HSS230 includes a database for network users, including subscription-related information to support the processing of communication sessions for network entities. HSS230 can support routing / roaming, authentication, authorization, naming / address resolution, location dependency, etc. An S6a reference point between HSS230 and MME224 may enable the transfer of subscription and authentication data for authenticating / authorizing user access to EPC222. PGW232 may terminate the SGi interface to a data network (DN) 236, which may include an application (app) / content server 238. PGW232 routes data packets between EPC222 and the data network 236. PGW232 is communicably coupled to SGW226 by an S5 reference point to facilitate user plane tunneling and tunnel management. PGW232 may further include nodes (e.g., PCEF) for policy enforcement and billing data collection.Furthermore, the SGi reference point can connect PGW232 to the same or a different data network 236 in a communicative manner. PGW232 can be connected to PCRF234 via a Gx reference point. PCRF234 is the policy and billing control element of EPC222. PCRF234 is connected to application / content server 238 in a communicative manner to determine appropriate QoS and billing parameters for the service flow. PCRF234 provisions the relevant rules to the PCEF (via the Gx reference point) using appropriate TFT and QCI.

[0063] CN220 may be a 5GC240 including AUSF242, AMF244, SMF246, UPF248, NSSF250, NEF252, NRF254, PCF256, UDM258, and AF260, which are coupled to each other via various interfaces as shown in the figure. The NF of 5GC140 can be briefly introduced as follows.

[0064] AUSF242 stores authentication data for UE202 and handles authentication-related functions. AUSF242 can provide a common authentication framework for various access types.

[0065] The AMF244 enables other functions of the 5GC240 to communicate with the UE202 and RAN204, and to subscribe to notifications regarding mobility events for the UE202. The AMF244 is also involved in registration management (e.g., to register the UE202), connectivity management, reachability management, mobility management, lawful interception of AMF-related events, and authentication and authorization of access. The AMF244 carries SM messages between the UE202 and SMF246 and acts as a transparent proxy for routing SM messages. The AMF244 also carries SMS messages between the UE202 and SMSF. The AMF244 interacts with the AUSF242 and UE202 to perform various security anchor and context management functions. Furthermore, the AMF244 is the termination point of the RAN CP interface, which includes the N2 interface between the RAN204 and the AMF244. The AMF244 is also the termination point for NAS(N1) signaling and performs NAS encryption and integrity protection.

[0066] The AMF244 also supports NAS signaling with the UE202 via the N3IWF interface. The N3IWF provides access to untrusted entities. The N3IWF may be the termination point for the N2 interface between the (R)AN204 and the AMF244 for the control plane, and the termination point for the N3 reference point between the RAN214 and the UPF248 for the user plane. Thus, the AMF244 handles N2 signaling from the SMF246 and AMF244 for PDU sessions and quality of service, encapsulates / decapsulates packets for IPSec and N3 tunneling, marks N3 user plane packets on the uplink, and applies quality of service corresponding to the N3 packet marks, taking into account the quality of service requirements associated with such marks received via N2. The N3IWF relays UL and DL control plane NAS signaling between the UE202 and the AMF244 via the N1 reference point between the UE202 and the AMF244, and also relays uplink and downlink user plane packets between the UE202 and the UPF248. The AMF244 can implement a Namf service-based interface and may be a termination point for the N14 reference point between two AMF244s and the N17 reference point between the AMF244 and a 5G-EIR (not shown in Figure 2).

[0067] SMF246 is involved in SM (e.g., session establishment and tunnel management between UPF248 and AN208), allocation and management of UE IP addresses (including arbitrary authorization), selection and control of UP functions, setting traffic steering on UPF248 to route traffic to more appropriate destinations, interface termination to policy control functions, policy enforcement, billing, and some control of QoS, lawful interception (for SM events and interface to LI systems), termination of the SM portion of NAS messages, downlink data notification, initiation of AN-specific SM information sent to AN208 via N2 by AMF244, and determination of the session's SSC mode. SM refers to the management of PDU sessions, and PDU session or "session" refers to the PDU connectivity service that provides or enables the exchange of PDUs between UE202 and DN236. SMF246 may also include edge computing enhancements (see, for example, [TS23548]), selection of EASDF261 and provision of its address to the UE as a DNS server for PDU sessions, use of EASDF261 services as defined in [TS23548], and provision and updating of ECS address configuration information to the UE to support the application layer architecture as defined in [TS23558]. The procedure for discovering and selecting EASDF261 is described in Chapter 6.3.23 of [TS23501].

[0068] The UPF248 functions as an anchor point for mobility within and between RATs, an external PDU session point for interconnects to data network 236, and a branching point to support multi-homed PDU sessions. The UPF248 routes and forwards packets, performs packet inspection, applies the user plane portion of policy rules, legally intercepts packets (UP collection), reports traffic usage, performs user plane QoS processing (e.g., packet filtering, gating, UL / DL rate application), performs uplink traffic verification (e.g., SDF vs. QoS flow mapping) and transport-level packet marking on uplinks and downlinks, and can also perform downlink packet buffering and downlink data notification triggers. The UPF248 may include an uplink classifier to support routing of traffic flows to the data network.

[0069] The NSSF250 selects a set of network slice instances to serve the UE202. The NSSF250 also determines, if necessary, the mapping to authorized NSSAIs and subscribed S-NSSAIs. The NSSF250 also determines the set of AMFs to be used to serve the UE202, or, based on appropriate configuration, a list of candidate AMFs by querying the NRF254 if necessary. The selection of a set of network slice instances for the UE202 may be triggered by the interaction of the AMF244, to which the UE202 is registered, with the NSSF250, which may result in changes to the AMF244. The NSSF250 may interact with the AMF244 via the N22 reference point and communicate with other NSSFs in the visited network via the N31 reference point (not shown).

[0070] NEF252 securely exposes services and functions provided by 3GPP® NFs to third parties, internal / republished entities, AF260s, edge computing systems, or fog computing systems (e.g., edge computing nodes). In such cases, NEF252 may authenticate, authorize, or throttle AFs. NEF252 can also translate information exchanged with AF260s and information exchanged with internal network functions. For example, NEF252 may translate between AF service identifiers and internal 5GC information. NEF252 can also receive information from other NFs based on their published functions. This information may be stored in NEF252 as structured data or in a data storage NF using a standardized interface. Stored information can be republished by NEF252 to other NFs and AFs, or used for other purposes such as analysis.

[0071] The NRF254 supports service discovery functionality, receiving NF discovery requests from NF instances and providing information about discovered NF instances to the requesting NF instances. The NRF254 also maintains information about available NF instances and the services they support. The NRF254 also supports service discovery functionality, receiving NF discovery requests from NF instances or SCPs (not shown) and providing information about discovered NF instances to the NF instances or SCPs.

[0072] PCF256 can not only provide and enforce policy rules for control plane functions, but can also support an integrated policy framework for managing network behavior. PCF256 can also implement a front-end for accessing subscription information related to policy decisions within the UDR of UDM258. In addition to communicating with functions via reference points as illustrated, PCF256 features an Npcf service-based interface.

[0073] The UDM258 processes subscription-related information to support the handling of communication sessions for network entities and stores subscription data for the UE202. For example, subscription data may be communicated between the UDM258 and the AMF244 via an N8 reference point. The UDM258 may consist of two parts: the application frontend and the UDR (e.g., UDR258 in the diagram). The UDR may store subscription data and policy data for the UDM258 and PCF256, and / or structured data and application data for publication for the NEF252 (including PFDs for application discovery and application request information for multiple UE202s). A Nudr service-based interface may be provided by the UDR221 to allow the UDM258, PCF256, and NEF252 to access specific sets of data stored and to read notifications of changes in relevant data within the UDR, update (e.g., add or modify), delete, and subscribe. The UDM258 may include a UDM-FE responsible for credential processing, location management, and subscription management. Several different frontends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access permission, registration / mobility management, and subscription management. In addition to communicating with other NFs via reference points as illustrated, the UDM258 may have a Nudm service-based interface.

[0074] The Edge Application Server Discovery Function (EASDF) 261 has a Neasdf service-based interface and connects to the SMF 246 via an N88 interface. One or more EASDF instances may be located within the PLMN, and the interaction between the 5GC NF and the EASDF 261 takes place within the PLMN. The EASDF 261 includes one or more of the following functions: registration with the NRF 254 for discovery and selection of the EASDF 261, processing DNS according to instructions from the SMF 246, and / or terminating DNS security when used. The processing of DNS in accordance with instructions from SMF246 includes one or more of the following functions: receiving DNS message processing rules and / or BaselineDNSPattern from SMF246, exchanging DNS messages with UE202, forwarding DNS messages to C-DNS or L-DNS for DNS queries, adding EDNC client subnet (ECS) options to DNS queries for FQDNs, reporting information about received DNS messages to SMF246, and / or buffering / discarding DNS messages from UE202 or DNS servers. The EASDF has a direct user-plane connection to the PSA UPF via N6 (e.g., without using any NAT) for the transmission of DNS signaling exchanged with the UE. The placement of NAT between EASDF261 and PSA UPF248 may or may not be supported. Further aspects of EASDF261 are described in [TS23548].

[0075] The AF260 influences application traffic routing, provides access to the NEF252, and interacts with the policy framework for policy control. The AF260 can also influence the (re)selection and traffic routing of the UPF248. Based on operator placement, if the AF260 is considered a trusted entity, the network operator may allow the AF260 to directly interact with the relevant NF. In some implementations, the AF260 is used for edge computing implementations.

[0076] The 5GC240 can enable edge computing by selecting operator / third-party services that are geographically close to the point where the UE202 is installed on the network. This can reduce latency and network load. In an edge computing implementation, the 5GC240 can select a UPF248 that is close to the UE202 and perform traffic steering from the UPF248 to the DN236 via the N6 interface. This can be based on the UE's subscription data, the UE's location, and information provided by the AF260. In this way, the AF260 can act on the (re)selection and traffic routing of the UPF.

[0077] The data network (DN) 236 may represent various network operator services, internet access, or third-party services that may be provided by one or more servers, for example, including an application / content server 238. DN236 may be an external public operator, private PDN, or intra-operator packet data network, for example, for the provisioning of IMS services. In this example, the application / content server 238 may be connected to IMS via an S-CSCF or I-CSCF. In some implementations, DN236 may represent one or more local area DNs (LADNs) that are accessible by UE202 within one or more specific areas. Outside these specific areas, UE202 cannot access the LADN / DN236.

[0078] Additionally, or alternatively, DN236 may be an edge DN236, which is a (local) DN that supports an architecture enabling edge applications. In such an example, application / content server 238 may represent a physical hardware system / device that provides application server functionality, and / or application software that resides in the cloud or on an edge computing node that runs the server functionality. In some examples, application / content server 238 provides an edge host environment that provides the support necessary for running the edge application server.

[0079] In some examples, 5GS can use one or more edge computing nodes to provide interfaces and offload the processing of wireless communication traffic. In such examples, the edge computing nodes may be contained within or coexist with one or more RAN210,214. For example, an edge computing node can provide connectivity between RAN214 and UPF248 in 5GC240. The edge computing node can use one or more NFV instances instantiated in the virtualization infrastructure within the edge computing node to handle wireless connectivity to and from RAN214 and UPF248.

[0080] In some embodiments, edge computing nodes provide a distributed computing environment for hosting applications and services, and also provide storage and processing resources to process data and / or content closer to subscribers (e.g., users of UE202) to reduce response times. Edge computing nodes also support, among other things, multitenancy runtime and hosting environments for applications including virtual appliance applications, middleware applications and infrastructure services that can be delivered as packaged virtual machine (VM) images, content delivery services including content caching, mobile big data analytics, and compute offloading. Computation offloading includes offloading compute tasks, workloads, applications, and / or services from UE202, CN220, DN236, and / or servers (e.g., application / content server 238) to edge computing nodes, or vice versa. For example, a device application or client application running on UE202 may offload application tasks or workloads to one or more edge computing nodes. In another example, an edge computing node could offload application tasks or workloads to a set of UE202s (for example, for distributed machine learning computations and / or similar).

[0081] An edge computing node may include or be part of an edge system that uses one or more edge computing technologies (ECTs) (also known as “edge computing frameworks”). An edge computing node may also be called an “edge host” or “edge server”. An edge system includes a set of edge servers and edge management systems (not shown) necessary to run edge computing applications within an operator network or a subset of an operator network. An edge server is a physical computer system that may include an edge platform and / or virtualization infrastructure, providing compute, storage, and network resources to edge computing applications. Each edge server is located at the edge of its corresponding access network and is configured to provide compute resources and / or various services (e.g., offloading compute tasks and / or workloads as described herein, cloud computing capabilities, IT services, and other similar resources and / or services) relatively close to the UE202. The VI of an edge computing node provides a virtualized environment and virtualized resources to the edge host, and edge computing applications may run on the VI as VMs and / or application containers.

[0082] In one exemplary implementation, ECT includes ETSI GR MEC 001 v3.1.1(2022-01), ETSI GS MEC 003 v3.1.1(2022-03), ETSI GS MEC 009 v3.1.1(2022-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 GS MEC 015 v2.1.1(2020-06), ETSI GS MEC 016 v2.2.1(2020-04), ETSI GS MEC 021 v2.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 GR MEC 031 The MEC framework (collectively referred to hereby as "[MEC]") described in v2.1.1(2020-10), filed on 1 April 2020 ([US'834]), and in application PCT / US2020 / 066969 ([PCT'696]) filed by Intel on 23 December 2020, and / or operates in accordance with the MEC framework. The contents of each of these documents are incorporated herein by reference in their entirety.This exemplary implementation (and / or any other exemplary implementation described herein) is based on ETSI GR NFV 001 V1.3.1 (2021-03), ETSI GS NFV 002 V1.2.1 (2014-12), ETSI GR NFV 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), and ETSI GS NFV-MAN 001. This may include NFV and / or other similar virtualization technologies (collectively referred to as "[ETSINFV]") as described in V1.1.1 (2014-12) and / or Israel et al., OSM Release FIVE Technical Overview, ETSI Open Source MANO, OSM White Paper, 1st ed. (Jan. 2019), https: / / osm.etsi.org / images / OSM-Whitepaper-TechContent-ReleaseFIVE-FINAL.pdf. The contents of each of these documents are incorporated herein by reference in their entirety.Other virtualization technologies and / or service orchestration and automation platforms may be used, such as those described in the 3GPP® Service-Based Management Architecture (SBMA) described in E2E Network Slicing Architecture, GSMA, Official Doc. NG.127, v1.0 (03 Jun. 2021), https: / / www.gsma.com / newsroom / wp-content / uploads / / NG.127-v1.0-2.pdf, Open Network Automation Platform (ONAP) documentation, Release Istanbul, v9.0.1 (17 Feb. 2022), https: / / docs.onap.org / en / latest / index.html ([ONAP]), and 3GPP® TS 28.533 v17.1.0 (2021-12-23) ([TS28533]). The contents of each of these documents are incorporated herein by reference in their entirety.

[0083] In another exemplary implementation, ECT is and / or operates according to the O-RAN framework. Typically, front-end and back-end device vendors and carrier waves work closely together to ensure compatibility. The flip side of such a working model is that plug-and-play with other devices becomes extremely difficult, which can hinder innovation. To address this and promote openness and interoperability at all levels, several key players interested in the wireless field (telecommunications operators, device manufacturers, academic institutions, etc.) established the Open RAN Alliance (“O-RAN”) in 2018. The O-RAN network architecture is a set of building blocks for designing a virtualized RAN on programmable hardware with AI / ML-powered radio access control. Various aspects of the O-RAN architecture are described in the following documents: O-RAN Architecture Description v07.00, O-RAN Alliance WG1 (Oct. 2022) ("[O-RAN.WG1.O-RAN-Architecture-Description]"); O-RAN Operations and Maintenance Architecture Specification v04.00, O-RAN Alliance WG1 (Feb. 2021) ("[O RAN.WG1.OAM-Architecture]"); O-RAN Operations and Maintenance Interface Specification v04.00, O-RAN Alliance WG1 (Feb. 2021) ("[O-RAN.WG1.O1-Interface.0]"); O-RAN Information Model and Data Models Specification v01.00, O-RAN Alliance WG1 (Feb. 2021); O-RAN Working Group 1 Slicing Architecture v08.00 (Oct.2022);O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Application Protocol v03.02 (Jul. 2021);O-RAN Working Group 1 Use Cases Detailed Specification v09.00 (Oct. 2022)(「[O-RAN.WG1.Use-Cases]」);O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: General Aspects and Principles v03.00 (Oct. 2022)(「[O-RAN.WG2.A1GAP]」);O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Type Definitions v04.00 (Oct. 2021);O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) A1 interface: Transport Protocol v02.00 (Oct. 2022);O-RAN Working Group 2 AI / ML workflow description and requirements v01.03 O-RAN Alliance WG2 (Oct. 2021)(「[O-RAN.WG2.AIML]」);O-RAN Working Group 2 (Non-RT RIC and A1 interface WG) Non-RT RIC Architecture v02.01 (Oct. 2022);O-RAN Working Group 2 Non-RT RIC: Functional Architecture v01.01,O-RAN Alliance WG2 (Jun. 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 (Oct. 2022);O-RAN Working Group 3 Near-Real-time RAN Intelligent Controller Architecture & E2 General Aspects and Principles v02.02 (Jul. 2022)(「[O-RAN.WG3.E2GAP]」);O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) v02.01 (Mar. 2022)(「[O-RAN.WG3.E2SM]」);O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM),Cell Configuration and Control v01.00 (Oct. 2022)(「[O-RAN.WG3.E2SM-CCC]」);O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) KPM v02.03 (Oct. 2022)(「[O-RAN.WG3.E2SM-KPM]」);O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Function Network Interface (NI) v01.00 (Feb. 2020)(「[ORAN-WG3.E2SM-NI]」);O-RAN Working Group 3 Near-Real-time Intelligent Controller E2 Service Model (E2SM) RAN Control v01.03 (Oct. 2022)(「[O-RAN.WG3.E2SM-RC]」);O-RAN Working Group 3,Near-Real-time Intelligent Controller,E2 Application Protocol (E2AP) v02.03 (Oct.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 (Oct. 2022)(「[O-RAN.WG3.RICARCH]」);O-RAN Working Group 4 (Open Fronthaul Interfaces WG) Control,User and Synchronization Plane Specification v09.00 (Jul. 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 (Jun. 2021);O-RAN Fronthaul Working Group 4 Cooperative Transport Interface Transport Management Plane Specification v02.00 (Jun. 2021);O-RAN Fronthaul Working Group 4 (Open Fronthaul Interfaces WG): Management Plane Specification v09.00 (Jul. 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 (Oct. 2022);O-RAN Alliance Working Group 5 O1 Interface specification for O-DU v05.00 (Oct.2022);O-RAN Open F1 / W1 / E1 / X2 / Xn Interfaces Working Group Transport Specification v01.00,O-RAN Alliance WG5 (Apr. 2020);O-RAN Working Group 6 (Cloudification and Orchestration) Cloud Architecture and Deployment Scenarios for O-RAN Virtualized RAN v04.00 (Oct. 2022)(「[O-RAN.WG6.CADS]」);O-RAN Cloud Platform Reference Designs v02.00,O-RAN Alliance WG6 (Feb. 2021);O-RAN Working Group 6 O2 Interface General Aspects and Principles v02.00 (Oct. 2022);O-RAN Working Group 6 (Cloudification and Orchestration Work Group);O-RAN Acceleration Abstraction Layer General Aspects and Principles v04.00 (Oct. 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 (Oct. 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 (Oct. 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 (Oct. 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 (Oct. 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 (Jul. 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 (Jul. 2022);O-RAN Open X-haul Transport Working Group Synchronization Architecture and Solution Specification v02.00,O-RAN Alliance WG9 (Mar. 2022);O-RAN Open Xhaul Transport WG9 WDM-based Fronthaul Transport v2.0,O-RAN Alliance WG9 (Mar. 2022);O-RAN Open Transport Working Group 9 Xhaul Packet Switched Architectures and Solutions v03.00,O-RAN Alliance WG9 (Jul. O-RAN Operations and Maintenance Interface Specification v08.00, O-RAN Alliance WG10 (Oct. This is described in 2022) ("[O-RAN.WG10.O1-Interface.0]"); O-RAN: Towards an Open and Smart RAN, O-RAN Alliance, White Paper (Oct. 2018); and U.S. Patent Application No. 17 / 484743 filed on September 24, 2021 (collectively referred to as "[O-RAN]"). The contents of each of these documents are incorporated herein by reference in their entirety.

[0084] In another exemplary implementation, ECT uses 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 v18.0.0 ([TS23222]), and 3GPP® TS 33.122 v18.0.0(2022-12-16)([TS33122]), and 3GPP(registered trademark) TS 29.222 v17.1.0(2021-06-25)([TS29222]), 3GPP(registered trademark) TS 23.502 v18.0.0(2022-12-21)([TS23502]), 3GPP(registered trademark) TS 29.522 v18.0.0(2022-12-16)([TS29522]), 3GPP(registered trademark) TS 29.122 v18.0.0(2022-12-16)([TS29122]), 3GPP(registered trademark) TS 23.682 The 3rd Generation Partnership Project (3GPP®) System Aspects Working Group 6 (SA6) Architecture for enabling Edge Applications (referred to as “3GPP® Edge Computing”) and / or operates in accordance with 3GPP® Edge Computing (collectively referred to as “[SA6Edge]”), as described in v17.3.0 (2002-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). The contents of each of these documents are incorporated herein by reference in their entirety.

[0085] In another exemplary implementation, ECT is and / or operates in accordance with the Intel Smart Edge Open framework (formerly known as OpenNESS) ("[ISEO]"), as described in the Intel Smart Edge Open Developer Guide, version 21.09 (30 Sep. 2021), available from https: / / smart-edge-open.github.io / . The contents of this document are incorporated herein by reference in their entirety.

[0086] In another exemplary implementation, the ECT follows Kanugovi et al., Multi-Access Management Services (MAMS), Internet Engineering Task Force (IETF), Request for Comments (RFC) 8743 (Mar. 2020) (“[RFC8743]”), Ford et al., TCP Extensions for Multipath Operation with Multiple Addresses, IETF RFC 8684 (Mar. 2020), De Coninck et al.,Multipath Extensions for QUIC (MP-QUIC),IETF draft-deconinck-quic-multipath-07,IETA,QUIC Working Group (03-May-2021),Zhu et al.,User-Plane Protocols for Multiple Access Management Service,IETF draft-zhu-intarea-mams-user-protocol-09,IETA,INTAREA (04-Mar-2020), and Zhu et al., Generic Multi-Access (GMA) Convergence It operates in accordance with the Multi-Access Management Service (MAMS) framework described in Encapsulation Protocols, IETF RFC 9188 (Feb. 2022) (collectively referred to as "[MAMS]").

[0087] The aforementioned examples of edge computing frameworks / ECTs and service deployments are merely illustrative of ECTs, and it should be understood that this disclosure may apply to numerous other or additional edge computing / networking technologies in various combinations and layouts of devices located at the edge of a network, including the various edge computing networks / systems described herein. Furthermore, the technologies disclosed herein may relate to other IoT edge network systems and configurations, and other intermediate processing entities and architectures may also apply to this disclosure. Examples of such edge computing / networking technologies include [MEC]; [O-RAN]; [ISEO]; [SA6Edge]; Content Delivery Networks (CDNs) (also known as “Content Delivery Networks”); Mobility Service Provider (MSP) edge computing and / or Mobility as a Service (Mass) provider systems (e.g., used in AECC architectures); Nebula edge cloud systems; Fog computing systems; Cloudlet edge cloud systems; Mobile Cloud Computing (MCC) systems; Central Office Re-architected as a Datacenter (CORD), Mobile CORD (M-Cord), and / or Converged Multi-Access and Core (COMAC) systems, among others. Furthermore, the technologies 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 this disclosure.

[0088] The 5GC 240 interface includes reference point and service-based interfaces. The reference points are: N1 (between UE202 and AMF224), N2 (between RAN214 and AMF244), N3 (between RAN214 and UPF248), N4 (between SMF246 and UPF248), N5 (between PCF256 and AF260), N6 (between UPF248 and DN236), N7 (between SMF246 and PCF256), N8 (between UDM258 and AMF244), N9 (between two UPF248s), N10 (between UDM258 and SMF246), and N1 This includes N1 (between AMF244 and SMF246), N12 (between AUSF242 and AMF244), N13 (between AUSF242 and UDM258), N14 (between two AMF244s; not shown), N15 (between PCF256 and AMF244 in a non-roaming scenario, or between PCF256 and AMF244 in a visited network in a roaming scenario), N16 (between two SMF246s; not shown), and N22 (between AMF244 and NSSF250). Other reference point representations not shown in Figure 2 may also be used. The service-based representation in Figure 2 represents NFs in the control plane, and NFs in the control plane enable other authorized NFs to access their services. Service-based interfaces (SBIs) include Namf (SBI presented by AMF244), Nsmf (SBI presented by SMF246), Nnef (SBI presented by NEF252), Npcf (SBI presented by PCF256), Nudm (SBI presented by UDM258), Naf (SBI presented by AF260), Nnrf (SBI presented by NRF254), Nnssf (SBI presented by NSSF250), and Nausf (SBI presented by AUSF242). Other service-based interfaces not shown in Figure 2 (e.g., Nudr, N5g-eir, and Nudsf) may also be used. In some examples, NEF252 can provide an interface to an edge computing node that can be used to handle wireless connectivity with RAN214.

[0089] In some implementations, the network architecture 200 may include an SMSF that is involved in confirming and verifying SMS subscriptions and relaying SM messages between the UE 202 and other entities (e.g., SMS-GMSC / IWMSC / SMS routers). SMS may also interact with the AMF 244 and UDM 258 for procedures that notify the UE 202 that it is available for SMS forwarding (e.g., setting a UE unreachable flag and notifying the UDM 258 when the UE 202 becomes available for SMS).

[0090] 5GS may also include indirect communication (see, e.g., Section 7.1.1 of 3GPP® TS 23.501); delegated discovery (see, e.g., Section 7.1.1 of 3GPP® TS 23.501); forwarding and routing of messages to destination NF / NF services; communication security (e.g., authentication of NF service consumers to access NF service producer APIs) (see, e.g., 3GPP® TS 33.501); load balancing, monitoring, overload control, etc.; and discovery and selection functions for UDM258, AUSF242, UDR259, PCF256 by accessing subscriber data stored in UDRs based on UE's SUPI, SUCI, or GPSI (see Section 6.3 of [TS23501]). The load balancing, monitoring, and overload control functions provided by SCP may be implementation-specific. SCP may be deployed in a distributed manner. There can be more than one SCP in the communication paths between various NF services. While SCPs are not NF instances, they can be deployed in a distributed, redundant, and scalable manner.

[0091] Figure 3 schematically represents the wireless network 300 according to various embodiments. The wireless network 300 may include a UE302 that wirelessly communicates with AN304. The UE302 and AN304 are similar to components of the same name described elsewhere in this specification and may be substantially interchangeable.

[0092] UE302 can be communicatively coupled to AN304 via connection 306. Connection 306 is represented as an air interface enabling communication coupling and can follow cellular communication protocols such as LTE or 5G NR protocols operating at mmWave or sub-6GHz frequencies.

[0093] UE302 may include a host platform 308 coupled with a modem platform 310. The host platform 308 may include an application processing circuit 312 which can be coupled with a protocol processing circuit 314 of the modem platform 310. The application processing circuit 312 may execute various applications of UE302 that source / sink application data. The application processing circuit 312 may further implement one or more layer operations that send application data to and receive application data from a data network. These layer operations may include transport (e.g., UDP) operations and internet (e.g., IP) operations.

[0094] The protocol processing circuit 314 may implement one or more layer operations to facilitate the transmission or reception of data via the connection 306. Layer operations implemented by the protocol processing circuit 314 may include, for example, MAC operations, RLC operations, PDCP operations, RRC operations, and NAS operations.

[0095] The modem platform 310 may further include a digital baseband circuit 316 which may include one or more layer operations that are “below” the layer operations performed by the protocol processing circuit 314 in the network protocol stack. These operations may include PHY operations that include, for example, HARQ-ACK functionality, scrambling / descrambling, coding / decoding, layer mapping / demapping, modulation symbol mapping, received symbol / bitmetric determination, multi-antenna port precoding / decoding which may include space-time, space-frequency, or space coding, reference signal generation / detection, preamble sequence generation and / or decoding, synchronization sequence generation / detection, control channel signal blind decoding, and one or more other related functions.

[0096] The modem platform 310 may further include a transmitting circuit 318, a receiving circuit 320, an RF circuit 322, and an RF front end (RFFE) 324. The RFFE 324 may include or be connected to one or more antenna panels 326. Briefly, the transmitting circuit 318 may include a digital-to-analog converter, a mixer, an intermediate frequency (IF) component, etc. The receiving circuit 320 may include an analog-to-digital converter, a mixer, an IF component, etc. The RF circuit 322 may include a low-noise amplifier, a power amplifier, a power monitoring component, etc. The RFFE 324 may include filters (e.g., surface / bulk acoustic wave filters), switches, an antenna tuner, a beamforming component (e.g., a phase array antenna component), etc. The selection and arrangement of the components of the transmitting circuit 318, receiving circuit 320, RF circuit 322, RFFE 324, and one or more antenna panels 326 (commonly referred to as “transmitting / receiving components”) may be specific to the details of the implementation, such as whether the communication is TDM or FDM, or whether it is in mmWave or sub-6GHz frequency. In some embodiments, the transmitting / receiving components may be arranged in multiple parallel transmit / receiving chains, or on the same or different chips / modules, etc.

[0097] In some embodiments, the protocol processing circuit 314 may include one or more instances of a control circuit (not shown) that provides control functions for the transmit / receive components.

[0098] Reception of the UE can be established by and through one or more antenna panels 326, RFFE 324, RF circuit 322, receiving circuit 320, digital baseband circuit 316, and protocol processing circuit 314. In some embodiments, one or more antenna panels 326 can receive transmissions from AN304 by receiving beamforming signals received by multiple antennas / antenna elements of one or more antenna panels 326.

[0099] The UE's transmission can be established by and through the protocol processing circuit 314, the digital baseband circuit 316, the transmitting circuit 318, the RF circuit 322, the RFFE 324, and one or more antenna panels 326. In some embodiments, the transmitting component of the UE 302 may apply spatial filters to the data to be transmitted so as to form a transmission beam radiated by the antenna elements of one or more antenna panels 326.

[0100] Similar to the UE302, the AN304 may include a host platform 328 coupled with a modem platform 330. The host platform 328 may include an application processing circuit 332 coupled with the protocol processing circuit 334 of the modem platform 330. The modem platform may further include a digital baseband circuit 336, a transmit circuit 338, a receive circuit 340, an RF circuit 342, an RFFE 344, and an antenna panel 346. The components of the AN304 are similar to the components of the same name in the UE302 and may be substantially interchangeable. In addition to performing the data transmission / reception described above, the components of the AN304 may perform various logical functions, including RNC functions such as radio bearer management, dynamic uplink and downlink radio resource management, and data packet scheduling.

[0101] Figure 4 is a block diagram representing components according to several exemplary embodiments that can read instructions from a machine-readable or computer-readable medium (e.g., a non-temporary machine-readable storage medium) and perform one or more of the methods described herein. Specifically, Figure 4 shows a schematic representation of hardware resources 400, each comprising 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. In embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 402 may be executed to provide an execution environment in which one or more network slices / subslice utilize the hardware resources 400.

[0102] One or more processors 410 may include, for example, processors 412 and 414. One or more processors 410 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a composite instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio frequency integrated circuit (RFIC), other processors (including those described herein), or any suitable combination thereof.

[0103] The memory / storage device 420 may include main memory, disk storage, or any suitable combination thereof. The memory / storage device 420 may also include, but is not limited to, any type of volatile, non-volatile, or quasi-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, or solid-state storage.

[0104] One or more communication resources 430 may include interconnects 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, one or more communication resources 430 may include wired communication components (e.g., for connection via USB, Ethernet®, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth Low Energy) components, Wi-Fi® components, and other communication components.

[0105] Instruction 450 may include software, programs, applications, applets, APPs, or other executable code that causes at least one of the one or more processors 410 to perform one or more of the methods described herein. Instruction 450 may reside, whole or in part, in at least one of the one or more processors 410 (e.g., in the processor's cache memory), a memory / storage device 420, or any suitable combination thereof. Furthermore, any part of instruction 450 may be transferred to the hardware resource 400 from any combination of one or more peripheral devices 404 or one or more databases 406. Thus, the memory of one or more processors 410, the memory / storage device 420, one or more peripheral devices 404, and one or more databases 406 are examples of computer-readable and machine-readable media.

[0106] Figure 5 shows another exemplary network architecture 500. Network 500 may operate in accordance with 3GPP® technical specifications or technical reports for 6G systems. In some examples, network 500 may operate concurrently with network architecture 200. For example, in some examples, network 500 may share one or more frequency resources or bandwidth resources with network architecture 200. As one specific example, a UE (e.g., UE502) may be configured to operate in both network 500 and network 200. Such a configuration may be based on a UE that includes circuitry configured for communication using the frequency and bandwidth resources of both network architectures 200 and 500. In general, some elements of network 500 may share one or more characteristics with elements of network architecture 200. For brevity and clarity, such elements may not be repeated in the description of network 500.

[0107] Network 500 may include UE502. UE502 may include any mobile or non-mobile computing device designed to communicate with RAN508 via a wireless connection. UE502 may be, for example, similar to UE202. UE502 may include, but is not limited to, smartphones, tablet computers, wearable computing devices, desktop computers, laptop computers, automotive infotainment, in-car entertainment devices, instrument panels, head-up display devices, onboard diagnostic devices, dashboard 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, network appliances, machine-type communication devices, M2M or D2D devices, IoT devices, etc.

[0108] Although not explicitly shown in Figure 5, in some examples, network 500 may include multiple UEs directly coupled to one another via sidelink interfaces. The UEs may be M2M / D2D devices communicating using physical sidelink channels such as PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc. (but not limited to these). Similarly, although not explicitly shown in Figure 5, UE502 may be communicably coupled to an AP such as AP206, as described with respect to Figure 2. Furthermore, although not explicitly shown in Figure 5, in some examples, RAN508 may include one or more ANs such as AN208, as described with respect to Figure 2. RAN508 and / or the ANs of RAN508 may be referred to as base stations (BS) or RAN nodes, or by other terms or names.

[0109] The UE502 and RAN508 may be configured to communicate via an air interface which may be called a sixth-generation (6G) air interface. A 6G air interface may include one or more features such as communication in terahertz (THz) or sub-THz bandwidth, or joint communication and sensing. As used herein, the term “joint communication and sensing” may refer to a system that enables wireless communication together with radar-based sensing through 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. Such frequency ranges may also be additionally or alternatively referred to as “millimeter wave” or “mmWave” frequency ranges.

[0110] RAN508 can enable communication between UE502 and 6G core network (CN)510. Specifically, RAN508 can assist in the transmission and reception of data between UE502 and 6G CN510. 6G CN510 may include various functions such as NSSF250, NEF252, NRF254, PCF256, UDM258, AF260, SMF246, and AUSF242. 6G CN510 may further include UPF248 and DN236, as shown in Figure 5.

[0111] Furthermore, RAN508 may include various additional functions that are additions or replacements for the functions of legacy cellular networks, such as 4G or 5G networks. Two such functions are Computation Control Functions (Comp CF)524 and Computation Service Functions (Comp SF)536. Comp CF524 and Comp SF536 may be parts or functions of the compute service plane. Comp CF524 may be a control plane function that provides functions such as managing Comp SF536, generating and managing compute task contexts (e.g., create, read, modify, delete), and interacting with the underlying compute infrastructure for compute resource management. Comp SF536 may be a user plane function that acts as a gateway for interfaceping compute service users (e.g., UE502) with compute nodes behind Comp SF instances. Some functions of Comp SF536 include the ability to parse compute service data received from users and compute tasks that can be executed on compute nodes, the ability to maintain a service mesh ingress gateway or service API gateway, the enforcement of service and billing policies, performance monitoring, and telemetry collection. In some cases, a Comp SF536 instance can function as a user plane gateway for a cluster of compute nodes. A Comp CF524 instance may control one or more Comp SF536 instances.

[0112] Two other such functions are the Communication Control Function (Comm CF) 528 and the Communication Service Function (Comm SF) 538, which may be part of the communication service plane. The Comm CF 528 may be a control plane function for managing the Comm SF 538, creating / configuring / releasing communication sessions, and managing the communication session context. The Comm SF 538 may be a user plane function for data transport. The Comm CF 528 and Comm SF 538 can be considered upgrades to the SMF 246 and UPF 248 described in Figure 2 for a 5G system. The upgrades provided by the Comm CF 528 and Comm SF 538 can enable service-aware transport. For legacy (e.g., 4G or 5G) data transport, the SMF 246 and UPF 248 may still be used.

[0113] Two other such functions are the Data Control Function (Data CF) 522 and the Data Service Function (Data SF) 532, which may be parts of the data service plane. The Data CF 522 may be a control plane function and provides functions such as managing the Data SF 532, creating / configuring / releasing data services, and managing the data service context. The Data SF 532 is a user plane function and may act as a gateway between data service users (e.g., various functions of UE502 and 6G CN510) and data service endpoints behind the gateway. Specific functions may include parsing data service user data and forwarding it to the corresponding data service endpoint, generating billing data, and reporting data service status.

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

[0115] Another such function may be a Service Registration Function (SRF) 514, which can function as a registry of system services provided on the user plane, such as services provided by service endpoints behind the Comp SF536 and Data SF532 gateways, or services provided by UE502. SRF514 can be considered a counterpart to NRF254, which can function as a registry of network functions.

[0116] Other such functions may include evolved service communication proxy (eSCP) and service infrastructure control function (SICF)526. These can provide service communication infrastructure for control plane services and user plane services. eSCP may relate to 5G service communication proxy (SCP) with added user plane service communication proxy functionality. Thus, eSCP is represented in two parts: eSCP-C512 for control plane service communication proxy and SCP-U534 for user plane service communication proxy. SICF526 can control and configure eSCP instances with respect to service traffic routing policies, access rules, load balancing configurations, performance monitoring, etc.

[0117] Another such function is found in the AMF544. The AMF544 is similar to the AMF244 but may have additional functions. Specifically, the AMF544 may include a potential redistribution of functions, such as moving the message forwarding function from the AMF544 to the RAN508.

[0118] Another such function is the service orchestration exposure function (SOEF)518. The SOEF518 can be configured to expose the orchestration and chaining of services to external users, such as applications.

[0119] UE502 may include an additional function called a computing 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 such as SOCF520, Comp CF524, Comp SF536, Data CF522, and / or Data SF532 for service discovery, request / response, compute task workload exchange, etc. The comp CSF 504 may also work with network-side functions to determine whether a compute task should be performed on elements of UE502, RAN508, and / or 6G CN510.

[0120] UE502 and / or Com Comp CSF504 may include a service mesh proxy 506. The service mesh proxy 506 may function as a proxy for service-to-service communications within the user plane. The functions of the service mesh proxy 506 may include one or more of the following: addressing, security, load balancing, etc.

[0121] Figure 6 shows an exemplary artificial intelligence (AI)-assisted communication architecture for communication between the UE605 and the RAN610. More specifically, as will be described in further detail below, AI / machine learning (ML) models may be used or leveraged to assist wireless communication between the UE605 and the RAN610.

[0122] In this example, the UE605 and RAN610 operate in accordance with the 3GPP® technical specifications and / or the technical reports for 6G systems. In some examples, the wireless cellular communication between the UE605 and RAN610 may be part of, or concurrent with, the network architecture 500, 200, and / or other network parts described herein.

[0123] UE605 is similar to any of the UE202, 202a, 202t, 202l, UE302, UE502, UE702, hardware resource 400, and / or other UEs or devices described herein, and may share one or more functions with them. UE605 may be, but is not limited to, smartphones, tablet computers, wearable computer devices, desktop computers, laptop computers, automotive infotainment, in-car entertainment devices, instrument panels, head-up display devices, onboard diagnostic devices, dashboard 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, network appliances, machine-type communication devices, M2M or D2D devices, IoT devices, etc. RAN610 is similar to the RAN210, RAN508, and / or other RANs described herein, and may share one or more functions with them.

[0124] As is clear from Figure 6, AI-related elements in UE605 may be similar to those in RAN610. For illustrative purposes, the descriptions of the various elements are given from the perspective of UE605. However, it should be understood that such descriptions or representations also apply to elements with the same names / numbers in RAN610 unless explicitly stated otherwise.

[0125] As described above, the UE605 may include various elements or functions related to AI / ML. Such elements may be implemented as hardware, software, firmware, and / or any combination thereof. For example, one or more elements may be implemented as part of the same hardware (e.g., a chip or multiprocessor chip), software (e.g., a computer program), or firmware as the other elements.

[0126] One such element may be a data repository 615. The data repository 615 may be involved in the collection and storage of data. Specifically, the data repository 615 may collect and store RAN configuration parameters, measurement data, performance KPIs (key performance indicators), model performance metrics, etc., for demo training, updating, and inference. More generally, the collected data is stored in the repository. The stored data may be discovered and extracted from the data repository 615 by another element. For example, as is obvious, the inference data selection / filter element 650 may read 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 610, and vice versa. More generally, the data repository 615 of the UE 605 may be communicatively coupled with the data repository 615 of the RAN 610, so that the respective data repositories of the UE and RAN can share the collected data.

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

[0128] As described above, another such element may be the model training function block 625. This function block may be involved in training and updating (retraining) AI / ML models. The selected model may be trained using a dataset supplied from the training data selection / filtering function block (including training, validation, and testing). The model training function 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.

[0129] The model repository 635 may be involved in the storage and retrieval of 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, UE605 may discover and request an AI / ML model from the model repository 635 of RAN610. Similarly, RAN610 may discover and request an AI / ML model from the model repository 635 of UE605. In some examples, RAN610 may configure the models and model parameters / or model parameters in the model repository 635 of UE605.

[0130] Other such elements may be the Model Management Function Block 640. The Model Management Function Block 640 may be involved in managing 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 the 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 a running model, start retraining a model, select a different model, etc. For example, the Model Management Function Block 640 of RAN 610 may be able to configure model management policies in the UE, as shown.

[0131] Other such elements may be the inference data selection / filtering function block 650. The inference data selection / filtering function block 650 may be involved in generating a dataset for model inference in the inference function block 645, which will be described later. Specifically, the inference data may be extracted from the data repository 615. The inference data selection / filtering function block 650 may select and / or filter the data based on the deployed AI / ML model. The data may be transformed / enhanced / preprocessed according to the same transformation / enhanced / preprocessing as the training data selection / filtering described with respect to function block 620. The generated inference dataset may be supplied to the inference function block 645.

[0132] Other such elements may be the inference function block 645. The inference function block 645 may be involved in performing the inferences described above. Specifically, the inference function block 645 may consume the inference dataset supplied by the inference data selection / filter function block 650 and generate one or more results. Such results may include data analysis, actions, policies, etc. The results may be supplied to the performance measurement function block 630.

[0133] The performance measurement function block 630 is configured to measure model performance metrics (e.g., accuracy, model bias, runtime delay, etc.) of a deployed and running model based on inference results for monitoring purposes. Model performance data may be stored in the data repository 615.

[0134] Figure 7 illustrates an aspect of an example RAN partitioning architecture. Figure 7 shows an exemplary network configuration including an example next-generation fronthaul (NGF) configuration 700a, where user equipment (UE) 702 is connected via an air interface to RU730 (also known as “remote radio unit 730,” “remote radio head 730,” or “RRH730”), RU730 is connected via NGF interface (NGFI)-I to digital unit (DU) 731, DU731 is connected via NGFI-II to central unit (CU) 732, and CU732 is connected via backhaul interface to core network (CN) 742. In a 3GPP® NG-RAN implementation (see, for example, [TS38401]), DU731 may be a distributed unit (for the purposes of this disclosure, the term “DU” may refer to a digital unit and / or a distributed unit unless otherwise indicated by the context). UE702 may be the same as or similar to UE202 and / or any other UE or user / client device described herein.

[0135] In some implementations, the NGF deployment 700a may be configured in a distributed RAN (D-RAN) architecture where CU732, DU731, and RU730 are located at cell sites, and CN742 is located at a centralized site. Alternatively, the NGF deployment 700a may be configured in a centralized RAN (C-RAN) architecture with centralized processing of one or more baseband units (BBUs) at a centralized site. In a C-RAN architecture, radio components are divided into separate components, and these separate components can be located in different locations. In one example of a C-RAN implementation, only RU720 is located at a cell site, while DU731, CU732, and CN742 are centralized or located at a central location. In another example of a C-RAN implementation, RU730 and DU731 are located at cell sites, and CU732 and CN742 are located at a centralized site. In another example of C-RAN implementation, only RU730 is located at the cell site, DU731 and CU732 are located at the RAN hub site, and CN742 is at the centralized site.

[0136] The CU732 is a central controller that can serve or otherwise connect to one or more DU731s and / or multiple RU730s. The CU732 is a network (logical) node that hosts the higher / upper layers of the network protocol functional partitioning. For example, in the 3GPP® NG-RAN and / or O-RAN architecture, the CU732 hosts the Radio Resource Control (RRC) layer, the Service Data Adaptive Protocol (SDAP) layer, and the Packet Data Convergence Protocol (PDCP) layer of the Next Generation NodeB (gNB), or hosts the RRC and PDCP protocol layers if it is included in or operates as an en-gNB of the E-UTRA-NR gNB. The SDAP sublayer performs mapping between quality of service flows and data radio bearers (DRBs) and marks quality of service IDs (QFIs) in both DL and UL packets. The PDCP sublayer performs data transfer on the user plane or control plane, maintains PDCP sequence numbers (SNs), compresses and decompresses headers using the Robust Header Compression (ROHC) protocol and / or the Ethernet Header Compression (EHC) protocol, encryption and decryption, integrity protection and integrity verification, provides timer-based SDU discarding, routing of split bearers, duplication and duplication discarding, sorting and sequential delivery, and / or out-of-order delivery. In various implementations, the CU732 terminates each F1 interface connected to the corresponding DU731 (see, for example, [TS38401]).

[0137] CU732 may include a CU-Control Plane (CP) entity (referred to here as "CU-CP732") and a CU-User Plane (UP) entity (referred to here as "CU-UP732"). CU-CP732 is a logical node that hosts the control plane portions of the RRC layer and PDCP protocol layer of CU732 (e.g., gNB-CU of en-gNB or gNB). CU-CP terminates the E1 interface connected to CU-UP, and the F1-C interface is connected to DU731. CU-UP732 is a logical node that hosts the user plane portion of the PDCP protocol layer (e.g., for NB-CU732 of en-gNB), and the user plane portion of the PDCP protocol layer and the SDAP protocol layer (e.g., for gNB-CU732 of gNB). CU-UP732 terminates the E1 interface connected to CU-CP732 and the F1-U interface connected to DU731.

[0138] The DU731 controls radio resources such as time and frequency band locally and in real time, and allocates resources to one or more UEs. The DU731 is a network (logical) node that hosts the middle and / or lower layers of the network protocol functional partitioning. For example, in the 3GPP® NG-RAN and / or O-RAN architecture, the DU731 hosts the Radio Link Control (RLC) Medium Access Control (MAC) and the High-PHY layer of the gNB or en-gNB, whose operation is at least partially controlled by the CU732. The RLC sublayer operates in one or more of the following modes: TM (Transparent Mode), UM (Unacknowledged Mode), and AM (Acknowledged Mode). The RLC sublayer performs the forwarding of upper-layer PDUs, sequence numbering independent of PDCP numbers (UM and AM), error correction by ARQ (AM only), segmentation (AM and UM) and re-segmentation (AM only) of RLC SDUs, SDU reconstruction (AM and UM), duplicate detection (AM only), RLC SDU discarding (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 of MAC SDUs belonging to one or different logical channels to and from transport blocks (TBs) transmitted and received with the physical layer on the transport channel, reporting scheduling information, error correction by HARQ (one HARQ entity per cell in the case of CA), priority processing between UEs by dynamic scheduling, priority processing between logical channels of a single UE by logical channel prioritization, priority processing between duplicate resources of a single UE, and / or padding.In some implementations, the DU731 can host the Backhaul Adaptation Protocol (BAP) layer (see, e.g., 3GPP® TS 38.340 v16.5.0 (July 7, 2021)) and / or the F1 Application Protocol (F1AP) (see, e.g., 3GPP® TS 38.470 v16.5.0 (July 1, 2021)), such as when the DU731 operates as an Integrated Access and Backhaul (IAB) node. A single DU731 supports one or more cells, and a single cell is supported by only one DU731. The DU731 terminates the F1 interface connected to the CU732. Additionally or alternatively, the DU731 may be connected to one or more RRH / RU730s.

[0139] A RU730 is a transmit / receive point (TRP) or other physical node that handles radio frequency (RF) processing functions. A RU730 is a network (logical) node that hosts lower layers based on lower layer functional partitioning. For example, in the 3GPP® NG-RAN and / or O-RAN architecture, a RU730 hosts the Low-PHY layer functions and RF processing of a radio interface based on lower layer functional partitioning. A RU730 may be similar to a 3GPP® transmit / receive point (TRP) or RRH, but specifically includes a Low-PHY layer. Examples of Low-PHY functions include Fast Fourier Transform (FFT), Inverse Fast Fourier Transform (IFFT), and Physical Random Access Channel (PRACH) extraction.

[0140] CU732, DU731, and RU730 are each connected by a link, which may be any suitable wired link (e.g., fiber, copper, etc.) and / or wireless link. In some implementations, various combinations of CU732, DU731, and RU730 may correspond to one or more of AN208 in Figure 2. Further aspects of CU732, DU731, and RU730 are described in [O-RAN], [TS38401], and [TS38410], the contents of which are incorporated herein by reference in their entirety.

[0141] In some implementations, the fronthaul gateway function (FHGW) may be located between the DU731 and the RU / RRU730 (not shown in Figure 7), where the interface between the DU731 and the FHGW is an open fronthaul (e.g., Option 7-2x) interface, and the interface between the FHGW function and the RU / RRU730 is any other suitable interface (e.g., Option 7, Option 8, etc.), including an open fronthaul (e.g., Option 7-2x) interface or one that does not support open fronthaul (e.g., Option 7-2x). The FHGW may be packaged with one or more other functions (e.g., Ethernet switching) in a physical device or appliance. In some implementations, the RAN controller may be coupled to communicate with the CU732 and / or DU731.

[0142] NGFI (also known as "xHaul") is a two-stage fronthaul architecture that separates the traditional RRU730-to-BBU connection in the C-RAN architecture into two levels, Level I and Level II. As shown by Deployment 700a in Figure 7, Level I connects the RU730 to the DU731 via NGFI-I, and Level II connects the DU731 to the CU732 via NGFI-II. The NGFI-I and NGFI-II connections may be wired or wireless, and any suitable RAT, such as any of those described herein, may be used. The purpose of the two-stage architecture is to improve deployment flexibility by distributing (dividing) the RAN node protocol functions between the CU732 and DU731 so that latency is mitigated. Generally, NGFI-I interfaces with the lower layers of the functional division, which have stringent latency and data rate requirements. In contrast, NGFI-II interfaces with the higher layers of the functional division relative to the layers of NGFI-I, thus relaxing the requirements for the fronthaul link.Examples of NGFI fronthaul interfaces and functional partitioning architectures include O-RAN7.2x fronthaul ([O-RAN.WG9.XPSAAS] and [O-RAN-WG4.CUS.0]), eCPRI (Enhanced Common Public Radio Interface) based C-RAN fronthaul (see, for example, Common Public Radio Interface: eCPRI Interface Specification, eCPRI Specification v2.0 (May 10, 2019), Common Public Radio Interface: Requirements for the eCPRI Transport Network, eCPRI Transport Network v1.2 (June 25, 2018), and [O-RAN-WG.4.CUS.0]), and RoE (Radio over Ethernet) based C-RAN fronthaul (see, for example, IEEE Standard for Radio over Ethernet Encapsulations and Mappings, IEEE Standards Association, IEEE 1914.3-2018 (October 5, 2018) (see "[IEEE1914.3]").Further aspects of NGFI are described in [O-RAN.WG9.XPSAASO-RAN.WG9.XPSAAS], [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 these are incorporated by reference to their respective full texts.

[0143] In one example, deployment 700a may implement a low-level split (LLS) (also known as "lower layer functional split 7-2x" or "split option 7-2x") performed between RU730 (e.g., O-RU in the O-RAN architecture) and DU731 (e.g., O-DU in the O-RAN architecture) (see, for example, [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 embodiment, NGFI-I is the open fronthaul interface described in the O-RAN open fronthaul usage (see, for example, [O-RAN-WG4.CUS.0]). For example, 3GPP® NG-RAN Functional Splitting (e.g., [TS38401] and 3GPP® TR 38.801 v14.0.0 (April 3, 2017)), the Small Cell Forum for Split Option 6 (e.g., 5G small cell architecture and product definitions: Configurations and Specifications for companies deploying small cells 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 See 251.10.01 (December 15, 2021) ("[SCF251]") and [O-RAN.WG7.IPC-HRD-Opt6]. The contents of each of these documents are incorporated into this application by reference in their entirety.Other LLS options may be used, such as related interfaces described in other standards or specifications, including O-RAN whitebox hardware partitioning option 8 (e.g., [O-RAN.WG7.IPC-HRD-Opt8]).

[0144] Additionally, or alternatively, CU732, DU731, and / or RU730 may be IAB nodes. IAB enables radio relay in NG-RAN, and relay nodes (referred to as “IAB nodes”) support access and backhauling via 3GPP® 5G / New Radio (NR) links / interfaces. The terminating node for NR backhauling on the network side is called an “IAB donor” and corresponds to a RAN node (e.g., gNB) with additional capabilities to support IAB. Backhauling can occur via a single hop or multiple hops. All IAB nodes connected to an IAB donor via one or more hops form a directed acyclic graph (DAG) topology with the IAB donor as its root. The IAB donor provides centralized resource, topology, and route management for the IAB topology. The IAB architecture is shown and described in [TS38300].

[0145] While NGF Deployment 700a shows CU732, DU731, RRH730, and CN742 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 CU732 and DU731 (e.g., CU-DU), which is connected to RRH730 via NGFI-I; (ii) integrating DU731 and the integrated RRH731 (e.g., CU-DU), which is connected to CU732 via NGFI-II; (iii) integrating the RAN controller and CU732, which is connected to DU731 via NGFI-II; (iv) integrating CU732, DU731, and RU730, which is connected to CN742 via a backhaul interface; (v) integrating the network controller (or intelligent controller) with CU732, DU731, and RU730. Any of the above embodiments including CU732 may also include integrating CU-CP732 and CP-UP732.

[0146] Figure 7 also shows an example RAN disaggregation configuration 700b (also called “Disaggregated RAN700b”), where UE702 is connected to RRH730, which is communicatively coupled to one or more of the RAN functions (RANF) 1-N (where N is a number). RANF1-N are separated and geographically distributed across several component segments and network nodes. In some implementations, each RANF1-N is a software (SW) element operated by a physical computing node, and RRH730 includes radio frequency (RF) circuitry (e.g., an RF propagation module for a specific RAT). In this example, RANF1 operates on a physical computing node located in the same location as RRH730, while the remaining RANFs are located far away from RRH730. Furthermore, in this example, CN742 is also separated into CN NF1-x (where x is a number) in the same or similar manner as RANF1-N. However, in other implementations, CN742 is not isolated.

[0147] Network disaggregation (or disaggregated networking) involves dividing networking equipment into functional components and allowing each component to be deployed individually. This may include separating software elements (e.g., NFs) from specific hardware elements and / or enabling software-defined networking (SDN) and / or NF virtualization (NFV) using APIs. RAN disaggregation involves network disaggregation and virtualization of various RANFs (e.g., RANF1-N in Figure 7). RANF1-N can be located in different physical locations within a RAN deployment in various topologies based on use cases. This enables the distribution and deployment of RANFs across different geographical regions and allows for RANF breakout to support various use cases (e.g., low-latency use cases) and flexible RAN implementations. Disaggregation provides a common or uniform RAN platform that can assume different profiles depending on the deployment location. This can reduce the number of fixed functional devices and lower the total cost of ownership compared to existing RAN architectures. Examples of RAN disaggregation frameworks include TIP (Telecom Infra Project) OpenRAN, Cisco® Open vRAN, [O-RAN], OOPT (Open Optical & Packet Transport), and ROADM (Reconfigurable Optical Add Drop Multiplexer).

[0148] In the first embodiment, RANF1~N isolate the RAN hardware and software using commercial off-the-shelf (COTS) hardware and open interfaces (e.g., NGFI-I and NGFI-II). In this embodiment, each RANF1~N may be a virtual BBU or vRAN controller operating on a COTS computing infrastructure with hardware acceleration for BBU / vRANF.

[0149] In the second embodiment, RANF1~N isolate one or more layers of the RAT protocol stack. As an example of this implementation, RANF1 is a DU731 running on a first COTS computing infrastructure with hardware acceleration for BBU / vRANF, and RANF2 is a virtual CU732 running on a second COTS computing infrastructure.

[0150] In the third embodiment, RANF1~N separates control plane functions from user plane functions. As an example of this implementation, RANF1 is a DU731 operating on a COTS computing infrastructure with hardware acceleration for BBU / vRANF, RANF2 is a virtual CU-CP732 operating on a COTS computing infrastructure, and a third RANF (e.g., RANF3 (not shown in Figure 7)) is a virtual CU-UP732 operating on the same or a different COTS computing infrastructure as the virtual CU-CP732. Additionally or alternatively, in this implementation, one or more CN NF1~x may be CN-UP functions, and one or more other CH NF1~x may be CN-CP functions.

[0151] In the fourth embodiment, RANF1~N isolate an example of [IEEE802]RAT. As an example of this implementation, RRH730 implements the WiFi PHY layer, RANF1 implements the Wi-Fi MAC sublayer, RANF1 implements the Wi-Fi Logical Link Control (LLC) sublayer, RANF2 implements one or more Wi-Fi upper layer protocols (e.g., network layer, transport layer, session layer, presentation layer, and / or application layer), etc.

[0152] In the fifth embodiment, RANF1~N separate different O-RAN RANFs, including E2SM. As an example of this implementation, RANF1 implements Near-RT RIC, RANF2 implements E2SM-KPM, RANF3 implements E2SM-CCC, RANF4 implements E2SM RAN control, RANF5 implements E2SM-NI, RANF6 implements functions to provide A1 services, and so on.

[0153] In any of the implementations described herein, the lower layers of the RAN protocol stack may feature real-time (RT) functions and relatively complex signal processing algorithms, while the upper layers of the RAN protocol stack may feature non-RT functions. In these implementations, the RT functions and signal processing algorithms can be implemented in the DU731 and / or RRH730, either using dedicated network elements or in COTS hardware extended with dedicated hardware accelerators.

[0154] Figure 7 also shows various functional partitioning options 700c for both DL and UL directions. Traditional RAN is an integrated network architecture based on Distributed RAN (D-RAN), which aggregates all RANFs into fewer network elements. As mentioned above, the disaggregated RAN architecture overcomes various shortcomings of the D-RAN model by providing flexible functional partitioning options. Disaggregated RAN divides an integrated network system into several functional components, which can then be rearranged individually as needed without hindering their ability to work together to provide overall network services. Partitioning option 700c is primarily a partition between CU732 and DU731, but may also include a partition between CU732, DU731, and RU730. For each option 700c, the protocol entities on the left side of the figure are included in the RANF implementing CU732, and the protocol entities on the right side of the figure are included in the RANF implementing DU731. For example, Option 2's functional decomposition involves separating non-RT processing (e.g., RRC layer and PDCP layer) from RT processing (e.g., RLC layer, MAC layer, and PHY layer), with the RANF implementing CU732 handling the networking functions of the RRC and PDCP layers, and the RANF implementing DU731 handling the baseband processing functions of the RLC layer (including High-RLC and Low-RLC), MAC layer (including High-MAC and Low-MAC), and PHY layer. In some implementations, the PHY layer is further decomposed between the DU731 and RU730, with the RANF implementing DU731 handling the High-PHY layer functions and the RU730 handling the Low-PHY layer functions. In some implementations, the Low-PHY entities may be operated by the RU730 regardless of the selected functional decomposition option. Under Option 2's splitting, the RANF implementing CU732 can connect to multiple DU731s (for example, CU732 is centralized), which eliminates changes to RRC and PFCP anchors during handovers between DU731s and allows the centralized CU732 to pool resources among multiple DU731s.Thus, the Option 2 functional partitioning can improve resource efficiency. The specific functional partitioning options used may vary depending on service requirements and network deployment scenarios and may be implementation-specific. In some implementations, all functional partitioning options may be selected, with each protocol stack entity being operated by its respective RANF (for example, the first RANF operates the RRC layer, the second RANF operates the PDCP layer, the third RANF operates the High-RLC layer, and so on until the eighth RANF operates the Low-PHY layer). Other partitioning options are also possible, such as those described 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].

[0155] In one or more embodiments, at least one of the components described in one or more of the aforementioned figures may be configured to perform one or more operations, techniques, processes, and / or methods described herein (including the examples given in the following Examples section). For example, a baseband circuit related to one or more of the aforementioned figures may be configured to operate according to one or more of the examples described below. As another example, a circuit related to a UE, base station, satellite, network element, etc., as described above in relation to one or more of the aforementioned figures, may be configured to operate according to one or more of the examples described below in the Examples section.

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

[0157] The terms “machine learning” or “ML” refer to the use of computer systems that implement algorithms and / or statistical models for performing specific tasks without using explicit instructions, but instead relying on patterns and inference. An ML algorithm constructs or estimates a mathematical model (such as an “ML model”) based on sample data (such as “training data” or “model training information”) 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 respect to some task and some performance metric, and an ML model may be any object or data structure produced after an ML algorithm has been trained on one or more training datasets. After training, an ML model may be used to make predictions on new datasets. The terms “ML algorithm” refer to a different concept from the terms “ML model,” but as used herein, these terms may be used synonymously.

[0158] The terms "machine learning model" and "ML model" can also refer to ML methods and concepts used by ML-assisted solutions. An "ML-assisted solution" is a solution that uses ML algorithms in operation to address a specific use case. ML models include supervised learning (e.g., linear regression, k-nearest neighbors (KNN), decision tree algorithm, support machine vectors, Bayesian algorithms, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal component analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-armed banded learning, deep RL, etc.), neural networks, etc. Depending on the implementation, a particular ML model may have many submodels as components, and an ML model may train all submodels together. Individually trained ML models can also be linked together in an ML pipeline during inference. An "ML pipeline" is a set of features, functions, or feature entities specific to an ML-assisted solution, and an ML pipeline may include a data pipeline, a model training pipeline, a model evaluation pipeline, and one or more data sources within the actor. An "actor" is an entity that hosts an ML-assisted solution using the output of an ML model inference. The term "ML training host" refers to an entity, such as a network function, that hosts the training of a model. The term "ML inference host" refers to an entity, such as a network function, that hosts a model during inference modes (including both model execution and optional online learning, where applicable). The ML host informs the actor of the output of the ML algorithm, and the actor decides on an action ("action" is performed by the actor 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 to determine the inference. The data used to train the ML model and the data used to determine the inference may overlap, but "training data" and "inference data" refer to different concepts.

[0159] This disclosure defines, or otherwise provides, the operation and functionality of a UE that supports measurements based on a positioning reference signal (PRS), such as carrier phase positioning (CPP) measurements. The following discussion may be applicable to any type of UE, such as any of the UEs shown in Figures 1A-18.

[0160] Under the 3GPP® NR Rel-18 research, a framework is needed to enable the use of the NR sidelink protocol to perform positioning measurements in order to support advanced positioning use cases. To achieve this, the disclosed technology includes an overall detection process for anchor nodes that enable sidelink-based positioning / sensing, thereby providing various approaches that can enhance anchor UE selection and defining various mechanisms for re-selecting anchor UEs during an ongoing SL positioning / sensing session. In this regard, the disclosed technology includes enhancing the anchor node detection procedure to improve anchor UE selection as part of a sidelink positioning session, details and comparisons of signaling mechanisms for LMF-based and LMFLMF-assisted anchor UE selection, and definitions of trigger conditions and their impact on the overall procedure for re-selecting anchor UEs during an ongoing positioning session.

[0161] With advancements in wireless communication technology, the demand for more accurate location information is increasing. Previously, rough location data was considered sufficient for most applications, but now, accurate and highly precise real-time location information is required. 3GPP® Rel-16 improves positioning procedures using techniques such as high bandwidth and multiple antennas, reducing latency and increasing flexibility. With the transition to 6G, the demand for accurate location information is further increasing due to the emergence of new use cases such as ranging (e.g., described in 3GPP® TS 22.261) and eV2X / public safety (e.g., described in TS 22.186). Sidelink-based positioning can be utilized to address these evolving use cases. Sidelink-based positioning offers unique advantages over conventional positioning and is particularly well-suited to supporting various advanced V2X scenarios (vehicle platooning, advanced driving, remote driving, etc.).

[0162] The entire sidelink positioning architecture and positioning procedure may include aspects that differ from traditional Uu-based positioning procedures. Such aspects include the role of so-called anchor nodes and related functions in the overall procedure.

[0163] Figure 8 shows an exemplary SL positioning architecture 800 that follows several aspects. Figure 8 shows a sidelink positioning architecture that includes an anchor UE that provides functionality partially based on the position management function (LMF) in conventional operation. In several aspects, the anchor node can perform at least the following functions:

[0164] (a) Interact with the target UE (using a new interface or an existing PC5 interface) to exchange sidelink positioning functions and support data (including SL-PRS settings) for specific location services.

[0165] (b) The system may also interact with the target UE by performing a sidelink positioning reference signal (SL-PRS) transmission and requesting the target UE to perform a measurement.

[0166] (c) If configured, a position estimate can also be obtained on request based on positioning measurements provided by the target UE.

[0167] (d) Furthermore, it can interact with NG-RAN nodes (using PC5 or a newly defined interface) to provide broadcast support data. It can also interact with LMFs present in the core network (CN) to perform the above functions.

[0168] In several aspects, the overall procedure for PC5-based positioning may include the following steps:

[0169] (a) Trigger event.

[0170] (b) Replacement of the side link positioning function.

[0171] (c) Transfer of sidelink positioning support data.

[0172] (d) SL positioning request location information.

[0173] (e) Measurement of Sl-PRS.

[0174] (f) Position calculation.

[0175] (g) Provision of location information using SL positioning.

[0176] The general process is similar to that of conventional Uu-based positioning procedures. However, since sidelink positioning procedures involve one or more anchor UEs / nodes in this case, there is an additional aspect to consider: how the target UE notices and selects the UE for a given positioning session. This issue is the focus of this disclosure, and the following discussion discloses various methods for detecting and selecting anchor UEs, as well as their impact on the overall procedure. While the following discussion focuses primarily on sidelink positioning, the same principles can be extended to sidelink-based sensing.

[0177] In some aspects, at the beginning of a sidelink positioning session, i.e., when a position request is triggered (by either the UE or the LMF / AMF), the target UE may need to identify the appropriate anchor UE to initiate the sidelink positioning procedure. To achieve this, the following approaches are possible:

[0178] Regarding the first approach, the target UE may perform a discovery procedure to detect any candidate anchor UEs nearby. This discovery procedure may rely entirely on the conventional sidelink PC5 discovery procedure (e.g., described in TS 23.287 and TS 23.304) processed above the AS layer. In several respects, both Model A and Model B discovery are applicable in this case. Alternatively, the PC5 discovery procedure may be extended to include certain information in the discovery message that may be helpful in supporting sidelink positioning. In several respects, one or more of the following may be considered during the session process:

[0179] (a) SL positioning function, including positioning methods supported by the anchor UE.

[0180] (b) A function to calculate position information based on SL-PRS measurements.

[0181] (c) Function to perform absolute positioning versus relative positioning / distance calculations.

[0182] In Model A, the target UE may broadcast a discovery announcement message, which includes the SL positioning / distancing service code and the information described above, indicating its interest in finding a suitable anchor UE. An anchor UE supporting the positioning method and other information indicated by the target UE may respond by setting up a direct PC5 connection with the target UE to assist in the positioning session.

[0183] In Model B, an anchor UE authorized and provisioned by the network to act as an anchor UE for sidelink positioning may periodically broadcast a solicitation message, which may include a service code for SL positioning / distancing and the information described above, i.e., supported positioning methods, ability to perform position estimation, etc. A target UE interested in SL positioning can then respond to the discovery message and set up a PC5 connection with the anchor UE.

[0184] An alternative approach relies on an AS layer mechanism to enable the target UE to select appropriate candidate anchor UEs for sidelink positioning. After a position request is triggered, the target UE determines a set of nearby available candidate anchor UEs. This can be handled by using an existing PC5 discovery procedure. Once the target UE compiles a list of candidate anchor UEs, various options, detailed below, are possible, along with the corresponding signaling flow.

[0185] (a) Option 1: The target UE may provide this list to the LMF and / or positioning server UE, along with the information described above, such as the anchor UE IR, supported positioning methods, position calculation capabilities, and signal quality from the anchor UE. Based on this information, the LMF and / or UE may select one or more anchor UEs suitable for the target UE for further selection.

[0186] (b) Option 2: Based on the location and / or service requirements of the target UE (e.g., quality of service, requested positioning method, etc.), the LMF / server UE may select one or more anchor UEs suitable for the target UE for further selection, based on a pre-configured list of anchor UEs (i.e., in contrast to Option 1, without the target UE explicitly providing a list of candidate anchor UEs in advance). To enable this, the anchor UEs may directly supply their functions and other relevant information to the LMF for pre-configuration.

[0187] In some aspects, the LMF or server UE may select one or more anchor UEs based on the aforementioned criteria (e.g., location of the target UE, server requests (e.g., quality of service, requested positioning method), supported positioning methods, position calculation capabilities, signal quality from the anchor UE, authorization information, etc.). In some aspects, the selection of anchor UEs may be specified or left to the LMF / server UE implementation. In some aspects, the target UE then initiates PC connection setup with the selected anchor UE for sidelink positioning. In some aspects, the LMF may also provide this information if the target UE is under direct network coverage. Figure 9 details the general procedure below. Figure 8 is a swimlane diagram 900 representing exemplary functionality for anchor UE selection based on the Location Management Function (LMF) according to several aspects.

[0188] In some aspects, the UE may make further anchor UE selections based on information provided by the LMF / server UE. In some aspects, in order to obtain the capabilities of the candidate anchor UEs, such as supported positioning methods and location calculation capabilities, the target UE may need to exchange SL positioning capabilities or acquire them in other ways based on the discovery procedure.

[0189] (c) Option 3: Based on the above options, the LMF / Server UE may provide the Target UE with a list of candidate anchor UEs. If so, the Target UE can select an anchor UE from the list. The Target UE may have selection criteria (e.g., signal quality from the anchor UE, supported positioning methods, computing capabilities, etc.) to be used for selecting an anchor UE from the discovered candidate anchor UEs set by the LMF (or pre-configured in the case of OOC). Based on these settings, the Target UE may compile this list and provide it to the upper layer, and the decision of which anchor to select may depend on the upper layer. Alternatively, this selection may be handled at the AS layer based on the aforementioned criteria. Or, the AS layer may check AS layer criteria (e.g., signal quality from the anchor UE) and send the decision to the upper layer for a final decision. In either case, once selected, the upper layer triggers a PC5 connection to the selected anchor UE. This option is applicable to both in-coverage and out-of-coverage scenarios. The signaling flow for this option is shown in Figure 10. Figure 10 is a swimlane diagram illustrating the exemplary functionality of an LMF-supported anchor UE according to several aspects.

[0190] In some aspects, in order to obtain the capabilities of a candidate anchor UE, such as supported positioning methods and location calculation capabilities, the target UE may need to perform a descent of SL positioning capabilities, obtain this based on a discovery procedure, or obtain it directly from the LMF / server UE.

[0191] One aspect to consider that is applicable to the approach described above is the number of UEs to be selected. In some aspects, there may be two different types of selected anchor UEs that are chosen by the LMF or server UE to serve the target UE.

[0192] (a) A primary anchor UE that is essential or indispensable to the positioning session.

[0193] (b) A secondary anchor UE that can be optionally set / selected for the positioning session.

[0194] In several aspects, multiple secondary anchor UEs may be configured for the target UE, and the LMF can include primary / secondary designation instructions for each selected anchor UE when sending them to the target UE. From an application layer perspective, this configuration can support certain QoS requirements that may require the transmission of reference signals from multiple anchor UEs. Furthermore, it provides additional redundancy, as the positioning session can continue if permitted, albeit with reduced quality of service, in the event of a link failure or any problem with a secondary anchor UE.

[0195] In several aspects, the LMF may consider the number of anchor UEs selected for the target UE based on quality of service. For example, at least three UEs can be involved in positioning; otherwise, the positioning results may not satisfy the application requirements. Therefore, if an anchor UE can only detect / connect to two other anchor UEs, the positioning session will not continue, and an error may be reported to the higher layer. Based on this, the minimum number of anchor UEs required may be included as part of the information / configuration message sent from the LMF to the target UE, or it may be defined as a requirement.

[0196] Given a session-based approach, once a positioning session is established and an anchor UE is selected, the target UE can exchange SL positioning capabilities and support data with one or more anchor UEs. Unlike the Uu, both the target UE and one or more anchor UEs are mobile during this process, and the link quality between them is likely to be constantly changing. Whether the anchor UEs remain continuously available throughout the positioning session is a unique issue, as it directly impacts the quality of service of the positioning method being used. For example, if the anchor UE and target UE become separated or enter an NLOS state, the accuracy of the SL-PRS measurement may be significantly reduced, potentially failing to meet the quality of service requirements of the selected positioning method. As mentioned above, if there is only one anchor UE, the measurement will fail. If there are multiple anchor UEs, failure may occur if the number of available anchors does not meet the performance requirements. If a problem occurs, the solution in conventional positioning designs is to report the failure to the location server and re-trigger the session. However, in such scenarios, it may be helpful to allow the target UE to search for and select another suitable anchor UE, and then either continue the positioning session or abort it and start a new one.

[0197] In several aspects, the target UE may provide information about the ongoing positioning session with the anchor UE to the higher layer, with the aim of determining whether it is necessary to re-select another anchor UE. The timing of when this information is provided to the higher layer can be determined based on various factors, such as the following:

[0198] (a) If a unicast link exists between the target UE and the anchor UE, the SL link quality (e.g., based on SL-RSRP) can be used to determine whether the anchor UE is considered valid.

[0199] (b) The anchor UE may, based on its criteria, instruct the target UE to conserve power, for example, if it is unable to continue SL-PRS transmission or position estimation.

[0200] (c) The anchor UE may instruct the target UE to select another candidate anchor UE by sending instructions (for example, based on performance).

[0201] (d) The anchor UE may provide a bit indication of whether it can still support the necessary quality of service for the SL positioning method / session.

[0202] (e) The anchor UE may indicate that it is not possible to continue transmitting the SL-PRS, for example, in order to conserve power or for other reasons.

[0203] In several respects, the target UE may set criteria that trigger the selection of an anchor UE from among those captured above. The LMF or server UE may supply such settings to the target UE (either within or outside the coverage, depending on the pre-configuration). If the conditions are met, the target UE may send instructions to the upper layer to either terminate and restart the ongoing positioning session, or to change it by discovering a new anchor UE using the procedure described above.

[0204] In some aspects, when the re-selection process described above is triggered when discovering and evaluating candidate anchor UEs, various methods for evaluating them may exist. In some aspects, criteria based on link quality standards specified in the case of relay re-selection, i.e., criteria based on SD-RSRP or SL-RSRP (if a unicast connection has already been established with the candidate anchor UE), can be used. In some embodiments, the selection may be based on a supported positioning method (as part of the discovery procedure specified in the previous selection) to compile a list of suitable candidate UEs, and then a new anchor UE is selected from the list based on the link quality standards. The upper layer may provide this list of candidate anchor UEs to the AS layer for the final selection, or it may select a suitable anchor UE from the list based on information reported by the AS layer.

[0205] Figure 11 is a swimlane diagram 1100 representing exemplary functionality for setting up an ongoing SL positioning session for anchor UE reselection, according to several aspects. Figure 11 shows the signaling flow when a UE has an ongoing SL positioning session and needs to reselect a new anchor UE to continue the ongoing positioning session. In several aspects, the trigger for reselection can be based on those described in the section above and can be issued from the upper layer of the target UE or by the anchor UE itself. In the case of in-coverage LMF-based positioning, the LMF can also trigger the target UE to perform anchor UE reselection.

[0206] The above explanation primarily relates to session-based positioning operation, that is, it assumes that a dedicated SLPP session is established between all relevant nodes / UEs before sidelink positioning is performed. However, a sessionless operation may also be supported, where the UE can perform SL-based positioning on a best-effort basis without requiring explicit signaling to establish a session. This is applicable to use cases where devices may move in and out of communication range, and the signaling overhead associated with session changes may be too large.

[0207] In session-based operation, additional signaling exists related to changes in the SLPP session, which may result in selected anchor UEs being added as part of the session and previously selected anchor UEs being removed from the session.

[0208] In a sessionless approach, the anchor UE discovery and re-selection described above can also function well. Since the discovery, evaluation, and selection of candidate anchor UEs are not directly affected by the presence or absence of an SLPP session, they are also applicable to sessionless operation.

[0209] In some respects, a system is disclosed that enables the discovery and selection / re-selection of anchor UEs / nodes for sidelink-based positioning / distancing. In some respects, the discovery of candidate anchor UEs for initiating a sidelink positioning procedure can be performed using two distinct approaches. In some respects, the disclosed configuration can rely on conventional sidelink PC5 discovery procedures (both Model A and Model B) using sidelink positioning-specific messages embedded within the discovery message, including SL positioning capabilities (including positioning methods supported by the anchor UE), the ability to calculate positional information based on SL-PRS measurements, and the ability to perform absolute-to-relative positioning / distancing calculations.

[0210] In some aspects, the access stratum (AS) layer may detect candidate anchor UEs using either an LMF-based or LMF-assisted method (and associated signaling). In some aspects, the target UE may provide a list of candidate UEs to the LMF and make a selection dependent on the LMF. In some aspects, the LMF may make its own selection of anchor UEs, independent of the information received from the target UE. In some aspects, the target UE may provide a list of candidate UEs to the LMF and make a selection based on criteria set by the LMF.

[0211] In some respects, anchor UEs can be classified into primary and secondary anchor UEs to support diverse quality of service requirements and provide further redundancy during side-link positioning procedures.

[0212] In some respects, the anchor UE can be reselected during an ongoing sidelink positioning session based on various specified triggers.

[0213] In some respects, the target UE may set criteria that trigger the re-selection of the anchor UE. Upon triggering, the target UE may send instructions to the upper layer to either end and restart the ongoing positioning session, or change it by discovering a new anchor UE.

[0214] In some respects, the evaluation of candidate anchor UEs for re-selection can be based on link quality criteria (similar to the case of relay re-selection). Alternatively, supported positioning methods can be used to classify and rank candidate anchor UEs.

[0215] In several respects, the above requirements for anchor UE discovery and re-selection are applicable to both sidelink-based sensing and both session-based and sessionless positioning operations.

[0216] In several aspects, the entire signaling flow for a sidelink positioning session is detailed in cases where anchor UE re-selection is triggered.

[0217] Figure 12 shows a block diagram of a communication device such as an evolved node B (eNB), a next-generation node B (gNB) (or other RAN node such as a base station), a network-controlled repeater (NCR), an access point (AP), a radio station (STA), a mobile station (MS), or a user equipment (UE), according to several aspects and to perform one or more of the technologies disclosed herein. In an alternative aspect, the communication device 1200 may operate as a standalone device or may be connected to other communication devices (e.g., networked).

[0218] A circuit (e.g., a processing circuit) is a collection of circuits realized in a tangible entity of device 1200, including hardware (e.g., simple circuits, gates, logic, etc.). Circuit components may change over time. A circuit includes elements that, individually or in combination, can perform specified operations at operating time. For example, circuit hardware may be designed invariantly (e.g., hardwired) to perform a particular operation. For example, the hardware of a circuit may include variable-connected physical components (e.g., execution units, transistors, simple circuits, etc.), including a machine-readable medium, which can be modified to encode instructions for a particular operation (e.g., magnetic, electrical, movable arrangement of invariant mass particles, etc.).

[0219] When physical components are connected, the underlying electrical properties of the hardware components change, for example, from an insulator to a conductor, or vice versa. Instructions allow embedded hardware (e.g., an execution unit or load mechanism) to create components of circuits within the hardware through variable connections to execute specific parts of operation during operation. Thus, in the example, a machine-readable medium element is either part of a circuit or communicatively coupled to other parts of a circuit while the device is operating. For example, any of the physical components may be used in more than one component of more than one circuit. For example, during operation, an execution unit may be used in a first circuit of a first circuit configuration at one point in time, and then reused at another point in time by a second circuit within the first circuit configuration, or by a third circuit within the second circuit configuration. Further examples of these components relating to device 1200 are as follows:

[0220] In some aspects, device 1200 may operate as a standalone device or may be connected to other devices (e.g., networked). In a networked configuration, communication device 1200 may operate as a server communication device, a client communication device, or both in a server-client network environment. For example, communication device 1200 may operate as a peer communication device in a peer-to-peer (P2P) (or other distributed) network environment. Communication device 1200 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile phone, smartphone, web appliance, network router, switch or bridge, or any communication device capable of executing instructions that specify the actions to be performed by the communication device. Furthermore, although only a single communication device is represented, the term “communication device” should also be understood to include any set of communication devices that individually or together execute a set (or set) of instructions to perform one or more of the methods described herein, such as cloud computing, software-as-a-service (SaaS), and other computer cluster configurations.

[0221] The examples described herein may include, or operate on, logic or multiple components, modules, or mechanisms. A module is a tangible entity (e.g., hardware) capable of performing a specific operation and may be configured or arranged in a specific manner. In one example, a circuit may be arranged as a module in a specific manner (e.g., internally or relative to an external entity such as another circuit). In one example, all or part of one or more computer systems (e.g., standalone, client, or server computer systems), or one or more hardware processors, may be configured by firmware or software (e.g., instructions, application parts, or applications) as modules that operate to perform a specific operation. In one example, the software may reside on a communication device-readable medium. In one example, the software, when executed by the underlying hardware of the module, causes the hardware to perform a specific operation.

[0222] Accordingly, the term “module” is understood to encompass tangible entities, i.e., entities that are physically configured, specifically configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a particular way or to perform some or all of the operations described herein. Considering an example where a module is temporarily configured, each module does not need to be instantiated at any given point in time. For example, if a module has a general-purpose hardware processor configured using software, the general-purpose hardware processor may be configured as different modules at different points in time. The software, therefore, can configure the hardware processor to constitute one module at one point in time and another module at another.

[0223] The communication device (e.g., UE) 1200 may include a hardware processor 1202 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 1204, static memory 1206, and storage devices 1216 (e.g., a hardware drive, a tape drive, flash storage, or other block or storage devices), some or all of which may communicate with each other via an interlink 1208 (e.g., a bus).

[0224] The communication device 1200 may further include a display device 1210, an input device 1212 (e.g., a keyboard), and a user interface (UE) navigation device 1214 (e.g., a mouse). In one example, the display device 1210, the input device 1212, and the UE navigation device 1214 may be touchscreen displays. The communication device 1200 may further include a signal generating device 1218 (e.g., a speaker), a network interface device 1220, and one or more sensors 1221, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or other sensors. The communication device 1200 may also include an output controller 1228, such as a serial connection (e.g., Universal Serial Bus (USB)), a parallel connection, or other wired or wireless connection (e.g., infrared (IR), near-field communication (NFC)) for communicating with or controlling one or more peripheral devices (e.g., a printer, a card reader).

[0225] The storage device 1216 may include a device-readable medium 1222 that stores one or more sets of data structures or instructions 1224 (e.g., software) that embody or utilize one or more of the technologies or functions described herein. In some respects, the registers of the hardware processor 1202, the main memory 1204, the static memory 1206, and / or the storage device 1216 may (in whole or at least in part) be or include the device-readable medium 1222 that stores one or more sets of data structures or instructions 1224 that are embody or utilize one or more of the technologies or functions described herein. In one example, one or any combination of the hardware processor 1202, the main memory 1204, the static memory 1206, or the storage device 1216 may constitute the device-readable medium 1222.

[0226] As used herein, the term “device-readable medium” is interchangeable with “computer-readable medium” or “machine-readable medium.” Although device-readable medium 1222 is represented as a single medium, the term “communication device-readable medium” may include a single or multiple mediums configured to store instructions 1224 (e.g., a centralized or distributed database and / or associated caches and servers). The term “communication device-readable medium” includes the terms “machine-readable medium” or “computer-readable medium” and may include any medium that can store, encode, or carry instructions (e.g., instructions 1224) executed by communication device 1200, causing communication device 1200 to execute one or more of the technologies of this disclosure, or any medium that can store, encode, or carry data structures used by or associated with such instructions. Examples of non-limiting communication device-readable mediums include solid-state memory and optical and magnetic media. Specific examples of communication device-readable media 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 media, magneto-optical disks, random access memory (RAM), and CD-ROM and DVD-ROM disks. In some examples, communication device-readable media include non-temporary communication device-readable media. In some examples, communication device-readable media may include communication device-readable media that are not temporary propagating signals.

[0227] Instruction 1224 may also be transmitted or received via a communication network 1226 using a transmission medium, via a network interface device 1220 using one of several transport protocols. In one example, the network interface device 1220 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to the communication network 1226. In one example, the network interface device 1220 may include multiple antennas for wireless communication using one of the following technologies: single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO). In some examples, the network interface device 1220 may wirelessly communicate using multi-user MIMO technology.

[0228] The term “transmission medium” should be understood to include any intangible medium capable of storing, encoding, or carrying instructions executed by the communication device 1200, including digital or analog communication signals or other intangible mediums to facilitate the communication of such software. In this regard, the transmission medium in the context of this disclosure is a device-readable medium.

[0229] The terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” mean the same thing and may be used synonymously in this disclosure. The terms are defined to include both mechanical storage media and transmission media. Thus, the terms include both storage devices / mediums and carrier / modulated data signals.

[0230] The implementation described in the subject may include one or more features, either individually or in combination, as illustrated by example.

[0231] Example 1 is a device for a user device (UE) configured to operate as a target user device (UE) in a fifth-generation nu-radio (5G NR) network, Processing circuit and The processing circuit has a memory coupled to it, The processing circuit is configured to constitute the UE for sidelink-based positioning in the 5G NR network. Encode a discovery announcement message for broadcasting to multiple anchor UEs, and the discovery announcement message includes a sidelink positioning service code and the sidelink positioning function of the target UE. Decode the discovery response message received from one of the aforementioned multiple anchor UEs via the direct PC5 communication link established by that anchor UE, and the discovery response message indicates the sidelink positioning function of that anchor UE. Based on the fact that the sidelink positioning function of the anchor UE matches the sidelink positioning function of the target UE, the system is configured to initiate a positioning session with the anchor UE. The memory is configured to store the discovery response message. It is a device.

[0232] In Example 2, regarding the subject matter of Example 1, The processing circuit further encodes the discovery announcement message to indicate the function of the target UE, which calculates position information based on the side-link positioning reference signal (SL-PRS) measurement. The subject is included.

[0233] In Example 3, regarding the subject matter of Example 2, The processing circuit initiates the positioning session based on the discovery response message indicating the function of the anchor UE that matches the function of the target UE used to calculate the position information. The subject is included.

[0234] In Example 4, regarding the themes of Examples 1-3, The processing circuit encodes the discovery announcement message to further indicate the function of the target UE, which performs absolute or relative positioning calculations based on side-link positioning reference signal (SL-PRS) measurements. The subject is included.

[0235] In Example 5, regarding the subject matter of Example 4, The processing circuit initiates the positioning session based on the discovery response message indicating the function of the anchor UE that matches the function of the target UE performing the absolute positioning calculation or the relative positioning calculation. The subject is included.

[0236] In Example 6, regarding the themes of Examples 1-5, The processing circuit determines a set of anchor UEs from the plurality of anchor UEs based on the discovery announcement message, and determines that the set of anchor UEs is available for the positioning session with the target UE. The subject is included.

[0237] In Example 7, regarding the subject matter of Example 6, The processing circuit encodes a list including the sidelink positioning function of the target UE and the anchor UE for transmission to the 5G NR network's LMF server. The subject is included.

[0238] In Example 8, regarding the subject matter of Example 7, The aforementioned processing circuit is The response message from the LMF server is decoded, the response message indicates at least the second anchor UE in the set of anchor UEs, and the response message is based on the sidelink positioning function of the target UE. A second positioning session is initiated with at least the second anchor UE. The subject is included.

[0239] In Example 9, regarding the subject matter of Example 8, The response message is further based on the function of the target UE, which calculates position information based on side-link positioning reference signal (SL-PRS) measurement. The subject is included.

[0240] In Example 10, the themes of Examples 1-9 are: A transceiver circuit coupled to the processing circuit, The transceiver circuit includes two or more antennas coupled to it.

[0241] Example 11 stores instructions to be executed by one or more processors of a Location Management Function (LMF) node, the instructions being for configuring the LMF node for sidelink-based positioning in a fifth-generation new radio (5G NR) or later network, the LMF node, The process involves decoding a reception from a target user device (UE), wherein the reception includes a list containing a set of anchor UEs and the sidelink positioning function of the target UE. Encoding a response message for transmission to the target UE, wherein the response message indicates at least one anchor UE in the set of anchor UEs that establishes a positioning session with the target UE. Perform an action that includes It is a computer-readable storage medium.

[0242] In Example 12, regarding the subject matter of Example 11, The response message is further based on the function of the target UE, which calculates position information based on side-link positioning reference signal (SL-PRS) measurement. The subject is included.

[0243] Example 13 stores instructions to be executed by one or more processors of a user device (UE), the instructions being for configuring the UE as a target UE for sidelink-based positioning in a 5th generation NERadio (5G NR) or later network, the UE, The method involves encoding a discovery announcement message for broadcasting to multiple anchor UEs, wherein the discovery announcement message includes a sidelink positioning service code and the sidelink positioning capabilities of the target UE. The process involves decoding a discovery response message received from one of the aforementioned multiple anchor UEs via a direct PC5 communication link established by that anchor UE, wherein the discovery response message indicates the sidelink positioning function of that anchor UE. Based on the fact that the sidelink positioning function of the anchor UE matches the sidelink positioning function of the target UE, a positioning session with the anchor UE is initiated. Perform an action that includes It is a computer-readable storage medium.

[0244] In Example 14, the subject of Example 13 further includes the operation of encoding the discovery announcement message to further indicate the ability of the target UE to calculate location information based on side-link positioning reference signal (SL-PRS) measurements.

[0245] In Example 15, the subject of Example 14 further includes the operation of initiating the positioning session based on the discovery response message indicating the capabilities of the anchor UE that match the capabilities of the target UE that calculate the location information.

[0246] In Example 16, the subject matter of Examples 13–15 further includes the operation of encoding the discovery announcement message to further indicate the ability of the target UE to perform absolute or relative positioning calculations based on side-link positioning reference signal (SL-PRS) measurements.

[0247] In Example 17, the subject of Example 16 further includes the operation of initiating the positioning session based on the discovery response message indicating the capabilities of the anchor UE that match the capabilities of the target UE performing the absolute positioning calculation or the relative positioning calculation.

[0248] In Example 18, the subject of Examples 13-17 further includes determining a set of anchor UEs from the multiple anchor UEs based on the discovery announcement message, The operation includes making the set of anchor UEs available for the positioning session with the target UE.

[0249] In Example 19, the subject of Example 18 further includes an operation that encodes a list of pairs of the target UE and the anchor UE for transmission to a location management function (LMF) server of the 5G NR network.

[0250] In Example 20, the subject of Example 19 is to decode a response message from the LMF server, the response message indicating at least a second anchor UE in the set of anchor UEs, the response message being based on the sidelink positioning capabilities of the target UE, and the operation further includes initiating a second positioning session with at least the second anchor UE.

[0251] Example 21 is at least one machine-readable medium containing instructions that, when executed by a processing circuit, cause the processing circuit to perform an action that performs one of the actions in Examples 1 to 20.

[0252] Example 22 is an apparatus that includes means for carrying out any of Examples 1 to 20.

[0253] Example 23 is a system that implements any of Examples 1 through 20.

[0254] While specific illustrative aspects have been described, it is clear that various changes and modifications can be made to those aspects without departing from the broader scope of this disclosure. Therefore, the specification and drawings should be interpreted as illustrative rather than restrictive. Accordingly, this detailed description should not be taken as restrictive, and the scope of the various aspects, along with the entire scope of equivalences to which the attached claims are granted, is defined solely by those claims.

[0255] [Claiming priority] This application claims priority to U.S. Provisional Patent Application No. 63 / 493843, filed on April 3, 2023, with the title of the invention "ANCHOR USER EQUIPMENT DISCOVERY AND RESELECTION FOR SIDELINK BASED POSITIONING AND SENSING," the aforementioned U.S. Provisional Patent Application is incorporated herein by reference in its entirety.

Claims

1. A device for a user device (UE) configured to operate as a target user device (UE) in a fifth-generation nu-radio (5G NR) network, Processing circuit and The processing circuit has a memory coupled to it, The processing circuit is configured to configure the UE for side link base positioning in the 5G NR network. Encode a discovery announcement message for broadcasting to multiple anchor UEs, and the discovery announcement message includes a sidelink positioning service code and the sidelink positioning function of the target UE. From one of the aforementioned multiple anchor UEs, decode the discovery response message received via the direct PC5 communication link established by that anchor UE, and the discovery response message indicates the sidelink positioning function of that anchor UE. The system is configured to initiate a positioning session with the anchor UE based on the fact that the sidelink positioning function of the anchor UE matches the sidelink positioning function of the target UE. The memory is configured to store the discovery response message. Device.

2. The aforementioned processing circuit is The function of the target UE, which calculates position information based on side-link positioning reference signal (SL-PRS) measurement, further demonstrates the encoding of the discovery announcement message. The apparatus according to claim 1.

3. The aforementioned processing circuit is The positioning session is initiated based on the discovery response message indicating the function of the anchor UE that matches the function of the target UE used to calculate the location information. The apparatus according to claim 2.

4. The aforementioned processing circuit is The function of the target UE, which performs absolute or relative positioning calculations based on side-link positioning reference signal (SL-PRS) measurements, is further indicated by encoding the discovery announcement message. The apparatus according to claim 1.

5. The aforementioned processing circuit is The positioning session is initiated based on the discovery response message indicating the function of the anchor UE that matches the function of the target UE performing the absolute positioning calculation or the relative positioning calculation. The apparatus according to claim 4.

6. The aforementioned processing circuit is Based on the aforementioned discovery announcement message, a set of anchor UEs is determined from the plurality of anchor UEs. The set of anchor UEs is available for the positioning session with the target UE. The apparatus according to any one of claims 1 to 5.

7. The aforementioned processing circuit is For transmission to the Local Movement Function (LMF) server of the 5G NR network, a list including the sidelink positioning function of the target UE and the anchor UE is encoded. The apparatus according to claim 6.

8. The aforementioned processing circuit is The response message from the LMF server is decoded, the response message indicates at least the second anchor UE in the set of anchor UEs, and the response message is based on the sidelink positioning function of the target UE. A second positioning session is initiated with at least the second anchor UE. The apparatus according to claim 7.

9. The response message is further based on the function of the target UE, which calculates position information based on the measurement of the sidelink positioning reference signal (SL-PRS). The apparatus according to claim 8.

10. A transceiver circuit coupled to the processing circuit, The transceiver circuit further comprises two or more antennas coupled to it, The apparatus according to any one of claims 1 to 5.

11. It stores instructions to be executed by one or more processors of a Location Management Function (LMF) node, the instructions being instructions for configuring the LMF node for sidelink-based positioning in a fifth-generation nuradio (5G NR) or later network, and the LMF node, The process involves decoding a reception from a target user device (UE), wherein the reception includes a list containing a set of anchor UEs and the sidelink positioning function of the target UE. Encoding a response message for transmission to the target UE, wherein the response message indicates at least one anchor UE in the set of anchor UEs that establishes a positioning session with the target UE. Perform an action that includes Computer-readable storage medium.

12. The response message is further based on the function of the target UE, which calculates position information based on the measurement of the sidelink positioning reference signal (SL-PRS). The computer-readable storage medium according to claim 11.

13. It stores instructions to be executed by one or more processors of a user device (UE), the instructions being for configuring the UE as a target UE for sidelink-based positioning in a fifth-generation nuradio (5G NR) or later network, and the UE The method involves encoding a discovery announcement message for broadcasting to multiple anchor UEs, wherein the discovery announcement message includes a sidelink positioning service code and the sidelink positioning function of the target UE. The process involves decoding a discovery response message received from one of the aforementioned multiple anchor UEs via a direct PC5 communication link established by that anchor UE, wherein the discovery response message indicates the sidelink positioning function of that anchor UE. Based on the fact that the sidelink positioning function of the anchor UE matches the sidelink positioning function of the target UE, a positioning session with the anchor UE is initiated. Perform an action that includes Computer-readable storage medium.

14. The aforementioned operation is, The function of the target UE to calculate position information based on side-link positioning reference signal (SL-PRS) measurement further includes encoding the discovery announcement message to indicate the function of the target UE further. The computer-readable storage medium according to claim 13.

15. The aforementioned operation is, The positioning session is further initiated based on the discovery response message indicating the function of the anchor UE that matches the function of the target UE that calculates the location information. The computer-readable storage medium according to claim 14.

16. The aforementioned operation is, The further includes encoding the discovery announcement message to indicate the function of the target UE, which performs absolute or relative positioning calculations based on side-link positioning reference signal (SL-PRS) measurements. The computer-readable storage medium according to claim 13.

17. The aforementioned operation is, The positioning session is further initiated based on the discovery response message indicating the function of the anchor UE that matches the function of the target UE performing the absolute positioning calculation or the relative positioning calculation. The computer-readable storage medium according to claim 16.

18. The aforementioned operation is, The process further includes determining a set of anchor UEs from the plurality of anchor UEs based on the discovery announcement message, The set of anchor UEs is available for the positioning session with the target UE. A computer-readable storage medium according to any one of claims 13 to 17.

19. The aforementioned operation is, The further includes encoding a list containing the sidelink positioning function of the target UE and the anchor UE pair for transmission to the Local Management Function (LMF) server of the 5G NR network, The computer-readable storage medium according to claim 18.

20. The aforementioned operation is, The process involves decoding the response message from the LMF server, wherein the response message indicates at least the second anchor UE in the set of anchor UEs, and the response message is based on the sidelink positioning function of the target UE. Further including initiating a second positioning session with at least the second anchor UE, The computer-readable storage medium according to claim 19.

Images