[go: up one dir, main page]

WO2025059359A1 - Aspects de configuration de signal de référence de positionnement de liaison latérale (prs) - Google Patents

Aspects de configuration de signal de référence de positionnement de liaison latérale (prs) Download PDF

Info

Publication number
WO2025059359A1
WO2025059359A1 PCT/US2024/046467 US2024046467W WO2025059359A1 WO 2025059359 A1 WO2025059359 A1 WO 2025059359A1 US 2024046467 W US2024046467 W US 2024046467W WO 2025059359 A1 WO2025059359 A1 WO 2025059359A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
prs
ran
network
configuration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/US2024/046467
Other languages
English (en)
Inventor
Ansab ALI
Yi Guo
Debdeep CHATTERJEE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of WO2025059359A1 publication Critical patent/WO2025059359A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0048—Allocation of pilot signals, i.e. of signals known to the receiver
    • H04L5/0051—Allocation of pilot signals, i.e. of signals known to the receiver of dedicated pilots, i.e. pilots destined for a single user or terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0091—Signalling for the administration of the divided path, e.g. signalling of configuration information
    • H04L5/0094—Indication of how sub-channels of the path are allocated
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

  • FIG. IB and FIG. 1C illustrate a non-roaming 5G system architecture, in accordance with some aspects.
  • FIG. 7 illustrates an example RAN split architecture, in accordance with some aspects.
  • any of the UE 101 and UE 102 can include an Internet-of-Things (loT) UE or a Cellular loT (CIoT) UE, which can include a network access layer designed for low-power loT applications utilizing shortlived UE connections.
  • any of the UE 101 and UE 102 can include a narrowband (NB) loT UE (e.g., an enhanced NB-IoT (eNB-IoT) UE and Further Enhanced (FeNB-IoT) UE).
  • NB narrowband
  • eNB-IoT enhanced NB-IoT
  • FeNB-IoT Further Enhanced
  • the UE 101 and UE 102 utilize connections 103 and 104, respectively, each of which includes a physical communications interface or layer (discussed in further detail below); in this example, the connections 103 and 104 are illustrated as an air interface to enable communicative coupling and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3 GPP Long Term Evolution (LTE) protocol, a fifth-generation (5G) protocol, a New Radio (NR) protocol, and the like.
  • GSM Global System for Mobile Communications
  • CDMA code-division multiple access
  • PTT Push-to-Talk
  • POC PTT over Cellular
  • UMTS Universal Mobile Telecommunications System
  • LTE Long Term Evolution
  • 5G fifth-generation
  • NR New Radio
  • the RAN 110 may include one or more RAN nodes for providing macrocells, e.g., macro RAN nodes, and one or more RAN nodes for providing femtocells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells), e.g., low power (LP) RAN node or an unlicensed spectrum based secondary RAN node.
  • macro RAN nodes e.g., macro RAN nodes
  • femtocells or picocells e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells
  • LP low power
  • the RAN 110 is shown to be communicatively coupled to a core network (CN) 120 via an SI interface 113.
  • the CN 120 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN (e.g., as illustrated in FIGS. 1B-1C).
  • EPC evolved packet core
  • NPC NextGen Packet Core
  • the SI interface 113 is split into two parts: the Sl-U interface 114, which carries user traffic data between the communication nodes 111 and 112 and the serving gateway (S-GW) 122, and the SI -mobility management entity (MME) interface 115, which is a signaling interface between the communication nodes 111 and 112 and MMEs 121.
  • S-GW serving gateway
  • MME SI -mobility management entity
  • the CN 120 comprises the MMEs 121, the S-GW 122, the Packet Data Network (PDN) Gateway (P-GW) 123, and a home subscriber server (HSS) 124.
  • the MMEs 121 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN).
  • the MMEs 121 may manage mobility aspects in access, such as gateway selection and tracking area list management.
  • the HSS 124 may comprise a database for network users, including subscription-related information to support the network entities' handling of communication sessions.
  • the CN 120 may comprise one or several HSSs 124, depending on the number of mobile subscribers, the capacity of the equipment, the organization of the network, etc.
  • the HSS 124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.
  • the S-GW 122 may terminate the SI interface 113 towards the RAN 110 and route data packets between the RAN 110 and the CN 120.
  • the S-GW 122 may be a local mobility anchor point for inter-RAN node handovers and may also provide an anchor for inter-3GPP mobility.
  • Other responsibilities of the S-GW 122 may include lawful intercept, charging, and some policy enforcement.
  • the P-GW 123 may terminate an SGi interface toward a PDN.
  • the P-GW 123 may route data packets between the EPC network (e.g., CN 120) and external networks such as a network including the application server 184 (alternatively referred to as application function (AF)) via an Internet Protocol (IP) interface 125.
  • the P-GW 123 can also communicate data to other external networks 131 A, which can include the Internet, IP multimedia subsystem (IPS) network, and other networks.
  • the application server 184 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc.).
  • PS UMTS Packet Services
  • the P-GW 123 is shown to be communicatively coupled to an application server 184 via an IP interface 125.
  • the application server 184 can also be configured to support one or more communication services (e.g., Voice-over- Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc.) for the UE 101 and UE 102 via the CN 120.
  • VoIP Voice-over- Internet Protocol
  • the P-GW 123 may further be a node for policy enforcement and charging data collection.
  • Policy and Charging Rules Function (PCRF) 126 is the policy and charging control element of the CN 120.
  • PCRF Policy and Charging Rules Function
  • HPLMN Home Public Land Mobile Network
  • IP-CAN Internet Protocol Connectivity Access Network
  • PCRFs there may be two PCRFs associated with a UE's IP-CAN session: a Home PCRF (H-PCRF) within an HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN).
  • the PCRF 126 may be communicatively coupled to the application server 184 via the P-GW 123.
  • the communication network 140 A can be an loT network or a 5G network, including a 5G new radio network using communications in the licensed (5GNR) and the unlicensed (5G NR-U) spectrum.
  • NB-IoT narrowband loT
  • An NG system architecture can include the RAN 110 and a 5G core network (e.g., CN 120).
  • RAN 110 in an NG system can be referred to as NG- RAN.
  • the RAN 110 can include a plurality of nodes, such as gNBs and NG- eNBs.
  • the CN 120 (also referred to as a 5G core network or 5GC) can include an access and mobility function (AMF) and/or a user plane function (UPF).
  • the AMF and the UPF can be communicatively coupled to the gNBs and the NG- eNBs via NG interfaces. More specifically, in some aspects, the gNBs and the NG-eNBs can be connected to the AMF by NG-C interfaces and the UPF by NG-U interfaces.
  • the gNBs and the NG-eNBs can be coupled to each other via Xn interfaces.
  • FIG. IB illustrates a non-roaming 5G system architecture in accordance with some aspects.
  • a 5G system architecture 140B in a reference point representation. More specifically, UE 102 can be in communication with RAN 110 as well as one or more other 5G core (5GC) network entities.
  • 5GC 5G core
  • the 5G system architecture MOB includes a plurality of network functions (NFs), such as access and mobility management function (AMF) 132, location management function (LMF) 133, session management function (SMF) 136, policy control function (PCF) 148, application function (AF) 150, user plane function (UPF) 134, network slice selection function (NSSF) 142, authentication server function (AUSF) 144, and unified data management (UDM)/home subscriber server (HSS) 146.
  • the UPF 134 can provide a connection to a data network (DN) 152, which can include, for example, operator services, Internet access, or third-party services.
  • DN data network
  • the AMF 132 can be used to manage access control and mobility and can also include network slice selection functionality.
  • the SMF 136 can be configured to set up and manage various sessions according to network policy.
  • the UPF 134 can be deployed in one or more configurations according to the desired service type.
  • the PCF 148 can be configured to provide a policy framework using network slicing, mobility management, and roaming (similar to PCRF in a 4G communication system).
  • the UDM can be configured to store subscriber profiles and data (similar to an HSS in a 4G communication system).
  • the LMF 133 may be used in connection with 5G positioning functionalities.
  • LMF 133 receives measurements and assistance information from the RAN 110 and the mobile device (e.g., UE 101) via the AMF 132 over the NLs interface to compute the position of the UE 101.
  • NR positioning protocol A (NRPPa) may be used to carry the positioning information between NG-RAN and LMF 133 over a next-generation control plane interface (NG-C).
  • LMF 133 configures the UE using the LTE positioning protocol (LPP) via AMF 132.
  • the RAN 110 configures the UE 101 using radio resource control (RRC) protocol over LTE- Uu and NR-Uu interfaces.
  • RRC radio resource control
  • the 5G system architecture 140B configures different reference signals to enable positioning measurements.
  • Example reference signals that may be used for positioning measurements include the positioning reference signal (NR PRS) in the downlink and the sounding reference signal (SRS) for positioning in the uplink.
  • the downlink positioning reference signal (PRS) is a reference signal configured to support downlink-based positioning methods.
  • the 5G system architecture 140B includes an IP multimedia subsystem (IMS) 168B as well as a plurality of IP multimedia core network subsystem entities, such as call session control functions (CSCFs). More specifically, the IMS 168B includes a CSCF, which can act as a proxy CSCF (P-CSCF) 162BE, a serving CSCF (S-CSCF) 164B, an emergency CSCF (E-CSCF) (not illustrated in FIG. IB), or interrogating CSCF (LCSCF) 166B.
  • P-CSCF 162B can be configured to be the first contact point for the UE 102 within the IMS 168B.
  • the S-CSCF 164B can be configured to handle the session states in the network, and the E-CSCF can be configured to handle certain aspects of emergency sessions, such as routing an emergency request to the correct emergency center or PSAP.
  • the LCSCF 166B can be configured to function as the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator or a roaming subscriber currently located within that network operator's service area.
  • the I-CSCF 166B can be connected to another IP multimedia network 170, e.g., an IMS operated by a different network operator.
  • the UDM/HSS 146 can be coupled to an application server (AS) 160B, which can include a telephony application server (TAS) or another AS.
  • AS 160B can be coupled to the IMS 168B via the S-CSCF 164B or the I-CSCF 166B.
  • FIG. IB illustrates the following reference points: N1 (between the UE 102 and the AMF 132), N2 (between the RAN 110 and the AMF 132), N3 (between the RAN 110 and the UPF 134), N4 (between the SMF 136 and the UPF 134), N5 (between the PCF 148 and the AF 150, not shown), N6 (between the UPF 134 and the DN 152), N7 (between the SMF 136 and the PCF 148, not shown), N8 (between the UDM/HSS 146 and the AMF 132, not shown), N9 (between two UPFs, not shown), N10 (between the UDM/HSS 146 and the SMF 136, not shown), Ni l (between the AMF 132 and the SMF 136, not shown), N12 (between the AUSF 144 and the AMF 132, not shown), N13 (between the AUSF 144
  • FIG. 1C illustrates a 5G system architecture 140C and a service-based representation.
  • the 5G system architecture 140C can also include a network exposure function (NEF) 154 and a network repository function (NRF) 156.
  • NEF network exposure function
  • NRF network repository function
  • 5G system architectures can be service-based, and interaction between network functions can be represented by corresponding point-to-point reference points Ni or as service-based interfaces.
  • service-based representations can be used to represent network functions within the control plane that enable other authorized network functions to access their services.
  • 5G system architecture 140C can include the following servicebased interfaces: Namf 158H (a service-based interface exhibited by the AMF 132), Nsmf 1581 (a service-based interface exhibited by the SMF 136), Nnef 158B (a service-based interface exhibited by the NEF 154), Npcf 158D (a service-based interface exhibited by the PCF 148), a Nudm 158E (a servicebased interface exhibited by the UDM/HSS 146), Naf 158F (a service-based interface exhibited by the AF 150), Nnrf 158C (a service-based interface exhibited by the NRF 156), Nnssf 158A (a service-based interface exhibited by the NSSF 142), Nausf 158G (a service-based interface exhibited by the AU
  • FIG. 2 depicts an example network architecture 200.
  • the network architecture 200 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems and can implement the disclosed techniques (e.g., the disclosed techniques can be configured/implemented by one or more devices operating within the network architecture 200).
  • the example embodiments are not limited in this regard, and the described examples may apply to other networks that benefit from the principles described herein, such as future 3 GPP systems or the like.
  • the network architecture 200 includes a UE 202, which is any mobile or non-mobile computing device designed to communicate with a RAN 204 via an over-the-air connection.
  • the UE 202 is communicatively coupled with the RAN 204 by a Uu interface, which may be applicable to both LTE and NR systems.
  • Examples of the UE 202 include, but are not limited to, a smartphone, tablet computer, wearable device (e.g., smart watch, fitness tracker, smart glasses, smart clothing/fabrics, head-mounted displays, smart shows, and/or the like), desktop computer, workstation, laptop computer, in-vehicle infotainment system, in-car entertainment system, instrument cluster, head-up display (HUD) device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, machine-to-machine (M2M), device-to-device (D2D), machine-type communication (MTC) device, Internet of Things (loT) device, smart appliance, flying drone or unmanned aerial vehicle (UAV), terrestrial drone or autonomous vehicle, robot, electronic signage, single-board computer (SBC) (e.g., Raspberry Pi, iOS, Intel Edison, and the like
  • the UE 202 can be a reduced capability (RedCap) UE, which is a UE with reduced capabilities as specified in clause 4.2.21.1 in 3GPP TS 38.306 vl7.4.0 (2023-03-30) (“[TS38306]”).
  • RedCap reduced capability
  • the network architecture 200 may include a set of UEs 202 coupled directly with one another via a D2D, ProSe, PC5, and/or SL interface, and/or any other suitable interface such as any of those discussed herein.
  • These UEs 202 may be M2M/D2D/MTC/IoT devices and/or vehicular systems that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, and the like.
  • the UE 202 may perform blind decoding attempts of SL channel s/links according to the various examples herein.
  • the UE 202 may additionally communicate with an AP 206 via an over-the-air (OTA) connection.
  • the AP 206 manages a WLAN connection, which may serve to offload some/all network traffic from the RAN 204.
  • the connection between the UE 202 and the AP 206 may be consistent with any IEEE 802.11 protocol.
  • the UE 202, RAN 204, and AP 206 may utilize cellular- WLAN aggregation/integration (e.g., LWA/LWIP).
  • Cellular- WLAN aggregation may involve the UE 202 being configured by the RAN 204 to utilize both cellular radio resources and WLAN resources.
  • the RAN 204 includes one or more access network nodes (ANs) 208.
  • the ANs 208 terminate air interface (s) for the UE 202 by providing access to stratum protocols, including RRC, PDCP, RLC, MAC, and PHY/L1 protocols. In this manner, the AN 208 enables data/voice connectivity between CN 220 and the UE 202.
  • the ANs 208 may be a macrocell base station or a low-power base station for providing femtocells, picocells, or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells, or some combination thereof.
  • an AN 208 can be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, and the like.
  • a “CU/DU split” architecture where the ANs 208 are embodied as a gNB-Central Unit (CU) that is communicatively coupled with one or more gNB -Distributed Units (DUs), where each DU may be communicatively coupled with one or more Radio Units (RUs) (also referred to as RRHs, RRUs, or the like) (see e.g., [TS38401]).
  • RUs Radio Units
  • the one or more RUs may be individual RSUs.
  • the CU/DU split may include an ng-eNB-CU and one or more ng-eNB-DUs instead of, or in addition to, the gNB-CU and gNB-DUs, respectively.
  • the ANs 208 employed as the CU may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network including a virtual Base Band Unit (BBU) or BBU pool, cloud RAN (CRAN), Radio Equipment Controller (REC), Radio Cloud Center (RCC), centralized RAN (C-RAN), virtualized RAN (vRAN), and/or the like (although these terms may refer to different implementation concepts). Any other type of architecture, arrangements, and/or configurations can be used.
  • BBU Virtual Base Band Unit
  • CRAN cloud RAN
  • REC Radio Equipment Controller
  • RRCC Radio Cloud Center
  • C-RAN centralized RAN
  • vRAN virtualized RAN
  • the set of ANs may be coupled with one another via an X2 interface (if the RAN 204 is an LTE RAN or Evolved Universal Terrestrial Radio Access Network (E-UTRAN) 210) or an Xn interface (if the RAN 204 is an NG-RAN 214).
  • the X2/Xn interfaces which may be separated into control/user plane interfaces in some examples, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, and the like.
  • the ANs of the RAN 204 may each manage one or more cells, cell groups, component carriers, and the like to provide the UE 202 with an air interface for network access.
  • the UE 202 may be simultaneously connected with a set of cells provided by the same or different ANs 208 of the RAN 204.
  • the UE 202 and RAN 204 may use carrier aggregation to allow the UE 202 to connect with a set of component carriers, each corresponding to a Pcell or Scell.
  • a first AN 208 may be a master node that provides an MCG
  • a second AN 208 may be a secondary node that provides an SCG.
  • the first/second ANs 208 may be any combination of eNB, gNB, ng-eNB, and the like.
  • the RAN 204 may provide the air interface over a licensed spectrum or an unlicensed spectrum.
  • the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells.
  • the nodes Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen- before-talk (LBT) protocol.
  • LBT listen- before-talk
  • individual UEs 202 provide radio information to one or more ANs 208 and/or one or more edge compute nodes (e.g., edge servers/hosts and the like).
  • the radio information may be in the form of one or more measurement reports and may include, for example, signal strength measurements, signal quality measurements, and/or the like.
  • Each measurement report is tagged with a timestamp and the location of the measurement (e.g., the UEs 202 current location).
  • the measurements collected by the UEs 202 and/or included in the measurement reports may include one or more of the following: 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 ratio (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-plus-noise-plus-distortion to noise-plus-distortion (SINAD) ratio, carrier- to-interference plus noise ratio (CINR), Additive White Gaussian Noise (AWGN), energy per bit to noise power density ratio (Eb/NO), energy per chip to interference power density ratio (Ec/10), energy per chip to noise power density ratio (Ec/NO), peak-to-
  • the RSRP, RSSI, and/or RSRQ measurements may include RSRP, RSSI, and/or RSRQ measurements of cellspecific reference signals, channel state information reference signals (CSI-RS), and/or synchronization signals (SS) or SS blocks for 3GPP networks (e.g., LTE or 5G/NR), and RSRP, RSSI, RSRQ, RCPI, RSNI, and/or ANPI measurements of various beacon, Fast Initial Link Setup (FILS) discovery frames, or probe response frames for WLAN/WiFi (e.g., [IEEE80211]) networks.
  • CSI-RS channel state information reference signals
  • SS synchronization signals
  • 3GPP networks e.g., LTE or 5G/NR
  • measurements may be additionally or alternatively used, such as those discussed in 3GPP TS 36.214 vl7.0.0 (2022-03-31) (“[TS36214]”), 3GPP TS 38.215 V17.3.0 (2023-03-30) (“[TS38215]”), 3GPP TS 38.314 vl7.2.0 (2023-01-13) (“[TS38314]”), IEEE Standard for Information Technology- Telecommunications and Information Exchange between Systems - Local and Metropolitan Area Networks— Specific Requirements - Part 11 : Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, IEEE Std 802.11-2020, pp.1-4379 (26 Feb. 2021) (“[IEEE80211]”), and/or the like. Additionally or alternatively, any of the measurements above (or a combination of measurements) may be collected by one or more ANs 208 and provided to the edge compute node(s).
  • MAC Wireless LAN Medium Access Control
  • PHY Physical Layer
  • the measurements can include one or more of the following measurements: measurements related to Data Radio Bearer (DRB) (e.g., number of DRBs attempted to setup, number of DRBs successfully setup, number of released active DRBs, in-session activity time for DRB, number of DRBs attempted to be resumed, number of DRBs successfully resumed, and the like); measurements related to Radio Resource Control (RRC) (e.g., mean number of RRC connections, maximum number of RRC connections, mean number of stored inactive RRC connections, maximum number of stored inactive RRC connections, number of attempted, successful, and/or failed RRC connection establishments, and the like); measurements related to UE Context (UECNTX); measurements related to Radio Resource Utilization (RRU) (e.g., DL total PRB usage, UL total PRB usage, distribution of DL total PRB usage, distribution of UL total PRB usage, DL PRB used for data traffic, UL PRB used for data traffic, DL total available PRBs,
  • RRC Radio Resource Control
  • the radio information may be reported in response to a trigger event and/or on a periodic basis. Additionally or alternatively, individual UEs 202 report radio information either at a low periodicity or a high periodicity depending on a data transfer that is to take place and/or other information about the data transfer. Additionally or alternatively, the edge compute node(s) may request the measurements from the ANs 208 at low or high periodicity, or the ANs 208 may provide the measurements to the edge compute node(s) at low or high periodicity.
  • the edge compute node(s) may obtain other relevant data from other edge compute node(s), core network functions (NFs), application functions (AFs), and/or other UEs 202 such as Key Performance Indicators (KPIs), with the measurement reports or separately from the measurement reports.
  • NFs core network functions
  • AFs application functions
  • KPIs Key Performance Indicators
  • observation data from one or more UEs, one or more RAN nodes, and/or core network NFs may be performed to supplement the obtained observation data such as, for example, substituting values from previous reports and/or historical data, apply an extrapolation filter, and/or the like.
  • acceptable bounds for the observation data may be predetermined or configured. For example, CQI and MCS measurements may be configured to only be within ranges defined by suitable 3 GPP standards.
  • a reported data value may be dropped for the current learning/training episode or epoch.
  • delay bounds may be defined or configured, and packets determined to have been received after the packet delivery delay bound may be dropped.
  • the UE 202 can also perform determine reference signal (RS) measurement and reporting procedures to provide the network with information about the quality of one or more wireless channels and/or the communication media in general, and this information can be used to optimize various aspects of the communication system.
  • the measurement and reporting procedures performed by the UE 202 can include those discussed in 3GPP TS 38.211 V17.4.0 (2023-01-04) (“[TS38211]”), 3GPP TS 38.212 vl7.4.0 (2023-01- 04) (“[TS38212]”), 3GPP TS 38.213 vl7.4.0 (2023-01-04) (“[TS38213]”), 3GPP TS 38.214 vl7.4.0 (2023-01-04) (“[TS38214]”), [TS38215], 3GPP TS 38.101-1 V18.0.0 (2023-01-12) (“[TS38.101-1]”), 3GPP TS 38.104 vl8.0.0 (2023-01-10) (“[TS38104]”), 3GPP
  • the physical signals and/or Rscan include demodulation reference signals (DM-RS), phase-tracking reference signals (PT-RS), positioning reference signal (PRS), channel-state information reference signal (CSI-RS), synchronization signal block (SSB), primary synchronization signal (PSS), secondary synchronization signal (SSS), and sounding reference signal (SRS).
  • DM-RS demodulation reference signals
  • PT-RS phase-tracking reference signals
  • PRS positioning reference signal
  • CSI-RS channel-state information reference signal
  • SSB synchronization signal block
  • PSS primary synchronization signal
  • SSS secondary synchronization signal
  • SRS sounding reference signal
  • any suitable data collection and/or measurement mechanism(s) may be used to collect the observation data.
  • data marking e.g., sequence numbering and the like
  • packet tracing e.g., signal measurement
  • data sampling e.g., averaging
  • timestamping e.g., timestamping
  • the collection of data may be based on the occurrence of events that trigger the collection of the data. Additionally or alternatively, data collection may take place at the initiation or termination of an event.
  • the data collection can be continuous, discontinuous, and/or have start and stop times.
  • the UE 202 or AN 208 may be or act as a roadside unit (RSU), which may refer to any transportation infrastructure entity used for V2X communications.
  • RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE.
  • An RSU implemented in or by a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB- type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like.
  • an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs.
  • the PGW 232 routes data packets between the EPC 222 and the data network 236.
  • the PGW 232 is communicatively coupled with the SGW 226 by an S5 reference point to facilitate user plane tunneling and tunnel management.
  • the PGW 232 may further include a node for policy enforcement and charging data collection (e.g., PCEF).
  • the SGi reference point may communicatively couple the PGW 232 with the same or different data network 236.
  • the PGW 232 may be communicatively coupled with a PCRF 234 via a Gx reference point.
  • the PCRF 234 is the policy and charging control element of the EPC 222.
  • the PCRF 234 is communicatively coupled to the app/content server 238 to determine appropriate QoS and charging parameters for service flows.
  • SOEF service orchestration exposure function
  • the SOEF may be configured to expose service orchestration and chaining services to external users such as applications.
  • model training functional block 625 may be responsible for training and updating(re-training) AI/ML models.
  • the selected model may be trained using the fed-in datasets (including training, validation, and testing) from the training data selection/filtering functional block.
  • the model training functional block 625 may produce trained and tested AI/ML models that are ready for deployment.
  • the produced trained and tested models can be stored in a model repository 635.
  • Another such element may be an inference data selection/filtering element 650.
  • the inference data selection/filtering element 650 may be responsible for generating datasets for model inference at the inference functional block 645, as described below. Specifically, inference data may be extracted from the data repository 615. The inference data selection/filtering element 650 may select and/or filter the data based on the deployed AI/ML model. Data may be transformed/augmented/pre-processed following the same transformation/augmentation/pre-processing as those in training data selection/filtering as described with respect to functional block 620. The produced inference dataset may be fed into the inference functional block 645. [00138] Another such element may be the inference functional block 645.
  • FIG. 7 depicts example RAN split architecture aspects.
  • FIG. 7 shows an example network deployment including an example next generation fronthaul (NGF) deployment 700a where a UE 702 is connected to an RU 730 (also referred to as a “remote radio unit 730”, “a remote radio head 730”, or “RRH 730”) via an air interface, the RU 730 is connected to a Digital Unit (DU) 731 via a NGF interface (NGFI)-I, the DU 731 is connected to a Central Unit (CU) 732 via an NGFI-II, and the CU 732 is connected to a core network (CN) 742 via a backhaul interface.
  • NGF next generation fronthaul
  • the DU 731 may be a distributed unit (for purposes of the present disclosure, the term “DU” may refer to a digital unit and/or a distributed unit unless the context dictates otherwise).
  • UEs 702 may be the same or similar to UEs 202 and/or any other UE or user/client device discussed herein.
  • the NGF deployment 700a may be arranged in a distributed RAN (D-RAN) architecture where the CU 732, DU 731, and RU 730 reside at a cell site, and the CN 742 is located at a centralized site.
  • D-RAN distributed RAN
  • the NGF deployment 700a may be arranged in a centralized RAN (C-RAN) architecture with centralized processing of one or more baseband units (BBUs) at the centralized site.
  • BBUs baseband units
  • the radio components are split into discrete components, which can be located in different locations.
  • only the RU 730 is disposed at the cell site, and the DU 731, the CU 732, and the CN 742 are centralized or disposed at a central location.
  • the RU 730 and the DU 731 are located at the cell site, and the CU 732 and the CN 742 are at the centralized site.
  • only the RU 730 is disposed at the cell site, the DU 731 and the CU 732 are located at a RAN hub site, and the CN 742 is at the centralized site.
  • the CU 732 is a central controller that can serve or otherwise connect to one or multiple DUs 731 and/or multiple RUs 730.
  • the CU 732 is a network (logical) node hosting higher/upper layers of a network protocol functional split.
  • a CU 732 hosts the radio resource control (RRC), Service Data Adaptation Protocol (SDAP), and Packet Data Convergence Protocol (PDCP) layers of a nextgeneration NodeB (gNB), or hosts the RRC and PDCP protocol layers when included in or operating as an E-UTRA-NR gNB (en-gNB).
  • RRC radio resource control
  • SDAP Service Data Adaptation Protocol
  • PDCP Packet Data Convergence Protocol
  • gNB nextgeneration NodeB
  • en-gNB E-UTRA-NR gNB
  • the SDAP sublayer performs mapping between quality of service flows and data radio bearers (DRBs) and marking quality of service flow IDs (QFI) in both DL and UL packets.
  • the PDCP sublayer performs transfers user plane or control plane data; maintains PDCP sequence numbers (SNs); header compression and decompression using the Robust Header Compression (ROHC) and/or Ethernet Header Compression (EHC) protocols; ciphering and deciphering; integrity protection and integrity verification; provides timer based SDU discard; routing for split bearers; duplication and duplicate discarding; reordering and in-order delivery; and/or out-of-order delivery.
  • a CU 732 terminates respective Fl interfaces connected with corresponding DUs 731 (see, e.g., [TS38401]).
  • a CU 732 may include a CU-control plane (CP) entity (referred to herein as “CU-CP 732”) and a CU-user plane (UP) entity (referred to herein as “CU-UP 732”).
  • the CU-CP 732 is a logical node hosting the RRC layer and the control plane part of the PDCP protocol layer of the CU 732 (e.g., a gNB-CU for an en-gNB or a gNB).
  • the CU-CP terminates an El interface connected with the CU-UP, and the Fl-C interface is connected with a DU 731.
  • the DU 731 controls radio resources, such as time and frequency bands, locally in real time and allocates resources to one or more UEs.
  • the DUs 731 are network (logical) nodes hosting middle and/or lower layers of the network protocol functional split.
  • a DU 731 hosts the radio link control (RLC) medium access control (MAC), and high-physical (PHY) layers of the gNB or en-gNB, and its operation is at least partly controlled by the CU 732.
  • the RLC sublayer operates in one or more of a Transparent Mode (TM), Unacknowledged Mode (UM), and Acknowledged Mode (AM).
  • TM Transparent Mode
  • UM Unacknowledged Mode
  • AM Acknowledged Mode
  • the RLC sublayer performs transfer of upper layer PDUs; sequence numbering independent of the one in PDCP (UM and AM); error correction through ARQ (AM only); segmentation (AM and UM) and resegmentation (AM only) of RLC SDUs; reassembly of SDU (AM and UM); duplicate detection (AM only); RLC SDU discard (AM and UM); RLC reestablishment; 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 into/from transport blocks (TB) delivered to/from the physical layer on transport channels; scheduling information reporting; error correction through HARQ (one HARQ entity per cell in case of CA); priority handling between UEs by means of dynamic scheduling; priority handling between logical channels of one UE by means of logical channel prioritization; priority handling between overlapping resources of one UE; and/or padding.
  • HARQ one HARQ entity per cell in case of CA
  • a DU 731 can host a Backhaul Adaptation Protocol (BAP) layer (see e.g., 3GPP TS 38.340 V16.5.0 (2021-07-07)) and/or an Fl application protocol (F1AP) (see e.g., 3GPP TS 38.470 V16.5.0 (2021-07-01)), such as when the DU 731 is operating as an Integrated Access and Backhaul (IAB) node.
  • BAP Backhaul Adaptation Protocol
  • F1AP Fl application protocol
  • IAB Integrated Access and Backhaul
  • One DU 731 supports one or multiple cells, and one cell is supported by only one DU 731.
  • a DU 731 terminates the Fl interface connected with a CU 732.
  • the DU 731 may be connected to one or more RRHs/RUs 730.
  • the RU 730 is a transmission/reception point (TRP) or other physical node that handles radiofrequency (RF) processing functions.
  • the RU 730 is a network (logical) node hosting lower layers based on a lower-layer functional split.
  • the RU 730 hosts low-PHY layer functions and RF processing of the radio interface based on a lower layer functional split.
  • the RU 730 may be similar to 3GPP’s transmission/reception point (TRP) or RRH but specifically includes the Low- PHY layer. Examples of low-PHY functions include fast Fourier transform (FFT), inverse FFT (IFFT), physical random access channel (PRACH) extraction, and the like.
  • FFT fast Fourier transform
  • IFFT inverse FFT
  • PRACH physical random access channel
  • a fronthaul gateway function may be disposed between the DU 731 and the RU/RRU 730 (not shown by FIG. 7), where the interface between the DU 731 and the FHGW is an Open Fronthaul (e.g., Option 7-2x) interface, the interface between FHGW function and the RU/RRU 730 is an Open Fronthaul (e.g., Option 7-2x) interface or any other suitable interface (e.g., option 7, option 8, or the like) including those that do not support Open Fronthaul (e.g., Option 7-2x).
  • the FHGW may be packaged with one or more other functions (e.g., Ethernet switching and/or the like) in a physical device or appliance.
  • a RAN controller may be communicatively coupled with the CU 732 and/or the DU 731.
  • NGFI also referred to as “xHaul” or the like
  • NGFI is a two-level fronthaul architecture that separates the traditional RRU 730 to BBU connectivity in the C-RAN architecture into two levels, namely levels I and II.
  • Level I connects the RU 730 via the NGFI-I to the DU 731
  • level II connects the DU 731 via the NGFI-II to the CU 732, as shown by deployment 700a in FIG. 7.
  • the NGFI-I and NGFI-II connections may be wired connections or wireless connections, which may utilize any suitable RAT such as any of those discussed herein.
  • the purpose of the two-level architecture is to distribute (split) the RAN node protocol functions between CU 732 and DU 731 such that latencies are relaxed, giving more deployment flexibility.
  • the NGFI-I interfaces with the lower layers of the function split, which have stringent delay and data rate requirements.
  • NGFI-II interfaces with higher layers of the function split relative to the layers of the NGFI-I, relaxing the requirements for the fronthaul link.
  • Examples of the NGFI fronthaul interfaces and functional split architectures include 0-RAN 7.2x fronthaul (see e.g., [O-RAN.WG9.XPSAAS] and [O-RAN-WG4.CUS.0]), Enhanced Common Radio Interface (CPRI) based C-RAN fronthaul (see e.g., Common Public Radio Interface: eCPRI Interface Specification, eCPRI Specification v2.0 (2019-05-10), Common Public Radio Interface: Requirements for the eCPRI Transport Network, eCPRI Transport Network vl.2 (2018-06-25), and [O-RAN-WG4.CUS.0]), Radio over Ethernet (RoE) based C-RAN fronthaul (see, e.g., IEEE Standard for Radio over Ethernet Encapsulations and Mappings, IEEE Standards Association, IEEE 1914.3-2018 (05 Oct.
  • the deployment 700a may implement a low-level split (LLS) (also referred to as a “Lower Layer Functional Split 7-2x” or “Split Option 7-2x”) that runs between the RU 730 (e.g., an O-RU in O-RAN architectures) and the DU 731 (e.g., an O-DU in O-RAN architectures) (see, e.g., [O-RAN.WG7.IPC-HRD-Opt7-2], [O-RAN. WG7.0MAC-HRD], [O- RAN.WG7.OMC-HRD-Opt7-2], [O-RAN.WG7.OMC-HRD-Opt7-2]).
  • LLC low-level split
  • the NGFLI is the Open Fronthaul interface described in the O-RAN Open Fronthaul Specification (see, e.g., [O-RAN-WG4.CUS.0]).
  • Other LLS options may be used, such as the relevant interfaces described in other standards or specifications such as, for example, the 3 GPP NG-RAN functional split (see e.g., [TS38401] and 3GPP TR 38.801 vl4.0.0 (2017-04- 03)), the Small Cell Forum for Split Option 6 (see 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 (05 Jul.
  • 5G NR FR1 Reference Design The case for a common, modular architecture for 5G NR FR1 small cell distributed radio units, Small Cell Forum, document 251.10.01 (15 Dec. 2021) (“[SCF251]”), and [O- RAN.WG7.IPC-HRD-Opt6], the contents of each of which are hereby incorporated by reference in their entireties), and/or in O-RAN white-box hardware Split Option 8 (e.g., [O-RAN.WG7.IPC-HRD-Opt8]).
  • the CUs 732, DUs 731, and/or RUs 730 may be IAB nodes.
  • IAB enables wireless relaying in an NG-RAN where a relaying node (referred to as an “lAB-node”) supports access and backhauling via 3GPP 5G/new radio (NR) links/interfaces.
  • the terminating node of NR backhauling on the network side is referred to as an “lAB-donor,” which represents a RAN node (e.g., a gNB) with additional functionality to support IAB.
  • Backhauling can occur via a single or multiple hops.
  • IAB nodes that are connected to an lAB-donor via one or multiple hops form a directed acyclic graph (DAG) topology with the lAB-donor as its root.
  • DAG directed acyclic graph
  • the lAB-donor performs centralized resource, topology, and route management for the IAB topology.
  • the IAB architecture is shown and described in [TS38300],
  • the NGF deployment 700a shows the CU 732, DU 731, RRH 730, and CN 742 as separate entities, in other implementations, some or all of these network nodes can be bundled, combined, or otherwise integrated into a single device or element, including collapsing some internal interfaces (e.g., Fl- C, Fl-U, El, E2, and the like).
  • some internal interfaces e.g., Fl- C, Fl-U, El, E2, and the like.
  • any of the aforementioned example implementations involving the CU 732 may also include integrating the CU-CP 732 and CP -UP
  • FIG. 7 also shows an example RAN disaggregation deployment 700b (also referred to as “disaggregated RAN 700b”) where the UE 702 is connected to the RRH 730, and the RRH 730 is communicatively coupled with one or more of the RAN functions (RANFs) 1-N (where N is a number).
  • the RANFs 1-N are disaggregated and distributed geographically across several component segments and network nodes.
  • each RANF 1-N is a software (SW) element operated by a physical compute node
  • the RRH 730 includes radiofrequency (RF) circuitry (e.g., an RF propagation module for a particular RAT and/or the like).
  • RF radiofrequency
  • the RANF 1 is operated on a physical compute node that is co-located with the RRH 730, and the other RANFs are disposed at locations further away from the RRH 730.
  • CN 742 is also disaggregated into CN NFs 1-x (where x is a number) in the same or similar manner as the RANFs 1-N. However, in other implementations, the CN 742 is not disaggregated.
  • Network disaggregation involves the separation of networking equipment into functional components and allowing each component to be individually deployed. This may encompass the separation of SW elements (e.g., NFs) from specific HW elements and/or using APIs to enable software-defined network (SDN) and/or NF virtualization (NFV).
  • SW elements e.g., NFs
  • SDN software-defined network
  • NFV NF virtualization
  • RAN disaggregation involves network disaggregation and virtualization of various RANFs (e.g., RANFs 1-N in FIG. 7). The RANFs 1-N can be placed in different physical sites in various topologies in an RAN deployment based on the use case.
  • Disaggregation offers a common or uniform RAN platform capable of assuming a distinct profile depending on where it is deployed. This allows fewer fixed-function devices and a lower total cost of ownership in comparison with existing RAN architectures.
  • Example RAN disaggregation frameworks are provided by Telecom Infra Project (TIP) OpenRANTM, Cisco® Open vRANTM, [O-RAN], Open Optical & Packet Transport (OOPT), Reconfigurable Optical Add Drop Multiplexer (RO ADM), and/or the like.
  • TIP Telecom Infra Project
  • IP Telecom Infra Project
  • OOPT Open Optical & Packet Transport
  • RO ADM Reconfigurable Optical Add Drop Multiplexer
  • the RANFs 1-N disaggregate RAN HW and SW with commercial off-the-shelf (COTS) HW and open interfaces (e.g., NGFI-I and NGFI-II and the like).
  • COTS commercial off-the-shelf
  • each RANF 1-N may be a virtual BBU or vRAN controller operating on COTS compute infrastructure with HW acceleration for BBU/vRANFs.
  • the RANFs 1-N disaggregate layers of one or more RAT protocol stacks.
  • RANF l is a DU 731 operating on the first COTS compute infrastructure with HW acceleration for BBU/vRANFs
  • RANF 2 is a virtual CU 732 operating on the second COTS compute infrastructure.
  • the RANFs 1-N disaggregate control plane and user plane functions.
  • the RANF l is a DU 731 operating on COTS compute infrastructure with HW acceleration for BBU/vRANFs
  • RANF 2 is a virtual CU-CP 732 operating on COTS compute infrastructure
  • a third RANF e.g., RANF 3 (not shown by Figure 7)
  • RANF 3 is a virtual CU-UP 732 operating on the same or different COTS compute infrastructure as the virtual CU-CP 732.
  • one or more CN NFs 1-x may be CN-UP functions
  • one or more other CN NFs 1-x may be CN-CP functions.
  • the RANFs 1-N disaggregate layers of a [IEEE802] RAT.
  • the RRH 730 implements a WiFi PHY layer
  • RANF 1 implements a WiFi MAC sublayer
  • RANF 1 implements a WiFi logical link control (LLC) sublayer
  • RANF 2 implements one or more WiFi upper layer protocols (e.g., network layer, transport layer, session layer, presentation layer, and/or application layer), and so forth.
  • WiFi upper layer protocols e.g., network layer, transport layer, session layer, presentation layer, and/or application layer
  • the RANFs 1-N disaggregate different O-RAN RANFs, including E2SMs.
  • RANF 1 implements the near-RT RIC
  • RANF 2 implements the E2SM-KPM
  • RANF 3 implements the E2SM-CCC
  • RANF 4 implements the E2SM RAN control
  • RANF 5 implements the E2SM-NI
  • RANF 6 implements functions for providing Al services, and so forth.
  • the lower layers of the RAN protocol stack can be characterized by real-time (RT) functions and relatively complex signal processing algorithms, and the higher layers of the RAN protocol stack can be characterized by non-RT functions.
  • the RT functions and signal processing algorithms can be implemented in DUs 731 and/or RRHs 730 either using purpose-built network elements or in COTS hardware augmented with purpose-built HW accelerators.
  • FIG. 7 also shows various functional split options 700c for both DL and UL directions.
  • the traditional RAN is an integrated network architecture based on a distributed RAN (D-RAN) model, where D-RAN integrates all RANFs into a few network elements.
  • D-RAN distributed RAN
  • the disaggregated RAN architecture provides flexible function split options to overcome various drawbacks of the D-RAN model.
  • the disaggregated RAN breaks up the integrated network system into several function components that can then be individually re-located as needed without hindering their ability to work together to provide holistic network services.
  • the split options 700c are mostly split between the CU 732 and the DU 731 but can include a split between the CU 732, DU 731, and RU 730.
  • the Option 2 function split includes splitting non-RT processing (e.g., RRC and PDCP layers) from RT processing (e.g., RLC, MAC, and PHY layers), where the RANF implementing the CU 732 performs network functions of the RRC and PDCP layers, and the RANF implementing the DU 731 performs the baseband processing functions of the RLC (including high-RLC and low-RLC), MAC (including high-MAC and low-MAC), and PHY layers.
  • non-RT processing e.g., RRC and PDCP layers
  • RT processing e.g., RLC, MAC, and PHY layers
  • the RANF implementing the CU 732 performs network functions of the RRC and PDCP layers
  • the RANF implementing the DU 731 performs the baseband processing functions of the RLC (including high-RLC and low-RLC), MAC (including high-MAC and low-MAC), and PHY layers.
  • the PHY layer is further split between the DU 731 and the RU 730, where the RANF implementing the DU 731 performs the high-PHY layer functions, and the RU 730 handles the low-PHY layer functions.
  • the Low-PHY entity may be operated by the RU 730 regardless of the selected functional split option.
  • the RANF implementing the CU 732 can connect to multiple DU 731 (e.g., the CU 732 is centralized), which allows RRC and PDCP anchor change to be eliminated during a handover across DUs 731 and allows the centralized CU 732 to pool resources across several DUs 731. In these ways, the option 2 function split can improve resource efficiencies.
  • each protocol stack entity is operated by a respective RANF (e.g., a first RANF operates the RRC layer, a second RANF operates the PDCP layer, a third RANF operates the high-RLC layer, and so forth until an eighth RANF operates the low-PHY layer).
  • a respective RANF e.g., a first RANF operates the RRC layer, a second RANF operates the PDCP layer, a third RANF operates the high-RLC layer, and so forth until an eighth RANF operates the low-PHY layer.
  • At least one of the components outlined in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as discussed herein (including the examples listed in the examples sections below).
  • baseband circuitry associated with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below.
  • circuitry associated with a UE, base station, satellite, network element, etc., as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.
  • the term “application” may refer to a complete and deployable package or environment to achieve a specific function in an operational environment.
  • AI/ML application or the like may be an application that contains some artificial intelligence (AI)/machine learning (ML) models and application-level descriptions. In some embodiments, an AI/ML application may be used to configure or implement one or more of the disclosed aspects.
  • machine learning or “ML” refers to the use of computer systems implementing algorithms and/or statistical models to perform a specific task(s) without using explicit instructions but instead relying on patterns and inferences.
  • ML algorithms build or estimate mathematical model(s) (referred to as “ML models” or the like) based on sample data (referred to as “training data,” “model training information,” or the like) to make predictions or decisions without being explicitly programmed to perform such tasks.
  • ML algorithm is a computer program that learns from experience concerning some task and some performance measure, and an ML model may be any object or data structure created after an ML algorithm is trained with one or more training datasets. After training, an ML model may be used to make predictions on new datasets.
  • ML algorithm refers to concepts different from the term “ML model,” these terms, as discussed herein, may be used interchangeably for the present disclosure.
  • ML model may also refer to ML methods and concepts used by an ML-assisted solution.
  • An “ML-assisted solution” is a solution that addresses a specific use case using ML algorithms during operation.
  • ML models include supervised learning (e.g., linear regression, k-nearest neighbor (KNN), decision tree algorithms, support machine vectors, Bayesian algorithm, ensemble algorithms, etc.), unsupervised learning (e.g., K-means clustering, principal component analysis (PCA), etc.), reinforcement learning (e.g., Q-learning, multi-armed bandit learning, deep RL, etc.), neural networks, and the like.
  • ML pipeline is a set of functionalities, functions, or functional entities specific to an ML- assisted solution; an ML pipeline may include one or several data sources in a data pipeline, a model training pipeline, a model evaluation pipeline, and an actor.
  • the “actor” is an entity that hosts an ML-assisted solution using the output of the ML model inference).
  • ML training host refers to an entity, such as a network function, that hosts the training of the model.
  • ML inference host refers to an entity, such as a network function, that hosts the model during inference mode (which includes both the model execution and any online learning, if applicable).
  • the ML host informs the actor about the output of the ML algorithm, and the actor decides on an action (an “action” is performed by an actor as a result of the output of an ML-assisted solution).
  • model inference information refers to information used as an input to the ML model for determining inference(s); the data used to train an ML model and the data used to determine inferences may overlap, however, “training data” and “inference data” refer to different concepts.
  • the present disclosure defines or otherwise provides sidelink (SL) PRS configurations.
  • the following discussion may be applicable to any type of UE or base station, such as any of the UEs or base stations in FIGS. 1 A-8.
  • the solutions developed in this IDF specify detailed RRC and sidelink positioning protocol (SLPP) signalling to enable configuration of cell-specific and UE-specific SL-PRS resource pool configuration as well as NR SL PRS measurement reporting to enable accurate location estimation using the sidelink interface.
  • SLPP sidelink positioning protocol
  • the fundamental procedure for sidelink positioning borrows from the legacy positioning framework quite heavily, with the basic procedure involving performing measurements on a reference signal (PRS) and location calculation (either locally or by forwarding to the LMF).
  • PRS reference signal
  • the sequence is termed SL-PRS (Sidelink Positioning Reference Signal) and the SL UE needs to be provided with the necessary configuration to be able to successfully perform SL-PRS transmission on the appropriate resources, perform measurements and (optionally) perform location computation.
  • SL-PRS Segment Positioning Reference Signal
  • the key difference from the case of legacy Uu based positioning is that the nodes performing SL-PRS transmission and those performing measurements can be sidelink UEs which may be completely outside of network coverage. Therefore, unlike the Uu case, how to provide and coordinate the configuration information across these UEs is an open issue, which we address in this IDF.
  • the UE may be configured with dedicated and/or shared resource pools for transmission of SL-PRS (shared with resource pools used for non-positioning related SL communication).
  • SL-PRS shared with resource pools used for non-positioning related SL communication.
  • new configuration needs to be defined to provide to the SL UE the necessary set of parameters for SL-PRS transmission.
  • one embodiment is to reuse the existing SL-ResourcePool IE to indicate the corresponding signaling for SL-PRS dedicated resource pools. This can be done by including the SL-PRS related configuration within the UE- specific SL BWP configuration RRC information element for a given sidelink frequency as exemplified below in Table 1.
  • Table 2 shows the corresponding cell-specific RRC signaling configuration.
  • the IE SL-BWP-PRSPoolConfig information element (shown in Table 3 below) is used to configure a UE-specific NR sidelink PRS dedicated resource pool. TABLE 3
  • the IE SL-BWP-PRSPoolConfigCommon (listed in Table 5 below) is used to configure the cell-specific NR sidelink PRS dedicated resource pool.
  • a new RRC IE can be defined for the dedicated resource pool which mimics the configuration for the shared resource pool to carry this configuration.
  • the detailed configuration is exemplified below in Table 6.
  • the above IE contains the set of parameters expected by the TX UE to determine the time frequency resource to be used for SL-PRS transmission as well as other parameters related to power control and channel congestion which impact the SL-PRS transmission.
  • the above set of SL-PRS related parameters can be incorporated within the existing SL-ResourcePool IE alongside a toggle which indicates if this configuration is for a shared resource pool or a dedicated pool for SL-PRS.
  • the other set of parameters which related to the NR SL positioning measurement reporting also need to be provided to the TX and RX UE in order to perform location estimation.
  • the parameters related to different positioning methods that may be supported for SL positioning e.g. SL-AoA, SL-RTT, etc.
  • this node is usually the LMF and so LPP signaling is used to provide this information from the UE to the LMF (i.e. via Location Information Transfer procedure).
  • LPP signaling is used to provide this information from the UE to the LMF (i.e. via Location Information Transfer procedure).
  • the same principle can be applied by using the newly defined SLPP signaling to transfer the measurement related parameters to the LMF/server UE via the Location Information Transfer procedure.
  • the parameters can be divided into two different sets:
  • the provide location information IE (CommonlEsProvideLocationlnformation) is listed in Table 8 below.
  • NR-SL-RSTD-SignalMeasurementlnformation is listed in Table 16 below. TABLE 16 [00191]
  • the above parameters can be carried via RRC signaling as well. Since the focus in this release is on unicast operation with a single target UE, it can be assumed that there exists a unicast connection between the target UE and the server UE. Therefore, SL RRC signaling can be defined and used to transfer the set of measurement related parameters to the peer UE.
  • the configuration of these parameters can follow legacy SL methodology, i.e. when under network coverage, the UE may be provided with this configuration via (a) Common configuration via SIB, or (b) Dedicated signaling via RRC.
  • the SL-PRS dedicated pool configuration may be bundled together with the SL communication pool configuration or it may be configured separately in a different SIB.
  • the UE needs to be RRC CONNECTED mode and may request dedicated SL-PRS configuration for a given resource pool via SidelinkUEInformation or UEAssistancelnformation framework.
  • the NW may provide the SL-PRS configuration for a particular SL carrier frequency (e.g. as part of the SL-FreqConfigCommon IE) that the UE is interested in performing SL-PRS transmission on.
  • a particular SL carrier frequency e.g. as part of the SL-FreqConfigCommon IE
  • some of the parameters may be configured via SIB and/or dedicated signaling while the others may be configured via preconfiguration.
  • some of the parameters related to power control may not need to be updated dynamically and can be statically configured via pre-configuration while other parameters which need to be updated frequently can be configured via SIB/dedicated signaling.
  • the present disclosure outlines the signaling design to enable configuration of SL-PRS related parameters essential to perform SL-PRS transmission and measurement reporting for accurate location estimation.
  • existing RRC signaling for SL resource pool configuration is repurposed and reused to signal SL-PRS related parameters from the network/gNB to the UE.
  • new RRC signaling is defined to carry the SL-PRS related parameters via a new information element (SL-POS-ResourcePool).
  • the parameters for SL measurement are reported using newly defined SLPP protocol over the sidelink interface from the UE to the LMF and/or server UE for location estimation.
  • signaling is defined to split parameters into two groups: a common part (which is applicable for all positioning methods) and a specific part (which is specific for a given positioning method).
  • RRC signaling is used instead of SLPP to signal the measurement reporting related parameters to the LMF/server UE.
  • SL-PRS related parameters may be configured via SIB signaling to UEs in RRC IDLE or RRC INACTIVE and via dedicated RRC signaling from gNB for UEs in RRC CONNECTED. For UEs out of network coverage, this configuration is provided via pre-configuration.
  • FIG. 8 illustrates a block diagram of a communication device such as an evolved Node-B (eNB), a new generation Node-B (gNB) (or another RAN node such as a base station), a network-controlled repeater (NCR), an access point (AP), a wireless station (STA), a mobile station (MS), or user equipment (UE), in accordance with some aspects and to perform one or more of the techniques disclosed herein.
  • the communication device 800 may operate as a standalone device or may be connected (e.g., networked) to other communication devices.
  • Circuitry e.g., processing circuitry
  • circuitry is a collection of circuits implemented in tangible entities of the device 800 that include hardware (e.g., simple circuits, gates, logic, etc.). Circuitry membership may be flexible over time. Circuitries include members that may, alone or in combination, perform specified operations when operating.
  • the circuitry hardware may be immutably designed to carry out a specific operation (e.g., hardwired).
  • the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.), including a machine-readable medium physically modified (e.g., magnetically, electrically, moveable placement of invariant massed particles, etc.) to encode instructions of the specific operation.
  • the underlying electrical properties of a hardware constituent are changed, for example, from an insulator to a conductor or vice versa.
  • the instructions enable embedded hardware (e.g., the execution units or a loading mechanism) to create members of the circuitry in hardware via the variable connections to carry out portions of the specific operation when in operation.
  • the machine-readable medium elements are part of the circuitry or are communicatively coupled to the other components of the circuitry when the device is operating.
  • any of the physical components may be used in more than one member of more than one circuitry.
  • execution units may be used in the first circuit of a first circuitry at one point in time and reused by a second circuit in the first circuitry or by a third circuit in a second circuitry at a different time. Additional examples of these components with respect to the device 800 follow.
  • the device 800 may operate as a standalone device or may be connected (e.g., networked) to other devices.
  • the communication device 800 may operate in the capacity of a server communication device, a client communication device, or both in serverclient network environments.
  • the communication device 800 may act as a peer communication device in a peer-to-peer (P2P) (or other distributed) network environment.
  • P2P peer-to-peer
  • the communication device 800 may be a UE, eNB, PC, tablet PC, STB, PDA, mobile telephone, smartphone, a web appliance, network router, a switch or bridge, or any communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by that communication device.
  • communication device shall also be taken to include any collection of communication devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), and other computer cluster configurations.
  • cloud computing software as a service
  • SaaS software as a service
  • Examples, as described herein, may include, or may operate on, logic or several components, modules, or mechanisms.
  • Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a particular manner.
  • circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module.
  • the whole or part of one or more computer systems e.g., a standalone, client, or server computer system
  • one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations.
  • the software may reside on a communication device-readable medium.
  • the software when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
  • module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein.
  • each of the modules needs not to be instantiated at any one moment in time.
  • the modules comprise a general- purpose hardware processor configured using the software
  • the general-purpose hardware processor may be configured as respective different modules at different times.
  • the software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.
  • the communication device 800 may include a hardware processor 802 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 804, a static memory 806, and a storage device 816 (e.g., hard drive, tape drive, flash storage, or other block or storage devices), some or all of which may communicate with each other via an interlink 808 (e.g., a bus).
  • a hardware processor 802 e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof
  • main memory 804 e.g., a main memory 804, a static memory 806, and a storage device 816 (e.g., hard drive, tape drive, flash storage, or other block or storage devices), some or all of which may communicate with each other via an interlink 808 (e.g., a bus).
  • an interlink 808 e.g., a bus
  • the communication device 800 may further include a display device 810, an input device 812 (e.g., a keyboard), and a user interface (UI) navigation device 814 (e.g., a mouse).
  • the display device 810, input device 812, and UI navigation device 814 may be a touchscreen display.
  • the communication device 800 may additionally include a signal generation device 818 (e.g., a speaker), a network interface device 820, and one or more sensors 821, such as a global positioning system (GPS) sensor, compass, accelerometer, or another sensor.
  • GPS global positioning system
  • the communication device 800 may include an output controller 828, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • a serial e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • USB universal serial bus
  • IR infrared
  • NFC near field communication
  • the storage device 816 may include a device-readable medium 822, on which is stored one or more sets of data structures or instructions 824 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein.
  • registers of the hardware processor 802, the main memory 804, the static memory 806, and/or the storage device 816 may be, or include (entirely or at least partially), the device-readable medium
  • the hardware processor 802 the main memory 804, the static memory 806, or the storage device 816 may constitute the device-readable medium 822.
  • the term “device-readable medium” is interchangeable with “computer-readable medium” or “machine-readable medium.” While the device-readable medium 822 is illustrated as a single medium, the term “communication device-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database and/or associated caches and servers) configured to store the instructions 824.
  • communication device-readable medium is inclusive of the terms “machine- readable medium” or “computer-readable medium” and may include any medium that is capable of storing, encoding, or carrying instructions (e.g., instructions 824) for execution by the communication device 800 and that causes the communication device 800 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions.
  • Non-limiting communication device-readable medium examples may include solid-state memories and optical and magnetic media.
  • communication device-readable media may include non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; Random Access Memory (RAM); and CD-ROM and DVD-ROM disks.
  • EPROM Electrically Programmable Read-Only Memory
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • flash memory devices e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)
  • flash memory devices e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)
  • flash memory devices e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM
  • Instructions 824 may further be transmitted or received over a communications network 826 using a transmission medium via the network interface device 820 utilizing any one of several transfer protocols.
  • the network interface device 820 may include one or more physical jacks (e.g., Ethernet, coaxial, or phonejacks) or one or more antennas to connect to the communications network 826.
  • the network interface device 820 may include a plurality of antennas to wirelessly communicate using at least one of the single-input-multiple-output (SIMO), MIMO, or multiple- input-single-output (MISO) techniques.
  • SIMO single-input-multiple-output
  • MIMO single-input-multiple-output
  • MISO multiple- input-single-output
  • the network interface device 820 may wirelessly communicate using Multiple User MIMO techniques.
  • transmission medium shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 800 and includes digital or analog communications signals or another intangible medium to facilitate communication of such software.
  • a transmission medium in the context of this disclosure is a device-readable medium.
  • machine-readable medium means the same thing and may be used interchangeably in this disclosure.
  • the terms are defined to include both machine-storage media and transmission media.
  • the terms include both storage devices/media and carrier waves/modulated data signals.
  • Example 1 is an apparatus for a user equipment (UE) configured for operation in a Fifth Generation New Radio (5G NR) network, the apparatus comprising: processing circuitry, wherein to configure the UE for sidelink (SL) positioning operation in the 5G NR network, the processing circuitry is to: decode radio resource control (RRC) signaling received from a base station, the RRC signaling including an information element (IE) with a resource pool configuration; select a first resource based on autonomous UE resource selection using the resource pool configuration; and encode a first SL positioning reference signal (PRS) for transmission to another UE using the first resource; and a memory coupled to the processing circuitry and configured to store the configuration signaling.
  • RRC radio resource control
  • IE information element
  • PRS first SL positioning reference signal
  • Example 2 the subject matter of Example 1 includes, wherein the RRC signaling is a SL-BWP-Config information element.
  • Example 3 the subject matter of Example 2 includes, wherein the IE is a SL-BWP-PRSPoolConfig IE.
  • Example 4 the subject matter of Examples 1-3 includes, wherein the processing circuitry is to: detect an SL PRS resource configuration for SL PRS transmission in the IE.
  • Example 5 the subject matter of Example 4 includes, wherein the processing circuitry is to: select the first resource based on the SL PRS resource configuration for SL PRS transmission.
  • Example 6 the subject matter of Examples 4-5 includes, wherein the SL PRS resource configuration for SL PRS transmission in the IE is an SL- PRSTxPool Selected configuration.
  • Example 7 the subject matter of Examples 4-6 includes, wherein the processing circuitry is to: select a second resource based on the SL PRS resource configuration for SL PRS transmission; and encode a second SL PRS for transmission to the another UE using the second resource, based on a network selection of the second resource.
  • Example 8 the subject matter of Example 7 includes, wherein the SL PRS resource configuration for SL PRS transmission in the IE is an SL- PRSTxPool Scheduling configuration.
  • Example 9 the subject matter of Examples 4-8 includes, wherein the processing circuitry is to: select a second resource based on a second SL PRS resource configuration for SL PRS reception in the IE; and decode a second SL PRS received from the another UE using the second resource, based on a network selection of the second resource.
  • Example 10 the subject matter of Examples 1-9 includes, transceiver circuitry coupled to the processing circuitry; and two or more antennas coupled to the transceiver circuitry.
  • Example 11 is a computer-readable storage medium that stores instructions for execution by one or more processors of a base station, the instructions to configure the base station for sidelink (SL) positioning operation in a Fifth Generation New Radio (5GNR) and beyond network, and to cause the base station to perform operations comprising: encoding radio resource control (RRC) signaling for communication to a user equipment (UE), the RRC signaling including an information element (IE) with a resource pool configuration, the IE comprising an SL PRS resource configuration for SL PRS transmission, and the SL PRS resource configuration for SL PRS transmission in the IE is an SL-PRSTxPool Selected configuration.
  • RRC radio resource control
  • Example 12 the subject matter of Example 11 includes, wherein the RRC signaling is a SL-BWP-Config information element.
  • Example 13 is a computer-readable storage medium that stores instructions for execution by one or more processors of a user equipment (UE), the instructions to configure the UE for sidelink (SL) positioning operation in a Fifth Generation New Radio (5GNR) and beyond network, and to cause the UE to perform operations comprising: decoding radio resource control (RRC) signaling received from a base station, the RRC signaling including an information element (IE) with a resource pool configuration; selecting a first resource based on autonomous UE resource selection using the resource pool configuration; and encoding a first SL positioning reference signal (PRS) for transmission to another UE using the first resource.
  • RRC radio resource control
  • IE information element
  • PRS SL positioning reference signal
  • Example 14 the subject matter of Example 13 includes, wherein the RRC signaling is a SL-BWP-Config information element.
  • Example 15 the subject matter of Example 14 includes, wherein the IE is a SL-BWP-PRSPoolConfig IE.
  • Example 16 the subject matter of Examples 13-15 includes, the operations comprising: detecting an SL PRS resource configuration for SL PRS transmission in the IE.
  • Example 17 the subject matter of Example 16 includes, the operations comprising: selecting the first resource based on the SL PRS resource configuration for SL PRS transmission.
  • Example 18 the subject matter of Examples 16-17 includes, wherein the SL PRS resource configuration for SL PRS transmission in the IE is an SL-PRSTxPool Selected configuration.
  • Example 19 the subject matter of Examples 16-18 includes, the operations comprising: selecting a second resource based on the SL PRS resource configuration for SL PRS transmission; and encoding a second SL PRS for transmission to the another UE using the second resource, based on a network selection of the second resource.
  • Example 20 the subject matter of Example 19 includes, wherein the SL PRS resource configuration for SL PRS transmission in the IE is an SL- PRSTxPool Scheduling configuration.
  • Example 21 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-20.
  • Example 22 is an apparatus comprising means to implement any of Examples 1-20.
  • Example 23 is a system to implement any of Examples 1-20.
  • Example 24 is a method to implement any of Examples 1-20.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Un appareil d'un UE configuré pour fonctionner dans un réseau 5G NR comprend un circuit de traitement couplé à une mémoire. Pour configurer l'UE pour une opération de positionnement SL dans le réseau 5G NR, le circuit de traitement est destiné à décoder une signalisation RRC comprenant un élément d'informations (IE) avec une configuration de groupe de ressources. Une première ressource est sélectionnée sur la base d'une sélection de ressource d'UE autonome à l'aide de la configuration de groupe de ressources. Un premier PRS SL est codé pour une transmission à un autre UE à l'aide de la première ressource.
PCT/US2024/046467 2023-09-15 2024-09-12 Aspects de configuration de signal de référence de positionnement de liaison latérale (prs) Pending WO2025059359A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202363583200P 2023-09-15 2023-09-15
US63/583,200 2023-09-15

Publications (1)

Publication Number Publication Date
WO2025059359A1 true WO2025059359A1 (fr) 2025-03-20

Family

ID=95021924

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2024/046467 Pending WO2025059359A1 (fr) 2023-09-15 2024-09-12 Aspects de configuration de signal de référence de positionnement de liaison latérale (prs)

Country Status (1)

Country Link
WO (1) WO2025059359A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210234650A1 (en) * 2019-04-12 2021-07-29 Iucf-Hyu (Industry-University Cooperation Foundation Hanyang University) Method and device for transmitting and receiving reference signal for positioning
US20230164511A1 (en) * 2021-11-23 2023-05-25 Qualcomm Incorporated User equipment based positioning
US20230283991A1 (en) * 2020-06-02 2023-09-07 Qualcomm Incorporated Improving sidelink positioning via messaging between wireless nodes

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210234650A1 (en) * 2019-04-12 2021-07-29 Iucf-Hyu (Industry-University Cooperation Foundation Hanyang University) Method and device for transmitting and receiving reference signal for positioning
US20230283991A1 (en) * 2020-06-02 2023-09-07 Qualcomm Incorporated Improving sidelink positioning via messaging between wireless nodes
US20230164511A1 (en) * 2021-11-23 2023-05-25 Qualcomm Incorporated User equipment based positioning

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FLORENT MUNIER, ERICSSON: "Resource allocation for SL positioning reference signal", 3GPP DRAFT; R1-2305831; TYPE DISCUSSION; NR_POS_ENH2-CORE, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG1, no. Incheon, KR; 20230522 - 20230526, 15 May 2023 (2023-05-15), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052311259 *
JIANG CHUANGXIN, ZTE: "Discussion on resource allocation for SL positioning reference signal", 3GPP DRAFT; R1-2300804; TYPE DISCUSSION; NR_POS_ENH2-CORE, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, vol. RAN WG1, no. Athens, GR; 20230227 - 20230303, 17 February 2023 (2023-02-17), Mobile Competence Centre ; 650, route des Lucioles ; F-06921 Sophia-Antipolis Cedex ; France, XP052247949 *

Similar Documents

Publication Publication Date Title
US11917527B2 (en) Resource allocation and activation/deactivation configuration of open radio access network (O-RAN) network slice subnets
EP3869847B1 (fr) Gestion de trafic multi-accès dans ran ouvert, o-ran
JP2024529832A (ja) アップリンク・フル・パワー送信のためのパワー・スケーリング
US20240284386A1 (en) New radio (nr) positioning measurement with reduced latency
WO2023018897A1 (fr) Mesures de retard entre gnb-cu et gnb-du
WO2025014819A1 (fr) Procédés et agencements pour un cadre d'applications de système
JP7735626B2 (ja) 無線ネットワークにおけるマルチｔｒｐ動作用のビームマネジメント
US20250274744A1 (en) User equipment (ue)-side applicable functionality reporting and management
WO2025059359A1 (fr) Aspects de configuration de signal de référence de positionnement de liaison latérale (prs)
WO2025212438A1 (fr) Fourniture d'informations d'association pour positionnement en liaison latérale
WO2025035080A1 (fr) Différence de synchronisation de réception maximale pour réceptions à panneaux multiples
WO2024211389A1 (fr) Découverte et resélection d'ue d'ancrage pour des communications de liaison latérale
WO2024211739A1 (fr) Configurations de positionnement de phase de porteuse
WO2025174443A1 (fr) Commande de puissance de liaison montante dans des systèmes en duplex intégral
WO2025029999A1 (fr) Mesure de technologie d'accès inter-radio (rat) sans intervalle
WO2025174457A1 (fr) Commande de puissance de srs et avance de temporisation pour trps
WO2025216900A1 (fr) Amplification de puissance de liaison montante pour agrégation de porteuses de liaison montante
WO2024211826A1 (fr) Positionnement de haute précision dans des systèmes cellulaires
WO2025212440A1 (fr) Association ptrs et dmrs pour transmissions sans fil
WO2024238356A1 (fr) Mesures de saut de fréquence pour positionnement d'ue redcap
WO2025085764A1 (fr) Réseau d'accès radio (ran) basé sur un service
WO2025235790A1 (fr) Transmission d'un signal de référence de sondage avec compensation de perte d'insertion
WO2024238186A1 (fr) Commande de puissance de transmission pour gestion d'interférence de liaison croisée
KR20250170586A (ko) 반송파 위상 포지셔닝 구성들
US20250392497A1 (en) Signal estimation using a compressed sounding reference signal (srs)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24866340

Country of ref document: EP

Kind code of ref document: A1