System for in-coverage sidelink positioning

Abstract

This disclosure relates to a system for sidelink positioning within a coverage area. A method for performing sidelink (SL) configuration for multiple user equipment (UEs) includes: sending a request for sidelink (SL) positioning reference signal (PRS) capability data to a transmitting UE (Tx UE) and a receiving UE (Rx UE); receiving corresponding SL PRS capability data from each of the Tx UE and the Rx UE; configuring an SL positioning reference signal (PRS) based on the SL PRS capability data for each of the Tx UE and the Rx UE; sending data specifying a selected SL PRS configuration to the Tx UE; receiving an acknowledgment signal from the Tx UE indicating a Tx UE SL PRS configuration based on the selected SL PRS configuration; and providing the Tx UE SL PRS configuration to the Rx UE.

Description

[0001] Priority requirements

[0002] This application claims priority to U.S. Patent Application Serial No. 63 / 296,813, filed January 5, 2022, pursuant to 35 U.S. SC §119(e), the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates in whole to wireless communications. Background Technology

[0004] For fifth-generation (5G) New Radio (NR) networks, sidelink (SL) communication allows direct communication between two User Equipment (UE) devices via a direct channel without passing through a base station. Radio Resource Control (RRC) provides the following services for SL: RRC provides PC5-RRC message transmission between two UEs. These messages may include configuration information, such as Sidelink Data Radio Bearer (SL-DRB) configuration information. These messages may also include UE capability information. UE capability is a piece of information indicating different parameters that can be supported at different layers. RRC provides Information Elements (IEs) for transmitting this information between UEs.

[0005] RRC can maintain and release PC5-RRC connections (including PC5 connections) between two UEs. A PC5 connection is a direct connection between two UEs after a PC5 unicast link has been established. A UE can have one or more connections to another UE.

[0006] RRC provides detection of SL radio link failure (SL-RLF) data for PC5-RRC connections based on indications from Media Access Control (MAC) or Radio Link Control (RLC). In the case of SL RLF, the UE immediately releases the resources of the PC5 RRC connection and sends an indication to the upper layer. For RRC-connected UEs, the UE also notifies the network when an RLF is detected. Summary of the Invention

[0007] This application describes a data processing system and process for SL positioning within a coverage area. A positioning reference signal (PRS) is transmitted using sidelink transmission. The sidelink PRS (SL-PRS) is used for various 5G positioning technologies, such as round-trip time (RTT), angle of arrival / departure (AoA / AoD), and time difference of arrival (TDOA). RTT-based positioning eliminates the requirement for tight network timing synchronization across nodes (as required in traditional technologies such as TDOA) and provides additional flexibility in network deployment and maintenance.

[0008] For each of the following scenarios—when the UE is within and outside NG-RAN coverage—sidelink transmission and reception of PC5 handover are supported. This disclosure describes techniques for supporting sidelink positioning within coverage to enable SL positioning both within and outside coverage. Generally, outside coverage (using PC5-RRC) is more common but potentially less efficient. When the UE is within coverage, the network relies on nodes (such as next-generation nodes gNB) and location management functions (LMFs) for centralized SL PRS resource assignment, centralized location estimation, and other location-related operations. The systems and procedures described herein define RRC signaling, NR Location Protocol A (NRPPa) messages (e.g., see 3GPP TS38.455 version 15.0.0 version 15), and LPP signaling to support SL positioning functionality within coverage. For these procedures, only some of the UEs involved in SL positioning need to be within coverage during operation. UEs within coverage include those performing active communications with the LMF. Other UEs may be outside coverage during the execution of the procedures described herein. In some specific implementations, SL positioning includes vehicle-to-the-world (V2X) communication, which involves direct vehicle-to-vehicle communication.

[0009] Several different approaches are possible for configuring SL PRS. In one specific implementation, the LMF requests SL PRS configuration directly from the UE via the Access and Mobility Management Function (AMF) using the Long Term Evolution (LTE) Positioning Protocol (LPP). Generally, new LPP messages are defined for the LMF to request SL PRS configuration (such as bandwidth availability) from the UE and for the UE to report successful or failed configuration. LPP messages may be referred to as SL-PRSConfigurationRequest (LMF to UE) and SL-PRSConfigurationResponse (UE to LMF) messages.

[0010] In the second implementation, NRPPa and RRC are used for SL PRS within the coverage area. The gNB uses RRC to configure SL PRS in the UE and sends this configuration to the LMF using an NRPPa message. To configure SL PRS in the UE using RRC, the RRCReconfiguration message is enhanced using the SL PRS configuration. To send communication to the LMF using an NRPPa message, the NRPPa message positioning information request is enhanced so that the LMF requests SL PRS configuration for the UE. Furthermore, the positioning information response message is enhanced to send the SL PRS configuration to the LMF.

[0011] In the third specific implementation, the LMF provides the SL PRS configuration as part of the auxiliary data to the SL UE, which performs measurements and reports location-related results. The SL PRS reported by the LMF is implemented using an enhanced LPPProvideAssistanceData message.

[0012] To activate or deactivate the SL PRS, the system may perform the following specific implementations. In a first implementation, the LMF uses LPP messages to directly activate or deactivate the SL Sounding Reference Signal (SRS) in the UE. More specifically, LPP messages are defined for LMF to activate and deactivate SL SRS transmissions. Generally, the SRS is an uplink reference signal transmitted by the UE to the base station. The SRS provides information about the combined effects of multipath fading, scattering, Doppler, and power loss of the transmitted signal. In some implementations, these LPP messages are called SL-SRSActivationDeactivationRequest (e.g., LMF to UE transmission). In some implementations, the LPP messages are called SL-SRSActivationDeactivationResponse (e.g., UE to LMF transmission).

[0013] In another implementation, the LMF uses NRPPa to send an SL PRS activation or deactivation request to the gNB. The gNB uses a MAC control element (CE) to activate or deactivate the SL PRS. In this example, the NRPPa positing activationrequest / response message is updated to achieve this functionality.

[0014] The system and processes described in this document achieve one or more of the following advantages, as well as others. For centralized SL PRS, relying on the gNB and LMF is more efficient when the UE is within coverage. Generally, this is because centralized coordination (e.g., via the LMF and / or gNB) typically outperforms distributed coordination. UEs communicating only with the gNB or LMF need to be within coverage. Other UEs can remain outside coverage but still indirectly benefit from this increased efficiency.

[0015] Generally, LPP RequestCapabilities messages are enhanced to enable SL positioning within coverage. As a result, the LMF can request UE SL PRS capabilities. For example, the message may include an sl-RequestCapabilities IE extended to support SL positioning within coverage. Generally, when a UE supporting SL PRS receives a RequestCapabilities LPP message via an sl-RequestCapabilities IE, the IE includes SL PRS capabilities in the ProvideCapabilities LPP message. For example, the message may include a new sl-ProvideCapabilities IE.

[0016] In addition to general indications of UE support for SL PRS capability transitions and reception, several SL PRS capabilities are reported. The reported SL PRS capabilities include those reported by the transmitting or measuring UE. For transmitting UEs, the reported SL PRS capabilities include a list of frequency bands for SL-PRS transmission. The reported capabilities include transmission power capabilities for SL-PRS, including support for power control. The reported capabilities include the UE's beam scanning capabilities. The reported SL PRS capabilities include how many SL-PRS resources the UE can transmit per frequency band. The reported SL PRS capabilities include support for each of periodic (P), semi-persistent (SP), and aperiodic (AP) transmissions.

[0017] The reported SL PRS capabilities include the SL-PRS capabilities reported by the measurement UE: For the measurement UE, the reported SL-PRS capabilities include whether it supports hybrid positioning, whether it supports UE-initiated on-demand SL-PRS requests, whether it supports multipath reporting in SL-PRS measurements, whether it supports RSRP measurement reporting, or whether it supports periodic reporting. For the measurement UE, the reported SL PRS capabilities include the maximum SL PRS bandwidth supported and reported by the UE in megahertz (MHz). This bandwidth may differ for FR1 compared to FR2. The bandwidth may differ for SL-only cases. The bandwidth may differ for SL+Uu PRS processing. Assuming the maximum SL PRS bandwidth supported and reported by the UE in MHz, the reported capabilities include the duration N of SL PRS symbols that the UE can process in ms per T milliseconds (ms). The duration may differ for SL-only cases or for SL+Uu PRS processing. The reported capabilities may include the maximum number of SL PRS resources that the UE can process in a time slot in each case. Compared to FR2, the maximum number can be different for FR1, and the maximum number can also be different for the case of SL only, or for SL+Uu PRS processing.

[0018] The technology disclosed in this application is implemented through one or more specific embodiments, which are described in the Embodiments section of this document.

[0019] Details of one or more specific embodiments are set forth in the following figures and detailed descriptions. The techniques described herein can be implemented by one or more wireless communication systems, components of wireless communication systems (e.g., sites, access points, user equipment, base stations, etc.) or other systems, devices, methods, or non-transitory computer-readable media. Other features and advantages will become apparent from the detailed descriptions, the figures, and the claims. Attached Figure Description

[0020] Figure 1 Exemplary wireless communication systems according to various specific implementations herein are shown.

[0021] Figure 2 Examples of computing devices according to various specific implementations are shown.

[0022] Figure 3 This is a diagram illustrating sidelink communication in a network.

[0023] Figure 4 This is a diagram showing a network that supports side-link configuration within its coverage area.

[0024] Figure 5 This is a flowchart illustrating an exemplary process for configuring side links within the coverage area.

[0025] Figure 6 This is a flowchart illustrating an exemplary process for configuring in-coverage side links using LPP messages.

[0026] Figure 7 This is a flowchart illustrating an exemplary process for configuring in-coverage side links using NRPPa messages.

[0027] Similar reference symbols in the various figures indicate similar elements. Detailed Implementation

[0028] Figure 1 An example of a wireless communication system 100 is illustrated. For convenience and not limitation, the exemplary system 100 is described in the context of Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards, as defined by the 3rd Generation Partnership Project (3GPP) technical specifications. More specifically, the wireless communication system 100 is described in the context of a non-standalone (NSA) network combining both LTE and NR, such as an E-UTRA (Evolved Universal Terrestrial Radio Access)-NR Dual Connectivity (EN-DC) network and a NE-DC network. However, the wireless communication system 100 could also be a standalone (SA) network combining only NR. Furthermore, other types of communication standards are also possible, including future 3GPP systems (e.g., sixth generation (6G)) systems, IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc.), etc.

[0029] like Figure 1 As shown, system 100 includes UE 101a and UE 101b (collectively referred to as "UE101"). In this example, UE101 is shown as a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks), but may also include any mobile or non-mobile computing device, such as consumer electronics devices, mobile phones, smartphones, feature phones, tablet computers, wearable computing devices, personal digital assistants (PDAs), pagers, wireless handheld devices, desktop computers, laptop computers, in-vehicle infotainment (IVI), in-vehicle entertainment (ICE) devices, instrument cluster (IC), head-up display (HUD) devices, onboard diagnostic (OBD) devices, dashtop mobile equipment (DME), mobile data terminal (MDT), electronic engine management system (EEMS), electronic / engine electronic control unit (ECU), electronic / engine electronic control module (ECM), embedded systems, microcontrollers, control modules, engine management system (EMS), connected or "smart" appliances, MTC devices, M2M, IoT devices, etc.

[0030] In some implementations, any of UEs 101 may be an IoT UE, which may include a network access layer designed to utilize low-power IoT applications with short-lived UE connections. The IoT UE may use technologies such as M2M or MTC to exchange data with an MTC server or device via PLMN, ProSe or D2D communication, sensor networks, or IoT networks. M2M or MTC data exchange may be machine-initiated data exchange. The IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) with short-lived connections. The IoT UE may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0031] UE 101 can be configured to connect to RAN 110, for example, communicatively coupled. In implementations, RAN 110 can be an NG RAN or 5G RAN, E-UTRAN, or a legacy RAN such as UTRAN or GERAN. As used herein, the term "NG RAN," etc., can refer to RAN 110 operating in NR or 5G system 100, while the term "E-UTRAN," etc., can refer to RAN 110 operating in LTE or 4G system 100. Multiple UEs 101 utilize connections (or channels) 103 and 104 respectively, each connection including a physical communication interface or layer (discussed in further detail below).

[0032] In this example, connections 103 and 104 are shown as air interfaces for communication coupling and can be consistent with cellular communication protocols such as GSM, CDMA, PTT, POC, UMTS, 3GPP LTE, LTE-A (LTE-Advanced Long Term Evolution), LTE-U (LTE-U), 5G, NR, NR-U (NR-U), and / or any other communication protocols discussed herein. In an implementation, UE 101 can directly exchange communication data via ProSe interface 105. ProSe interface 105 may also be referred to as SL interface 105 and may include one or more logical channels, including but not limited to PSCCH, PSSCH, PSDCH, and PSBCH.

[0033] The diagram shows UE 101b configured to access AP 106 (also referred to as "WLAN node 106", "WLAN 106", "WLAN terminal 106", "WT 106", etc.) via connection 107. Connection 107 may include a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, where AP 106 will include Wireless Fibre. Router. In this example, AP 106 is shown connected to the Internet but not to the core network of the wireless system (described in further detail below). In various implementations, UE 101b, RAN 110, and AP 106 can be configured to utilize LWA operation and / or LWIP operation. LWA operation may involve RAN nodes 111a-b configuring UE 101b, which is in the RRC_CONNECTED state, to utilize the radio resources of LTE and WLAN. LWIP operation may involve UE 101b using WLAN radio resources (e.g., connection 107) via an IPsec protocol tunnel to authenticate and encrypt packets (e.g., IP packets) transmitted through connection 107. IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header to protect the original header of the IP packet.

[0034] RAN 110 includes one or more AN nodes or RAN nodes 111a and 111b (collectively referred to as "RAN node 111") that enable connections between 103 and 104. As used herein, the terms "access node," "access point," etc., can describe equipment that provides radio baseband functionality for data and / or voice connections between the network and one or more users. These access nodes can be referred to as BS, gNB, RAN node, eNB, NodeB, RSU, TRxP, or TRP, etc., and can include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). As used herein, the terms "NG RAN node," etc., can refer to RAN node 111 (e.g., gNB) operating in NR or 5G system 100, while the terms "E-UT RAN node," etc., can refer to RAN node 111 (e.g., eNB) operating in LTE or 4G system 100. According to various implementation schemes, RAN node 111 may be implemented as one or more of dedicated physical devices such as macro cell base stations and / or low-power (LP) base stations for providing smaller coverage areas, smaller user capacity or higher bandwidth compared to macro cells.

[0035] In some implementations, all or part of RAN node 111 may be implemented as one or more software entities running on a server computer as part of a virtual network, which may be referred to as CRAN and / or Virtual Baseband Unit Pool (vBBUP). In these implementations, CRAN or vBBUP may implement RAN function splitting, such as PDCP splitting, where the RRC and PDCP layers are operated by CRAN / vBBUP and other L2 protocol entities are operated by individual RAN nodes 111; MAC / PHY splitting, where the RRC, PDCP, RLC, and MAC layers are operated by CRAN / vBBUP and the PHY layer is operated by individual RAN nodes 111; or “lower PHY” splitting, where the upper part of the RRC, PDCP, RLC, MAC, and PHY layers is operated by CRAN / vBBUP and the lower part of the PHY layer is operated by individual RAN nodes 111. This virtualization framework allows the idle processor cores of multiple RAN nodes 111 to execute other virtualized applications. In some specific implementations, a single RAN node 111 may represent a virtual network via various F1 interfaces (…). Figure 1 (Not shown) Individual gNB-DUs connected to the gNB-CU. In these specific implementations, the gNB-DU may include one or more remote radio head units or RFEMs, and the gNB-CU may be operated by a server (not shown) located in RAN 110 or by a server pool in a manner similar to CRAN / vBBUP. In addition or alternatively, one or more RAN nodes in RAN 111 may be next-generation eNBs (ng-eNBs), which are E-UTRA user plane and control plane protocol terminals providing access to UE 101 and connected to 5GC (e.g., via ng interface (discussed below)). Figure 2 RAN node of CN220.

[0036] In a V2X scenario, one or more nodes in RAN Node 111 can be an RSU or act as an RSU. The term "roadside unit" or "RSU" can refer to any traffic infrastructure entity used for V2X communication. An RSU can be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, wherein an RSU implemented in or by a UE can be referred to as a "UE-type RSU", an RSU implemented in or by an eNB can be referred to as an "eNB-type RSU", an RSU implemented in or by a gNB can be referred to as a "gNB-type RSU", and so on. In one example, an RSU is a computing device coupled to radio frequency circuitry located on the roadside that provides connectivity support to a passing vehicle UE 101 (vUE 101). An RSU may also include internal data storage circuitry for storing intersection map geometry, traffic statistics, media, and applications / software for sensing and controlling ongoing vehicle and pedestrian traffic. The RSU may operate on the 5.9 GHz Direct Near Range Communication (DSRC) band to provide extremely low-latency communication required for high-speed events, such as collision avoidance and traffic warnings. Alternatively, the RSU may operate on the cellular V2X band to provide the aforementioned low-latency communication as well as other cellular communication services. Alternatively, the RSU may operate as a Wi-Fi hotspot (2.4 GHz band) and / or provide connectivity to one or more cellular networks to provide uplink and downlink communication. Some or all of the computing device and the RSU's radio frequency circuitry may be packaged in a weather-resistant package suitable for outdoor installation and may include a network interface controller to provide wired connectivity (e.g., Ethernet) to traffic signal controllers and / or backhaul networks.

[0037] Any node in RAN 111 can serve as the endpoint of the air interface protocol and can be the first point of contact for UE 101. In some implementations, any node in RAN 111 can perform various logical functions of RAN 110, including but not limited to the functions of the Radio Network Controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

[0038] In the implementation, UE 101 may be configured to communicate with each other or with any of the RAN nodes 111 on a multi-carrier communication channel using OFDM communication signals according to various communication technologies, such as, but not limited to, OFDMA communication technology (e.g., for downlink communication) or SC-FDMA communication technology (e.g., for uplink and ProSe or sidelink communication), although the scope of the implementation is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0039] In some implementations, the downlink resource grid can be used for downlink transmissions from any node in RAN 111 to UE 101, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, referred to as a resource grid or time-frequency resource grid, which represents the physical resources in the downlink within each time slot. This time-frequency plane representation is common practice for OFDM systems, making radio resource allocation intuitive. Each column and row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid comprises multiple resource blocks that describe the mapping of certain physical channels to resource elements. Each resource block comprises a set of resource elements; in the frequency domain, this can represent the minimum amount of resources currently available for allocation. Such resource blocks are used to transmit several different physical downlink channels.

[0040] According to various implementations, UE 101 and RAN node 111 transmit data (e.g., transmit and receive data) through licensed media (also referred to as “licensed spectrum” and / or “licensed band”) and unlicensed shared media (also referred to as “unlicensed spectrum” and / or “unlicensed band”). Licensed spectrum may include channels operating in the frequency range of approximately 400 MHz to approximately 3.8 GHz, while unlicensed spectrum may include a 5 GHz band. NR in the unlicensed spectrum may be referred to as NR-U, and LTE in the unlicensed spectrum may be referred to as LTE-U, Licensed Assisted Access (LAA), or MulteFire.

[0041] To operate in unlicensed spectrum, UE 101 and RAN node 111 may use LAA, eLAA, and / or feLAA mechanisms. In these specific implementations, UE 101 and RAN node 111 may perform one or more known medium sensing and / or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmission in the unlicensed spectrum. Medium / carrier sensing operations may be performed according to a Listen-After-Talk (LBT) protocol.

[0042] LBT is a mechanism that equipment (e.g., UE 101, RAN node 111, etc.) uses to sense a medium (e.g., a channel or carrier frequency) and transmit when the medium is sensed to be idle (or when a specific channel in the medium is sensed to be unoccupied). The medium sensing operation may include CCA, which utilizes at least ED to determine the presence of other signals on the channel in order to determine whether the channel is occupied or idle. This LBT mechanism allows cellular / LAA networks to coexist with existing systems in unlicensed spectrum and with other LAA networks. ED may include sensing RF energy in the intended transmission band over a period of time and comparing the sensed RF energy with a predefined or configured threshold.

[0043] Typically, existing systems in the 5GHz band are WLANs based on IEEE 802.11 technology. WLANs employ a contention-based channel access mechanism called CSMA / CA. Here, when a WLAN node (e.g., a mobile station (MS) such as UE 101, AP 106, etc.) intends to transmit, the WLAN node can first perform CCA before transmitting. Additionally, in cases where more than one WLAN node senses the channel as idle and transmits simultaneously, a backoff mechanism is used to avoid collisions. This backoff mechanism can be a counter randomly introduced within the CWS, which increases exponentially upon collision and resets to a minimum value upon successful transmission. The LBT mechanism designed for LAA is somewhat similar to WLAN's CSMA / CA. In some specific implementations, the LBT process for DL ​​or UL transmission bursts (including PDSCH or PUSCH transmissions) can have a variable-length LAA contention window between the X and Y ECCA time slots, where X and Y are the minimum and maximum values ​​of the LAA's CWS. In one example, the minimum CWS for LAA transmission can be 9 microseconds (μs); however, the size of the CWS and MCOT (e.g., transmission burst) can be based on government regulatory requirements.

[0044] The LAA mechanism is built upon the CA technology of LTE-Advanced systems. In CA, each aggregated carrier is called a CC. A CC can have a bandwidth of 1.4, 3, 5, 10, 15, or 20 MHz, and a maximum of five CCs can be aggregated, thus the maximum aggregated bandwidth is 100 MHz. In FDD systems, the number of aggregated carriers can differ for DL ​​and UL, where the number of UL CCs is equal to or less than the number of DL component carriers. In some cases, individual CCs can have different bandwidths than the other CCs. In TDD systems, the number of CCs and the bandwidth of each CC are usually the same for DL ​​and UL.

[0045] The CA also includes individual serving cells to provide individual CCs. The coverage of serving cells can differ, for example, because CCs on different frequency bands will experience different path losses. The primary serving cell, or PCell, provides the PCC for both UL and DL and handles activities related to RRC and NAS. Other serving cells are called SCells, and each SCell provides individual SCCs for both UL and DL. SCCs can be added and removed as needed, and changing the PCC may require UE 101 to undergo handover. In LAA, eLAA, and feLAA, some or all of the SCells can operate in unlicensed spectrum (referred to as "LAA SCells"), and LAA SCells are assisted by PCells operating in licensed spectrum. When a UE is configured to have more than one LAA SCell, the UE can receive UL grants on the configured LAA SCells, indicating different PUSCH start positions within the same subframe.

[0046] The PDSCH carries user data and higher-layer signaling to multiple UEs 101. Among other information, the PDCCH carries information about the transmission format and resource allocation related to the PDSCH channel. It can also inform multiple UEs 101 about the transmission format, resource allocation, and HARQ information related to the uplink shared channel. Typically, downlink scheduling (allocating control and shared channel resource blocks to UEs 101b within the cell) can be performed at any of the RAN nodes 111 based on channel quality information fed back from any of the UEs 101. Downlink resource allocation information can be transmitted on the PDCCH used for (e.g., allocated to) each UE in the UEs 101.

[0047] PDCCH uses CCEs to transmit control information. Before being mapped to resource elements, the complex-valued symbols of the PDCCH can first be organized into quadruplets, which can then be arranged using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets, called REGs, each with four physical resource elements. Four Quadrature Phase Shift Keying (QPSK) symbols can be mapped to each REG. Depending on the DCI size and channel conditions, one or more CCEs can be used to transmit the PDCCH. Four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation levels, L = 1, 2, 4, or 8) can exist.

[0048] Some implementations may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some implementations may utilize EPDCCH, which uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similarly, each ECCE may correspond to a set of nine, each consisting of four physical resource elements, called EREG. In some cases, an ECCE may have a different number of EREGs.

[0049] RAN nodes 111 can be configured to communicate with each other via interface 112. In an implementation where system 100 is an LTE system, interface 112 can be an X2 interface 112. The X2 interface can be defined between two or more RAN nodes 111 connected to EPC 120 (e.g., two or more eNBs, etc.), and / or between two eNBs connected to EPC 120. In some specific implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). X2-U can provide flow control mechanisms for user packets transmitted via the X2 interface and can be used to transmit information about the delivery of user data between eNBs. For example, X2-U can provide specific sequence number information about user data transmitted from MeNB to SeNB; information about the successful in-order delivery of PDCP PDUs from SeNB to UE 101 for user data; information about PDCP PDUs not delivered to UE 101; information about the current minimum expected buffer size at SeNB for transmitting user data to the UE; and so on. The X2-C provides LTE intra-eNB access mobility functions, including context transmission from the source eNB to the destination eNB, user plane transmission control, load management functions, and inter-cell interference coordination functions.

[0050] In system 100, which is a 5G or NR system (e.g., when CN 120 is as follows), Figure 2In an implementation of 5GC 120, interface 112 may be an Xn interface 112. The Xn interface is defined between two or more RAN nodes 111 (e.g., two or more gNBs, etc.) connected to 5GC 120, between a RAN node 111 (e.g., a gNB) connected to 5GC 120 and an eNB, and / or between two eNBs connected to 5GC 120. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U provides non-guaranteed delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C provides management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 101 in connected modes (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected modes between one or more RAN nodes 111. Mobility support may include context transfer from the old (source) serving RAN node 111 to the new (destination) serving RAN node 111, and control of the user plane tunnel between the old (source) serving RAN node 111 and the new (destination) serving RAN node 111. The Xn-U protocol stack may include a transport network layer built on top of the Internet Protocol (IP) transport layer, and a GTP-U layer on top of the UDP and / or IP layers for carrying user plane PDUs. The Xn-C protocol stack may include an application layer signaling protocol (referred to as the Xn Application Protocol (Xn-AP)) and a transport network layer built on top of SCTP. SCTP may be on top of the IP layer and provides guaranteed delivery of application layer messages. In the transport IP layer, point-to-point transmission is used to deliver signaling PDUs. In other specific implementations, the Xn-U protocol stack and / or the Xn-C protocol stack may be the same as or similar to the user plane and / or control plane protocol stacks shown and described herein.

[0051] RAN 110 is shown communicatively coupled to the core network—in this embodiment, communicatively coupled to the core network (CN) 120. CN 120 may include multiple network elements 122 configured to provide various data and telecommunications services to customers / subscribers (e.g., users of multiple UEs 101) connected to CN 120 via RAN 110. Components of CN 120 may be implemented in a physical node or separate physical nodes, including components for reading and executing instructions from machine-readable or computer-readable media (e.g., non-transitory machine-readable storage media). In some embodiments, NFV may be used to virtualize any or all of the aforementioned network node functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instance of CN 120 may be referred to as a network slice, and a logical instance of a portion of CN 120 may be referred to as a network subslice. NFV architectures and infrastructure may be used to virtualize one or more network functions onto physical resources comprising a combination of industry-standard server hardware, storage hardware, or switches (or alternatively, performed by proprietary hardware). In other words, an NFV system can be used to perform a virtual or reconfigurable concrete implementation of one or more EPC components / functions.

[0052] Generally, application server 130 can be a component that provides IP bearer resources for use with the core network (e.g., UMTS PS domain, LTE PS data service, etc.). Application server 130 can also be configured to support one or more communication services for UE 101 via EPC 120 (e.g., VoIP sessions, PTT sessions, group communication sessions, social networking services, etc.).

[0053] In this implementation, CN 120 may be a 5GC (referred to as "5GC 120", etc.), and RAN 110 may be connected to CN 120 via NG interface 113. In this implementation, NG interface 113 may be divided into two parts: an NG user plane (NG-U) interface 114, which carries traffic data between RAN node 111 and UPF; and an S1 control plane (NG-C) interface 115, which is the signaling interface between RAN node 111 and AMF. (Reference) Figure 2 CN 120 is an implementation scheme of 5GC 120. This will be discussed in more detail.

[0054] In one implementation, CN 120 may be a 5G CN (referred to as "5GC 120", etc.), while in other implementations, CN 120 may be an EPC. When CN 120 is an EPC (referred to as "EPC 120", etc.), RAN 110 may be connected to CN 120 via S1 interface 113. In one implementation, S1 interface 113 may be divided into two parts: an S1 user plane (S1-U) interface 114, which carries traffic data between RAN node 111 and S-GW; and an S1-MME interface 115, which is the signaling interface between RAN node 111 and MME.

[0055] Figure 2 The architecture of a system 200 including a second CN 220 according to various embodiments is shown. System 200 is shown as including a UE 201, which may be the same as or similar to the previously discussed UE 101 and UE XR101; (R)AN 210, which may be the same as or similar to the previously discussed RAN 110 and RAN XR110, and may include the previously discussed RAN node 111; and DN 203, which may be, for example, operator services, Internet access, or third-party services; and 5GC 220. 5GC 220 may include AUSF 222; AMF 221; SMF 224; NEF 223; PCF 226; NRF 225; UDM 227; AF 228; UPF 202; and NSSF 229.

[0056] UPF 202 can act as an anchor point for mobility within and between RATs, an external PDU session point interconnected with DN 203, and a branch point supporting multi-homed PDU sessions. UPF 202 can also perform packet routing and forwarding, packet inspection, user plane portion of policy rules, lawful packet interception (UP collection), traffic usage reporting, QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), uplink traffic authentication (e.g., SDF to QoS flow mapping), transport level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. UPF 202 may include an uplink classifier to support traffic routing to the data network. DN 203 may represent various network operator services, Internet access, or third-party services. DN 203 may include or be similar to the previously discussed application server 130. UPF 202 can interact with SMF 224 via the N4 reference point between SMF 224 and UPF 202.

[0057] AUSF 222 can store data for UE 201 authentication and handle authentication-related functions. AUSF 222 can facilitate a common authentication framework for various access types. AUSF 222 can communicate with AMF 221 via the N12 reference point between AMF 221 and AUSF 222; and with UDM 227 via the N13 reference point between UDM 227 and AUSF 222. Additionally, AUSF 222 can present an interface based on Nausf services.

[0058] AMF 221 can handle registration management (e.g., registering UE 201, etc.), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. AMF 221 can be the termination point of the N11 reference point between AMF 221 and SMF 224. AMF 221 can provide transport for SM messages between UE 201 and SMF 224 and act as a transparent proxy for routing SM messages. AMF 221 can also provide transport for UE 201 and SMSF ( Figure 2 Transmission of SMS messages between (not shown in the diagram). AMF 221 can act as a SEAF, which may include interaction with AUSF 222 and UE 201, receiving an intermediate key established due to the UE 201 authentication process. In the case of using USIM-based authentication, AMF 221 may retrieve security material from AUSF 222. AMF 221 may also include an SCM function that receives a key from the SEA for deriving a network-specific key for access. Furthermore, AMF 221 may be the termination point of the RAN CP interface, which may include or may be the N2 reference point between (R)AN210 and AMF 221, and AMF 221 may be the termination point of NAS (N1) signaling, performing NAS encryption and integrity protection.

[0059] AMF 221 can also support NAS signaling with UE 201 via the N3 IWF interface. The N3 IWF can be used to provide access to untrusted entities. The N3 IWF can be the termination point of the N2 interface between the control plane (R)AN 210 and AMF 221, and can be the termination point of the N3 reference point between the user plane (R)AN 210 and UPF 202. Therefore, AMF 221 can process N2 signaling from SMF 224 and AMF 221 for PDU sessions and QoS, encapsulate / decapsulate packets for IPsec and N3 tunneling, mark N3 user plane packets in the uplink, and perform QoS corresponding to the N3 packet markings, taking into account the QoS requirements associated with such markings received via N2. The N3IWF can also relay uplink and downlink control plane NAS signaling between UE 201 and AMF 221 via the N1 reference point between UE 201 and AMF 221, and relay uplink and downlink user plane packets between UE 201 and UPF 202. The N3IWF also provides a mechanism for establishing an IPsec tunnel using UE 201. AMF 221 can present an interface based on Namf services and can be the N14 reference point between two AMF 221s and between AMF 221 and 5G-EIR (…). Figure 2 The endpoint of the N17 reference point (not shown).

[0060] UE 201 may need to register with AMF 221 to receive network services. The RM is used to register or deregister UE 201 with the network (e.g., AMF 221) and to establish a UE context within the network (e.g., AMF 221). UE 201 can operate in either the RM-REGISTERED or RM-DEREGISTERED state. In the RM-DEREGISTERED state, UE 201 is not registered with the network, and the UE context in AMF 221 does not maintain valid location or routing information for UE 201, making it unreachable by AMF 221. In the RM-REGISTERED state, UE 201 is registered with the network, and the UE context in AMF 221 can maintain valid location or routing information for UE 201, making it reachable by AMF 221. In the RM-REGISTERED state, UE 201 can execute mobility registration update procedures, execute periodic registration update procedures triggered by the expiration of periodic update timers (e.g., to notify the network that UE 201 is still active), and execute registration update procedures to update UE capability information or renegotiate protocol parameters with the network, etc.

[0061] AMF 221 can store one or more RM contexts for UE 201, where each RM context is associated with a specific access to the network. The RM context can be a data structure, database object, etc., indicating or storing, in particular, the registration status and periodic update timers for each access type. AMF 221 can also store 5GC MM contexts that are the same as or similar to the previously discussed (E)MM contexts. In various implementations, AMF 221 can store CE Mode B limitation parameters of UE 201 in the associated MM or RM context. AMF 221 can also derive values ​​from UE usage setting parameters already stored in the UE context (and / or MM / RM context) when needed.

[0062] The CM can be used to establish and release signaling connections between UE 201 and AMF 221 via the N1 interface. The signaling connection enables NAS signaling exchange between UE 201 and CN 220, and includes signaling connections between the UE and AN (e.g., RRC connections for non-3GPP access or UE-N3IWF connections) and N2 connections between the AN (e.g., RAN 210) and AMF 221 for UE 201. UE 201 can operate in two CM states (CM-IDLE mode or CM-CONNECTED F-EF227336).

[0063] The UE 201 may operate in one of the following modes: When the UE 201 operates in CM-IDLE state / mode, the UE 201 may not have a NAS signaling connection established with the AMF 221 via the N1 interface, and the UE 201 may have (R)AN 210 signaling connections (e.g., N2 and / or N3 connections). When the UE 201 operates in CM-CONNECTED state / mode, the UE 201 may have a NAS signaling connection established with the AMF 221 via the N1 interface, and the UE 201 may have (R)AN 210 signaling connections (e.g., N2 and / or N3 connections). Establishing an N2 connection between (R)AN 210 and AMF 221 can cause UE201 to switch from CM-IDLE mode to CM-CONNECTED mode, and UE201 can switch from CM-CONNECTED mode to CM-IDLE mode when the N2 signaling between (R)AN 210 and AMF 221 is released.

[0064] SMF 224 may be responsible for SM (e.g., session establishment, modification, and release, including tunnel maintenance between UPF and AN nodes); UE IP address allocation and management (including optional authorization); selection and control of UP functions; configuring traffic redirection of the UPF to route traffic to the correct destination; terminating the interface toward policy control functions; policy enforcement and QoS control portions; lawful interception (for SM events and interfaces with the LI system); terminating the SM portion of NAS messages; downlink data notification; initiating AN-specific SM information sent to the AN via N2 through the AMF; and determining the SSC mode of the session. SM may refer to the management of PDU sessions, and a PDU session or “session” may refer to the PDU connectivity service that provides or enables PDU exchange between UE 201, identified by the Data Network Name (DNN), and Data Network (DN) 203. Using NAS SM signaling exchanged via the N1 reference point between UE 201 and SMF 224, a PDU session can be established upon request by UE 201, modified upon request by both UE 201 and 5GC 220, and released upon request by both UE 201 and 5GC 220. Upon request from the application server, 5GC 220 can trigger a specific application in UE 201. In response to receiving a trigger message, UE 201 can pass the trigger message (or relevant portions / information of the trigger message) to one or more identified applications in UE 201. The identified applications in UE 201 can establish a PDU session to a specific DNN. SMF 224 can check whether the UE 201 request matches the user subscription information associated with UE 201. In this regard, SMF 224 can retrieve and / or request updates from UDM 227 regarding SMF 224 level subscription data.

[0065] The SMF 224 may include the following roaming functions: handling local execution to apply QoS SLAs (VPLMN); charging data collection and charging interface (VPLMN); lawful interception (for SM events and interfaces with the LI system, in the VPLMN); and support for interaction with external DNs to transmit signaling for PDU session authorization / authentication via external DNs. In roaming scenarios, an N16 reference point between two SMF 224s may be included in system 200, which may be located between an SMF 224 in the visited network and another SMF 224 in the home network. Additionally, the SMF 224 may present an interface based on Nsmf services.

[0066] NEF 223 provides components for securely exposing services and capabilities provided by 3GPP network functions to third parties, internal exposure / re-exposure, application functions (e.g., AF 228), edge computing, or fog computing systems, etc. In such implementations, NEF 223 can authenticate, authorize, and / or restrict AFs. NEF 223 can also translate information exchanged with AF 228 and information exchanged with internal network functions. For example, NEF 223 can translate between AF service identifiers and internal 5GC information. NEF 223 can also receive information from other network functions (NFs) based on their exposure capabilities. This information can be stored as structured data at NEF 223 or stored at a data storage NF using a standardized interface. The stored information can then be re-exposed by NEF 223 to other NFs and AFs, and / or used for other purposes such as analysis. Additionally, NEF 223 can present an interface based on Nnef services.

[0067] The NRF 225 supports service discovery, receiving NF discovery requests from NF instances and providing information about discovered NF instances to them. The NRF 225 also maintains information about available NF instances and the services they support. As used herein, terms such as "instantiation" can refer to the creation of an instance, and "instance" can refer to the concrete occurrence of an object, which may occur, for example, during the execution of program code. Additionally, the NRF 225 can present an interface based on NRF services.

[0068] PCF 226 can provide policy rules for control plane functions to enforce these functions and can also support a unified policy framework to manage network behavior. PCF 226 can also implement FE to access subscription information related to policy decisions in the UDR of UDM 227. PCF 226 can communicate with AMF 221 via the N15 reference point between PCF 226 and AMF 221, which can include PCF 226 in the visited network and AMF 221 in roaming scenarios. PCF 226 can communicate with AF 228 via the N5 reference point between PCF 226 and AF 228, and can communicate with SMF 224 via the N7 reference point between PCF 226 and SMF 224. System 200 and / or CN 220 may also include the N24 reference point between PCF 226 (in the home network) and PCF 226 in the visited network. Additionally, PCF 226 can present an interface based on NPCF services.

[0069] UDM 227 can process subscription-related information to support network entities in handling communication sessions and can store UE 201's subscription data. For example, subscription data can be transmitted between UDM 227 and AMF 221 via the N8 reference point between UDM 227 and AMF. UDM 227 may include two parts: the application FE and the UDR (User Data Transfer Protocol). Figure 2 (FE and UDR are not shown). The UDR may store subscription data and policy data of UDM 227 and PCF 226, and / or structured data for exposure of NEF 223, as well as application data (including PFD for application detection, application request information of multiple UEs 201). The interface based on the Nudr service may be presented by UDR 221 to allow UDM 227, PCF 226, and NEF 223 to access specific sets of stored data, as well as notifications for reading, updating (e.g., adding, modifying), deleting, and subscribing to relevant data changes in the UDR. The UDM may include UDM-FE, which is responsible for handling credentials, location management, subscription management, etc. Several different front-ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification processing, access authorization, registration / mobility management, and subscription management. The UDR may interact with SMF 224 via the N10 reference point between UDM 227 and SMF 224. The UDM 227 also supports SMS management, with SMS-FE implementing similar application logic as previously discussed. Additionally, the UDM227 can present an interface based on Nudm services.

[0070] AF 228 can provide application-level influence on traffic routing, provide access to the NCE, and interact with the policy framework for policy control. The NCE can be a mechanism allowing 5GC 220 and AF 228 to provide information to each other via NEF 223, which can be used in edge computing implementations. In such implementations, network operators and third-party services can be hosted near the UE 201 access point to achieve efficient service delivery through reduced end-to-end latency and load on the transport network. For edge computing implementations, 5GC can select UPF 202 near UE 201 and perform traffic redirection from UPF 202 to DN 203 via the N6 interface. This can be based on UE subscription data, UE location, and information provided by AF 228. Thus, AF 228 can influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 228 is considered a trusted entity, network operators can allow AF 228 to interact directly with the relevant NF. Additionally, AF 228 can present an interface based on Naf services.

[0071] NSSF 229 can select a set of network slice instances to serve UE 201. If needed, NSSF 229 can also determine the allowed NSSAIs and the mapping to subscribed S-NSSAIs. NSSF 229 can also determine the AMF set, or list of candidate AMFs 221, for serving UE 201 based on appropriate configuration and possibly by querying NRF 225. The selection of a set of network slice instances for UE 201 can be triggered by AMF 221, where UE 201 registers through interaction with NSSF 229, which can cause changes to AMF 221. NSSF 229 can interact with AMF 221 via the N22 reference point between AMF 221 and NSSF 229, and via the N31 reference point (…). Figure 2 (Not shown) communicates with another NSSF 229 in the visited network. Additionally, the NSSF 229 may present an interface based on the Nnssf service.

[0072] As previously discussed, CN 220 may include an SMSF responsible for SMS subscription checks and authentication, and relaying SM messages to / from UE 201 to / from other entities such as SMS-GMSC / IWMSC / SMS routers. SMS may also interact with AMF 221 and UDM 227 for notification procedures that make UE 201 available for SMS delivery (e.g., setting a UE unreachable flag and notifying UDM 227 when UE 201 is available for SMS).

[0073] CN 120 may also include Figure 2 Other elements not shown include data storage systems / architecture, 5G-EIR, SEPP, etc. Data storage systems may include SDSF, UDSF, etc. Any NF can be transmitted via any NF and UDSF ( Figure 2 The N18 reference points (not shown) between NFs store unstructured data in or retrieve it from the UDSF (e.g., UE context). Individual NFs may share a UDSF for storing their respective unstructured data, or each NF may have its own UDSF located at or near the individual NF. Additionally, the UDSF may present an interface based on the Nudsf service (…). Figure 2 (Not shown). 5G-EIR can be an NF that checks the status of PEI to determine whether to blacklist a specific device / entity from the network; and SEPP can be a non-transparent agent that performs topology hiding, message filtering, and policing on the control plane interface between PLMNs.

[0074] Furthermore, there can be more reference points and / or service-based interfaces between NF services; however, for clarity, Figure 2These interfaces and reference points are omitted. In one example, CN220 may include an Nx interface, which is an inter-CN interface between the MME (e.g., MME XR121) and AMF221 to enable interoperability between CN220 and CN XR120. Other example interfaces / reference points may include an interface based on N5g-EIR services presented by 5G-EIR, reference point N27 between the NRF in the visited network and the NRF in the home network; and reference point N31 between the NSSF in the visited network and the NSSF in the home network.

[0075] Figure 3 This is a diagram illustrating sidelink communication within network 300. Network 300 is configured for SLPRS within its coverage area. Network 300 includes 5GC Location Services (LCS) entities 310. These entities may include any entity that provides or requires location-based services. For example, LCS entity 310 may include a Gateway Mobile Location Center (GMLC). A GMLC is a control plane system that intersects with emergency and commercial LCS clients and operator networks to provide the location of mobile devices required to support location-based services (LBS). Other such examples of LCS entities are possible. The network includes a 300 Location Management Function (LMF). An LMF may be a server (or other specific implementation of location management) that collects measurements from devices (e.g., UEs 301, 302) and configures signaling for the UEs. The LMF processes location service requests from UEs and responds to these requests with responses from the UEs. Access and Mobility Management Function (AMF) 306 is a control plane function in the 5G core network, as previously described. The AMF's functions include registration management for UEs 301, 302, accessibility management for UEs, and connectivity management for UEs. Network 300 includes at least two UEs 301 and 302. UE 302 is referred to as the transmitting UE (or Tx UE) and is within coverage area and therefore connected to LMF 308. Receiving UE (Rx UE) 301 is a second UE in network 300 that is not necessarily within coverage area and therefore not necessarily connected to LMF 308. Instead, Rx UE 301 connects to Tx UE 302 using SL communication (e.g., using a PC5 interface).

[0076] The general process of SL localization is now described. Network 300 is shown as having general relationships between entities 301, 302, 304, 306, 308, and 310. These relationships are described herein and will be discussed subsequently. Figures 4 to 7A more specific implementation of SL positioning within the coverage area is described. A location service request 312 is sent from LCS entity 310 to AMF 306. For example, an entity in the 5GC (e.g., GMLC) requests location services (e.g., location) for target UE 302 from serving AMF 306. Also, at step 314, serving AMF 306 determines the need for location services for target UE 302 (e.g., locating UE 302 for an emergency call). At step 318, AMF 306 transmits the location service request to LMF 308.

[0077] The LMF 308 initiates a positioning procedure (320) to the serving ng-gNB in ​​the NG-RAN, such as to obtain positioning measurement results or auxiliary data. At step 320, the SL PRS within the coverage area is configured. One or more of procedures 400, 500, 600, and 700 can be used for SL PRS configuration. Generally, at step 320, the LMF 308 configures the SL PRS by performing the following operations.

[0078] LMF 308 learns the capabilities of each of Tx UE 302 and Rx UE 301. These capabilities include the transmission band and bandwidth availability of each of UEs 301 and 302. These capabilities include a list of operations supported by each of UEs 301 and 302, including positioning capabilities. Here, Tx UE 302 reports what resources are available for SL PRS transmission. For example, transmitting UE 302 may report the following potential SL-PRS capabilities to LMF 308: Transmitting UE 302 may report a list of bands available for SL-PRS transmission. The band list includes available transmission bands for SL-PRS transmission. UE 302 may report transmission power capabilities for SL-PRS. Transmission power capabilities include indications of support for power control. UE 302 reports its beam scanning capabilities. Beam scanning capabilities include what beamforming is possible. For example, beam scanning capabilities describe how the UE searches for beams and what beam configurations are available for SL-PRS. The UE 302 report indicates the amount of SL-PRS resources that can be transmitted per frequency band. The UE 302 report also indicates what types of transmissions are available for SL-PRS. For example, the UE 302 report whether periodic transmissions are available, semi-persistent transmissions are available, and / or non-periodic transmissions are available.

[0079] Measurement UE 301 is configured to report the following capabilities for SL-PRS. For example, measurement UE 301 is configured to report whether Rx UE 301 supports hybrid positioning. Here, hybrid positioning includes using SL PRS and Uu PRS measurements together to determine positioning. Rx UE 301 is configured to report whether support for UE-initiated on-demand SL-PRS requests is available. Rx UE 301 is configured to report whether multipathing in SL-PRS measurements is supported. Rx UE 301 is configured to report whether RSRP measurements are supported. Rx UE 301 is configured to report whether periodic reporting is supported. Rx UE 301 is configured to report the maximum SL PRS bandwidth supported by UE 301 in MHz. The maximum SL PRS bandwidth may be different for frequency range 1 (FR1) or frequency range 2 (FR2). The maximum bandwidth may be different for SL-only communication compared to SL+Uu PRS communication. UE 301 is configured to report the duration N of SL PRS symbols, in milliseconds (ms), that UE 301 can process per T milliseconds (ms). This assumes the maximum SL PRS bandwidth in MHz. UE 301 reports N duration values ​​in milliseconds that UE 301 supports. The duration may differ for SL-only communication compared to SL+UuPRS processing. Rx UE 301 is configured to report the maximum number of SL PRS resources that UE 301 can process in a timeslot. The maximum number may differ for FR1 compared to FR2. The maximum number of timeslots may differ for SL-only communication compared to SL+UuPRS processing.

[0080] Specific examples of the capabilities of UEs 301 and 302 are now described. UEs 301 and 302 can be configured for different values ​​of the maximum SL PRS bandwidth in MHz that they support and report. For example, UEs 301 and 302 can support the FR1 band for SL PRS within their coverage area: {5,10,20,40,50,80,100}. UEs 301 and 302 can support the FR2 band for SL PRS within their coverage area: {50,100,200,400}. UEs 301 and 302 support Type 1 or Type 2 downlink (DL) PRS buffering capabilities. For Type 1, a sub-slot / symbol-level buffering scheme is used. For Type 2, a slot-level buffering scheme is used. UEs 301 and 302 report this capability to LMF 308. Assuming the maximum DL PRS bandwidth supported and reported by the UE in MHz, UEs 301 and 302 report the duration N of DL PRS symbols that the UE can process per Tms in ms, as previously described. Exemplary values ​​for N include {0.125, 0.25, 0.5, 1, 2, 4, 6, 8, 12, 16, 20, 25, 30, 32, 35, 40, 45, 50} ms. Exemplary values ​​for T include {8, 16, 20, 30, 40, 80, 160, 320, 640, 1280} ms. The maximum number of DL PRS resources that UEs 301 and 302 can process in a time slot in each case includes the following: For the FR1 band, for each SCS with a 15kHz, 30kHz, or 60kHz band, the number can be one of {1, 2, 4, 6, 8, 12, 16, 24, 32, 48, 64}. For the FR2 band, the number of SCSs including 60kHz or 120kHz is {1,2,4,6,8,12,16,24,32,48,64}.

[0081] Once the capabilities of UEs 301 and 302 are reported to LMF 308 via AMF 306, LMF 308 is configured to configure SL PRS according to the reported capabilities. In general description, for this embodiment, LMF 308 configures the SL PRS for each of UEs 301 and 302. LMF 308 sends SL PRS configuration data to UE 302. LMF 308 receives confirmation from Tx UE 302 that the PRS configuration has been applied to Tx UE 302. LMF 308 provides the SL PRS configuration applied by Tx UE 302 to Rx UE 301, enabling Rx UE to measure PRS. LMF 308 receives the applied PRS configuration from Tx UE 302 and (via Tx UE 302) from Rx UE 301. PRS positioning measurement results 514 for the specified distance between UEs can be received from Rx UE. If the absolute coordinates of one of UEs 301 and 302 are known, the positioning measurement results of each of UEs 301 and 302 are used to determine the absolute coordinates of all UEs. The positioning measurement results may include one or more of the following: distance measurement results, time of flight measurement results, time difference of arrival measurement results, angle of arrival measurement results, or some combination thereof.

[0082] For DL ​​positioning, LMF 308 may initiate positioning procedure 322 to UE 302 to obtain a location estimate or positioning measurement result or to transmit location assistance data to UE 302. At step 322, AMF 306 collects the UE measurement results and provides them to LMF 308. LMF 308 provides a location service response (234) to AMF 306, including any results such as success or failure indications. Additionally, if requested and obtained, the results include the location estimate of UE 302. AMF 306 sends a location service response 326 to entity 310. AMF 306 returns a location service response 326 to 5GC entity 310, including results such as the location estimate of UE 302. In some implementations, AMF 306 uses location service response 324 to assist in triggering a service requested from entity 310. For example, AMF 306 can provide a location service response 328, which provides the GMLC with a location estimate of either UE 301 or 302 associated with an emergency call. Location service response 330 may include data transmission to or via UE 302 to UE 301. (See also: [link to relevant documentation]) Figure 4The specific messaging used to request capabilities from UEs 301 and 302, receive responses, and configure the UE's SL PRS can vary. In the first example, for SL PRS configuration, LMF 308 uses LPP messages to communicate with UE 302 and via UE 302 to UE 301. This is about... Figure 4 The description continues. In another example, the AMF308 communicates with UEs 301 and 302 using NRPPa signaling. In this latter example, the LMF 308 communicates via NG-RAN nodes to reach UEs 301 and 302. This example is about... Figure 4 Described.

[0083] The location determination process of Network 300 may involve using different positioning methods to obtain location-related measurements of the target UE and calculating a location estimate and possible additional information (such as velocity) from these measurements. Positioning methods include the following examples. Positioning methods for NG-RAN access include network-assisted GNSS methods, observed time difference of arrival (OTDOA) positioning, enhanced cell ID methods, WLAN positioning, Bluetooth positioning, terrestrial beacon system (TBS) positioning, and sensor-based methods including those using atmospheric pressure sensor and motion sensor data. In some implementations, hybrid positioning using multiple methods from the above list of positioning methods is also supported. In some implementations, independent modes (e.g., autonomous, without network assistance) using one or more methods from the above list of positioning methods are also supported.

[0084] Figure 4 This is a diagram illustrating network 400 that supports on-line link configuration within coverage area. For capability reporting and configuration, the LPP (LTE Location Protocol) RequestCapabilities message is enhanced, enabling the LMF 308 to request UE SL PRS capabilities. For example, this message may include support for... Figure 3The described capability request / reporting new sl-RequestCapabilities IE. When UE 302, which supports SL PRS, receives a RequestCapabilitiesLPP message with an sl-RequestCapabilities IE, UE 302 is configured to report SL PRS capabilities back to LMF 308 in a ProvideCapabilities LPP message. For example, the message may include a request for one or more of the sl-ProvideCapabilities IEs previously listed for UE 302 or for UE 301 to report via UE 302. In some implementations, a complete list of SL PRS capabilities is requested. In some implementations, specific values ​​of SL are requested, and other values ​​have default values. Each of the previously described SL PRS capabilities may be reported individually or in any combination, in addition to the general indication that UE 301 and 302 support the transition and reception of SL PRS capabilities. Even if UEs 302 and 301 support SL and UL or DL ​​positioning in the Uu interface (e.g., the NR-Uu interface for connecting the UE to the gNB in ​​the air), the UE inevitably supports “hybrid” positioning, so the reported capabilities may depend on what LMF 308 requests.

[0085] LMF 308 can configure SL PRS as described hereafter. In one implementation, LMF 308 uses LPP (LTE Positioning Protocol) messages to request SL PRS configuration directly from UE 302 or via UE 302 from UE 301. LPP messages are defined for LMF 308 to request SL PRS configuration (e.g., bandwidth or other SL PRS capabilities as previously described) from UE 302 and for UE 302 to report successful configuration (or failure). LPP messages may be referred to as SL-PRSConfigurationRequest (e.g., LMF 308 to UE 302, 301) and SL-PRSConfigurationResponse (e.g., UE 301, 302 to LMF 308). These messages are newly added to the existing LPP protocol. NG RAN nodes (e.g., gNB / TRP 402 or gNB / TRP group 404) do not read LPP messages. Therefore, the gNB does not change the ability to report to LMF 308, nor does it change the SL PRS configuration for UE301 and 302 performed by LMF 308. Figure 4In this example, LPP capability transmission 408 represents the first step for configuring SL PRS via LPP messaging. At step 408, an LPP capability transmission is performed between UEs 301 and 302 and LMF 308. Capability transmission 408 provides SL PRS capabilities from UEs 301 and 302 to LMF 308 via LPP messages. In this example, once UEs 301 and 302 are configured, LMF 308 sends LPP messages to UEs 301 and 302 to provide auxiliary data 424 or request location information 426. To reach UE 301, LPP messages 424 and 426 are sent to UE 302 via gNBs 402 and 404, and UE 302 sends the request to UE 301. UEs 301 and 302 provide response data including location information in LPP message 432. Response data 432 is sent to LMF 308 via gNBs that do not read LPP messages.

[0086] In another implementation, LMF 308 and / or gNB 402 use the NRPPa protocol RRC to configure SL PRS. In this implementation, gNB 402 configures SL PRS in UE 302 via RRC and sends the configuration to LMF 308 via NRPPa signaling. To configure UE 302, the gNB 402 message RRCReconfiguration is enhanced with SL PRS configuration parameters specifying what the SL PRS configuration for UEs 301 and 302 is. For NRPPa messages to LMF 308, the positioning information request message can be enhanced to allow LMF 308 to request (UE 302's) SL PRS configuration. Furthermore, the positioning information response message in the NRPPa signaling is enhanced to send the SL PRS configuration to LMF 308. Figure 4In step 406, NRPPa configuration is shown. To configure SL PRS using NRPPa signaling, an NRPPa DL PRS configuration IE 406 is sent as previously described. LMF 308 sends a location information request 410 using an NRPPa message. In this embodiment, at step 412, gNB 402 is configured to determine UL SRS resources. The determined SRS resource data is sent to UEs 301 and 302 (e.g., via UE 302 to UE 301). This is sent using an Rx UE SRS configuration message 414 from UE 302 to UE 301. As previously described, an NRPPa location information response 416 is sent from UE 302 to LMF 308 via gNB 402. LMF 308 responds with an NRPPa message 418 requesting UE SR activation. This is forwarded to UE 301 via UE 302 in the activation Rx UE SRS transmission 420. After configuring UEs 301 and 302 using NRPPa messages, LMF 308 sends multiple NRPPa measurement requests 422 to each of gNBs 402 and 404 in network 400. These requests 422 are forwarded to UE 302. Figure 4 As shown, UE 302 (and UE 301 via UE 302) provides location data to gNBs 402 and 404. Then, the corresponding gNBs 402 and 404 provide a measurement response to LMF 308 using NRPPa measurement response message 434.

[0087] In another implementation, LMF 308 provides the previously described SL PRS configuration as part of the auxiliary data to SL UE 302. This UE 302 performs measurements and reports location-related results. This functionality is implemented using the LPPProvideAssistanceData message 424.

[0088] In some specific implementations, when UE 302 reports SL-PRS measurement results to LMF 308, UEs 301 and 302 include the following data: The SL-PRS measurement results include the identifier of the SL-PRS transmitter, which can be either SL-PRS-ID or SL-TRP-ID. This identifier corresponds to the identifier used in LPP auxiliary data 424. The report includes the Absolute Radio Channel Number (ARFCN), which is a code specifying a pair of physical radio carriers used for transmission and reception in a terrestrial mobile radio system, one physical radio carrier for uplink signals and one physical radio carrier for downlink signals. UEs 301 and 302 may also report frequency information regarding the location of the measurement. UEs 301 and 302 may report the SL-PRS resource ID or resource set ID, which corresponds to the ID used in the LPP auxiliary data. UEs 301 and 302 may report the Relative Time of Arrival (RTOA). UEs 301 and 302 may report the Reference Signal Time Difference (RSTD). RSTD measurement results include the reference TPR concept in SL, which can be a known PRU. UEs 301 and 302 can report measurement timestamps. UEs 301 and 302 can report the timing quality of time-based measurement results. In addition to time-based or angle-based measurement results, UEs 301 and 302 can also report SL-RSRP results as another type of measurement result.

[0089] In some specific implementations, the SRS configuration may include SL-PRS-ID or SL-TRP-ID. For each SL-PRS-ID or each SL-TRP-ID, LMF 308 includes the following information for UE 301, 302 to receive and measure: LMF 308 includes a request for frequency information (including carrier (e.g., ARFCN)). LMF 308 includes a request for the starting offset of a resource or resource set (e.g., offset to DFN#0). Here, DFN refers to the direct frame number. LMF 308 includes a request for the resource repetition pattern, including slot offset and symbol offset values. LMF 308 includes a request for the expected SL-PRS measurement values. This request is to prevent measurements of distant SL transmitters using the same SL-PRS resource. LMF 308 includes a request for measurement error tolerance (e.g., uncertainty). LMF 308 includes a request for details of L1 parameters such as Tx power, comb size, and SL-PRS sequence. LMF 308 can request a reference to SL-TPR and its resource configuration.

[0090] Generally speaking, the SL-PRS ID is not part of the SL-PRS signal. A unique physical cell ID is not used in the SL channel. The receiving UE 302 uniquely identifies the SL-PRS ID by tracking unique characteristics of the PRS transmission itself (such as the timing and frequency location of resource transmissions, or a unique SL-PRS sequence).

[0091] The gNB is configured to ensure that each periodic SL-PRS resource can be uniquely associated with one SL transmitter within its cell coverage area. This can be done as part of the NRPPa messaging. However, this is not guaranteed for the LPP messaging described earlier.

[0092] The activation and deactivation of SL PRS are now described. LMF 308 uses LPP messaging to directly activate or deactivate SL PRS in UEs 301 and 302. LPP messages are defined for LMF 308 to activate and deactivate SL PRS transmissions. For example, the LPP messages are called SL-SRSActivationDeactivationRequest (for LMF 308 to UE 302 messaging) and SL-SRSActivationDeactivationResponse (for UE 302 to LMF 308 messaging).

[0093] In one example, the SL-SRSActivationDeactivationRequest IE is shown below. The SL-SRSActivationDeactivationRequest message body in the LPP message is used by the location server to request the target device to activate the SL SRS transmission.

[0094]

[0095] The following is an example SL-SRSActivationDeactivationResponse message. The SL-SRSActivationDeactivationResponse message body in the LPP message indicates the result of the SL SRS activation or deactivation request.

[0096]

[0097] In another example of activation and / or deactivation by the LMF 308, the LMF 308 sends an SLPRS activation or deactivation request to the gNB using NRPPa signaling. The gNB then activates or deactivates the SLPRS using MAC CE. The NRPPa positioning activation request / response message is enhanced to enable this functionality. An example of the NRPPa message is now described. Exemplary parameters for the positioning activation request are shown in Tables 1-2 below. Table 1 shows the configuration of the first message. This message is sent by the LMF to activate / trigger the UE's UL SRS transmission by the NG RAN node.

[0098] Table 1: NRPPa signaling for NG-RAN node location activation request / response .

[0099]

[0100] F-EF227336

[0101]

[0102] Table 2 shows the positioning activation response message. This message is sent by the NG-RAN node to confirm successful UL SRS activation in the UE.

[0103] Table 2: NG-RAN Nodes LMF Location Activation Request / Response NRPPa Signaling .

[0104]

[0105] Figure 5 This is a flowchart illustrating an exemplary process 500 for configuring side links within coverage area. Process 500 may be derived from previously mentioned... Figures 1 to 4The described components (such as networks 300 and 400) perform the following: In procedure 500, the LMF requests SL PRS capability from UEs 301 and 302 (501). The LMF 308 or gNB 402 is configured to receive Tx UE 302 SL PRS capability data and Rx UE SL PRS capability (502). As previously described, in a first embodiment, the SL PRS capability request and response are performed using LPP messaging from the LMF 308 to UEs 301 and 302. As previously described, in another embodiment, the SL PRS capability request and response are performed using NRPPa messages. When using NRPPa messages, the gNB is configured to receive capability data (or otherwise determine what the SL PRS configuration of UEs 301 and 302 is). When using LPP messages, the SL PRS configuration is performed by the AMF 308.

[0106] Procedure 500 includes configuring SL PRS based on received capability data from UEs 301 and 302 (504). When using LPP messaging, this configuration is performed by AMF 308. When using NRPPa messaging, gNB 402 can configure SL PRS. The entity configuring SL PRS (e.g., gNB 402 or AMF 308) sends the SL PRS configuration to UE 302 and then via UE 302 to UE 301 (506). AMF 308 sends an LPP message via gNB 402, but gNB 402 does not change the SL PRS configuration.

[0107] AMF 308 or gNB 402 receives confirmation from Tx UE 302 that UE 301 and UE 302 have applied the SL PRS configuration respectively (508). The SL PRS configuration is provided to Rx UE 301 so that Rx UE 301 can measure SL PRS (510).

[0108] Check the SL PRS status (512). When SL PRS is always active at check 512, AMF 308 or gNB 402 receives SL PRS positioning measurements from UE 302 specifying the distance between UEs 301 and 302 (514). When SL PRS is not always active, procedure 600 or 700 is invoked for SL PRS activation / deactivation, as described below. Once procedure 600 / 700 is executed to activate SL PRS when needed, LMF 308 or gNB 402 receives SL PRS positioning data (514).

[0109] Process 500 includes determining the absolute position of at least one of the UEs based on the distance between the received UEs 301 and 302 and the known coordinates of at least one of the UEs 301 and 302 (516).

[0110] Figure 6 This is a flowchart illustrating an exemplary process 600 for configuring in-coverage side links using LPP messages. Process 600 can be derived from previously mentioned... Figures 1 to 4 The described components (such as those in networks 300 and 400) perform this operation. When LMF 308 performs SL PRS configuration using LPP messaging, procedure 600 is executed. If SL PRS is not activated or should be deactivated, LMF 308 sends an LPP SL activation / deactivation request to Tx UE 302 via gNB 402 to activate PRS transmission (602). Procedure 600 includes causing Tx UE 302 to initiate PRS transmission based on the SL activation / deactivation request of step 602 (604).

[0111] Figure 7 This is a flowchart illustrating an exemplary process 700 for configuring in-coverage side links using NRPPa messages. Process 700 can be derived from previously mentioned... Figures 1 to 4 The described components (such as those in networks 300 and 400) perform the following: LMF 208 sends an NRPPa sidelink activation / deactivation request to gNB 402 (702). The gNB then sends the request to UE 302 to induce activation or deactivation of PRS transmission at UE 302. The gNB, through its MAC control element (CE), causes Tx UE 302 to initiate PRS transmission based on the SL activation / deactivation request of step 702 (704).

[0112] Example

[0113] Further exemplary implementations are provided in the following sections.

[0114] Example 1 includes a method for performing sidelink (SL) configuration for multiple user equipment (UEs). The method includes: sending a request for sidelink (SL) positioning reference signal (PRS) capability data to a transmitting UE (Tx UE) and a receiving UE (Rx UE); receiving corresponding SL PRS capability data from each of the Tx UE and Rx UE; configuring an SL positioning reference signal (PRS) based on the SL PRS capability data for each of the Tx UE and Rx UE; sending data specifying a selected SL PRS configuration to the Tx UE; receiving an acknowledgment signal from the Tx UE indicating the Tx UE SL PRS configuration based on the selected SL PRS configuration; and providing the Tx UE SL PRS configuration to the Rx UE.

[0115] Example 2 may include Example 1, and further includes: receiving positioning measurement results from the Rx UE based on the Tx UE SL PRS configuration.

[0116] Example 3 may include any of Examples 1-2, and further includes: configuring SLPRS by the Location Management Function (LMF).

[0117] Example 4 may include Examples 1-3, and also includes: SL PRS configured by (gNB).

[0118] Example 5 may include any one of Examples 1-4, and further includes: configuring SL PRS by gNB and LMF, wherein the LMF generates SL PRS configuration, and wherein the gNB updates at least a portion of the SL PRS configuration.

[0119] Example 6 may include any one of Examples 1-5, and further includes: the gNB sending a request for SL PRS capability data using radio control (RRC) signaling, wherein the gNB sends the capability data to the LMF using New Radio Positioning Protocol A (NRPPa) messages.

[0120] Example 7 may include any of Examples 1-6, wherein the LMF uses LTE Location Protocol (LPP) messages to send a request for SL PRS capability data.

[0121] Example 8 may include any of Examples 1-7, wherein the LMF provides SL PRS configuration as part of an LPP providing auxiliary data message sent to the Tx UE and / or Rx UE.

[0122] Example 9 may include any one of Examples 1-8, and further includes: sending an LPP message including an SL activation / deactivation request to the Tx UE via a gNB relay to activate PRS transmission; and enabling the UE to initiate PRS transmission based on the SL activation / deactivation request.

[0123] Example 10 may include any of Examples 1-9, and further includes: sending an NRPPa message including an SL activation / deactivation request to cause activation or deactivation of PRS transmission at the UE; and causing the UE to initiate PRS transmission based on the SL activation / deactivation request via a media access control (MAC) control element (CE) of the gNB.

[0124] Example 11 may include any one of Examples 1-10, wherein the SL PRS capability data includes SL-PRS-ID.

[0125] Example 12 may include any one of Examples 1-11, wherein the SL PRS capability data includes ARFCN.

[0126] Example 13 may include any one of Examples 1-12, wherein the SL PRS capability data includes one or more of the starting offset of a resource or resource set and the resource repetition pattern.

[0127] Example 14 may include any one of Examples 1-13, wherein the SL PRS capability data includes the desired SL-PRS measurement.

[0128] Example 15 may include any one of Examples 1-14, wherein the SL PRS capability data includes measurement error tolerance.

[0129] Example 16 may include any one of Examples 1-15, wherein configuring SL PRS includes configuring hybrid positioning.

[0130] Example 17 may include any one of Examples 1-16, wherein configuring SL PRS includes configuring UE-initiated on-demand SL-PRS requests.

[0131] Example 18 may include any of Examples 1-17, wherein configuring SL PRS includes configuring multipath in SL-PRS measurements.

[0132] Example 19 may include any of Examples 1-18, wherein configuring SL PRS includes configuring RSRP measurement reports.

[0133] Example 20 may include any of Examples 1-19, wherein configuring SL PRS includes configuring periodic reporting.

[0134] Example 21 may include any one of Examples 1-20, wherein configuring SL PRS includes configuring the maximum SL PRS bandwidth in MHz.

[0135] Example 22 may include any of Examples 1-21, wherein configuring SL PRS includes configuring the duration of the number of SL PRS symbols that the UE can process per given number of milliseconds.

[0136] Example 23 may include any of Examples 1-22, wherein configuring SL PRS includes configuring the number of SL PRS resources that a Tx UE or Rx UE processes in a time slot.

[0137] Example 24 includes a system configured to perform sidelink (SL) configuration for multiple user equipment (UEs), the system comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations including: sending a request for sidelink (SL) positioning reference signal (PRS) capability data to a transmitting UE (Tx UE) and a receiving UE (Rx UE); receiving corresponding SL PRS capability data from each of the Tx UE and Rx UE; configuring an SL positioning reference signal (PRS) based on the SL PRS capability data for each of the Tx UE and Rx UE; sending data specifying a selected SL PRS configuration to the Tx UE; receiving an acknowledgment signal from the Tx UE indicating a Tx UE SL PRS configuration based on the selected SL PRS configuration from the Tx UE; providing the Tx UE SL PRS configuration to the Rx UE; and receiving positioning measurement results from the Rx UE based on the Tx UE SL PRS configuration.

[0138] Example 25 may include Example 24, and also includes: configuring SL PRS by the Location Management Function (LMF).

[0139] Example 26 may include Examples 24-25, and also includes: configuring SL PRS by the next-generation node (gNB).

[0140] Example 27 may include any of Examples 24-26, and further includes: configuring SL PRS by gNB and LMF, wherein the LMF generates SL PRS configuration, and wherein the gNB updates at least a portion of the SL PRS configuration.

[0141] Example 28 may include any of Examples 24-27, and further includes: the gNB sending a request for SL PRS capability data using radio control (RRC) signaling, wherein the gNB sends the capability data to the LMF using New Radio Positioning Protocol A (NRPPa) messages.

[0142] Example 29 may include any of Examples 24-28, wherein the LMF uses LTE Location Protocol (LPP) messages to send a request for SL PRS capability data.

[0143] Example 30 may include any of Examples 24-29, wherein the LMF provides SL PRS configuration as part of an LPP providing auxiliary data message sent to the TxUE and / or RxUE.

[0144] Example 31 may include any one of Examples 24-30, and further includes: sending an LPP message including an SL activation / deactivation request to the Tx UE via a gNB relay to activate PRS transmission; and enabling the UE to initiate PRS transmission based on the SL activation / deactivation request.

[0145] Example 32 may include any of Examples 24-31, and further includes: sending an NRPPa message including an SL activation / deactivation request to cause activation or deactivation of PRS transmission at the UE; and causing the UE to initiate PRS transmission based on the SL activation / deactivation request via a media access control (MAC) control element (CE) of the gNB.

[0146] Example 33 may include any one of Examples 24-32, wherein the SL PRS capability data includes SL-PRS-ID.

[0147] Example 34 may include any one of Examples 24-33, wherein the SL PRS capability data includes ARFCN.

[0148] Example 35 may include any one of Examples 24-34, wherein the SL PRS capability data includes one or more of the starting offset of a resource or resource set and the resource repetition pattern.

[0149] Example 36 may include any one of Examples 24-35, wherein the SL PRS capability data includes the desired SL-PRS measurement.

[0150] Example 37 may include any one of Examples 24-36, wherein the SL PRS capability data includes measurement error tolerance.

[0151] Example 38 may include any of Examples 24-37, wherein configuring SL PRS includes configuring hybrid positioning.

[0152] Example 39 may include any of Examples 24-38, wherein configuring SL PRS includes configuring UE-initiated on-demand SL-PRS requests.

[0153] Example 40 may include any of Examples 24-39, wherein configuring SL PRS includes configuring multipath in SL-PRS measurements.

[0154] Example 41 may include any of Examples 24-40, wherein configuring SL PRS includes configuring RSRP measurement reports.

[0155] Example 42 may include any of Examples 24-41, wherein configuring SL PRS includes configuring periodic reporting.

[0156] Example 43 may include any one of Examples 24-42, wherein configuring SL PRS includes configuring the maximum SL PRS bandwidth in MHz.

[0157] Example 44 may include any of Examples 24-43, wherein configuring SL PRS includes configuring the duration of the number of SL PRS symbols that the UE can process per given number of milliseconds.

[0158] Example 45 may include any one of Examples 24-44, wherein configuring SL PRS includes configuring the number of SL PRS resources that a Tx UE or Rx UE processes in a time slot.

[0159] Example 46 may include a user equipment (UE) configured to perform sidelink (SL) communication, the UE comprising: at least one processor; and a memory storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations including: receiving a request from a network device for sidelink (SL) positioning reference signal (PRS) capability data; sending the SL PRS capability data to the network device; receiving from the network device data specifying a configuration of the SL PRS based on the SL positioning reference signal (PRS) capability data; sending to the network device an acknowledgment signal indicating the UE SL PRS configuration based on the specified SL PRS configuration data; receiving the SL PRS configuration of another UE from the network device; and sending to the network device positioning measurement results based on the UE SL PRS configuration and the SL PRS configuration of the other UE.

[0160] Example 47 may include Example 46, wherein the network device includes a location management function (LMF).

[0161] Example 48 may include any one of Examples 46-47, wherein the network device includes a gNB.

[0162] Example 49 may include any one of Examples 46-48, wherein the SL PRS is configured by the gNB and the LMF, wherein the LMF generates the SL PRS configuration, and wherein the gNB updates at least a portion of the SL PRS configuration.

[0163] Example 50 may include any of Examples 46-49, wherein the gNB sends a request for SL PRS capability data using Radio Resource Control (RRC) signaling, and wherein the gNB sends configuration data to the LMF using New Radio Positioning Protocol A (NRPPa) messages.

[0164] Example 51 may include any of Examples 46-50, wherein the LMF uses an LTE Location Protocol (LPP) message to send a request for SL PRS capability data.

[0165] Example 52 may include any of Examples 46-51, wherein the LMF provides SL PRS configuration as part of an LPP providing auxiliary data message sent to the UE and / or another UE.

[0166] Example 53 may include any one of Examples 46-52, and these operations further include: receiving an LPP message including an SL activation / deactivation request via a gNB relay to activate PRS transmission; and initiating PRS transmission based on the SL activation / deactivation request.

[0167] Example 54 may include any of Examples 46-54, and these operations further include: receiving an NRPPa message including an SL activation / deactivation request; and initiating a PRS transmission based on the SL activation / deactivation request in response to receiving a Media Access Control (MAC) Control Element (CE) from the gNB.

[0168] Example 55 may include any one of Examples 46-54, wherein the SL PRS capability data includes the SL-PRS-ID.

[0169] Example 56 may include any one of Examples 46-55, wherein the SL PRS capability data includes ARFCN.

[0170] Example 57 may include any of Examples 46-56, wherein the SL PRS capability data includes one or more of the starting offset of a resource or resource set and the resource repeating pattern.

[0171] Example 58 may include any of Examples 46-57, wherein the SL PRS capability data includes the desired SL-PRS measurement.

[0172] Example 59 may include any one of Examples 46-58, wherein the SL PRS capability data includes measurement error tolerance.

[0173] Example 60 may include any of Examples 46-59, wherein the SL PRS includes a hybrid positioning configuration.

[0174] Example 61 may include any of Examples 46-60, wherein configuring SL PRS includes configuring on-demand SL-PRS requests initiated by the UE.

[0175] Example 62 may include any of Examples 46-61, wherein configuring SL PRS includes configuring multipath in SL-PRS measurements.

[0176] Example 63 may include any of Examples 46-62, wherein configuring SL PRS includes configuring RSRP measurement reports.

[0177] Example 64 may include any of Examples 46-63, wherein configuring SL PRS includes the configuration of periodic reporting.

[0178] Example 65 may include any of Examples 46-64, wherein configuring SL PRS includes configuring the maximum SL PRS bandwidth in MHz.

[0179] Example 66 may include any of Examples 46-65, wherein configuring SL PRS includes configuring the duration of a number of SL PRS symbols that the UE can process per given number of milliseconds.

[0180] Example 67 may include any of Examples 46-66, wherein configuring SL PRS includes configuring the number of SL PRS resources that the UE or another UE processes in a time slot.

[0181] Example 68 may include a signal, or a portion thereof, described or associated with any of Examples 1-67.

[0182] Example 69 may include a datagram, frame, segment, PDU or message, or a portion or component thereof, as described or associated with any of Examples 1-68 or otherwise described in this disclosure.

[0183] Example 70 may include a signal, or a portion thereof, encoded with data according to any one of Examples 1-68 or otherwise described in this disclosure.

[0184] Example 71 may include a signal, or a portion thereof, encoded as a datagram, IE, packet, frame, segment, PDU, or message, as described or associated with any of Examples 1-68 or otherwise described in this disclosure.

[0185] Example 72 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or a portion thereof, as described or associated with any of Examples 1-68.

[0186] Embodiment 73 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process, or a portion thereof, as described or associated with any one of Embodiments 1-68.

[0187] Example 74 may include signals in a wireless network as shown and described herein.

[0188] Example 75 may include methods for communicating in a wireless network as shown and described herein.

[0189] Example 76 may include a system for providing wireless communication as shown and described herein.

[0190] Example 77 may include a device for providing wireless communication as shown and described herein.

[0191] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0192] Specific implementations of the subject matter and functional operations described in this specification may be implemented in digital electronic circuits, in tangibly embodied computer software or firmware, in computer hardware (including the structures disclosed herein and their equivalents), or in a combination of one or more of these. Software implementations of the subject matter may be implemented as one or more computer programs. Each computer program may include one or more modules of computer program instructions encoded on a tangible, non-transitory, computer-readable computer storage medium for execution by a data processing apparatus or for controlling the operation of the data processing apparatus. Alternatively or additionally, the program instructions may be encoded in / on an artificially generated propagated signal. In one example, the signal may be a machine-generated electrical signal, optical signal, or electromagnetic signal generated to encode information for transmission to a suitable receiver device for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of computer storage media.

[0193] The terms “data processing apparatus,” “computer,” and “computing device” (or their equivalents as understood by one of ordinary skill in the art) refer to data processing hardware. For example, a data processing apparatus may encompass various means, devices, and machines for processing data, including programmable processors, computers, or multiple processors or computers. The apparatus may also include special-purpose logic circuitry, including, for example, a central processing unit (CPU), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC). In some embodiments, the data processing apparatus or special-purpose logic circuitry (or a combination thereof) may be hardware-based or software-based (or a combination of hardware-based and software-based). The apparatus may optionally include code that creates an execution environment for computer programs, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of execution environments. This disclosure contemplates the use of data processing apparatuses with or without conventional operating systems (e.g., LINUX, UNIX, WINDOWS, MAC OS, ANDROID, or IOS).

[0194] A computer program, also referred to or described as a program, software, software application, module, software module, script, or code, can be written in any form of programming language. Programming languages ​​may include, for example, compiled languages, interpreted languages, declarative languages, or procedural languages. A program can be deployed in any form, including as a standalone program, module, component, subroutine, or unit for use in a computing environment. A computer program may, but does not necessarily, correspond to a file in a file system. A program may be stored as part of a file containing other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple harmonized files storing one or more modules, subroutines, or code portions. A computer program may be deployed to execute on a single computer or on multiple computers located at, for example, a single site or distributed across multiple sites interconnected by a communication network. While portions of a program shown in various figures may be depicted as separate modules implementing various features and functions through various objects, methods, or processes, a program may alternatively include multiple submodules, third-party services, components, and libraries. Conversely, the features and functions of various components may be combined into a single component as appropriate. Thresholds determined for computation may be determined statically, dynamically, or simultaneously statically and dynamically.

[0195] While this specification contains numerous specific implementation details, these details should not be construed as limiting the scope of the claims, but rather as descriptions of features that may be specific to particular implementations. Some features described in the context of different implementations may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may be implemented individually or in any suitable sub-combination in multiple implementations. Furthermore, while the features previously described may be described as functioning in certain combinations, and even initially claimed in this manner, one or more features in a claimed combination may be removed from that combination in certain circumstances, and the claimed combination may involve sub-combinations or variations thereof.

[0196] Specific embodiments of the subject matter have been described. Other embodiments, modifications, and arrangements of the described embodiments are within the scope of the following claims, and will be apparent to those skilled in the art. Although the operations are shown in a specific order in the drawings or claims, this should not be construed as requiring such operations to be performed in the specific order or successive order shown, or requiring the performance of all the operations shown (some operations may be considered optional) to achieve the desired result. In some cases, multitasking or parallel processing (or a combination of multitasking and parallel processing) may be advantageous and may be performed as appropriate.

[0197] Furthermore, the division or integration of various system modules and components in the previously described specific implementations should not be construed as requiring such division or integration in all specific implementations, and it should be understood that the program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0198] Therefore, the exemplary embodiments described above do not limit or restrict this disclosure. Other changes, substitutions, and modifications are also possible without departing from the spirit and scope of this disclosure.

Claims

1. A method for sidelink (SL) positioning performed by a location management function (LMF), the method comprising: Send a request for peer link (SL) positioning reference signal (PRS) capability data to the transmitting UE (Tx UE) and the receiving UE (Rx UE); Receive the corresponding SL PRS capability data from each of the Tx UE and the Rx UE; Configure an SL positioning reference signal (PRS) based on the SL PRS capability data for each of the Tx UE and the Rx UE. Send data specifying the selected SL PRS configuration to the Tx UE; Receive from the Tx UE an acknowledgment signal indicating the Tx UE SL PRS configuration based on the selected SL PRS configuration; and Provide the Rx UE with the Tx UE SL PRS configuration including bandwidth availability so that the Rx UE can measure the SL PRS.

2. The method according to claim 1, further comprising: Receive positioning measurement results from the Rx UE based on the Tx UE SL PRS configuration.

3. The method of claim 1, further comprising: The SL PRS is configured by the LMF.

4. The method of claim 1, further comprising: The SL PRS is configured by gNB.

5. The method of claim 1, further comprising: The SL PRS is configured by the gNB and the LMF, wherein the LMF generates the SL PRS configuration, and wherein the gNB updates at least a portion of the SL PRS configuration.

6. The method of claim 1, wherein the gNB sends the request for the SLPRS capability data using Radio Resource Control (RRC) signaling, and wherein the gNB sends the capability data to the LMF using New Radio Positioning Protocol A (NRPPa) messages.

7. The method of claim 1, wherein the LMF uses an LTE Location Protocol (LPP) message to send the request for the SL PRS capability data.

8. The method of claim 7, wherein the LMF provides the SL PRS configuration as part of an LPP providing auxiliary data message sent to the Tx UE and / or the Rx UE.

9. The method according to claim 1, further comprising: Activate SL PRS transmission by sending an LPP message including an SL PRS activation / deactivation request to the Tx UE via gNB relay; as well as The UE initiates SL PRS transmission based on the SL PRS activation / deactivation request.

10. The method of claim 1, further comprising: Send an NRPPa message including an SL PRS activation / deactivation request to trigger activation or deactivation of SL PRS transmission at the UE; as well as The UE initiates an SL PRS transmission based on the SL PRS activation / deactivation request via the gNB's Media Access Control (MAC) control element (CE).

11. The method of claim 1, wherein the SL PRS capability data includes SL-PRS-ID.

12. The method of claim 1, wherein the SL PRS capability data includes ARFCN.

13. The method of claim 1, wherein the SL PRS capability data includes one or more of the following: the starting offset of a resource or resource set, the resource repetition pattern, the expected SL-PRS measurement value, or the measurement error value.

14. The method of claim 1, wherein configuring the SL PRS comprises: Configure hybrid positioning, UE-initiated on-demand SL-PRS requests, multipath in SL-PRS measurements, RSRP measurement reports, periodic reports, maximum SL PRS bandwidth in MHz, duration of the number of SL PRS symbols that the UE can process in milliseconds per given number of milliseconds, or the number of SL PRS resources processed by the Tx UE or Rx UE in a time slot.

15. One or more processors, said one or more processors being configured to perform side-link (SL) localization by performing operations, said operations including: Send a request for peer link (SL) positioning reference signal (PRS) capability data to the transmitting UE (Tx UE) and the receiving UE (Rx UE); Receive the corresponding SL PRS capability data from each of the Tx UE and the Rx UE; Configure an SL positioning reference signal (PRS) based on the SL PRS capability data for each of the Tx UE and the Rx UE. Send data specifying the selected SL PRS configuration to the Tx UE; Receive from the Tx UE an acknowledgment signal indicating the Tx UE SL PRS configuration based on the selected SL PRS configuration; Provide the Rx UE with a Tx UE SL PRS configuration including bandwidth availability to enable the Rx UE to handle the SL PRS; and Receive positioning measurement results from the Rx UE based on the Tx UE SL PRS configuration.

16. The processor of claim 15, further comprising: The SL PRS is configured by the Location Management Function (LMF).

17. The processor of claim 15, further comprising: The SL PRS is configured by gNB and LMF, wherein the LMF generates the SL PRS configuration, and wherein the gNB updates at least a portion of the SL PRS configuration.

18. One or more processors according to claim 15, wherein the gNB sends the request for the SL PRS capability data using Radio Resource Control (RRC) signaling, and wherein the gNB sends the capability data to the LMF using New Radio Positioning Protocol A (NRPPa) messages.

19. The processor of claim 15, further comprising: Activate SL PRS transmission by sending an LPP message, including an SL PRS activation / deactivation request, to the Tx UE via a gNB relay; as well as The UE initiates SL PRS transmission based on the SL PRS activation / deactivation request.

20. The processor of claim 15, further comprising: Send an NRPPa message including an SL PRS activation / deactivation request to trigger activation or deactivation of SL PRS transmission at the UE; as well as The UE initiates an SL PRS transmission based on the SL PRS activation / deactivation request via the media access control (MAC) control element (CE) of the gNB.

Images