System and method for sidelink positioning protocol

Abstract

Techniques for sidelink positioning are disclosed. In an aspect, an initiating user equipment (UE) transmits a first request to create a sidelink positioning protocol (SLPP) session to each of a set of one or more receiving UEs, and receives a first response from the set of one or more receiving UEs, each indicating that the SLPP session is accepted or rejected by the receiving party. A group of one or more UEs participating in the SLPP session is determined by the initiator UE from among the recipient UEs that receive a respective first response indicating acceptance of the SLPP session. In another aspect, a UE transmitting an SLPP message may indicate a first broadcast mode (e.g., unicast, multicast, broadcast, etc.) of the SLPP message and may optionally indicate a second broadcast mode (e.g., unicast, multicast, broadcast, etc.) of a response to the SLPP message.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims the benefit of U.S. Provisional Application No. 63 / 485,378, filed on February 16, 2023, entitled “SIGNALING ASSOCIATED WITH SIDELINK POSITIONING PROTOCOL SESSION,” U.S. Provisional Application No. 63 / 494,721, filed on April 6, 2023, entitled “SIGNALING ASSOCIATED WITH SIDELINK POSITIONING PROTOCOL SESSION,” and U.S. Provisional Application No. 63 / 501,664, filed on May 11, 2023, entitled “SIGNALING ASSOCIATED WITH SIDELINK POSITIONING PROTOCOL SESSION,” each of which is assigned to the assignee of the present application and expressly incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to the field of wireless communications, and more particularly to determining the location of one or more user equipments (UEs) using radio frequency (RF) signals transmitted between UEs based on sidelink (SL) communications. Background Art

[0004] Wireless communication systems are widely deployed to provide a variety of telecommunication services, such as telephony, video, data, messaging, positioning, and broadcasting. Typical wireless communication systems employ multiple-access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power). Examples of such multiple-access systems include fourth-generation (4G) systems (such as Long Term Evolution (LTE), LTE-Advanced (LTE-A), or LTE-A Pro) systems) and fifth-generation (5G) systems (also referred to as New Radio (NR) systems).

[0005] In some examples, a wireless multiple-access communication system may include multiple base stations, each of which simultaneously supports communication for multiple communication devices (also known as user equipment (UE)). A base station may communicate with a set of one or more UEs on downlink channels (e.g., for transmissions from the base station to the UE) and uplink channels (e.g., for transmissions from the UE to the base station). Additionally, the UEs may communicate directly with each other using sidelink channels.

[0006] The location of a UE may be useful or necessary for a variety of applications, including emergency calls, navigation, direction finding, asset tracking, and internet services. For example, in a cellular network, a base station may transmit a downlink reference signal, which the UE uses to obtain positioning measurements, and / or a UE may transmit an uplink reference signal, which the base station uses to obtain positioning measurements. The UE may use the positioning measurements to calculate an estimate of its own position in UE-based positioning, or may send the positioning measurements to a network entity (e.g., a location server), which may calculate the UE's position based on the positioning measurements in UE-assisted positioning.

[0007] There are many other applications in which the location of one or more UEs may be required and in which traditional UE-based positioning and UE-assisted positioning may not be useful. Examples of such other applications include vehicle-to-everything (V2X) communication and coordination, public safety first responder scenarios, and control and coordination of automated environments such as factories and warehouses. In these applications, it may be more efficient for UEs to communicate using sidelink signaling and for the UEs to be positioned using sidelink-related positioning measurements and / or sidelink-related control signaling. In addition, procedures may be established to enable two or more UEs to perform positioning (including ranging) using sidelink communications. However, many aspects of these sidelink-based procedures have not yet been formalized. Summary of the Invention

[0008] The following is a brief overview of one or more aspects disclosed herein. Therefore, the following overview should not be considered an extensive overview of all contemplated aspects, nor should it be considered to identify key or important elements related to all contemplated aspects, or to delineate the scope of any particular aspect. Therefore, the sole purpose of the following overview is to present certain concepts related to one or more aspects of the mechanisms disclosed herein in a simplified form prior to the detailed description presented below.

[0009] In one aspect, a method of operating an initiator user equipment (UE) includes: sending a first request to each receiving UE in a set of one or more receiving UEs to create a sidelink positioning protocol (SLPP) session; receiving a first response from each receiving UE in the set of one or more receiving UEs, wherein each first response indicates acceptance or rejection of the SLPP session by the corresponding receiving UE; determining a group of one or more UEs participating in the SLPP session from the receiving UEs from which the corresponding first response indicating acceptance of the SLPP session is received; sending a second request to start the SLPP session to the group of one or more UEs; and receiving a second response from each UE in the group of one or more UEs, wherein each second response confirms the second request.

[0010] In one aspect, a method of operating a recipient user equipment (UE) includes receiving a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiator UE; and sending a first response to the initiator UE indicating acceptance or rejection of the SLPP session by the recipient UE.

[0011] In one aspect, a method of operating a user equipment (UE) includes determining a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message, the SLPP message being associated with an SLPP session; determining a second casting mode associated with one or more SLPP response messages to the SLPP message; and sending the SLPP message to a set of one or more UEs according to the first casting mode, wherein the SLPP message includes an indication of both the first casting mode and the second casting mode.

[0012] In one aspect, a method of operating a user equipment (UE) includes: receiving a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, wherein the SLPP message is received according to a first broadcast mode and the SLPP message includes an indication of both the first broadcast mode and a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and sending an SLPP response message in response to the SLPP message according to the second broadcast mode.

[0013] In one aspect, an initiator user equipment (UE) includes one or more memories; one or more transceivers; and one or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors being configured, individually or in combination, to: send a first request to create a sidelink positioning protocol (SLPP) session to each receiving UE in a set of one or more receiving UEs via the one or more transceivers; receive a first response from each receiving UE in the set of one or more receiving UEs via the one or more transceivers, wherein each first response indicates acceptance or rejection of the SLPP session by the corresponding receiving UE; determine a group of one or more UEs participating in the SLPP session from the receiving UEs from which the corresponding first response indicating acceptance of the SLPP session is received; send a second request to start the SLPP session to the group of one or more UEs via the one or more transceivers; and receive a second response from each UE in the group of one or more UEs via the one or more transceivers, wherein each second response confirms the second request.

[0014] In one aspect, a user equipment (UE) includes one or more memories; one or more transceivers; and one or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors being configured, individually or in combination, to: receive a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiator UE via the one or more transceivers; and send a first response to the initiator UE via the one or more transceivers indicating that the recipient UE accepts or rejects the SLPP session.

[0015] In one aspect, a user equipment (UE) includes one or more memories; one or more transceivers; and one or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors being configured, individually or in combination, to: determine a first broadcast mode associated with a Sidelink Positioning Protocol (SLPP) message, the SLPP message being associated with an SLPP session; determine a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and send the SLPP message to a set of one or more UEs via the one or more transceivers according to the first broadcast mode, wherein the SLPP message includes an indication of both the first broadcast mode and the second broadcast mode.

[0016] In one aspect, a user equipment (UE) includes one or more memories; one or more transceivers; and one or more processors communicatively coupled to the one or more memories and the one or more transceivers, the one or more processors being configured, individually or in combination, to: receive, via the one or more transceivers, a Sidelink Positioning Protocol (SLPP) message associated with an SLPP session, wherein the SLPP message is received according to a first broadcast mode and the SLPP message includes an indication of both the first broadcast mode and a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and send, via the one or more transceivers, an SLPP response message in response to the SLPP message according to the second broadcast mode.

[0017] In one aspect, an initiator user equipment (UE) includes means for sending a first request to each recipient UE in a set of one or more recipient UEs to create a sidelink positioning protocol (SLPP) session; means for receiving a first response from each recipient UE in the set of one or more recipient UEs, wherein each first response indicates acceptance or rejection of the SLPP session by the corresponding recipient UE; means for determining a group of one or more UEs participating in the SLPP session from the recipient UEs that received the corresponding first response indicating acceptance of the SLPP session; means for sending a second request to the group of one or more UEs to start the SLPP session; and means for receiving a second response from each UE in the group of one or more UEs, wherein each second response confirms the second request.

[0018] In one aspect, a user equipment (UE) includes means for receiving a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiator UE; and means for sending a first response to the initiator UE indicating acceptance or rejection of the SLPP session by a recipient UE.

[0019] In one aspect, a user equipment (UE) includes means for determining a first broadcast mode associated with a Sidelink Positioning Protocol (SLPP) message associated with an SLPP session; means for determining a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and means for sending the SLPP message to a set of one or more UEs according to the first broadcast mode, wherein the SLPP message includes an indication of both the first broadcast mode and the second broadcast mode.

[0020] In one aspect, a user equipment (UE) includes means for receiving a Sidelink Positioning Protocol (SLPP) message associated with an SLPP session, wherein the SLPP message is received according to a first broadcast mode and includes an indication of both the first broadcast mode and a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and means for sending an SLPP response message in response to the SLPP message according to the second broadcast mode.

[0021] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by an initiator user equipment (UE), cause the initiator UE to: send a first request to each recipient UE in a set of one or more recipient UEs to create a Sidelink Positioning Protocol (SLPP) session; receive a first response from each recipient UE in the set of one or more recipient UEs, wherein each first response indicates acceptance or rejection of the SLPP session by the corresponding recipient UE; determine a group of one or more UEs participating in the SLPP session from among the recipient UEs from which the corresponding first response indicating acceptance of the SLPP session is received; send a second request to the group of one or more UEs to start the SLPP session; and receive a second response from each UE in the group of one or more UEs, wherein each second response confirms the second request.

[0022] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a user equipment (UE), cause the UE to: receive a first request from an initiating UE to create a Sidelink Positioning Protocol (SLPP) session; and send a first response to the initiating UE indicating acceptance or rejection of the SLPP session by a receiving UE.

[0023] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a user equipment (UE), cause the UE to: determine a first broadcast mode associated with a Sidelink Positioning Protocol (SLPP) message, the SLPP message being associated with an SLPP session; determine a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and send the SLPP message to a set of one or more UEs according to the first broadcast mode, wherein the SLPP message includes an indication of both the first broadcast mode and the second broadcast mode.

[0024] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by a user equipment (UE), cause the UE to: receive a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, wherein the SLPP message is received according to a first broadcast mode and includes an indication of both the first broadcast mode and a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and send an SLPP response message in response to the SLPP message according to the second broadcast mode.

[0025] Other objects and advantages associated with the aspects disclosed herein will be apparent to those skilled in the art based on the accompanying drawings and detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] The accompanying drawings are presented to aid in describing various aspects of the disclosure and are provided solely for illustration of these aspects and not limitation of the disclosure.

[0027] Figure 1 The architecture of a communication system including multiple UEs, a radio access network (RAN), and a 5G core network (5GC) is shown.

[0028] Figure 2 The architecture of a communication system for network-supported sidelink positioning is shown.

[0029] Figure 3A and Figure 3B Various scenarios of interest for sidelink-only positioning or joint Uu and sidelink positioning according to aspects of the present disclosure are shown.

[0030] Figure 4 A reference architecture for sidelink positioning and ranging-based services for non-roaming and same-PLMN operation is shown.

[0031] Figure 5 The overall architecture of UE positioning applicable to NG-RAN according to aspects of the present disclosure is shown.

[0032] Figure 6 The SLPP protocol layering over the PC5 reference point is shown.

[0033] Figure 7 The SLPP non-IP type encoding scheme is shown.

[0034] Figures 8A-8C An example scenario of sidelink positioning / ranging according to aspects of the present disclosure is shown.

[0035] Figure 9 An SLPP session establishment process according to aspects of the present disclosure is shown.

[0036] Figure 10 An SLPP session modification procedure according to aspects of the present disclosure is shown.

[0037] Figure 11 Sidelink positioning sessionless operation according to aspects of the present disclosure is shown.

[0038] Figure 12 SLPP sessionless operation according to aspects of the present disclosure is shown.

[0039] Figure 13 Sidelink-only positioning for multiple target UEs and UE-assisted initiator (centralized) positioning computation according to aspects of the present disclosure are shown.

[0040] Figure 14Sidelink-only positioning by multiple target UEs with UE-based (distributed) positioning computation according to aspects of the present disclosure is shown.

[0041] Figure 15 A LMF-assisted sidelink positioning (MO-LR) procedure according to aspects of the present disclosure is shown.

[0042] Figure 16 LMF initiated sidelink positioning for MT-LR procedure according to aspects of the present disclosure is shown.

[0043] Figure 17 Joint Uu-sidelink positioning according to aspects of the present disclosure is shown.

[0044] Figure 18 An SLPP unicast transaction according to aspects of the present disclosure is shown.

[0045] Figure 19 An SLPP group transaction with group reply is shown according to aspects of the present disclosure.

[0046] Figure 20 An SLPP group transaction with unicast reply is shown according to aspects of the present disclosure.

[0047] Figure 21 An SLPP broadcast transaction according to aspects of the present disclosure is shown.

[0048] Figure 22 An SLPP capability transfer procedure according to aspects of the present disclosure is shown.

[0049] Figure 23 The SLPP capability indication procedure according to aspects of the present disclosure is shown.

[0050] Figure 24 The SLPP-assisted data transfer process according to aspects of the present disclosure is shown.

[0051] Figure 25 The SLPP-assisted data delivery process according to aspects of the present disclosure is shown.

[0052] Figure 26 The SLPP location information transmission process according to aspects of the present disclosure is shown.

[0053] Figure 27 The SLPP location information delivery process according to aspects of the present disclosure is shown.

[0054] Figure 28 The SLPP create session request / acceptance / rejection process according to aspects of the present disclosure is shown.

[0055] Figure 29 An SLPP session start request / response process according to aspects of the present disclosure is shown.

[0056] Figure 30 An SLPP session start request / response process according to aspects of the present disclosure is shown.

[0057] Figure 31 An SLPP session start request / response process according to aspects of the present disclosure is shown.

[0058] Figure 32 A UE-assisted (centralized) sidelink-only positioning procedure for a single target UE according to aspects of the present disclosure is shown.

[0059] Figure 33 A UE-assisted (centralized) sidelink-only positioning multiple target UEs procedure according to aspects of the present disclosure is shown.

[0060] Figure 34 A UE-assisted (centralized) sidelink-only ranging procedure for a single target UE according to aspects of the present disclosure is shown.

[0061] Figure 35 A UE-assisted (centralized) sidelink-only ranging procedure for multiple target UEs according to aspects of the present disclosure is shown.

[0062] Figure 36 A UE-based (distributed) sidelink-only positioning single target UE procedure according to aspects of the present disclosure is shown.

[0063] Figure 37 A UE-based (distributed) sidelink-only positioning multiple target UEs procedure according to aspects of the present disclosure is shown.

[0064] Figure 38 A UE-based (distributed) sidelink-only ranging procedure for a single target UE according to aspects of the present disclosure is shown.

[0065] Figure 39 A UE-based (distributed) sidelink-only ranging procedure for multiple target UEs according to aspects of the present disclosure is shown.

[0066] Figure 40A 、 Figure 40B and Figure 40C is a simplified block diagram of several sample aspects of components that may be employed in a user equipment (UE), a base station, and a network entity, respectively, and configured to support communications as taught herein.

[0067] Figure 41 An exemplary communication process according to aspects of the present disclosure is shown.

[0068] Figure 42 An exemplary communication process according to aspects of the present disclosure is shown.

[0069] Figure 43 An exemplary communication process according to aspects of the present disclosure is shown.

[0070] Figure 44 An exemplary communication process according to aspects of the present disclosure is shown.

[0071] According to certain example embodiments, the same reference numerals in the various drawings indicate the same elements. In addition, multiple instances of an element may be indicated by following the first digit of the element with a letter or hyphen and a second digit. For example, multiple instances of element 110 may be indicated as 110-1, 110-2, 110-3, etc. or 110a, 110b, 110c, etc. When only the first digit is used to refer to such an element, it should be understood that any instance of the element (e.g., element 110 in the previous example would refer to elements 110-1, 110-2, and 110-3 or elements 110a, 110b, and 110c) is used. DETAILED DESCRIPTION

[0072] Aspects of the present disclosure are provided in the following description and related drawings, which are directed to various examples provided for illustrative purposes. Alternative aspects may be designed without departing from the scope of the present disclosure. In addition, in order not to confuse the relevant details of the present disclosure, well-known elements of the present disclosure will not be described in detail or will be omitted.

[0073] This document discusses techniques and apparatus for supporting sidelink positioning (SL) between UEs. The Sidelink Positioning Protocol (SLPP) can be used to support pair-based positioning (referred to as paired mode), group operation (referred to as group mode), and network-supported sidelink positioning of UEs in SLPP.

[0074] As used herein, the words "exemplary" and / or "example" mean "serving as an example, instance, or illustration." Any aspect described herein as "exemplary" and / or "example" is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the term "aspects of the disclosure" does not require that all aspects of the disclosure include the discussed feature, advantage, or mode of operation.

[0075] Those skilled in the art will appreciate that any of a variety of different technologies and techniques may be used to represent the information and signals described below. For example, depending in part on the specific application, in part on the desired design, in part on the corresponding technology, etc., data, instructions, commands, information, signals, bits, symbols, and chips that may be mentioned throughout the following description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.

[0076] Furthermore, many aspects are described in terms of sequences of actions to be performed by, for example, elements of a computing device. It will be recognized that the various actions described herein may be performed by specific circuits (e.g., application specific integrated circuits (ASICs)), by program instructions executed by one or more processors, or by a combination of both. Additionally, the sequences of actions described herein may be considered to be fully contained in any form of non-transitory computer-readable storage medium having stored therein a corresponding set of computer instructions that, when executed, will cause or instruct an associated processor of a device to perform the functions described herein. Accordingly, various aspects of the present disclosure may be embodied in a variety of different forms, all of which are considered to be within the scope of the claimed subject matter. Furthermore, for each aspect described herein, the corresponding form of any such aspect may be described herein as, for example, "logic configured to" perform the described actions.

[0077] As used herein, the terms "user equipment" (UE) and "base station" are not intended to be specific to or limited to any particular radio access technology (RAT), unless otherwise noted. Generally speaking, a UE can be any wireless communication device (e.g., a mobile phone, router, tablet, laptop, consumer asset location device, wearable device (e.g., smartwatch, glasses, augmented reality (AR) / virtual reality (VR) headsets, etc.), vehicle (e.g., car, motorcycle, bicycle, etc.), Internet of Things (IoT) device, etc.) used by a user to communicate over a wireless communication network. A UE can be mobile or (for example, sometimes) stationary and can communicate with a radio access network (RAN). As used herein, the term "UE" can be interchangeably referred to as an "access terminal" or "AT," "client device," "wireless device," "subscriber equipment," "subscriber terminal," "subscriber station," "user terminal" or "UT," "mobile device," "mobile terminal," "mobile station," or variations thereof. Typically, a UE can communicate with a core network via the RAN, and through the core network, the UE can connect to external networks (such as the Internet) and other UEs. Of course, other mechanisms for connecting to the core network and / or the Internet are also possible for the UE, such as through a wired access network, a wireless local area network (WLAN) network (eg, based on the Institute of Electrical and Electronics Engineers (IEEE) 802.11 specification, etc.), etc.

[0078] Depending on the network in which the base station is deployed, the base station may operate according to one of several RATs for communicating with UEs and may be referred to interchangeably as an access point (AP), network node, NodeB, evolved NodeB (eNB), next-generation eNB (ng-eNB), new radio (NR) NodeB (also known as gNB or gNodeB), etc. A base station may primarily support wireless access for UEs, including supporting data, voice, and / or signaling connections for the supported UEs. In some systems, a base station may provide pure edge node signaling functionality, while in other systems it may provide additional control and / or network management functionality. The communication link through which a UE may send signals to a base station is referred to as an uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). The communication link through which a base station may send signals to a UE is referred to as a downlink (DL) or forward link channel (e.g., paging channel, control channel, broadcast channel, forward traffic channel, etc.). As used herein, the term traffic channel (TCH) may refer to either an uplink / reverse or a downlink / forward traffic channel.

[0079] The term "base station" can refer to a single physical transmit-receive point (TRP) or to multiple physical TRPs that may or may not be co-located. For example, when the term "base station" refers to a single physical TRP, the physical TRP may be the base station antenna corresponding to one cell (or several cell sectors) of the base station. When the term "base station" refers to multiple co-located physical TRPs, the physical TRP may be the base station's antenna array (e.g., in a multiple-input, multiple-output (MIMO) system or when the base station employs beamforming). When the term "base station" refers to multiple non-co-located physical TRPs, the physical TRP may be a distributed antenna system (DAS) (a network of spatially separated antennas connected to a common source via a transport medium) or a remote radio head (RRH) (a remote base station connected to a serving base station). Alternatively, a non-co-located physical TRP may be the serving base station receiving measurement reports from a UE and a neighboring base station whose reference radio frequency (RF) signal the UE is measuring. Because a TRP is the point at which a base station transmits and receives wireless signals, as used herein, references to transmissions from or receptions at a base station should be understood to refer to a specific TRP of the base station.

[0080] In some embodiments that support UE positioning, a base station may not support wireless access for the UE (e.g., may not support data, voice, and / or signaling connections for the UE), but may instead send reference signals to the UE for measurement by the UE and / or may receive and measure signals sent by the UE. Such a base station may be referred to as a positioning beacon (e.g., when sending signals to the UE) and / or a position measurement unit (e.g., when receiving and measuring signals from the UE).

[0081] An "RF signal" comprises an electromagnetic wave of a given frequency that carries information through the space between a transmitter and a receiver. As used herein, a transmitter may transmit a single "RF signal" or multiple "RF signals" to a receiver. However, due to the propagation characteristics of RF signals through multipath channels, a receiver may receive multiple "RF signals" corresponding to each transmitted RF signal. The same transmitted RF signal on different paths between a transmitter and a receiver may be referred to as a "multipath" RF signal. As used herein, an RF signal may also be referred to as a "wireless signal" or simply a "signal," where the context clearly indicates whether the term "signal" refers to a wireless signal or an RF signal.

[0082] Figure 1An example of a communication system 100 is shown that includes a first UE 105A, a second UE 105B, a third UE 105C, a radio access network (RAN) 135 (here, a fifth generation (5G) next generation (NG) RAN (NG-RAN), and a 5G core network (5GC) 140. For example, the 5GC 140 can be a public land mobile network (PLMN). The UEs 105A, 105B, and 105C may sometimes be referred to herein individually or collectively as UEs 105. The UEs 105 may be, for example, IoT devices, location tracker devices, cellular phones, vehicles, on-board units (OBUs), or other similar types of devices. The UEs 105 may also be considered RSUs or PRUs. The 5G network may also be referred to as a new radio (NR) network; the NG-RAN 135 may be referred to as a 5G RAN or an NR RAN; and the 5GC 140 may be referred to as an NG core network (NGC). 135 may be another type of RAN, for example, a 3G RAN, a 4G Long Term Evolution (LTE) RAN, etc. The communication system 100 may utilize a constellation of space vehicles (SVs) 190, which may support a satellite positioning system (SPS) (e.g., a global navigation satellite system (GNSS) such as the Global Positioning System (GPS), the Global Navigation Satellite System (GLONASS), Galileo, or BeiDou, or some other local or regional SPS such as the Indian Regional Navigation Satellite System (IRNSS), the European Geostationary Navigation Overlay Service (EGNOS), or the Wide Area Augmentation System (WAAS)). In some embodiments, the UE 105 may communicate with the earth station (ES) via the SVs 190 and the earth station ( Figure 1 110) or 5GC 140 nodes. In this case, UE 105 may not communicate directly with the RAN nodes, but rather only via SV 190. This can be used to increase the coverage and / or capacity of NG-RAN 135. Additional components of communication system 100 are described below. Communication system 100 may include additional or alternative components.

[0083] like Figure 1As shown, NG-RAN 135 includes NR nodeBs (gNBs) 110a and 110b and a next-generation eNodeB (ng-eNB) 114. 5GC 140 includes an access and mobility management function (AMF) 115, a session management function (SMF) 117, a location management function (LMF) 120, a gateway mobile location center (GMLC) 125, a user plane function (UPF) 118, and a secure user plane location (SUPL) location platform (SLP) 119. gNBs 110a, 110b, and ng-eNB 114 are communicatively coupled to each other and are each wirelessly configured for bidirectional communication with UE 105. They are also communicatively coupled to and configured for bidirectional communication with AMF 115 and UPF 118. gNBs 110a, 110b, and ng-eNB 114 may be referred to as base stations (BSs) or RAN nodes. AMF 115, SMF 117, LMF 120, and GMLC 125 are communicatively coupled to one another, and GMLC 125 is communicatively coupled to external client 130. AMF 115, SMF 117, UPF 118, and SLP 119 are communicatively coupled to one another, and SLP 119 is communicatively coupled to external client 130. According to some embodiments, server 121, Internet 122, and server 123 may be communicatively coupled to UPF 118 and may facilitate SL positioning. SMF 117 may also serve as the initial point of contact for a service control function (SCF) (not shown) to create, control, and delete media sessions. Base stations 110a, 110b, and 114 may be macro cells (e.g., high-power cellular base stations), small cells (e.g., low-power cellular base stations), or access points (e.g., short-range base stations configured to communicate using short-range technologies such as Wi-Fi, Wi-Fi Direct (Wi-Fi D), Bluetooth, Bluetooth Low Energy (BLE), Zigbee, etc.). One or more of the base stations 110a, 110b, 114 may be configured to communicate with the UE 105 via multiple carriers. Each base station 110a, 110b, 114 may provide communication coverage for a corresponding geographic area (e.g., a cell). Each cell may be divided into multiple sectors based on the capabilities of the base station antenna.

[0084] Figure 1A general description of various components is provided, any or all of which may be used as appropriate, and each of which may be duplicated or omitted as needed. Specifically, although only UE 105 is shown, many UEs (e.g., hundreds, thousands, millions, etc.) may be used in communication system 100. Similarly, communication system 100 may include a greater (or fewer) number of SVs (i.e., more or fewer than the four SVs 190 shown), gNBs 110a, 110b, ng-eNBs 114, AMFs 115, external clients 130, and / or other components. The connections shown connecting the various components of communication system 100 include data and signaling connections, which may include additional (intermediate) components, direct or indirect physical and / or wireless connections, and / or additional networks. Furthermore, components may be rearranged, combined, separated, replaced, and / or omitted, depending on the desired functionality.

[0085] although Figure 1 A 5G-based network is shown. Similar network implementations and configurations may be used for other communication technologies, such as 3G, Long Term Evolution (LTE), future 6G, etc. The embodiments described herein (whether for 5G technology and / or for one or more other communication technologies and / or protocols) may be used to transmit (or broadcast) directional synchronization signals, receive and measure the directional signals at a UE (e.g., UE 105) or base stations 110a, 110b, 114, and / or provide location assistance to UE 105 (via LMF 120 or SLP 119 or other location servers), and / or calculate the position of one or both of UEs 105 at a device with positioning capabilities, such as UE 105, base stations 110a, 110b, 114, LMF 120, or SLP 119, based on measurements of such directional transmission signals received at UE 105 or base stations 110a, 110b, 114. The GMLC 125, LMF 120, AMF 115, SMF 117, UPF 118, SLP 119, ng-eNB (eNodeB) 114 and gNB (gNodeB) 110a, 110b are examples and may be replaced by or include various other entities including location server functionality and / or base station functionality in various embodiments.

[0086] Communication system 100 is capable of wireless communication because components of system 100 can communicate with each other directly or indirectly (at least sometimes using wireless connections), for example, via base stations 110a, 110b, 114 and / or network 140 (and / or one or more other devices not shown, such as one or more other base transceiver stations). For indirect communication, changes to the communication may occur during transmission from one entity to another, such as changes to header information, formatting, etc. UE 105 may include multiple UEs and may be mobile wireless communication devices, but may also communicate wirelessly and via wired connections. UE 105 may be any of a variety of devices, such as a smartphone, tablet, or vehicle-based device, but these are merely examples, as UE 105 is not required to have any of these configurations, and other UE configurations may be used. Other UEs may include wearable devices (e.g., smart watches, smart jewelry, smart glasses, or headphones, etc.). Other UEs, whether currently existing or developed in the future, may also be used. In addition, other wireless devices (whether mobile or not) can be implemented within the system 100 and can communicate with each other and / or with the UE 105, base stations 110a, 110b, 114, the core network 140, and / or external clients 130. For example, such other devices can include IoT or IIoT devices, medical devices, home entertainment and / or automation devices, etc. The core network 140 can communicate with the external clients 130, servers 123, or servers 121 (e.g., each of which can be a computer system), for example, to allow the external clients 130, servers 123, or servers 121 to request and / or receive location information about the UE 105 (e.g., via the GMLC 125, SLP 119, or UPF 118).

[0087] The UE 105 or other device may be configured to communicate in various networks and / or for various purposes and / or using various technologies (e.g., 5G, Wi-Fi (also known as WiFi) communications, Wi-Fi communications at multiple frequencies, satellite positioning, satellite communications, one or more types of communications (e.g., GSM (Global System for Mobile), CDMA (Code Division Multiple Access), LTE (Long Term Evolution), V2X (e.g., V2P (vehicle to pedestrian), V2I (vehicle to infrastructure), V2V (vehicle to vehicle)), IEEE 802.11p, etc.) for communication. V2X communication can be cellular (Cellular-V2X (C-V2X)) and / or Wi-Fi (e.g., DSRC (Dedicated Short Range Connection)). The system 100 can support operation on multiple carriers (waveform signals of different frequencies). A multi-carrier transmitter can transmit modulated signals on multiple carriers simultaneously. Each modulated signal can be a code division multiple access (CDMA) signal, a time division multiple access (TDMA) signal, an orthogonal frequency division multiple access (OFDMA) signal, a single carrier frequency division multiple access (SC-FDMA) signal, etc. Each modulated signal can be sent on a different carrier and can carry pilots, overhead information, data, etc. UE 105 may communicate with each other by UE-to-UE sidelink (SL) communication via transmissions on one or more sidelink channels, such as a physical sidelink synchronization channel (PSSCH), a physical sidelink broadcast channel (PSBCH), a physical sidelink control channel (PSCCH), a synchronization signal block (SSB), a sidelink channel state information reference signal (SL-CSIRS), a physical sidelink feedback channel (PSFCH), a sidelink positioning reference signal (SL PRS), or a sidelink sounding reference signal (SL-SRS).

[0088] The UE 105 may include and / or may be referred to as a device, a mobile device, a wireless device, a mobile terminal, a terminal, a mobile station (MS), a terminal supporting secure user plane location (SUPL) (SET), or other designations. Typically, although not necessarily, the UE 105 may support wireless communications using one or more radio access technologies (RATs), such as Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA), Wideband CDMA (WCDMA), LTE, High Rate Packet Data (HRPD), IEEE 802.11 Wi-Fi (also known as WiFi), Bluetooth (BT), Worldwide Interoperability for Microwave Access (WiMAX), 5G New Radio (NR) (e.g., using NG-RAN 135 and 5GC 140), future 6G, etc. The UE 105 may support wireless communications using a wireless local area network (WLAN), which may be connected to other networks (e.g., the Internet) using, for example, a digital subscriber line (DSL) or packet cable. Use of one or more of these RATs may allow UE 105 to communicate with external clients 130, server 121, and / or server 123 (e.g., via elements of 5GC 140 and possibly Internet 122) and / or allow external clients 130, server 121, and / or server 123 to receive location-related information about UE 105 (e.g., via GMLC 125, SLP 119, or UPF 118).

[0089] Each UE 105 may comprise a single entity or may comprise multiple entities, such as in a personal area network, where a user may employ audio, video, and / or data I / O (input / output) devices and / or body sensors, as well as a separate wired or wireless modem. A position estimate for a UE (e.g., UE 105) may be referred to as position, position estimate, position fix, fix, position fix, position estimate, or position fix, and may be geodetic, providing the UE with position coordinates (e.g., latitude and longitude), which may or may not include an altitude component (e.g., height above sea level, height above or depth below ground level, floor level, or basement level). Alternatively, the UE's location may be expressed as a city location (e.g., a postal address or the name of a point or small area in a building, such as a specific room or floor). The UE's location may be expressed as an area or volume (defined in a geographic or city-specific manner) within which the UE is expected to be located with a certain probability or confidence level (e.g., 67%, 95%, etc.). The UE's location may be expressed as a relative position, including, for example, distance and direction from a known location. A relative position can be expressed as relative coordinates (e.g., X, Y (and Z) coordinates) defined relative to some origin at a known location, which can be defined, for example, geographically, in city terms, or by reference to a point, area, or volume indicated on a map, floor plan, or building plan. In the descriptions contained herein, unless otherwise specified, the use of the term position can include any of these variations.

[0090] When using sidelink positioning, the absolute (e.g., global) or relative position of a UE may not always be obtained. Instead, a position result for the UE may be obtained, which may include the range or distance between the UE and each of one or more other UEs, the direction from the UE to each of the one or more other UEs, the UE's position relative to the position of some other UE, the position of one or more other UEs relative to the UE's position, the UE's velocity, and / or the velocity of each of the one or more other UEs. The UE's velocity may be absolute (e.g., relative to the Earth) or relative to some other UE, which may then be referred to as "relative velocity." The relative velocity of UE B relative to another UE A may include a "radial velocity" component, which may be equal to the rate of change of the range from UE A to UE B, and a "lateral velocity" component, which may be at right angles to the radial velocity component as seen from UE A and may be equal to the angular rate of change of the direction from UE A to UE B multiplied by the range from UE A to UE B. In the description contained herein, unless otherwise specified, the term "position result" or "position results" used for sidelink positioning of a UE or group of one or more UEs may include any of these variations.

[0091] As used herein, the term "target UE" may refer to a UE for which a position result is desired. When a group of two or more UEs participates in SL positioning, only some of the group of one or more UEs may be target UEs, as position results may already be known or may not be needed for other UEs. However, in general, when discussing the techniques described herein for positioning a group of one or more UEs, all UEs may be considered potential target UEs, as there may be little or no difference in how the techniques described herein are used for positioning.

[0092] UE 105 may be configured to communicate with other entities using one or more of a variety of technologies. UE 105 may be configured to communicate with one or more other UEs (e.g., other UEs 105) via one or more device-to-device (D2D) peer-to-peer (P2P) links. The D2D P2P links may be examples of (or may be supported by) sidelink signaling and may be supported by any suitable D2D radio access technology (RAT), such as LTE Direct (LTE-D), Wi-Fi Direct (Wi-Fi D), Bluetooth, etc. One or more UEs in a group of one or more UEs utilizing D2D communication may be within the geographic coverage area of ​​a transmit / receive point (TRP), such as one or more of gNBs 110a, 110b, and / or ng-eNB 114. Other UEs in such a group may be outside such geographic coverage area or may be unable to receive transmissions from the base station. A group of UEs communicating via D2D communication may utilize a one-to-many (1:M) system, in which each UE can transmit to other UEs in the group. A TRP may facilitate resource scheduling for D2D communication. In other cases, D2D communication may occur between UEs without involving a TRP. One or more of the groups of one or more UEs utilizing D2D communication may be within the geographic coverage area of ​​a TRP. Other UEs in such groups may be outside such geographic coverage area or unable to receive transmissions from the base station. A group of UEs communicating via D2D communication may utilize a one-to-many (1:M) system, in which each UE can transmit to other UEs in the group. A TRP may facilitate resource scheduling for D2D communication. In other cases, D2D communication may occur between UEs without involving a TRP.

[0093] Figure 1 The base stations (BSs) in the NG-RAN 135 shown include NR Node Bs, referred to as gNBs 110a and 110b. The pair of gNBs 110a, 110b in the NG-RAN 135 can be connected to each other via one or more other gNBs. Access to the 5G network is provided to the UE 105 via wireless communications between the UE and one or more gNBs 110a, 110b. The gNBs 110a, 110b can provide wireless communications access to the 5GC 140 on behalf of the UE using 5G. Figure 1In the figures, the serving gNB for UE 105A is assumed to be gNB110b, and the serving gNB for UE 105B is assumed to be gNB 110a, although if UE 105 moves to another location, another gNB may serve as the serving gNB, or may serve as an assisting gNB to provide additional throughput and bandwidth to UE 105, and UE 105 may share the same serving gNB.

[0094] Figure 1 The illustrated base stations (BSs) in the NG-RAN 135 may include an ng-eNB 114, also known as a next-generation evolved Node B. The ng-eNB 114 may be connected to one or more gNBs 110a, 110b in the NG-RAN 135, possibly via one or more other gNBs and / or one or more other ng-eNBs. The ng-eNB 114 may provide LTE radio access and / or evolved LTE (eLTE) radio access to the UE 105. One or more of the gNBs 110a, 110b and / or ng-eNB 114 may be configured to function as a location-only beacon, which can transmit signals to assist in determining the location of the UE 105 but cannot receive signals from the UE 105 or other UEs.

[0095] Base stations 110a, 110b, 114 may transmit one or more downlink reference signals, including positioning reference signal (PRS) transmissions. PRS transmissions may be configured for a specific UE 105 to measure and report one or more reporting parameters (e.g., reporting quantities) associated with positioning and location information. PRS transmissions and reporting parameter feedback may support various location services (e.g., navigation systems and emergency communications). In some examples, the reporting parameters supplement one or more additional location systems supported by the UE 105, such as Global Positioning System (GPS) technology.

[0096] Base stations 110a, 110b, and 114 may configure PRS transmissions on one or more PRS resources of a channel. Depending on the number of configured ports, a PRS resource may span resource elements of multiple physical resource blocks (PRBs) within one or more OFDM symbols of a slot. For example, a PRS resource may span one symbol of a slot and include one port for transmission. In any OFDM symbol, a PRS resource may occupy consecutive PRBs. In some examples, a PRS transmission may be mapped to consecutive OFDM symbols of the slot. In other examples, a PRS transmission may be mapped to interspersed OFDM symbols of the slot. Furthermore, PRS transmissions may support frequency hopping within a PRB of the channel.

[0097] Depending on the PRS resource configuration of the base stations 110a, 110b, and 114, one or more PRS resources may span multiple PRS resource sets. The structure of one or more PRS resources, PRS resource sets, and PRS resource configurations within a PRS transmission may be referred to as a multi-level resource configuration. For example, the multi-level PRS resource configuration of the base stations 110a, 110b, and 114 may include multiple PRS resource sets, and each PRS resource set may include a set of PRS resources (e.g., a set of four PRS resources).

[0098] The UE 105 may receive a PRS transmission on one or more PRS resources in the time slot. The UE 105 may determine reporting parameters for at least some of the PRS resources included in the transmission. The reporting parameters (which may include reporting quantities) for each PRS resource may include one or more of time of arrival (TOA), reference signal time difference (RSTD), reference signal received power (RSRP), angle, PRS identification number, receive-transmit difference (UE Rx-Tx), signal-to-noise ratio (SNR), or reference signal received quality (RSRQ).

[0099] Similarly, the UE 105 may be configured to transmit one or more additional uplink reference signals, which may be received by the base stations 110a, 110b, and 114 and used for positioning. For example, the UE 105 may transmit a sounding reference signal (SRS) for positioning. The base stations 110a, 110b, and 114 receiving the uplink reference signal from the UE 105 may perform positioning measurements, such as one or more of time of arrival (TOA) and receive-transmit difference (UE Rx-Tx).

[0100] Reference signals from one or more base stations 110a, 110b, 114 or the UE, such as PRS signals or SRS signals used for positioning signals or other reference signals, can be used to determine the UE's position estimate. Positioning methods such as downlink (DL) time difference of arrival (DL-TDOA), DL angle of departure (DL-AOD), and enhanced cell ID (ECID) are positioning methods that can be used to estimate the UE's position using reference signals from base stations. For example, DL-TDOA relies on measuring the reference signal time difference (RSTD) between downlink (DL) signals received from the base station of a reference cell and the base stations of one or more neighboring cells. DL signals from which RTSD can be obtained include cell-specific reference signals (CRS) and positioning reference signals (PRS).

[0101] Other positioning methods can use reference signals transmitted by the UE, including uplink-based positioning methods and downlink-and-uplink-based positioning methods. For example, uplink-based positioning methods include UL Time Difference of Arrival (UL-TDOA), UL Angle of Arrival (UL AOA), and UL Relative Time of Arrival (UL-RTOA). Downlink-and-uplink-based positioning methods include, for example, multi-cell Round Trip Time (RTT) between the UE and one or more neighboring base stations. Additionally, sidelink-based positioning can be used, in which the UE transmits and / or receives sidelink positioning reference signals that are measured and used for positioning.

[0102] As mentioned above, although Figure 1 Nodes configured to communicate according to a 5G communication protocol are depicted, but nodes configured to communicate according to other communication protocols (such as, for example, an LTE protocol, an IEEE 802.11x protocol, or a future 6G protocol) may be used. For example, in an Evolved Packet System (EPS) that provides LTE radio access to a UE 105, the RAN may include an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), which may include base stations including evolved Node Bs (eNBs). The core network for the EPS may include an Evolved Packet Core (EPC). The EPS may include an E-UTRAN plus an EPC, where the E-UTRAN corresponds to Figure 1 NG-RAN 135 in, and EPC corresponds to Figure 1 5GC 140 in.

[0103] The gNBs 110a, 110b, and ng-eNB 114 may communicate with an AMF 115, which may communicate with an LMF 120 for positioning functions. The AMF 115 may support mobility of the UE 105, including cell changes and handovers, and may participate in supporting signaling connections to the UE 105 and possible data and voice bearers for the UE 105. The LMF 120 may communicate directly or indirectly with the UE 105, or directly or indirectly with the base stations 110a, 110b, 114, for example, via wireless communications. When the UE 105 accesses the NG-RAN 135, the LMF 120 may support positioning of the UE 105 and may support positioning procedures / methods such as Assisted GNSS (A-GNSS), Time Difference of Arrival (TDOA) (e.g., downlink (DL) TDOA or uplink (UL) TDOA), Real-Time Kinematics (RTK), Precise Point Positioning (PPP), Differential GNSS (DG NSS), Enhanced Cell ID (E-CID), Angle of Arrival (AOA), Angle of Departure (AOD), and / or other positioning methods. The LMF 120 may process location service requests for the UE 105, for example, received from the AMF 115 or from the GMLC 125. The LMF 120 may be connected to the AMF 115 and / or the GMLC 125. A node / system implementing the LMF 120 may additionally or alternatively implement other types of location support modules, such as an Enhanced Serving Mobile Location Center (E-SMLC) or a Secure User Plane Location (SUPL) Location Platform (SLP). At least some positioning functions (including deriving the UE's location) may be performed at the UE (e.g., using signal measurements obtained by the UE of signals transmitted by wireless nodes such as gNB 110a, 110b and / or ng-eNB 114 and / or assistance data provided to the UE by, for example, LMF 120). Alternatively, at least some positioning functions (including deriving the UE's location) may be performed at the LMF 120 (e.g., using signal measurements obtained by gNB 110a, 110b and / or ng-eNB 114). The AMF 115 may serve as a control node that handles signaling between the UE 105 and the core network 140 and provides QoS (Quality of Service) flow and session management. The AMF 115 may support mobility of the UE 105, including cell changes and handovers, and may participate in supporting signaling connections to the UE 105.

[0104] The GMLC 125 may support location requests for the UE 105 received from the external client 130 and may forward such location requests to the AMF 115 for forwarding by the AMF 115 to the LMF 120, or may forward the location requests directly to the LMF 120. A location response (e.g., containing a location estimate or sidelink location result for the UE 105) from the LMF 120 may be returned to the GMLC 125 directly or via the AMF 115, and the GMLC 125 may then return the location response (e.g., containing a location estimate or sidelink location result) to the external client 130. The GMLC 125 is shown connected to the AMF 115 and the LMF 120, although in some embodiments the 5GC 140 may support only one of these connections.

[0105] User Plane Function (UPF) 118 can support voice and data bearer support for UE 105 and enable voice and data access for UE 105 to other networks, such as the Internet 122, and servers, such as servers 121 and 123. UPF 118 can connect to gNB 110 and ng-eNB 114. UPF 118 functions may include: external protocol data unit (PDU) session point interconnection with data networks, packet (e.g., Internet Protocol (IP)) routing and forwarding, user plane portion of packet inspection and policy enforcement, user plane Quality of Service (QoS) processing, downlink packet buffering, and downlink data notification triggering. UPF 118 can connect to SLP 119 to support positioning of UE 105 using SUPL. SLP 119 may further connect to or be accessible from external client 130.

[0106] As shown, a session management function (SMF) 117 is connected to the AMF 115 and the UPF 118. The SMF 117 may have the ability to control both local and central UPFs within a PDU session. The SMF 117 may manage the establishment, modification, and release of PDU sessions for the UE 105, perform IP address allocation and management for the UE 105, act as a Dynamic Host Configuration Protocol (DHCP) server for the UE 105, and select and control the UPF 118 on behalf of the UE 105.

[0107] like Figure 1As further shown in FIG, LMF 120 may communicate with gNB 110a, 110b and / or ng-eNB 114 using New Radio Positioning Protocol A (NRPPa), which may be defined in 3GPP Technical Specification (TS) 38.455. NRPPa messages may be transmitted between gNB 110a (or gNB 110b) and LMF 120 via AMF 115, and / or between ng-eNB 114 and LMF 120. Figure 1 As further shown in FIG, the LMF 120 and the UE 105 may communicate using the LTE Positioning Protocol (LPP), which may be defined in 3GPP TS 37.355. Here, LPP messages may be transmitted between the UE 105 and the LMF 120 via the AMF 115 and the serving gNB 110a, 110b or the serving ng-eNB 114 for the UE 105. For example, the LPP messages may be transmitted between the LMF 120 and the AMF 115 using a service operation based on the Hypertext Transfer Protocol (HTTP), and may be transmitted between the AMF 115 and the UE 105 using a 5G Non-Access Stratum (NAS) protocol.

[0108] The LPP protocol may be used to support positioning of the UE 105 using UE-assisted and / or UE-based positioning methods such as A-GNSS, RTK, TDOA, AOA, AOD, and / or E-CID. The NRPPa protocol may be used to support positioning of the UE 105 using network-based positioning methods such as E-CID (e.g., when used with measurements obtained by the gNB 110a, 110b, or ng-eNB 114), and / or the NRPPa protocol may be used by the LMF 120 to obtain location-related information from the gNB 110a, 110b, and / or ng-eNB 114, such as parameters defining directional synchronization signal (SS) transmissions from the gNB 110a, 110b, and / or ng-eNB 114. The LMF 120 may also use the LMF 120 to obtain location-related information from the gNB 110a, 110b, and / or ng-eNB 114. Figure 1 140, but may be external to the core network 140, such as in an NG-RAN. For example, the LMF 120 may be co-located or integrated with the gNB, or may be located remotely from the gNB and configured to communicate directly or indirectly with the gNB.

[0109] Using UE-assisted positioning methods, a UE (e.g., UE 105A or UE 105B) may obtain location measurements and send them to a location server (e.g., LMF 120) for use in computing a location estimate for the UE. For example, the location measurements may include one or more of received signal strength indication (RSSI), round-trip time (RTT), reference signal time difference (RSTD), reference signal received power (RSRP), and / or reference signal received quality (RSRQ), AOA, and AOD for gNBs 110a, 110b, ng-eNB 114, and / or WLAN APs. The location measurements may also or alternatively include measurements of GNSS pseudoranges, code phase, and / or carrier phase for SVs 190-193.

[0110] With the UE-based positioning method, a UE (e.g., UE 105A or UE 105B) may obtain position measurements (e.g., which may be the same or similar to the position measurements of the UE-assisted positioning method) and may calculate the UE's position (e.g., with the aid of assistance data received from a location server such as LMF 120 or broadcast by gNB 110a, 110b, ng-eNB 114 or other base station or AP).

[0111] Using network-based positioning methods, one or more base stations (e.g., gNBs 110a, 110b and / or ng-eNB 114) may obtain location measurements (e.g., RSSI, RTT, RSRP, RSRQ, AOA, AOD, or Time of Arrival (ToA)) of signals transmitted by a UE (e.g., UE 105A or UE 105B) and / or may receive measurements obtained by the UE. One or more base stations or APs may send the measurements to a location server (e.g., LMF 120) for use in computing a position estimate for the UE.

[0112] As described above, although the communication system 100 is described in conjunction with 5G technology, the communication system 100 can be implemented to support other communication technologies for supporting and interacting with mobile devices such as UE 105 (e.g., implementing voice, data, positioning, and other functions), such as GSM, WCDMA, LTE, etc. For example, in the EPS, the NG-RAN 135 can be replaced by the E-UTRAN including the eNB, and the 5GC 140 can be replaced by the EPC including the Mobility Management Entity (MME) instead of the AMF 115, the E-SMLC instead of the LMF 120, and the GMLC that can be similar to the GMLC 125.

[0113] In radio networks such as Figure 1Positioning of a UE in the communication system 100 shown typically uses the Uu interface, i.e., the radio interface between the UE 105 and the radio access network, for DL ​​PRS and / or UL PRS. Positioning of the UE may also or alternatively use a sidelink PRS (SL PRS), which may be a reference signal defined for a specific sidelink for positioning, or may reuse the Uu PRS, such as the UL PRS, sometimes referred to as a sounding reference signal (SRS) for positioning (SRSPos), or may transmit other reference signals in the sidelink channel. Sidelink positioning may enhance UE positioning by providing additional transmitting (or receiving) nodes. A UE with a known positioning, such as UE 105B, may be used to support positioning determination of another target UE, such as UE 105A, where UE 105B is sometimes referred to as an anchor node.

[0114] Using sidelink positioning methods, UE 105A, for example, may transmit a sidelink PRS or sidelink (SL) SRS signal that is received and measured by another UE 105B. Additionally or alternatively, UE 105B may transmit a sidelink PRS or sidelink SRS signal that is received and measured by UE 105A. The sidelink PRS may be similar to the PRS (e.g., DL PRS) transmitted by gNB 110, for example, as previously described. The sidelink SRS may be similar to the SRS (e.g., uplink) SRS transmitted by UE 105 for measurement by gNB 110, for example, as previously described. The SL PRS may be transmitted on a separate, short time period (e.g., approximately 1 millisecond in duration) referred to as a "SL PRS opportunity" or "SL PRS positioning opportunity." Measurements of SL PRS or SLSRS signals can include receive-transmit time difference (Rx-Tx), time of arrival (TOA), reference signal received power (RSRP), reference signal received quality (RSRQ), angle of arrival (AOA), and reference signal time difference (RSTD). SL positioning methods can include SL round-trip time (RTT) (also known as ranging), SL AOA, and SL AOD.

[0115] In some scenarios, a group of one or more UEs 105 may support SL positioning. In this case, one UE in the group (e.g., UE 105A) may transmit a SL PRS or SL SRS signal that may be measured by some or all other UEs 105 in the group (e.g., UEs 105B and 105C). Some or all other UEs 105 in the group may also each transmit an SLPRS or SL SRS signal (e.g., where each UE 105 transmits the SL SRS or SL SRS at one or more times that are different from the times at which the other UEs 105 in the group transmit the SL PRS or SL SRS), which may be measured by some or all other UEs 105 in the group other than the UEs 105 transmitting the ULPRS or ULS SRS. Measurements made by the UEs 105 applicable to the transmission of the SL PRS or SL SRS by the group of one or more UEs 105 may include Rx-Tx, TOA, RSTD, AOA, RSRP, and RSRQ. The positioning methods supported by these measurements may include sidelink RTT (e.g., ranging), sidelink AOA, sidelink AOD, and sidelink TDOA (SL-TDOA). Based on the measurements and positioning methods, each UE 105 may determine a position result for itself and / or one or more other UEs 105 in the group. As previously described, the position result for the UE 105 may include a range or distance between the UE 105 and each of the one or more other UEs 105 in the group, a direction from the UE 105 to each of the one or more other UEs 105 in the group, a direction from each of the one or more other UEs 105 in the group to the UE 105, the position of the UE 105 relative to the position of another UE 105 in the group, the position of the UE 105 relative to another known position, the absolute position of the UE 105, the velocity of the UE 105, or the velocity of the UE 105 relative to another UE 105.

[0116] Sidelink positioning can be used to locate a UE independently of the core network (e.g., 5GC 140) or serving PLMN. One example implementation of sidelink positioning can be found in vehicle-to-everything (V2X) communication systems, which can be used for safety-related applications such as safety warnings, traffic congestion (e.g., automated traffic control), and coordinated or automated vehicle maneuvers. One aspect of sidelink positioning that may require a standardized solution is the Sidelink Positioning Protocol (SLPP), which can be used between UEs (including between an RSU and a UE), as well as between location servers. For example, SLPP can support sidelink positioning between UEs, RSUs, and PRUs independent of network access. SLPP can provide support for sidelink positioning for a pair of UEs (e.g., for ranging), a group of UEs (V2X), and UEs that are members of multiple different groups. For example, SLPP can provide support for various positioning technologies currently standardized by location servers (e.g., LMF 120) for UE-based and UE-assisted support, such as PRS RTT, AOA, Differential AOA (DAOA), AOD, and Differential AOD (DAOD), but can also enable support for other PRS- and SRS-based positioning methods and non-PRS methods such as RTK at a later date. By enabling the addition of new capabilities and methods at a later date, SLPP can avoid the need to define a separate new positioning protocol distinct from SLPP. For example, additional positioning methods that may be included in SLPP at a later date may include RTK, Wi-Fi, ultra-wideband (UWB), and BT positioning methods.

[0117] SLPP can initially enable direct sidelink operation (where UEs communicate and coordinate positioning by exchanging SLPP messages using sidelink signaling) and can later be expanded to sidelink operation via relays and operation via the network, where UEs can exchange SLPP messages via the network or via an intermediate relay UE. For example, this can be used to coordinate positioning of two vehicles on a collision course, where direct SL signals between the two vehicles are not possible around corners. Therefore, SLPP can initially define support for SL PRS-based positioning in a generic manner to simplify the subsequent expansion of support for other positioning methods. For example, SLPP can define generic SLPP messages similar to the generic LPP messages defined for LPP in 3GPP TS 37.355. Where feasible, SLPP can support separate positioning methods (e.g., SL PRS RTT, SL PRS AOA, and SL PRS AOD) using generic procedures and parameters. SLPP can define procedures that can be reused for multiple positioning methods, rather than being limited to just one or a few positioning methods. SLPP can be enabled for transmission and use by various entities (such as UEs, RSUs, and PRUs) and location servers (such as LMFs and SUPL SLPs). Location servers (e.g., LMFs and SUPL SLPs) can use SLPP messages to transmit within LPP messages to enable UE-assisted positioning with the LMF or SUPL SLP. Alternatively, location servers (e.g., LMFs and SUPL SLPs) can use SLPP messages to transmit messages not associated with LPP messages to enable UE-assisted positioning with the LMF or SUPL SLP. SLPP can further support relative (local) and global positioning.

[0118] As an example, Figure 2 FIG. 2 shows the architecture of a communication system 200 capable of network-supported sidelink positioning. Figure 2 As shown, multiple UEs (e.g., UE 105) can be combined into the same group 210 for sidelink positioning. Within group 210, various subgroups of UEs can exist. For example, group 210 of UEs can include a first subgroup 212 of UEs served by a first network (PLMN1 140a), a second subgroup 214 of UEs served by a second (different) network (PLMN2 140b), and a third subgroup 216 of UEs that are not within the coverage of, and not served by, either network. One or more of the UEs served by a network (e.g., UEs in subgroup 212 served by PLMN1 140a or UEs in subgroup 214 served by PLMN2 140b) can include an RSU.

[0119] A location server in a serving network (e.g., LMF1 120a, SUPL SLP1 119a, or Server 1 121a in serving PLMN1 140a, LMF2 120b, SUPL SLP2 119b, or Server 2 121b and Server 3 123 in serving PLMN2 140b (communicating with the UE via PLMN1 140a and / or PLMN2 140b)) may assist some or all UEs in a group served by a network (PLMN), such as subgroups 212 and 214, respectively. As shown, the location server may support the UE by communicating with the UE using "LPP / SLPP," where "LPP / SLPP" refers to communicating using LPP, SLPP, SLPP embedded in LPP, or a combination thereof. For example, LMF1 120a and LMF2 120b may embed SLPP within LPP while supporting UEs in subgroups 212 and 214, respectively (e.g., where each SLPP message transmitted between the UE and LMF1 120a or LMF2 120b is embedded within an LPP message, and where an LPP message may include one or more embedded SLPP messages). Similarly, SUPL SLP1 119a and SUPL SLP2 119b may embed SLPP within LPP while supporting UEs in subgroups 212 and 214, respectively, where LPP messages are embedded within SUPL User Plane Positioning Protocol (ULP) messages. Additionally or alternatively, LPP messages and / or SLPP messages may be used, where SLPP messages are not embedded within LPP messages (although LPP messages or SLPP messages may still be embedded within SUPL ULP messages). Additionally, UEs in each subgroup, as well as UEs in different subgroups, may exchange SLPP messages with each other to support and coordinate SL positioning.

[0120] Location server (e.g., LMF / SUPL SLP / Server 1 / Server 2 / Server 3) support for a particular UE or UEs may not be visible to other UEs in the group. For example, location server support from PLMN1 140a for UEs in subgroup 212 may not be visible to UEs in subgroup 214 and may not be visible to out-of-coverage UEs in subgroup 216. The support provided by the location server to the UEs may include determination or verification of SL PRS configuration and calculation of location results for UEs, including supported UEs and unsupported UEs (e.g., such as calculating location results for UEs in supported subgroups and UEs in unsupported subgroups, e.g., if positioning information for UEs in unsupported subgroups is provided to the location server). In some embodiments, signaling between location servers in separate networks may be used to provide more complete network support. As shown, LMF-LMF or SUPL SLP-SUPL SLP signaling may use extensions of SLPP (in Figure 2 SLPP**) to enable more complete network support.

[0121] SLPP message types may be aligned with LPP message types to enable LPP messages to contain embedded SLPP messages and / or to enable SLPP procedures to be aligned with LPP procedures, which may reduce implementation and / or testing. Figure 2 Signaling between LMF1 120a and one or more UEs of subgroup 212 (eg, a SLPP message or messages embedded in an LPP message) and signaling between LMF2 120b and one or more UEs of subgroup 214 are shown. Figure 2 SLPP messages, or LPP messages containing embedded SLPP messages, are also shown and are embedded in SUPL ULP messages. These messages are exchanged between SUPLSLP1 119a and one or more UEs in subgroup 212, and between SUPL SLP2 119b and one or more UEs in subgroup 214. SLPP may include messages similar to the LPP Request Capability message and the LPP Offer Capability message. For example, in SLPP, the messages may be referred to as "Request Capability and Resources" and "Offer Capability and Resources." Requesting / offering capabilities and resources in SLPP may initially be limited to NR SL PRS capabilities and resources, but may later be extended to capabilities and resources for LTE SL PRS, RTK, Wi-Fi, BT, and the like.

[0122] In another example, the SLPP may include a message similar to the LPP Provide Assistance Data message, which may be referred to as a "Provide Positioning Signal Configuration" (or simply "Provide Assistance Data") in the SLPP. The Provide Positioning Signal Configuration in the SLPP may include, for example, the SL PRS configuration to be transmitted by each UE and measured by other UEs, the start time and duration of the transmission, the termination condition for the transmission, and the type of SL PRS measurement requested (such as Rx-Tx, AOA, RSRP, RSRD, TOA, TDOA). In some embodiments, the Provide Positioning Signal Configuration in the SLPP may be extended to define other types of signals, such as RTK signals to be measured, Wi-Fi signals to be transmitted and measured, etc. The Provide Positioning Signal Configuration in the SLPP may include additional information, for example, to assist UEs in acquiring and measuring signals (e.g., SL PRS signals) and determining the time of transmission and measurement.

[0123] In another example, the SLPP message may include a message such as "Confirm Positioning Signal Configuration" (or "Provide Assistance Data Confirmation") that does not have a corresponding LPP message. For example, the "Confirm Positioning Signal Configuration" message in the SLPP message may confirm whether the provision of the positioning signal configuration (or provision of assistance data) is agreeable. If the provision of the positioning signal configuration is (partially) unacceptable, a different configuration may be provided as the provision of the positioning signal configuration. Because the LPP message does not have a similar message, if the SLPP message is embedded in an LPP message, a new LPP message type may be added to carry the "Confirm Positioning Signal Configuration" SLPP message. However, if the SLPP message is not embedded in an LPP message, such a new LPP message type may not be necessary.

[0124] In another example, the SLPP may include a message similar to the LPP Provide Location Information message, which may be referred to as a "Provide Location Information" message in the SLPP. The Provide Location Information message in the SLPP may include and provide SL PRS measurements obtained by the UE for SL PRSs transmitted by one or more other UEs, and / or may include and provide location results obtained for the UE and / or other UEs. The Provide Location Information in the SLPP may be extended to include and provide other measurements, such as measurements of RTK, Wi-Fi, BT, etc.

[0125] like Figure 2As shown, UEs in each subgroup and UEs in different subgroups can signal each other using SLPP (e.g., where a UE sends an SLPP message to one or more other UEs). Additionally, a location server (e.g., LMF, SUPL SLP, or servers 1-3) can support UEs using SLPP (as described above). As previously described, according to some embodiments, SLPP can be embedded in LPP, embedded in both LPP and SUPL, or can be sent without being embedded in LPP. Thus, a first UE can receive a first SLPP message from a second UE and can send the first SLPP message to a location server supporting the first UE. The first UE can receive a second SLPP message in response to the first SLPP message from the location server and can send the second SLPP message to the second UE.

[0126] NR may support or enable various sidelink positioning techniques. Figure 3A Various scenarios of interest for sidelink-only positioning or combined Uu and sidelink positioning according to aspects of the present disclosure are illustrated. In scenario 310, at least one peer UE with a known location can improve a target UE's Uu-based positioning (e.g., multi-cell round-trip time (RTT), downlink time difference of arrival (DL-TDOA), etc.) by providing an additional anchor (e.g., using sidelink RTT (SL-RTT)). In scenario 320, a low-end (e.g., reduced capacity or "RedCap") target UE can obtain assistance from a premium UE to determine its position using, for example, sidelink positioning and ranging procedures with the premium UE. Compared to the low-end UE, the premium UE may have more capabilities, such as more sensors, a faster processor, more memory, more antenna elements, higher transmit power capability, access to additional frequency bands, or any combination thereof. In scenario 330, a relay UE (e.g., with a known location) participates in the remote UE's positioning estimate without performing uplink positioning reference signal (PRS) transmission over the Uu interface. Scenario 340 illustrates joint positioning of multiple UEs. Specifically, in scenario 340, two UEs with unknown positioning can be jointly positioned in non-line-of-sight (NLOS) conditions by utilizing constraints from nearby UEs.

[0127] Figure 3BAdditional interesting scenarios for sidelink-only positioning or combined Uu and sidelink positioning according to aspects of the present disclosure are shown. In scenario 350, UEs used for public safety (e.g., police, firefighters, etc.) can perform peer-to-peer (P2P) positioning and ranging for public safety and other purposes. For example, in scenario 350, the public safety UEs may be out of coverage of the network and use sidelink positioning techniques to determine the position or relative distance and relative positioning among the public safety UEs. Similarly, scenario 360 shows multiple UEs out of coverage and using sidelink positioning techniques (such as SL-RTT) to determine the position or relative distance and relative positioning.

[0128] Using the SL positioning method (also known as "SLPP positioning"), a first UE may transmit a SL-PRS or SL-SRS signal, which is received and measured by a second UE. Additionally or alternatively, the second UE may transmit a SL-PRS or SL-SRS signal, which is received and measured by the first UE. Measurements of the SL PRS or SL SRS signal may include Rx-Tx, Time of Observation (TOA), RSRP, RSRQ, and AoA. SL positioning methods may include SL RTT (also known as ranging), SL AoA, and SL AoD. In some scenarios, a group of one or more UEs may support SL positioning. In this case, one UE in the group may transmit a SL PRS or SL SRS signal, which may be measured by some or all other UEs in the group. Some or all other UEs in the group may also transmit SL PRS or SL SRS signals (e.g., where each UE transmits the SL SRS or SL SRS at a time or times different from the time when other UEs in the group transmit the SL PRS or SL SRS), which may be measured by some or all other UEs in the group other than the UE transmitting the UL PRS or UL SRS. Measurements performed by a UE applicable to transmission of a SL PRS or SL SRS by a group of one or more UEs may include Rx-Tx, TOA, RSTD, AOA, RSRP, and RSRQ. Positioning methods supported by these measurements may include SL RTT (e.g., ranging), SL AOA, SL AOD, and SL TDOA (SL TDOA). Based on the measurements and positioning methods, each UE may determine the relative or absolute position of itself and / or other UEs. For example, the relative position of a UE may include the position of the UE relative to one or more other UEs in the group.

[0129] In some designs, location server (e.g., LMF / SUPL SLP) support for a UE may not be visible to other UEs in the group (e.g., out-of-coverage UEs). The support provided by the location server to the UE may include determination or verification of the PRS configuration and calculation of the relative location of the UE (including UEs in the supported subgroup as well as UEs in the unsupported subgroup, e.g., if location information for UEs in the unsupported subgroup is provided to the location server). For example, in some embodiments, signaling between location servers in separate networks may be used to provide more complete network support.

[0130] In some designs, the SLPP message type may be aligned with LPP so that an LPP message can contain an SLPP message. In some designs, an LPP message containing an SLPP message may be embedded in a Secure User Plane Positioning (SUPL) User Plane Positioning Protocol (ULP) message. For example, SLPP may include messages similar to the LPP request capability and offer capability messages, such as request capabilities and resources and offer capabilities and resources in SLPP. Requesting / offering capabilities and resources in SLPP may be limited to NR PRS but may be extended to LTE PRS, real-time kinematics (RTK), WiFi, BT, and others.

[0131] In another example, the SLPP may include a message similar to the LPP provision assistance data message. For example, in the SLPP, this message may be referred to as a provision positioning signal configuration message. The provision positioning signal configuration message in the SLPP message may include, for example, a PRS configuration message to be transmitted by each UE and measured by other UEs, a start time, duration, and termination conditions, and one or more of the requested measurement types (such as Rx-Tx, AOA, RSRP, and TDOA). In some embodiments, the provision positioning signal configuration message in the SLPP message may be extended to define other types of signals, such as RTK signals to be measured, WiFi signals to be transmitted and measured, and the like. The provision positioning signal configuration message in the SLPP message may include additional information, for example, to assist the UE in acquiring and measuring signals and determining transmission times.

[0132] In another example, the SLPP message may include a message such as a "Confirm Positioning Signal Configuration" message, which does not have a corresponding LPP message. For example, the "Confirm Positioning Signal Configuration" message in the SLPP message may confirm whether the provided positioning signal configuration is agreeable. If the provided positioning signal configuration is (partially) not agreeable, a different configuration may be provided as the provided positioning signal configuration. Because the LPP message does not have a similar message, a new LPP message type may be added to carry the "Confirm Positioning Signal Configuration" SLPP message.

[0133] In another example, SLPP may include a message similar to the LPP Provide Location Information message. For example, in SLPP, the message may be referred to as Provide Location Information. The Provide Location Information in SLPP may provide PRS measurements of other UEs and / or relative positions to other UEs. The Provide Location Information in SLPP may be extended to other measurements, such as RTK, WiFi, BT, etc.

[0134] In some designs described above, sidelink positioning for relative positioning, ranging, and absolute positioning may include UE discovery, session-based operation, session-less operation, capability exchange, measurement configuration, and exchange of location information derived from the performed measurements. Sidelink positioning and ranging may occur between UEs or between a UE and a LMF via multiple broadcast types, depending on the deployment scenario and operational use case.

[0135] The basis of sidelink positioning and ranging is UE peer-to-peer operation. Therefore, the current 5GS architecture using a network-based location server (user plane location server or control plane location server) is not sufficient for sidelink positioning.

[0136] Figure 4 A reference architecture 400 for sidelink positioning and ranging-based services for non-roaming and same-PLMN operation is shown. This architecture supports sidelink positioning and ranging for in-coverage (IC), out-of-coverage (OOC), and partial coverage (PC) operations and is applicable to both PC5-only and joint PC5-Uu positioning. The Sidelink Positioning / Ranging Function (SPRF) provides SLPP support between UEs to configure measurements and exchange measurement results. The SPRF can also provide position and range calculations on behalf of other UEs. For scenarios involving the LMF, the SPRF enables the LMF to request UE capability information, configure measurements, receive measurement results, and perform position and range calculations for and / or on behalf of participating UEs. Two or more UEs can participate in a one-to-many or many-to-many sidelink positioning and ranging session using discovery and positioning protocols over the SR5 reference point. SR5 is carried over the PC5 reference point and provides an interface for discovery and SLPP positioning protocols between UEs.

[0137] The terms target UE and anchor describe specific UE functions or capabilities that a UE can exercise when participating in sidelink positioning (discussed in detail below). These roles are not architectural entities, but rather UE functions. The architectural entity / node remains "UE," and each UE in the architecture can act as a "target," an "anchor," a "server," and so on, depending on its capabilities. Specifically, a UE can support several roles simultaneously. For example, a UE can be the target of positioning while also assisting in the positioning of other UEs. Therefore, the NG-RAN positioning architecture can be independent of "UE role" (function), eliminating the need to define separate architectural diagrams for UEs in coverage, partial coverage, or out of coverage.

[0138] Figure 4 The reference architecture described in can be directly mapped to Figure 5 The overall positioning architecture shown, Figure 5 An NG-RAN UE positioning architecture 500 is shown, applicable to all coverage scenarios (e.g., separate architectures are not required for in-coverage or out-of-coverage scenarios). UEs in coverage (UE A, UE B) and out-of-coverage (UE C, UE D) use SLPP for sidelink positioning and ranging over the PC5 reference point. Network components (such as LMFs supporting SLPP) can provide UE assistance by requesting UE capabilities, configuring measurements, receiving measurement results, and calculating the resulting position or relative position, as discussed further below.

[0139] In some designs, PC5-U is used for the delivery of SLPP. Figure 6 The SLPP protocol layering 600 over the PC5 reference point is shown. Figure 7 SLPP non-IP type encoding scheme 700 is shown. In some designs, for protocol layering, SLPP on PC5-U can reuse the existing SDU header type “non-IP” by simply defining an additional V2X message family encoding value (e.g., “SR5”) for the non-IP type used by SLPP, such as Figure 7 This enables SLPP signaling over SR5 to be used as a payload on the V2X application and V2X / ProSe layer. Figure 6 The PC5 user plane protocol is layered as shown.

[0140] Sidelink communications may be susceptible to packet loss due to changes in UE separation / proximity (such as in the case of mobile UEs) or due to obstruction between UEs. This behavior is characteristic of sidelink communications regardless of the broadcast or transport type. This packet loss may result in the loss of SLPP messages.

[0141] In the case of LPP for Uu operation, LPP message loss is also possible when the LPP message is not successfully forwarded by the MME or AMF. Therefore, LPP already includes reliable delivery mechanisms, including LPP-level acknowledgment and retransmission capabilities. Since PC5-U delivery itself does not provide a reliable delivery mechanism, SLPP can also support LPP acknowledgment and retransmission capabilities, allowing the SLPP process to be designed with redundancy and transport fault tolerance. To leverage redundancy, a UE can send an SLPP request message to a group of one or more UEs, each of which responds with an acknowledgment of acceptance of the message or an acknowledgment that it has performed or can later perform the requested action (e.g., transmitting and / or measuring sidelink reference signals). If each response also carries the original information from the SLPP request message, any UE that did not receive the SLPP request message but received at least one response message can infer and reconstruct the original SLPP request, thereby overcoming the loss of the original SLPP message. Using LPP-based reliability applied to SLPP, the sender of an SLPP request message to a group of one or more UEs can determine when the target UE does not receive the message and then take appropriate action, such as resending the request message at a later time, or not expecting the non-responsive UE to take the requested action.

[0142] LPP-based reliability implemented in SLPP is relevant for session-based operation, in which a group of one or more UEs participating in a sidelink ranging and positioning session will benefit from reliable delivery, particularly if the resulting ranging / positioning is applied to group operations. If the session leader (initiator) determines that reliability is appropriate for the session, the leader may choose to invoke reliability. In contrast, sessionless operation seeks to minimize the overhead and latency of ranging / positioning between UEs with temporary, brief interactions and, therefore, may not require reliable delivery. Therefore, the initiator of a session-based or sessionless sidelink ranging and positioning transaction has the flexibility to decide whether to invoke SLPP reliable delivery. LPP-based reliability implemented in SLPP provides the additional advantage that SLPP can operate reliably between the UE and the LMF, as discussed further below.

[0143] In some designs, communication via the sidelink may result in packet loss due to changes in the relative positioning of participating UEs and / or shadowing, potentially leading to loss of SLPP messages. Mechanisms may be added to support SLPP robustness, such as redundancy, acknowledgment and retransmission, and / or tolerance to delivery failures.

[0144] In some designs, the LPP reliable transport mechanism of duplicate detection, acknowledgment, and retransmission can be applied to SLPP.

[0145] In some designs, SLPP supports at least the LPP reliable transport mechanism for duplicate detection, acknowledgment, and retransmission.

[0146] In some designs, with respect to session-based and sessionless operation, sidelink positioning supports the session-based concept in SLPP, where signaling messages within a session can be correlated with each other by the involved UEs. In some designs, sessionless operation may also be supported.

[0147] In some designs, with respect to session-based and sessionless operation, SLPP sessionless operation may be supported, at least in the case of supporting positioning methods that do not require the mutual exchange of SLPP messages associated with each other among UEs. In some designs, sessionless operation may operate securely.

[0148] In some designs, for session-based SLPP, an SLPP session is used among UEs with only PC5 to obtain location-related measurements / position estimates, transfer assistance data, or exchange capabilities.

[0149] In some designs, for session-based SLPP, a single SLPP session is created to support a single location request at least with a single target UE. In one aspect, support for sessions with multiple target UEs in a single location request may be provided.

[0150] In some designs, for session-based SLPP, SLPP transactions are indicated at the SLPP protocol layer using a transaction ID to associate messages with each other (e.g., requests and responses).

[0151] In some designs, for session-based SLPP, messages within a transaction are linked by a common transaction identifier.

[0152] In some designs, group positioning may be utilized to obtain position estimates for multiple target UEs (absolute positioning) or multiple UE pairs (ranging / relative positioning) per LCS request. In some designs, at least part of the group management for group positioning may be performed at the upper / application layer.

[0153] Sidelink positioning can support numerous use cases, including V2X, public safety (PS), commercial, and Industrial Internet of Things (IIoT). These use cases may involve fixed UEs, mobile UEs, or a combination / group of fixed and mobile UEs. In one of these use cases, an individual UE can initiate a sidelink positioning session with one or more UEs in its proximity (UEs with which sidelink communication can be established). These UEs can constitute all UEs in the initiating UE's proximity, a subset of UEs in the initiating UE's proximity, or a single UE in the initiating UE's proximity. Group-based use cases for sidelink ranging and positioning include V2X scenarios with RSUs and multiple vehicles, multiple vehicles in a fleet, mission-critical (MCX) services, and museum or other tours.

[0154] Figures 8A-8C An example use case is shown in . Figures 8A-8C Example sidelink positioning / ranging scenarios 800, 820, and 830 are shown, respectively, according to aspects of the present disclosure. Figure 8A In , UE1 initiates a sidelink positioning session with the only UE in its vicinity. Figure 8B In , UE1 initiates a sidelink positioning session with a subset of four UEs in its vicinity, while Figure 8C In the example, UE1 initiates a sidelink positioning session with all UEs in its vicinity. Figures 8A-8C The examples in

[15] are for V2X use cases, but the three scenarios shown are equally applicable to public safety, commercial, and IIoT use cases. In one aspect, a UE may initiate a sidelink positioning session with one of its neighboring UEs or with a group of one or more neighboring UEs. When initiating a sidelink positioning session with a group of one or more UEs, the group may constitute all or a subset of the UEs in the neighboring UE.

[0155] For sidelink positioning and ranging scenarios, where participating UEs are aware of each other’s presence (e.g. if Figure 8B Three participating UEs or Figure 8C For sidelink positioning and ranging scenarios that do not require the exchange of SLPP messages to associate with each other, sessionless operation can be used (e.g., if the participating UEs do not have an established association). The determination of session-based or sessionless operation can be made by the application layer based on the specific scenario, use case, and determination of the participating UEs (e.g., the location / range of a specific set of one or more UEs or the location / range of a group of neighboring UEs). The session-based or sessionless transaction is then instantiated by SLPP. The following description provides a description of possible SLPP session establishment, termination, and modification.

[0156] LPP does not support explicit management of LPP sessions and services. An LPP session is always a one-to-one association between a UE and a location server, where the location server (e.g., LMF in the NR case) is always assumed to control the LPP session, not the UE. In contrast, for sidelink positioning, a UE can participate in multiple SLPP sessions simultaneously (V2X, MCX, public safety, etc.). Each individual SLPP session can be with different UEs, different groups of one or more UEs, or overlapping groups of UEs. Each SLPP session may have different requirements for ranging, positioning, periodicity, methods used, etc. A UE participating in multiple SLPP sessions must maintain knowledge and state of the different sessions and session participants, each with different session participants and different session requirements. To accommodate UE operational considerations, including power consumption and privacy, the UE may also be able to accept or reject session participation. Furthermore, given the mobile nature of sidelink UEs, the composition of session participants may change over the course of a session, which implies the need to support session modification and termination capabilities. These aspects of sidelink positioning session operation (explicit session acceptance, rejection, modification, and termination) cannot be directly supported using SLPP-based LPP capabilities, assistance data, and location information. Instead, new SLPP messages are required, which can be considered as part of SLPP session and service management.

[0157] The following description of SLPP session establishment and session modification assumes that SLPP supports session acceptance, rejection, termination, and modification. Note that these SLPP features are not required for sessionless operation.

[0158] Figure 9 The SLPP session establishment process 900 according to aspects of the present disclosure is shown. In some designs, SLPP is carried as a payload on the V2X / ProSe layer, and interaction and exchange are performed between the application layer and the SLPP layer. Figure 9 This includes operations 0 to 8, which are summarized as follows:

[0159] Figure 9 , operation 0: The application layer in UE1 and other UEs can perform UE discovery, determine and verify the requested services, and perform group management (e.g., create a group containing UEs 1 to n). The application layer in UE1 also verifies that all UEs 1 to n support SLPP. The application layer in UE1 then requests sidelink ranging and positioning results for UEs 1 to n from the SLPP layer in UE1, and provides the SLPP layer in UE1 with the application layer ID and layer 2 ID for each of UEs 1 to n. It can also provide an application layer group ID and layer 2 group ID for a group of one or more UEs 1 to n. In some designs, the exact API between the application layer and the SLPP layer can be considered implementation-dependent.

[0160] Figure 9 , Operation 1UE1 sends an SLPP Create Session Request message to each of UE2 through n. This message includes the SLPP session ID assigned by UE1 and may include the Layer 2 group ID of the SLPP session. The SLPP Create Session Request message also includes an SLPP transaction ID to correlate the SLPP Create Session Request message with received SLPP Create Session Accept and SLPP Create Session Reject messages. The SLPP Create Session Request message may be sent via unicast, multicast, or broadcast.

[0161] Figure 9 , Operation 2 Each UE (from UE2 to n) that can accept the session request sends an SLPP Create Session Accept message to UE1. Otherwise, the UE sends an SLPP Create Session Reject message to UE1. The SLPP Create Session Accept and SLPP Create Session Reject messages include the SLPP transaction ID associated with the SLPP Create Session Request message. The SLPP Create Session Accept and SLPP Create Session Reject messages can be sent via unicast, multicast, or broadcast.

[0162] Figure 9 , Operation 3 : UE1 determines the UE to be used for the SLPP session from the UEs that return the SLPP Create Session Accept in operation 2. Figure 9 In this example, it is assumed that all UEs 2 to n accept the SLPP session request.

[0163] Figure 9 , Operation 4 UE1 sends an SLPP Session Start Request message to UE2-n identified for the session in operation 3 to start the SLPP session. The SLPP Session Start Request message includes the Application Layer ID and Layer 2 ID of each UE in the session, as well as the SLPP UE ID assigned by UE1 to locate each UE in the session. The SLPP UE ID can be an integer (e.g., in the range of 1 to n) that identifies each UE within the SLPP session. The SLPP Session Start Request message also includes an SLPP Transaction ID to correlate the SLPP Session Start Request message with the received SLPP Session Start Response message. The SLPP Session Start Request message can be sent via unicast, multicast, or broadcast.

[0164] Figure 9 , Operation 5UE2-n confirms the session start with an SLPP Session Start Response: Accept message, after which positioning within the session can begin. The SLPP Session Start Response: Accept message includes the SLPP transaction ID associated with the SLPP Create Session Start Request message. The SLPP Session Start Response: Accept message can be sent via unicast, multicast, or broadcast. In one aspect, after performing session establishment at operations 4 and 5, all UEs 1-n will be aware of all other UEs in the session, including their application layer IDs, layer 2 IDs, SLPP IDs, layer 2 group IDs, etc. Subsequently, only the SLPP UE ID and SLPP session ID are required in subsequent SLPP transactions (e.g., at operation 6).

[0165] Figure 9 , Operation 6 : Execute SL positioning / ranging process.

[0166] Figure 9 , Operation 7-8 Once positioning is complete (e.g., upon completing the application layer request at operation 0), UE1 may send an SLPP Session End Request message to each participant, UE2-n. Each UE acknowledges the SLPP Session End Request message by sending an SLPP Session End Response message back to UE1. The SLPP Session End Request and SLPP Session End Response messages include an SLPP transaction ID to correlate the request and response messages. The SLPP Session End Request and SLPP Session End Response messages may be sent via unicast, multicast, or broadcast.

[0167] refer to Figure 9 In one aspect, the SLPP layer may assign an SLPP session ID that is unique to a particular sidelink positioning session and an individual SLPP ID for each UE participating in the session. The SLPP ID may be an integer (e.g., in the range of 1 to n). The SLPP session ID may be an integer value or may include a unique identifier for UE1 plus a local numeric ID assigned by UE1.

[0168] For example, Figure 10 As shown, the SLPP session can be modified by adding or removing UEs. Figure 10 An SLPP session modification process 1000 is shown in accordance with aspects of the present disclosure.

[0169] Session modification is particularly relevant to sidelink positioning, given the dynamic nature of the sidelink use case introduced by UE mobility. The accessibility of UEs within any initial set of one or more UEs in a sidelink ranging / positioning session is likely to change during the ranging / positioning session. The initial set of one or more UEs in an SLPP session may also change, for example, after the SLPP session has been established. Figure 9The SLPP session may change during operation 6 in step 1 because not all UEs may have the required SLPP positioning capabilities (e.g., SL-PRS, SL positioning method capabilities, the ability to act as an anchor UE, etc.). Therefore, UEs may need to be removed from the SLPP session, and newly discovered UEs may need to be added to the SLPP session. The application layer may also determine the addition and removal of UEs for other reasons (e.g., due to changes in the service requirements of some UEs).

[0170] Figure 10 shows a method for modifying an SLPP session (e.g., which may have been used Figure 9 The process 1000 is established by the process 900 and includes operations 0 to 4, which are summarized as follows:

[0171] Figure 10 , operation 0 : The application layer in UE1 may request the SLPP layer to add and / or remove UEs from the group of one or more UEs for which an SLPP session was previously established. Alternatively or additionally, the SLPP layer in UE1 may detect that some UEs in the SLPP session are no longer available for SLPP positioning (e.g., due to no longer being within the PC5 range of other UEs or due to insufficient resources or capabilities to perform SLPP positioning) and may need to remove these UEs from the previously established SLPP session.

[0172] Figure 10 , Operation 1 : UE1 sends an SLPP Modify Session Request to a modified set of one or more UEs in the SLPP session (UEs currently in the modified session and any new UEs). The SLPP Modify Session Request message may be unicast, multicast, or broadcast to both the current UE and the new UE (e.g., using a new Layer 2 Group ID provided by the application layer in operation 0). The SLPP Modify Session Request message may include the new Layer 2 Group ID of the SLPP modified session and the new SLPP Session ID. UEs currently in the SLPP session may be addressed using their SLPP UE IDs, and any new UEs may be addressed using their Application Layer IDs. If it is not possible or not permitted (e.g., for policy reasons) to multicast or broadcast the message to both the current UE and the new UE, UE1 performs Figure 9 1 and 2 of the SLPP establishment procedure 900 to create an SLPP modified session for the new UE. For existing UEs that may not be part of the modified session, UE1 may perform Figure 9 The SLPP sessions of these UEs are terminated through operations 7 and 8 of the SLPP establishment procedure 900. The SLPP modify session request message includes an SLPP transaction ID to associate the SLPP modify session request message with the received SLPP modify session accept / reject message.

[0173] Figure 10 , Operation 2 Each UE capable of accepting the session modification request (UE 2 through n) sends an SLPP Modify Session Accept message to UE 1. Otherwise, each UE sends an SLPP Modify Session Reject message to UE 1. The SLPP Modify Session Accept and SLPP Modify Session Reject messages can be sent via unicast, multicast, or broadcast. The SLPP Modify Session Accept and SLPP Modify Session Reject messages include the SLPP transaction ID associated with the SLPP Modify Session Request message.

[0174] Figure 10 , Operation 3 : UE1 returns the SLPP Modify Session Accept message in operation 2 or performs the Figure 9 In the case of operations 1 and 2, the UE that returns the SLPP Create Session Accept message determines the UE used for the SLPP Modify Session.

[0175] Figure 10 , Operation 4 :UE1 according to Figure 9 Operations 4-8 of the SLPP modified session are continued to establish the SLPP session. In this case, at operation 4, UE1 assigns a new SLPP UE ID to all UEs.

[0176] refer to Figure 10 In one aspect, for SLPP session-based operations, SLPP may support at least the following message types:

[0177] • SLPP create session request / accept / reject

[0178] •SLPP session start request / response (*)

[0179] •SLPP session end request / response (*)

[0180] •SLPP session modification request / accept / reject (*)

[0181] Note that the messages indicated above with an asterisk (*) may be combined into a single SLPP message using the Create / Modify / Release mechanism.

[0182] In addition to session-based operation, many sidelink positioning / ranging use cases can benefit from session-less operation, and to support session-less operation, the following can be supported: SLPP session-less operation can be supported, at least in the case of supporting positioning methods that do not require the mutual exchange of SLPP messages associated with each other among UEs. In some designs, session-less operation can operate securely.

[0183] Sessionless operation use cases include situations with dynamic or mobile UEs where it is desirable to minimize the signaling overhead and associated session establishment delays that may be incurred by session-based operations. Applicable scenarios include situations where a UE needs to determine the location / range of its neighboring UEs for temporary or brief time intervals, such as when a vehicle is crossing an intersection, a vehicle is entering a highway from an on-ramp, or public safety personnel are moving around an action area. Figure 11 An example scenario 1100 for a V2X use case is shown in FIG.

[0184] refer to Figure 11 , for the case of a vehicle crossing an intersection, the RSU UE performs sidelink positioning / ranging on the UE. In such a scenario, the set of one or more UEs close to and interested in the RSU for sidelink positioning often changes, thereby facilitating more flexible, session-less operation. Note that although this scenario shows session-less operation for fixed UEs ( Figure 11 The benefits of session-less operation are not achieved for the RSU in the UE, but session-less operation is also applicable and beneficial for mobile UEs (vehicles) that initiate sidelink positioning.

[0185] In some designs, the signaling overhead of sessionless operation is minimized to accommodate dynamic UE conditions, as shown below. Figure 12 As stated.

[0186] Figure 12 SLPP sessionless operation 1200 is shown in accordance with aspects of the present disclosure. Figure 12 It includes operations 1 to 6, which are summarized as follows:

[0187] Figure 12 , Operation 1 : The application layer in UE1 can request the SLPP layer to initiate sidelink positioning for UEs that may be in the vicinity of UE1. The application layer in UE1 can make this request to the SLPP layer periodically through configuration or based on the determination of its neighboring UEs or through other means. UE1 sends an SLPP Provide Assistance Data message via connectionless multicast or broadcast. The SLPP Provide Assistance Data message includes the SL-PRS configuration of the UEs that can participate (for example, based on compatible capabilities). The SLPP Provide Assistance Data message includes an SLPP transaction ID to associate the SLPP Provide Assistance Data message with the received SLPP Request Location Information message and SLPP Provide Location Information message.

[0188] Note that a UE receiving an SLPP Provide Assistance Data message without mutually exchanging SLPP Session Establishment messages may determine that this is for a sessionless sidelink ranging / positioning session by omitting the SLPP Session ID or by other means from the allocated space of SLPP Session IDs.

[0189] Figure 12 , Operation 2At operation 4, each of UEs 2-n determines the SL-PRS configuration to be transmitted. This may be based on the SL-PRS configuration information received at operation 1. Optionally, each of UEs 2-n transmits an SLPP Provide Assistance Data message via connectionless multicast or broadcast. The SLPP Provide Assistance Data message includes the SL-PRS configuration that each UE may transmit at operation 4 and the UE's identity (e.g., application layer ID).

[0190] Figure 12 , Operation 3 Each of UE1 and optionally UE2-n transmits an SLPP Request Location Information message via connectionless multicast or broadcast. The SLPP Request Location Information message indicates the measurement result to be obtained in operation 5 and / or the location result to be transmitted in operation 6. The SLPP Request Location Information message includes an SLPP transaction ID to associate the SLPP Request Location Information message with the received SLPP Provide Assistance Data message.

[0191] Figure 12 , Operation 4 : Each participating UE transmits its own SL-PRS according to the SL-PRS configuration indicated in operation 1 or determined in operation 2. In operation 1 or operation 2, the duration of SL-PRS transmission may be controlled by a timer provided in the SLPP Provide Assistance Data message.

[0192] Figure 12 , Operation 5 : Each participating UE performs SL-PRS measurement according to the configuration in the SLPP Provide Assistance Data message in operation 1 or operation 2 or as requested in operation 3.

[0193] Figure 12 , Operation 6 Upon completion of SL-PRS transmission and SL-PRS measurement, or periodically during this period, the participating UE transmits an SLPP Provide Location Information message including the measurement results obtained in operation 5. Based on the configuration received in the SLPP Provide Assistance Data message, SL-PRS transmission and SL-PRS measurement may be performed periodically. The SLPP Provide Location Information message includes an SLPP transaction ID to associate the SLPP Provide Location Information message with the received SLPP Provide Assistance Data message.

[0194] refer to Figure 12In some designs, session-less operation is established without exchanging SLPP session establishment signaling via SLPP Offer Assistance Data messages. In some designs, the SLPP session ID can be assigned a specific ID value to indicate session-less operation. The importance of group positioning for sidelink ranging and positioning is clear. Because SLPP on PC5-U is carried as a V2X payload, group management can be implemented by leveraging upper / application layers that provide group information to the V2X (SLPP) layer. The upper / application layers manage group composition and group identity and provide overall group management to the lower layer (SLPP).

[0195] refer to Figure 12 ,In some designs, group positioning is used to obtain position estimates for multiple target UEs (absolute positioning) or multiple UE pairs (ranging / relative positioning) per LCS request.

[0196] refer to Figure 12 In some designs, at least part of the group management for group positioning is performed at the upper / application layer.

[0197] Ranging and positioning calculations performed by UEs participating in sidelink positioning and ranging, including range / positioning calculations performed by one UE on behalf of multiple target UEs (UE-assisted) and range / positioning calculations performed by multiple target UEs (UE-based), may be supported via at least unicast SLPP / RSPP "centralized" operation (i.e., operation in which one UE performs range and / or positioning calculations based on measurement / position information related to itself and / or other UEs). If group positioning is determined to be supported, performing at least ranging at multiple UEs using estimated calculations may be feasible.

[0198] Figure 12 and Figure 13 Example process flows for SLPP UE-assisted (one UE performs range / positioning calculations on behalf of multiple target UEs) and UE-based (multiple target UEs perform range / positioning calculations) are shown. Note that both UE-assisted and UE-based operations follow the same first seven operations (session establishment, capability transfer, and assistance data exchange).

[0199] Figure 13 Session-based sidelink-only positioning 1300 with UE-assisted initiator (centralized) positioning computation for multiple target UEs is shown in accordance with aspects of the present disclosure. Figure 13 It includes operations 1 to 11, which are summarized as follows:

[0200] Figure 13 , Operation 1 : UE B performs the SLPP session establishment procedure described (e.g., Figure 9 shown).

[0201] Figure 13 , Operation 2 UE B sends an SLPP Request Capability message to the group of multiple target UEs established in operation 1. The SLPP Request Capability message requests SL positioning capabilities from the UEs participating in the session. Depending on the specific scenario, the SLPP Request Capability message can be sent by UE B to UE A, UE C, and UE D via broadcast, multicast, or unicast.

[0202] Figure 13 , Operation 3 The multiple target UEs addressed by UE B in operation 2 respond with an SLPP Provide Capabilities message. UE capabilities may refer to specific sidelink positioning methods (e.g., SL-RTT, SL-AoA, SL-TDOA, etc.) or may be common to multiple positioning methods. Capabilities may also include SL-PRS capabilities, an indication of whether the UE can act as an anchor UE and / or a location server UE, position / range calculation capabilities, etc. If the UE can act as an anchor UE, the SLPP Provide Capabilities message may also include location coordinates. Depending on the specific scenario, UE A, UE C, and UE D may send the SLPP Provide Capabilities message via broadcast, multicast, or unicast.

[0203] Figure 13 , Operation 4 : Can be based on capability information from operation 3, such as Figure 10 The SLPP session is modified (eg, removing UEs with incompatible capabilities such as SL positioning method, anchor capability, etc.).

[0204] Figure 13 , Operation 5 : UE B sends an SLPP Provide Assistance Data message to the group of multiple target UEs established in operation 1 or 4. The SLPP Provide Assistance Data message includes the SL-PRS configuration for each UE in the group. The SLPP Provide Assistance Data message may be sent via broadcast, multicast, or unicast, depending on the specific scenario. After receiving the assistance data (or at an indicated start time included in the message), each UE in the group of multiple target UEs transmits its corresponding SL-PRS. The duration of SL-PRS transmission may be controlled by a timer provided in the message or may continue until the SLPP session is terminated in operation 11. Depending on the specific scenario, the SL-PRS may be sent via broadcast, multicast, or unicast.

[0205] Figure 13 , Operation 6 UE B sends an SLPP Request Location Information message to a group of one or more UEs. This message indicates the type of location information required and the associated QoS (e.g., expected accuracy, response time, etc.). The message also includes an indication that the initiating UE (UE B) may perform range / positioning calculations. Depending on the specific scenario, the SLPP Request Location Information message may be sent via broadcast, multicast, or unicast.

[0206] Figure 13 , Operation 7: Each participating UE performs the requested SL-PRS transmission and measurement.

[0207] Figure 13 , Operation 8 Upon completion of transmission and measurement, or periodically, or after expiration of the response time received in operation 6, each of the multiple target UEs transmits an SLPP Provide Location Information message with the location result requested in operation 6. The message may also include an indication of whether to request the other UE (in this case, the initiating UE B) to provide the location result (e.g., calculated range and / or position) back to the UE. Based on the configuration received in the SLPP Provide Assistance Data message, SL-PRS transmission and SL-PRS measurement may be performed periodically. Depending on the specific scenario, the SLPP Provide Location Information message may be sent via broadcast, multicast, or unicast.

[0208] Figure 13 , Operation 9 : The initiating UE B performs range / positioning calculations using the location result received at operation 8 and the location result already obtained by UE B at operation 7.

[0209] Figure 13 , Operation 10 : If requested in operation 8, UE B may distribute the location results of UEs A, C, D to other UEs A, C, D in the session. Depending on the specific scenario, the location results may be distributed via broadcast, multicast, or unicast.

[0210] Figure 13 , Operation 11 : SLPP session can be terminated (e.g. Figure 9 shown).

[0211] Figure 14 Session-based sidelink-only positioning 1400 is shown, wherein multiple target UEs perform UE-based (distributed) positioning calculations according to aspects of the present disclosure. Figure 14 It includes operations 1 to 11, which are summarized as follows:

[0212] Figure 14 , operations 1-5 :and Figure 13 Same as in.

[0213] Figure 14 , Operation 6 UE B sends an SLPP Request Location Information message to a group of multiple target UEs. The message indicates the type of location information required and the associated QoS (e.g., desired accuracy, response time, etc.). The message also includes an indication that each participating UE can perform range / positioning calculations. Depending on the specific scenario, the SLPP Request Location Information message can be sent by UE B to UE A, UE C, and UE D via broadcast, multicast, or unicast.

[0214] Figure 14 , Operation 7-8 :and Figure 13 Same as in.

[0215] Figure 14 , Operation 9 : Each participating UE performs range / positioning calculations using the position result received at operation 8 and its own position result obtained at operation 7.

[0216] Figure 14 , Operation 10 : If requested in operation 8, each UE may distribute its location result to other UEs in the session. Depending on the specific scenario, the location result may be distributed via broadcast, multicast or unicast.

[0217] Figure 14 , Operation 11 : SLPP session can be terminated (e.g. Figure 9 shown).

[0218] refer to Figure 14 In some designs, UE-based (distributed) sidelink positioning and ranging enables UE positioning calculation to be independent of individual UEs and may reduce the overall SLPP signaling required for sidelink positioning. In one aspect, SLPP may support UE-based (distributed) sidelink positioning, enabling multiple target UEs to determine position and range based on exchanged location information.

[0219] Regarding multicast and broadcast transmission of SLPP, in some designs it is feasible to send at least the following positioning signaling for multicast / broadcast (in addition to unicast):

[0220] •SL positioning capability

[0221] •SL positioning assistance data

[0222] •SL position measurement and information

[0223] In some designs, such as Figure 13 and Figure 14 As shown, UE assisted ( Figure 13 ) and UE-based ( Figure 14 Sidelink ranging and positioning both involve capability exchange and assistance data transfer between multiple target UEs and between multiple target UEs. In some designs, unicast, multicast, or broadcast transmission can be used for capability exchange and assistance data transfer. In some designs, security of sidelink ranging and positioning signaling via multicast and broadcast is feasible. Regarding location information exchange, location information exchange can support multicast / broadcast transmission.

[0224] In some designs, sidelink ranging and positioning signaling sent via multicast or broadcast can be supported. The solution for secure SLPP transmission via multicast or broadcast removes any obstacles or barriers to secure distribution of capabilities, assistance data, and location information via multicast or broadcast.

[0225] In some designs, with respect to 3GPP prioritization, existing application layer messages defined by SDOs including ETSI-ITS, SAE, and CSAE that include UE GNSS location and UE GNSS location accuracy (e.g., CAM, BSM, CPM, SDSM, etc.) carried as 3GPP V2X payloads may be supported. Since SLPP is also carried as a V2X payload, the communication of location information does not pose a risk to UE operation.

[0226] In some designs, with the discretion of the sending UE, the distribution of location information can be determined or selected by the sending (transmitting) UE. If the sending UE is subject to policy or other restrictions on the exchange of location information, it can choose not to distribute location information. In one aspect, the security of multicast or broadcast transmission does not hinder the exchange of location information via multicast / broadcast. In one aspect, existing 3GPP V2X payload standardized messages support the exchange of UE GNSS location and UE GNSS location accuracy via multicast and broadcast. In one aspect, SLPP supports the exchange of location information via unicast, multicast, and broadcast.

[0227] The basic SLPP transaction types (capability transfer, assistance data transfer, location information transfer) applicable to support sidelink positioning and ranging scenarios outside coverage may also be applied in coverage and partial coverage scenarios. These scenarios include LMF assisted (MO-LR) and LMF initiated (MT-LR) sidelink positioning and ranging. When at least one participating UE is in network coverage and is enabled to access a PLMN by subscription, the UE may request LMF assistance for a sidelink positioning and ranging session, or may be requested by the LMF to participate in a sidelink positioning and ranging session. In this mode of operation, not all UEs may have access to a PLMN and be supported by or to have support provided to them by the LMF (LMF support may be limited to certain UEs). Possible examples of LMF assisted (MO-LR) and LMF initiated (MT-LR) sidelink positioning and ranging are shown in Figures 1 and 2, respectively. Figure 15 and Figure 16 Shown in.

[0228] Figure 15 The LMF assisted sidelink positioning mobile originated location request (MO-LR) process 1500 is shown according to aspects of the present disclosure. Specifically, Figure 15 An example of LMF-assisted sidelink positioning and ranging is shown, where the LMF acts as an adjunct for UE B in network coverage and initiates a sidelink positioning and ranging session. Figure 15 Operations 1 to 16 are included, which are summarized as follows:

[0229] Figure 15 , operations 1-4 :and Figure 13 The operations 1-4 are the same as in .

[0230] Figure 15 , Operation 5 : Initiating UE B requests positioning assistance from the LMF by sending a supplementary service (e.g., MO-LR) request to the LMF via the serving AMF of UE B. UE B may indicate whether LMF assistance in the form of assistance data and / or position calculation is required.

[0231] Figure 15 , Operation 6 As part of operation 5, initiating UE B may include the SL-PRS capabilities of all UEs (operation 6b) and a request for specific assistance data (operation 6c). Alternatively, the LMF may request the SL-PRS capabilities of all UEs in operation 6a, and UE B may then return the capabilities in operation 6b and send a request for specific assistance data in operation 6c. The LMF then determines the requested assistance data and provides it to UE B in an SLPP Provide Assistance Data message in operation 6d.

[0232] Figure 15 , Operation 7 : If UE B requests position calculation assistance at operation 5, the LMF sends SLPP request location information to UE B to request position measurement results consistent with the SL-PRS capabilities of all UEs received at operation 6b and any assistance data sent at operation 6d.

[0233] Figure 15 , Operation 8-11 :and Figure 13 Operations 5-8 are the same as in .

[0234] Figure 15 , Operation 12 : If operation 7 does not occur, the initiating UE B may perform range / positioning calculations using the location result received at operation 11 and the location result already obtained by UE B at operation 10.

[0235] Figure 15 , Operation 13 : If operation 7 does occur, UE B provides the location measurements obtained from all participating UEs in the session to the LMF in an SLPP Provide Location Information message.

[0236] Figure 15 , Operation 14 : LMF performs range / positioning calculations.

[0237] Figure 15 , Operation 15 : The LMF provides the calculated range / positioning to UE B via the serving AMF in the supplementary service (e.g. MO-LR) response.

[0238] Figure 15 , Operation 16 : SLPP session can be as follows Figure 9 Said is terminated.

[0239] refer to Figure 15In one aspect, a new supplementary service operation or MO-LR for UE-initiated SLPP transactions towards LMF may be supported.

[0240] Figure 16 An LMF initiated sidelink positioning for a Mobile Terminated Location Request (MT-LR) procedure 1600 is shown in accordance with aspects of the present disclosure. Figure 16 An example of LMF initiated sidelink positioning and ranging operation with a target UE (UE B) in network coverage to obtain MT-LR position result is shown. The MT-LR may have been located by an external client or AF ( Figure 16 (not shown), the external client or AF will provide all necessary information of MT-LR to LMF (e.g. via GMLC and AMF). Figure 16 It includes operations 1 to 10, which are summarized as follows:

[0241] Figure 16 , Operation 1 The LMF requests sidelink positioning from UE B via a Supplementary Service Request message to the SL MT-LR. The Location Request indicates the type of location result requested (e.g., the location of UE B and / or other UEs), the identity and / or address of the specific UEs to be addressed (e.g., UE A, C, D), or whether any UE can be used, and whether a single set of location results (immediate location) or deferred (e.g., periodic or triggered) location results are requested. The Supplementary Service Request may also include an embedded SLPP Request Location Information message indicating the specific SLPP location results or measurements to be provided by UE B, and / or an embedded SLPP Provide Assistance Data message to provide assistance data (e.g., SL-PRS configuration) for the SLPP positioning session to UE B.

[0242] Figure 16 , Operation 2 :UE B tries to discover other UEs A, C, D (if not already discovered) and establish an SLPP session, such as Figure 9 As stated.

[0243] Figure 16 , Operation 3 : UE B sends an SLPP request capability message to the group of one or more UEs established in operation 2, requesting SL positioning capability from the UEs participating in the session.

[0244] Figure 16 , Operation 4 : The UE in operation 3 addressed by UE B responds with an SLPP OfferCapability message.

[0245] Figure 16 , Operation 5 :UE B can stimulate Figure 10 The SLPP session modification process.

[0246] Figure 16 , Operation 6 : UE B confirms or acknowledges the supplementary service request from operation 1 with a supplementary service response. The supplementary service response may indicate whether any requested UEs are available for positioning (eg, whether UEs A, C, D have been discovered by UE B).

[0247] Figure 16 , Operation 7 : Sidelink positioning / ranging also appears in Figure 13 Operation 5-10, Figure 14 Operation 5-10 or Figure 15 Operations 5-12.

[0248] Figure 16 , Operation 8 : UE B provides the LMF with the location results and / or measurements obtained from all participating UEs in the session in the SLPP Provide Location Information message.

[0249] Figure 16 , Operation 9 : If not already included in operation 8, the LMF performs the range / positioning calculation for the UE and returns the position to the external client or AF. For delayed (periodic or triggered) positioning, the SLPP positioning of UE B and the return of the position result to the LMF may be repeated.

[0250] Figure 16 , Operation 10 : SLPP session can be as follows Figure 9 Termination as described.

[0251] refer to Figure 16 In one aspect, new supplementary service operations for SLPP transactions initiated by MT-LR or LMF towards the UE may be supported.

[0252] On the one hand, the basic SLPP transaction types and procedures for capability transfer, assistance data transfer, and location information transfer are applicable to support sidelink positioning and ranging scenarios in coverage, partial coverage, and outside coverage, and can also be applied to support joint sidelink-Uu positioning. This can be simply achieved by targeting Figure 17 The desired positioning method shown is achieved by jointly performing SLPP, LPP, and NRPPa procedures. For Uu-only positioning, LPP and NRPPa are jointly used for UE positioning operations (e.g., for multi-RTT). For joint Uu and SL positioning, any combination of LPP, SLPP, and NRPPa can be used, depending on the desired positioning method (UL, DL, and SL positioning).

[0253] Figure 17 A joint Uu-sidelink positioning process 1700 is shown in accordance with aspects of the present disclosure. Figure 17 It includes operations 1 to 7, which are summarized as follows:

[0254] Figure 17 , Operation 1: LMF can obtain sidelink positioning capability from the target UE and can request sidelink position results from the target UE.

[0255] Figure 17 , Operation 2 : The LMF can obtain the LPP positioning method capabilities from the target UE and can request location results for one or more LPP positioning methods.

[0256] Figure 17 , Operation 3 : The LMF may request UL-SRS configuration from the serving NG-RAN node of the target device and may configure a TRP for UL-SRS measurement. Note: The procedures and transactions of operations 1-3 may be sequenced in any preferred order. For example, the LMF may first jointly obtain the capabilities of SLPP and LPP, then jointly request the location results of SLPP and LPP, etc.

[0257] Figure 17 , Operation 4 :The target device executes as Figure 13 The sidelink positioning process described.

[0258] Figure 17 , Operation 5 : The target device provides SLPP position results to LMF.

[0259] Figure 17 , Operation 6 : The target device provides the LPP position result to the LMF.

[0260] Figure 17 , Operation 7 : TRP provides NRPPa position results to LMF.

[0261] On the one hand, Figure 17 Procedure 1700 can support hybrid / joint Uu (including RAT-independent methods) and sidelink positioning in the same manner as currently supported using LPP (and potentially NRPPa). For example, several LPP positioning methods can be used for the same positioning session. The LMF is aware that different positioning methods apply to the same positioning session. The UE is unaware unless the same LPP messages and transactions are used for different positioning methods. When different LPP transactions and messages are used, the UE may not know whether different positioning methods refer to the same LPP session or different LPP sessions. When both Uu and PC5-based procedures and signaling are used, from the perspective of the coordination entity (in this case, the LMF), the Uu and PC5-based positioning procedures are part of the same positioning session. This approach allows for the independent definition and use of SLPP, LPP, and NRPPa, even though the coordination entity (such as the LMF) may be aware of a common positioning session. Specifically, this means that SLPP signaling does not need to convey LPP session-related information, and similarly, LPP signaling does not need to convey SLPP session-related information. This can significantly reduce SLPP and LPP impact, standardization impact, and requirements on the UE and network.

[0262] refer to Figure 17 , on the one hand, hybrid Uu, SL and RAT-independent positioning can be supported by jointly using SLPP, LPP and NRPPa procedures.

[0263] refer to Figure 17 On the one hand, using SLPP transactions / procedures independently of LPP also means that there is no additional impact on UEs (and LMFs) that do not need to support sidelink positioning, and vice versa. For example, if an LMF or UE is to receive an LPP message with sidelink positioning content, then decoding of the LPP message may need to be "sidelink-capable" even if that content is not supported. Similarly, if a sidelink positioning or ranging device (or LMF) does not need to support LPP positioning, then it is not necessary to support LPP only for sidelink positioning or ranging content. This allows for the definition of a smaller protocol, reducing the Abstract Syntax Notation One (ASN.1) definition footprint for the protocol and associated processing support. This can simplify UE implementation when LPP is not required.

[0264] refer to Figure 17 ,On one hand, using LMF as SLPP endpoint not only allows SLPP messages to be embedded in ,supplementary service operations (e.g., MT-LR, MO-LR, etc.), but also enables joint sidelink and Uu positioning with minimal ,changes to existing protocols.

[0265] refer to Figure 17 On the one hand, using LMF as SLPP endpoint will allow sidelink-only positioning (with LMF support) without LPP support, which will reduce the complexity of sidelink-only positioning and ranging devices and LMF.

[0266] refer to Figure 17 In one aspect, specifying the sidelink positioning functionality isolated within the SLPP does not require modifications to the LPP and therefore does not increase the LPP ASN.1 footprint for UEs and LMFs that are not sidelink capable.

[0267] refer to Figure 17 In one aspect, the LMF may be a protocol endpoint of the SLPP.

[0268] In one aspect, SLPP messages may be sent via broadcast, multicast, or unicast, depending on the specific scenario. SLPP may indicate the transaction (communication) mode to be used for each SLPP message, i.e., whether broadcast mode, multicast mode, or unicast mode is to be used (e.g., in a common SLPP message header). SLPP may support at least the following general transaction modes:

[0269] •Unicast transactions

[0270] • Group transactions with group replies

[0271] • Group transactions with unicast replies

[0272] • Broadcasting

[0273] The exact API between the SLPP layer and the transport layer may depend on the implementation.

[0274] Figure 18 An SLPP unicast transaction 1800 is shown in accordance with aspects of the present disclosure. Figure 18 This includes operations 1 to 2, which are summarized as follows:

[0275] Figure 18 , Operation 1 : UE A sends an SLPP message to UE B. The message includes the SLPP mode set to "unicast". The message includes the SLPP session ID (if applicable), the transaction ID, and the source and destination UE IDs (e.g., application layer ID, layer 2 ID, SLPP UE ID).

[0276] Figure 18 , Operation 2 : If the SLPP message from operation 1 requires a response, UE B sends a SLPP message to UE A, where the SLPP mode is set to "unicast" and the transaction ID and UE A's destination ID are as received in operation 1.

[0277] Figure 19 An SLPP group transaction 1900 with group reply is shown in accordance with aspects of the present disclosure. Figure 19 This includes operations 1 to 2, which are summarized as follows:

[0278] Figure 19 , Operation 1 : UE A sends an SLPP message to a group of one or more UEs (UE B, C, D, etc.). The message includes the SLPP mode set to "Multicast-Group Reply," indicating that the destination UE can respond via multicast, or to "Multicast" if the SLPP message does not require a response. The message includes the SLPP session ID (if applicable), transaction ID, and group ID (e.g., application layer group ID, layer 2 group ID, or SLPP group ID).

[0279] Figure 19 , Operation 2 If the SLPP message received by destination UEs B, C, D, etc. from operation 1 requires a response (SLPP mode is set to "Multicast - Group Reply"), UEs B, C, D, etc. send an SLPP message with the SLPP mode set to "Multicast" (and thus also returned to the other UEs in the group). The message includes the session ID (if applicable), the transaction ID, and the group ID received in operation 1.

[0280] Figure 20 An SLPP group transaction 2000 with unicast reply is shown in accordance with aspects of the present disclosure. Figure 20 This includes operations 1 to 2, which are summarized as follows:

[0281] Figure 20 , Operation 1 : UE A sends an SLPP message to a group of one or more UEs (UEs B, C, D, etc.). The message includes the SLPP mode set to "Groupcast-Unicast Reply," indicating that the destination UE can respond via unicast. If no response is requested, the SLPP mode may indicate "Multicast." The message includes the SLPP session ID (if applicable), the transaction ID, and the group ID (e.g., application layer group ID, layer 2 group ID, or SLPP group ID).

[0282] Figure 20 , Operation 2 If the SLPP message from operation 1 received by destination UEs B, C, D, etc. requires a response, then UEs B, C, D, etc. each send an SLPP message with the SLPP mode set to "unicast." The message includes the session ID (if applicable), the transaction ID and source UE ID of the individual UEs, and the destination ID of UE A received in operation 1.

[0283] Figure 21 An SLPP broadcast transaction 2100 is shown in accordance with aspects of the present disclosure. Figure 21 This includes operations 1 to 2, which are summarized as follows:

[0284] Figure 21 , Operation 1 : UE A sends an SLPP message with the SLPP mode set to "broadcast". The message includes the SLPP session ID (if applicable) and the transaction ID.

[0285] Figure 21 , Operation 2 : If the SLPP message from operation 1 received by UE B, C, D, etc. requires a response, UE B, C, D, etc. sends SLPP information with SLPP mode set to "broadcast". The message includes the SLPP session ID (if received in operation 1) and the transaction ID.

[0286] refer to Figure 21 In one aspect, SLPP may indicate the transaction (communication) mode to be used for each SLPP message, i.e., whether broadcast mode, multicast mode, or unicast mode is to be used (e.g., in a common SLPP message header). At least the following common transaction modes may be supported:

[0287] •Unicast transactions

[0288] • Group transactions with group replies

[0289] • Group transactions with unicast replies

[0290] • Broadcasting affairs.

[0291] Note that not all transaction modes allow all SLPP message types.

[0292] In terms of SLPP functionality, to enable sidelink positioning, SLPP / RSPP may support at least the following functions:

[0293] •1.SL positioning capability transmission

[0294] •2.SL positioning assistance data exchange

[0295] •3.SL location information transmission

[0296] •4. Error handling

[0297] 5. Give Up

[0298] Capabilities in the context of SLPP may refer to the ability to support different positioning methods defined for SLPP (e.g., SL-RTT, SL-TDOA, etc.), different aspects of specific positioning methods (e.g., different types of measurements or assistance data), and features specific to certain UE roles (e.g., the ability to operate as a server or anchor UE, etc.).

[0299] The exchange of capabilities between different endpoints can be initiated by a request or sent as unsolicited information. If a request is used, the endpoint sends an SLPP RequestCapabilities message using one of the request's allowed transaction modes with the capabilities information. The addressed endpoint then responds with an SLPP OfferCapabilities message.

[0300] Note that an endpoint may include one or more UEs or LMFs.

[0301] Figure 22 An SLPP capability transfer process 2200 is shown in accordance with aspects of the present disclosure. Figure 22 This includes operations 1 to 2, which are summarized as follows:

[0302] Figure 22 , Operation 1 : A sending endpoint may use one of the above SLPP transaction modes to send a request for SLPP-related capabilities to one or more receiving endpoints.

[0303] Figure 22 , Operation 2 : The receiving endpoint communicates its SLPP-related capabilities to the sending endpoint using one of the above SLPP transaction modes. Capabilities may refer to a specific positioning method or may be common to multiple positioning methods.

[0304] refer to Figure 22In one aspect, the SLPP Capability Indication procedure is used for unsolicited capability transfer.

[0305] Figure 23 An SLPP capability indication process 2300 is shown in accordance with aspects of the present disclosure. Figure 23 This includes operation 1, which is summarized as follows:

[0306] Figure 23 , Operation 1 : The sending endpoint uses one of the above SLPP transaction modes to provide SLPP-related capabilities to one or more receiving endpoints.

[0307] refer to Figure 23 In one aspect, SLPP-related capabilities may include the general information summarized in Table 1 below:

[0308] information SL positioning capabilities: -Supported positioning methods and measurement values ​​for each method (e.g., SL-RTT, SL-AoA, SL-TDOA) - Supported SL-PRS details -Support positioning computing capabilities -UE-based: A UE can calculate its own positioning using its own and other UEs’ measurements -UE Assisted: UE can only perform measurements; requires a separate server (UE or LMF) to perform positioning calculations Anchor ability (yes / no): - UE's location coordinates (if available) NOTE: Anchor UE location may also be obtained / updated via the location information transfer procedure. - Fixed / unfixed indication and / or speed - Timing / synchronization capabilities (e.g., TDOA methods); e.g., GNSS-DFN accuracy Location Server Capability (yes / no): -Positioning calculation function of other UEs - Supported methods: For example, RTT, AoA, TDOA - Assist in data generation / distribution functions - Supported assistance data types (TBD) - It can also indicate whether the UE can act as a server UE with the help of LMF

[0309] Table 1: SLPP related capabilities

[0310] refer to Figure 23 ,On the one hand, the SLPP provides capabilities message can provide information about the device's ability to support different positioning methods defined for SLPP (e.g., SL-RTT, SL-TDOA, etc.), different aspects of specific positioning methods (e.g., different types of measurements or assistance data), and features specific to certain UE roles (e.g., the ability to operate as a server or anchor UE, etc.).

[0311] Assistance data may include SL-PRS configuration information and may be delivered either by request or unsolicited. If request is used, the endpoint sends a SLPP Request Assistance Data message for SL-PRS assistance data to a server (e.g., a UE or LMF (via MO-LR)), indicating the required assistance data. The addressed endpoint then responds with a SLPP Offer Assistance Data message.

[0312] Figure 24 An SLPP-assisted data transfer process 2400 is shown in accordance with aspects of the present disclosure. Figure 24 It includes operations 1 to 3, which are summarized as follows:

[0313] Figure 24 , Operation 1 : The sending endpoint may send a request for assistance data to the receiving endpoint (e.g., server UE or LMF) using one of the above SLPP transaction modes. The message may indicate the specific assistance data required.

[0314] Figure 24 , Operation 2 : The receiving endpoint transmits assistance data to the transmitting endpoint using one of the above SLPP transaction modes. The assistance data transmitted can match any assistance data requested in operation 1.

[0315] Figure 24 , Operation 3 : The receiving endpoint may transmit additional assistance data to the sending endpoint in one or more additional SLPP Provide Assistance Data messages.

[0316] refer to Figure 24 In one aspect, the SLPP Assisted Data Transfer procedure is used for unsolicited assistance data transfer.

[0317] Figure 25 An SLPP-assisted data transfer process 2500 is shown in accordance with aspects of the present disclosure. Figure 25 This includes operations 1 to 2, which are summarized as follows:

[0318] Figure 25 , Operation 1 : The sending endpoint uses one of the above SLPP transaction modes to transmit assistance data to one or more receiving endpoints.

[0319] Figure 25 , Operation 2 : The sending endpoint may transmit additional assistance data to the receiving UE in one or more additional SLPP Provide Assistance Data messages.

[0320] refer to Figure 25 In one aspect, the assistance data may include the general information summarized in Table 2:

[0321] information SL-PRS configuration information of the UE participants in the session. The start time and duration of the SL-PRS (if assistance data is provided to trigger SL-PRS transmission at the receiver).

[0322] Table 2: SLPP-related assistance

[0323] refer to Figure 25 In one aspect, the SLPP Request Assistance Data message may allow an SLPP-capable endpoint to request positioning assistance data (e.g., SL-PRS configuration information and resources) from a server (e.g., a server UE or LMF). The SLPP Provide Assistance Data message may allow a server (e.g., a server UE or LMF) to provide positioning assistance data (e.g., SL-PRS configuration information and resources) to participant UEs in a session.

[0324] The term "position information" applies to both the actual position estimate and the values ​​used to calculate the position (SL positioning measurements). It can be delivered in response to a request or unsolicited.

[0325] Figure 26 An SLPP location information transmission process 2600 is shown in accordance with aspects of the present disclosure. Figure 26 It includes operations 1 to 3, which are summarized as follows:

[0326] Figure 26 , Operation 1: A sending endpoint may send a request for location information to one or more receiving endpoints using one of the above SLPP transaction modes. The message indicates the type of location information required and the associated QoS.

[0327] Figure 26 , Operation 2 In response to operation 1, the receiving endpoint transmits location information to the sending endpoint using one of the above SLPP transaction modes. The transmitted location information may match the location information requested in operation 1.

[0328] Figure 26 , Operation 3 : The receiving endpoint may transmit additional location information to the sending endpoint in one or more additional SLPP Provide Location Information messages using one of the above-described SLPP transaction modes.

[0329] refer to Figure 26 In one aspect, the SLPP location information transfer procedure is used for unsolicited location information delivery.

[0330] Figure 27 An SLPP location information delivery process 2700 is shown in accordance with aspects of the present disclosure. Figure 27 This includes operations 1 to 2, which are summarized as follows:

[0331] Figure 27 , Operation 1 : The sending endpoint uses one of the above SLPP transaction modes to transmit location information to one or more receiving endpoints.

[0332] Figure 27 , Operation 2 : A sending endpoint can use one of the above SLPP transaction modes to transmit additional location information to one or more receiving endpoints.

[0333] Table 3 describes Figure 27 The information contained in the signaling is:

[0334] information SLPP requests location information: - Requested location measurements (e.g. RxTx, AoA, RSTD, etc.) (UE assisted) -Request location coordinates and speed (based on UE) - Requested positioning QoS (e.g., accuracy, response time) - Indicates whether to request a calculated position estimate (centralized mode) or whether to request each UE to calculate its own position (distributed mode). -Optional trigger indication for SL-PRS transmission and measurement SLPP provides location information: - Position measurement - Position coordinates and speed

[0335] Table 3: SLPP related location information

[0336] refer to Figure 27 In one aspect, the SLPP Request / Provide Location Information message may allow an SLP-capable endpoint to request / provide location measurements or location estimates from a participant UE in a session.

[0337] An SLPP-capable UE may initiate a sidelink ranging and positioning session with other SLPP-capable UEs. Based on application layer requests for sidelink positioning and ranging results from one or more SLPP-capable UEs, an SLPP-capable UE may initiate an SLPP session in an unsolicited manner.

[0338] Figure 28An SLPP create session request / accept / reject process 2800 is shown in accordance with aspects of the present disclosure. Figure 28 It includes operations 1 to 3, which are summarized as follows:

[0339] Figure 28 , Operation 1 : A sending UE may send a request to create a sidelink ranging and positioning session to one or more receiving UEs. The SLPP Create Session Request message may be sent by the sending UE using one of the above-described SLPP transaction modes.

[0340] Figure 28 , Operation 2 : The receiving UE that chooses to participate in the sidelink ranging and positioning session proposed by the sending UE responds to the sending UE with an SLPP Create Session Accept message. The SLPP Create Session Accept message may be sent by the sending UE using one of the above-mentioned SLPP transaction modes.

[0341] Figure 28 , Operation 3 : The receiving UE that chooses not to participate in the sidelink ranging and positioning session proposed by the sending UE responds to the sending UE with an SLPP Create Session Reject message. The SLPP Create Session Reject message may be sent by the sending UE using one of the above-mentioned SLPP transaction modes.

[0342] refer to Figure 28 , the SLPP Create Session Request / Accept / Reject message may include the general information summarized in Table 4 below:

[0343] information SLPP create session request: -SLPP session ID (assigned by the sending entity) - Layer 2 Group ID SLPP create session accept: -SLPP session ID (assigned by the sending entity) - Layer 2 Group ID - Application layer ID of each participating receiving UE - Layer 2 ID of each participating receiving UE SLPP session creation is rejected: -SLPP session ID (assigned by the sending entity) - Layer 2 Group ID

[0344] Table 4: SLPP Create Session Request / Response

[0345] refer to Figure 28 In one aspect, the SLPP Create Session Request message may allow a SLPP UE to request the creation of a sidelink ranging and positioning session and provide information about the proposed sidelink ranging and positioning session, including the SLPP and Layer 2 ID. In one aspect, the SLPP Create Session Accept message may allow a SLPP UE to accept a SLPP session proposed by an SLPP-capable UE. In one aspect, the SLPP Create Session Reject message may allow a SLPP UE to reject a SLPP session proposed by an SLPP-capable UE.

[0346] A SLPP-capable UE that has created a sidelink ranging and positioning session (SLPP session) to another SLPP-capable UE may start the SLPP session for the SLPP-capable UE that has accepted the proposed SLPP session request.

[0347] Figure 29An SLPP session start request / response process 2900 is shown in accordance with aspects of the present disclosure. Figure 29 This includes operations 1 to 2, which are summarized as follows:

[0348] Figure 29 , Operation 1 : A sending UE may use the SLPP Session Start Request message to start a SLPP session to one or more receiving UEs. The SLPP Session Start Request message may be sent by the sending UE using one of the above-described SLPP transaction modes.

[0349] Figure 29 , Operation 2 : The receiving UE responds to the sending UE with an SLPP session start response message. The SLPP session start response message may be sent by the sending UE using one of the above-mentioned SLPP transaction modes.

[0350] refer to Figure 29 , the SLPP session start request / response message may include the general information summarized in Table 5 below:

[0351] information SLPP session start request: -SLPP session ID - Layer 2 Group ID - Application layer ID of each participating receiving UE - Layer 2 ID of each participating receiving UE -SLPP ID of each participating receiving UE SLPP session start response: -SLPP session ID - Layer 2 Group ID -Application layer ID used to respond to the receiving UE - Layer 2 ID for responding to receiving UE - SLPP ID used to respond to the receiving UE

[0352] Table 5: SLPP Session Start Request / Response

[0353] refer to Figure 29 In one aspect, the SLPP Session Start Request message may allow a SLPP UE to request the start of a sidelink ranging and positioning session using the SLPP Create Session Request / Response message and provide information about the SLPP UEs participating in the session. In one aspect, the SLPP Session Start Response message may allow a SLPP UE to confirm the start of the SLPP session.

[0354] A SLPP-capable UE that has created and started a sidelink ranging and positioning session (SLPP session) to another SLPP-capable UE may modify the SLPP session for the SLPP-capable UE that has accepted the proposed SLPP session.

[0355] Figure 30 An SLPP modify session request / response process 3000 is shown in accordance with aspects of the present disclosure. Figure 30 It includes operations 1 to 3, which are summarized as follows:

[0356] Figure 30 , Operation 1 : A sending UE may send a request to modify a sidelink ranging and positioning session (SLPP session) for an SLPP UE participating in an SLPP session. The SLPP Modify Session Request message may be sent by the sending UE using one of the above-described SLPP transaction modes.

[0357] Figure 30 , Operation 2: The receiving UE participating in the SLPP session that chooses to accept the proposed session modification responds to the sending UE with an SLPP Modify Session Accept message. The sending UE may use one of the above-mentioned SLPP transaction modes to send the SLPP Modify Session Accept message.

[0358] Figure 30 , Operation 3 : A receiving UE participating in an SLPP session that chooses not to participate in the sidelink ranging and positioning session proposed by the sending UE responds to the sending UE with an SLPP Modify Session Reject message. The SLPP Modify Session Reject message may be sent by the sending UE using one of the above-described SLPP transaction modes.

[0359] refer to Figure 30 , the SLPP Modify Session Request / Accept / Reject message may include the general information summarized in Table 6 below:

[0360] information SLPP modify session request: - Active SLPP session ID -Active Layer 2 Group ID - New SLPP session ID - New Layer 2 Group ID -Event Participants -SLPP ID -Added participants -Application layer ID -SLPP ID SLPP modify session accept: -SLPP session ID - Layer 2 Group ID - Application layer ID of each participating receiving UE - Layer 2 ID of each participating receiving UE SLPP modify session rejection: -SLPP session ID - Layer 2 Group ID

[0361] Table 6: SLPP Create Session Request / Response

[0362] refer to Figure 30 In one aspect, the SLPP Modify Session Request message may allow a SLPP UE to request modification of an existing SLPP session and provide information about the proposed modified SLPP session and the participating SLPP UEs, including the SLPP and Layer 2 IDs. In one aspect, the SLPP Modify Session Accept message may allow a SLPP UE to accept a SLPP session modification proposed by an SLPP-capable UE. In one aspect, the SLPP Modify Session Reject message may allow a SLPP UE to reject a SLPP session modification proposed by an SLPP-capable UE.

[0363] A SLPP capable UE that has established a sidelink ranging and positioning session (SLPP session) to another SLPP capable UE may terminate the SLPP session for the SLPP capable UE participating in the SLPP session.

[0364] Figure 31 An SLPP session end request / response process 3100 is shown in accordance with aspects of the present disclosure. Figure 31 This includes operations 1 to 2, which are summarized as follows:

[0365] Figure 31 , Operation 1 : The sending UE may terminate a sidelink ranging and positioning session (SLPP session) of an SLPP UE participating in the SLPP session by sending an SLPP Session End Request message. The SLPP Session End Request message may be sent by the sending UE using one of the above-described SLPP transaction modes.

[0366] Figure 31 , Operation 2 The receiving UE responds to the sending UE with an SLPP Session End Response message. The SLPP Session End Response message may be sent by the sending UE using one of the above SLPP transaction modes. When the session is terminated, the receiving UE deletes the SLPP Session ID and the SLPP ID.

[0367] refer to Figure 31 , the SLPP session end request / response message may include the general information summarized in Table 7 below.

[0368] information SLPP session end request: -SLPP session ID - Layer 2 Group ID SLPP session end response: -SLPP session ID - Layer 2 Group ID - SLPP ID used to respond to the receiving UE

[0369] Table 7: SLPP Session Start Request / Response

[0370] refer to Figure 31 In one aspect, the SLPP Session End Request message may allow a SLPP UE to request termination of a sidelink ranging and positioning session. In one aspect, the SLPP Session End Response message may allow a SLPP UE to confirm termination of a SLPP session.

[0371] Regarding sidelink positioning discovery, at least for out-of-coverage scenarios, the discovery process is included in the sidelink positioning process. In one aspect, a discovery message can be used to carry information for target discovery and candidate selection for SL positioning UEs, including at least an indication of the anchor UE, target UE, and server UE roles. Various information about the anchor UE (e.g., location knowledge) can be indicated. In one aspect, UE role information is indicated in the Discovery SLPP meta field. In one aspect, this applies to both the discovery mode and the messages.

[0372] Regarding sidelink positioning discovery for in-coverage and partial coverage scenarios, sidelink ranging and positioning procedures can be implemented for SL-MT-LR and SL-MO-LR. These procedures (SL-MT-LR and SL-MO-LR) describe the operations of the LCS client and UE, respectively, to obtain sidelink positioning / ranging results for a group of n UEs (n ≥ 2) on PC5. For both SL-MT-LR and SL-MO-LR procedures, the UE performs discovery over PC5. In one aspect, discovery is included in the sidelink positioning procedure for all PC5 sidelink positioning scenarios (e.g., in-coverage, out-of-coverage, partial coverage).

[0373] Structuring SLPP ASN.1 in a manner similar to LPP can enable reuse of existing LPP designs and promote commonality between the two designs. Specifically, SLPP messages can include common header information (e.g., session ID, UE ID, transaction ID, etc.) and a message body that implements the individual SLPP transaction type (capabilities transfer, assistance data transfer, location information transfer, etc.). In one aspect, SLPP messages contain a common header (including, for example, session ID, UE ID, transaction ID, etc.) and a message body that implements the individual SLPP transaction type (capabilities transfer, assistance data transfer, location information transfer, etc.). In LPP, each message body information element (IE) is a sequence (SEQUENCE) of separate IEs that apply to all or individual positioning methods. For example, the LPPRequestCapabilities message body contains the relevant IEs for each LPP positioning method (similar to all other LPP message body IEs), using the following ASN.1 definitions:

[0374] RequestCapabilities-r9-IEs ::= SEQUENCE {

[0375] commonIEsRequestCapabilitiesCommonIEsRequestCapabilitiesOPTIONAL,--Need ON

[0376] a-gnss-RequestCapabilitiesA-GNSS-RequestCapabilitiesOPTIONAL,--NeedON

[0377] otdoa-RequestCapabilitiesOTDOA-RequestCapabilitiesOPTIONAL,--Need ON

[0378] ecid-RequestCapabilitiesECID-RequestCapabilitiesOPTIONAL,--Need ON

[0379] epdu-RequestCapabilitiesEPDU-SequenceOPTIONAL,--Need ON

[0380] ...,

[0381] [[sensor-RequestCapabilities-r13Sensor-RequestCapabilities-r13OPTIONAL,-- Need ON

[0382] tbs-RequestCapabilities-r13TBS-RequestCapabilities-r13OPTIONAL,--Need ON

[0383] wlan-RequestCapabilities-r13WLAN-RequestCapabilities-r13OPTIONAL,--Need ON

[0384] bt-RequestCapabilities-r13BT-RequestCapabilities-r13OPTIONAL-- NeedON

[0385] ]],

[0386] [[nr-ECID-RequestCapabilities-r16NR-ECID-RequestCapabilities-r16OPTIONAL,-- Need ON

[0387] nr-Multi-RTT-RequestCapabilities-r16

[0388] NR-Multi-RTT-RequestCapabilities-r16

[0389] OPTIONAL,-- Need ON

[0390] nr-DL-AoD-RequestCapabilities-r16

[0391] NR-DL-AoD-RequestCapabilities-r16OPTIONAL,-- Need ON

[0392] nr-DL-TDOA-RequestCapabilities-r16

[0393] NR-DL-TDOA-RequestCapabilities-r16OPTIONAL,-- Need ON

[0394] nr-UL-RequestCapabilities-r16NR-UL-RequestCapabilities-r16OPTIONAL--Need ON ]]

[0396] }

[0397] --ASN1STOP

[0398] Implementations using this approach will have to compile the entire LPP ASN.1, even when supporting only a single positioning method. This is because each field in the sequence has an explicit ASN.1 definition (e.g., IEsCommonIEsRequestCapabilities, A-GNSS-RequestCapabilities, etc.). Therefore, the actual LPP encoder / decoder footprint remains the same regardless of which / how many positioning methods a device supports. This can be a potential problem and cost barrier for low-cost devices that have limited memory to support only a small subset of their required positioning methods. This issue was discussed during Rel-14 when adding NB-IoT support to LPP.

[0399] Assuming that SLPP may also evolve / increase in future versions, the SLPP ASN.1 design may allow for "selective ASN.1 compilation", where implementations only need to compile ASN.1 for supported SLPP functions. This can be achieved by grouping "SLPP functions" into separate independent modules. Taking LPP as an example, each SLPP module / group can be a separate positioning method. There is no need to use explicit ASN.1 definitions for each message body IE, and it can be defined as an octet string (OCTETSTRING). For example, the RequestCapabilities-r9-IEs above can be defined in ASN.1 as follows:

[0400] RequestCapabilities-r9-IEs ::= SEQUENCE {

[0401] commonIEsRequestCapabilitiesOCTET STRING OPTIONAL,--CommonIEsRequestCapabilities

[0402] a-gnss-RequestCapabilitiesOCTET STRING OPTIONAL,-- A-GNSS-RequestCapabilities

[0403] otdoa-RequestCapabilitiesOCTET STRING OPTIONAL,-- OTDOA-RequestCapabilities

[0404] ecid-RequestCapabilitiesOCTET STRING OPTIONAL,-- ECID-RequestCapabilities

[0405] epdu-RequestCapabilitiesOCTET STRING OPTIONAL,-- EPDU-Sequence

[0406] ...,

[0407] [[sensor-RequestCapabilities-r13OCTET STRING OPTIONAL,-- Sensor-RequestCapabilities

[0408] tbs-RequestCapabilities-r13OCTET STRING OPTIONAL,-- TBS-RequestCapabilities

[0409] wlan-RequestCapabilities-r13OCTET STRING OPTIONAL,-- WLAN-RequestCapabilities

[0410] bt-RequestCapabilities-r13OCTET STRING OPTIONAL-- BT-RequestCapabilities

[0411] ]],

[0412] [[nr-ECID-RequestCapabilities-r16OCTET STRING OPTIONAL,-- NR-ECID-RequestCapabilities

[0413] nr-Multi-RTT-RequestCapabilities-r16

[0414] OCTET STRING OPTIONAL,-- NR-Multi-RTT-RequestCapabilities

[0415] nr-DL-AoD-RequestCapabilities-r16

[0416] OCTET STRING OPTIONAL,-- NR-DL-AoD-RequestCapabilities

[0417] nr-DL-TDOA-RequestCapabilities-r16

[0418] OCTET STRING OPTIONAL,-- NR-DL-TDOA-RequestCapabilities

[0419] nr-UL-RequestCapabilities-r16OCTET STRING OPTIONAL-- NR-UL-RequestCapabilities ]]

[0421] }

[0422] --ASN1STOP

[0423] On the one hand, the Positioning Method IE will be defined in a separate ASN.1 PDU imported by the main SLPP PDU. This way, any (sub)PDUs containing unsupported positioning methods or features can be excluded from the protocol and do not require compilation. Consequently, the message encoder / decoder footprint is reduced because it does not contain the entire SLPP. Any unsupported received IE / message will still be correctly decoded (as an octet string) and then ignored, just as with explicit ASN.1 definitions. However, in the example above, the contents of the unsupported octet strings do not need to be individually decoded.

[0424] An example structure using LPP as a baseline is provided below. Note that this does not imply that the structure of SLPP must be the same as the LPP shown. It is only used as a baseline to illustrate the proposal. In one aspect, the SLPP design may allow support for individual SL positioning methods in a forward-compatible manner to allow additional positioning methods to be added in future versions (e.g., similar to LPP). In one aspect, the SLPP ASN.1 design may allow for "selective ASN.1 compilation". The entire SLPP functionality is divided into "groups", each of which is defined as a separate ASN.1 module. A "group" may correspond to a positioning method, but other groupings are possible. Implementations only need to compile SLPP modules that contain supported "groups" (functionality, positioning methods, etc.).

[0425] An example of the SLPP PDU ASN.1 structure of SLPP-PDU-Definition is as follows:

[0426] –SLPP-PDU-Definitions

[0427] --ASN1START

[0428] SLPP-PDU-Definitions

[0429] DEFINITIONS AUTOMATIC TAGS ::=

[0430] BEGIN

[0431] --ASN1STOP

[0432] –Imports

[0433] Note: Implementations only need to include supported "Method" PDUs. Unsupported methods do not need to be included, and therefore do not impact the protocol size. For example, if an implementation does not support "Method A," the SLPP-PDU-Method-A-Content PDU does not need to be included in the protocol.

[0434] --ASN1START

[0435] IMPORTS

[0436] CommonIEsRequestCapabilities,

[0437] CommonIEsProvideCapabilities,

[0438] CommonIEsRequestAssistanceData,

[0439] CommonIEsProvideAssistanceData,

[0440] CommonIEsRequestLocationInformation,

[0441] CommonIEsProvideLocationInformation

[0442] FROM

[0443] SLPP-PDU-Common-Contents

[0444] Method-A-RequestCapabilities,

[0445] Method-A-ProvideCapabilities,

[0446] Method-A-RequestAssistanceData,

[0447] Method-A-ProvideAssistanceData,

[0448] Method-A-RequestLocationInformation,

[0449] Method-A-ProvideLocationInformation

[0450] FROM

[0451] SLPP-PDU-Method-A-Contents

[0452] Method-B-RequestCapabilities,

[0453] Method-B-ProvideCapabilities,

[0454] Method-B-RequestAssistanceData,

[0455] Method-B-ProvideAssistanceData,

[0456] Method-B-RequestLocationInformation,

[0457] Method-B-ProvideLocationInformation

[0458] FROM

[0459] SLPP-PDU-Method-B-Contents

[0460] Method-C-RequestCapabilities,

[0461] Method-C-ProvideCapabilities,

[0462] Method-C-RequestAssistanceData,

[0463] Method-C-ProvideAssistanceData,

[0464] Method-C-RequestLocationInformation,

[0465] Method-C-ProvideLocationInformation

[0466] FROM

[0467] SLPP-PDU-Method-C-Contents;

[0468] -- ASN1STOP

[0469] –SLPP-Message

[0470] -- ASN1START

[0471] SLPP-Message ::= SEQUENCE {

[0472] slpp-MessageHeader SLPP-MessageHeader,

[0473] slpp-MessageBody SLPP-MessageBody

[0474] }

[0475] -- ASN1STOP

[0476] –SLPP-MessageHeader

[0477] -- ASN1START

[0478] SLPP-MessageHeader ::= CHOICE {

[0479] c1 CHOICE {

[0480] slpp-message-header SLPP-Message-Header,

[0481] spare1 NULL

[0482] },

[0483] messageClassExtensionSEQUENCE {}

[0484] }

[0485] SLPP-Message-Header ::= SEQUENCE {

[0486] -- e.g., transaction ID, sequence number, etc.

[0487] }

[0488] -- ASN1STOP

[0489] –SLPP-MessageBody

[0490] -- ASN1START

[0491] SLPP-MessageBody ::= CHOICE {

[0492] c1 CHOICE {

[0493] requestCapabilities RequestCapabilities,

[0494] provideCapabilities ProvideCapabilities,

[0495] requestAssistanceData RequestAssistanceData,

[0496] provideAssistanceData ProvideAssistanceData,

[0497] requestLocationInformation RequestLocationInformation,

[0498] provideLocationInformation ProvideLocationInformation,

[0499] --

[0500] -- additional SLPP messages FFS (e.g., session operationmessages)

[0501] --

[0502] spare2 NULL, spare1 NULL

[0503] },

[0504] messageClassExtensionSEQUENCE {}

[0505] }

[0506] -- ASN1STOP

[0507] –RequestCapabilities

[0508] -- ASN1START

[0509] RequestCapabilities ::= SEQUENCE {

[0510] criticalExtensions CHOICE {

[0511] requestCapabilities RequestCapabilities-IEs,

[0512] criticalExtensionsFuture SEQUENCE {}

[0513] }

[0514] }

[0515] RequestCapabilities-IEs ::= SEQUENCE {

[0516] commonIEsRequestCapabilities OCTET STRING OPTIONAL, --Containing CommonIEsRequestCapabilities

[0517] method-A-RequestCapabilities OCTET STRING OPTIONAL, --Containing Method-A-RequestCapabilities

[0518] method-B-RequestCapabilities OCTET STRING OPTIONAL, --Containing Method-B-RequestCapabilities

[0519] method-C-RequestCapabilities OCTET STRING OPTIONAL, --Containing Method-C-RequestCapabilities

[0520] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0521] nonCriticalExtension SEQUENCE {} OPTIONAL

[0522] }

[0523] -- ASN1STOP

[0524] –ProvideCapabilities

[0525] -- ASN1START

[0526] ProvideCapabilities ::= SEQUENCE {

[0527] criticalExtensions CHOICE {

[0528] provideCapabilities ProvideCapabilities-IEs,

[0529] criticalExtensionsFuture SEQUENCE {}

[0530] }

[0531] }

[0532] ProvideCapabilities-IEs ::= SEQUENCE {

[0533] commonIEsProvideCapabilities OCTET STRING OPTIONAL, --Containing CommonIEsProvideCapabilities

[0534] method-A-ProvideCapabilities OCTET STRING OPTIONAL, --Containing Method-A-ProvideCapabilities

[0535] method-B-ProvideCapabilities OCTET STRING OPTIONAL, --Containing Method-B-ProvideCapabilities

[0536] method-C-ProvideCapabilities OCTET STRING OPTIONAL, --Containing Method-C-ProvideCapabilities

[0537] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0538] nonCriticalExtension SEQUENCE {} OPTIONAL

[0539] }

[0540] -- ASN1STOP

[0541] –RequestAssistanceData

[0542] -- ASN1START

[0543] RequestAssistanceData ::= SEQUENCE {

[0544] criticalExtensions CHOICE {

[0545] requestAssistanceData RequestAssistanceData-IEs,

[0546] criticalExtensionsFuture SEQUENCE {}

[0547] }

[0548] }

[0549] RequestAssistanceData-IEs ::= SEQUENCE {

[0550] commonIEsRequestAssistanceData OCTET STRING OPTIONAL, --Containing CommonIEsRequestAssistanceData

[0551] method-A-RequestAssistanceData OCTET STRING OPTIONAL, --Containing Method-A-RequestAssistanceData

[0552] method-B-RequestAssistanceData OCTET STRING OPTIONAL, --Containing Method-B-RequestAssistanceData

[0553] method-C-RequestAssistanceData OCTET STRING OPTIONAL, --Containing Method-C-RequestAssistanceData

[0554] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0555] nonCriticalExtension SEQUENCE {} OPTIONAL

[0556] }

[0557] -- ASN1STOP

[0558] –ProvideAssistanceData

[0559] -- ASN1START

[0560] ProvideAssistanceData ::= SEQUENCE {

[0561] criticalExtensions CHOICE {

[0562] provideAssistanceData ProvideAssistanceData-IEs,

[0563] criticalExtensionsFuture SEQUENCE {}

[0564] }

[0565] }

[0566] ProvideAssistanceData-IEs ::= SEQUENCE {

[0567] commonIEsProvideAssistanceData OCTET STRING OPTIONAL, --Containing CommonIEsProvideAssistanceData

[0568] method-A-ProvideAssistanceData OCTET STRING OPTIONAL, --Containing Method-A-ProvideAssistanceData

[0569] method-B-ProvideAssistanceData OCTET STRING OPTIONAL, --Containing Method-B-ProvideAssistanceData

[0570] method-C-ProvideAssistanceData OCTET STRING OPTIONAL, --Containing Method-C-ProvideAssistanceData

[0571] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0572] nonCriticalExtension SEQUENCE {} OPTIONAL

[0573] }

[0574] -- ASN1STOP

[0575] –RequestLocationInformation

[0576] -- ASN1START

[0577] RequestLocationInformation ::= SEQUENCE {

[0578] criticalExtensions CHOICE {

[0579] requestLocationInformation RequestLocationInformation-IEs,

[0580] criticalExtensionsFuture SEQUENCE {}

[0581] }

[0582] }

[0583] RequestLocationInformation-IEs ::= SEQUENCE {

[0584] commonIEsRequestLocationInformation OCTET STRING OPTIONAL, --Containing CommonIEsRequestLocationInformation

[0585] method-A-RequestLocationInformation OCTET STRING OPTIONAL, --Containing Method-A-RequestLocationInformation

[0586] method-B-RequestLocationInformation OCTET STRING OPTIONAL, --Containing Method-B-RequestLocationInformation

[0587] method-C-RequestLocationInformation OCTET STRING OPTIONAL, --Containing Method-C-RequestLocationInformation

[0588] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0589] nonCriticalExtension SEQUENCE {} OPTIONAL

[0590] }

[0591] -- ASN1STOP

[0592] –ProvideLocationInformation

[0593] -- ASN1START

[0594] ProvideLocationInformation ::= SEQUENCE {

[0595] criticalExtensions CHOICE {

[0596] provideLocationInformation ProvideLocationInformation-IEs,

[0597] criticalExtensionsFuture SEQUENCE {}

[0598] }

[0599] }

[0600] ProvideLocationInformation-IEs ::= SEQUENCE {

[0601] commonIEsProvideLocationInformation OCTET STRING OPTIONAL, --Containing CommonIEsProvideLocationInformation

[0602] method-A-ProvideLocationInformation OCTET STRING OPTIONAL, --Containing Method-A-ProvideLocationInformation

[0603] method-B-ProvideLocationInformation OCTET STRING OPTIONAL, --Containing Method-B-ProvideLocationInformation

[0604] method-C-ProvideLocationInformation OCTET STRING OPTIONAL, --Containing Method-C-ProvideLocationInformation

[0605] lateNonCriticalExtension OCTET STRING OPTIONAL,

[0606] nonCriticalExtension SEQUENCE {} OPTIONAL

[0607] }

[0608] -- ASN1STOP

[0609] –End of SLPP-PDU-Definitions

[0610] -- ASN1START

[0611] END

[0612] -- ASN1STOP

[0613] Examples of SLPP PDU comment content are as follows:

[0614] –SLPP-PDU-Common-Contents

[0615] -- ASN1START

[0616] SLPP-PDU-Common-Contents

[0617] DEFINITIONS AUTOMATIC TAGS ::=

[0618] BEGIN

[0619] -- ASN1STOP

[0620] –CommonIEsRequestCapabilities

[0621] -- ASN1START

[0622] CommonIEsRequestCapabilities ::= SEQUENCE {

[0623] }

[0624] -- ASN1STOP

[0625] –CommonIEsProvideCapabilities

[0626] -- ASN1START

[0627] CommonIEsProvideCapabilities ::= SEQUENCE {

[0628] }

[0629] -- ASN1STOP

[0630] –CommonIEsRequestAssistanceData

[0631] -- ASN1START

[0632] CommonIEsRequestAssistanceData ::= SEQUENCE {

[0633] }

[0634] -- ASN1STOP

[0635] –CommonIEsProvideAssistanceData

[0636] -- ASN1START

[0637] CommonIEsProvideAssistanceData ::= SEQUENCE {

[0638] }

[0639] -- ASN1STOP

[0640] –CommonIEsRequestLocationInformation

[0641] -- ASN1START

[0642] CommonIEsRequestLocationInformation ::= SEQUENCE {

[0643] }

[0644] -- ASN1STOP

[0645] –CommonIEsProvideLocationInformation

[0646] -- ASN1START

[0647] CommonIEsProvideLocationInformation ::= SEQUENCE {

[0648] }

[0649] -- ASN1STOP

[0650] –End of SLPP-PDU-Common-Contents

[0651] -- ASN1START

[0652] END

[0653] -- ASN1STOP

[0654] Examples of SLPP PDU Method-A Contents are as follows:

[0655] –SLPP-PDU-Method-A-Contents

[0656] -- ASN1START

[0657] SLPP-PDU-Method-A-Contents

[0658] DEFINITIONS AUTOMATIC TAGS ::=

[0659] BEGIN

[0660] -- ASN1STOP

[0661] –Method-A-RequestCapabilities

[0662] -- ASN1START

[0663] Method-A-RequestCapabilities ::= SEQUENCE {

[0664] }

[0665] -- ASN1STOP

[0666] –Method-A-ProvideCapabilities

[0667] -- ASN1START

[0668] Method-A-ProvideCapabilities ::= SEQUENCE {

[0669] }

[0670] -- ASN1STOP

[0671] –Method-A-RequestAssistanceData

[0672] -- ASN1START

[0673] Method-A-RequestAssistanceData ::= SEQUENCE {

[0674] }

[0675] -- ASN1STOP

[0676] –Method-A-ProvideAssistanceData

[0677] -- ASN1START

[0678] Method-A-ProvideAssistanceData ::= SEQUENCE {

[0679] }

[0680] -- ASN1STOP

[0681] –Method-A-RequestLocationInformation

[0682] -- ASN1START

[0683] Method-A-RequestLocationInformation ::= SEQUENCE {

[0684] }

[0685] -- ASN1STOP

[0686] –Method-A-ProvideLocationInformation

[0687] -- ASN1START

[0688] Method-A-ProvideLocationInformation ::= SEQUENCE {

[0689] }

[0690] -- ASN1STOP

[0691] –End of SLPP-PDU-Method-A-Contents

[0692] -- ASN1START

[0693] END

[0694] -- ASN1STOP

[0695] An example of the SLPP PDU Method-B content is as follows:

[0696] –SLPP-PDU-Method-B-Contents

[0697] -- ASN1START

[0698] [[ID=I45]]SLPP-PDU-Method-B-Contents

[0699] DEFINITIONS AUTOMATIC TAGS ::=

[0700] BEGIN

[0701] -- ASN1STOP

[0702] –Method-B-RequestCapabilities

[0703] -- ASN1START

[0704] Method-B-RequestCapabilities ::= SEQUENCE {

[0705] }

[0706] -- ASN1STOP

[0707] –Method-B-ProvideCapabilities

[0708] -- ASN1START

[0709] Method-B-ProvideCapabilities ::= SEQUENCE {

[0710] }

[0711] -- ASN1STOP

[0712] –Method-B-RequestAssistanceData

[0713] -- ASN1START

[0714] Method-B-RequestAssistanceData ::= SEQUENCE {

[0715] }

[0716] -- ASN1STOP

[0717] –Method-B-ProvideAssistanceData

[0718] -- ASN1START

[0719] Method-B-ProvideAssistanceData ::= SEQUENCE {

[0720] }

[0721] -- ASN1STOP

[0722] –Method-B-RequestLocationInformation

[0723] -- ASN1START

[0724] Method-B-RequestLocationInformation ::= SEQUENCE {

[0725] }

[0726] -- ASN1STOP

[0727] – Method - B - Provide Location Information

[0728] -- ASN1START

[0729] Method - B - Provide Location Information ::= SEQUENCE {

[0730] }

[0731] -- ASN1STOP

[0732] – End of SLPP - PDU - Method - B - Contents

[0733] -- ASN1START

[0734] END

[0735] -- ASN1STOP

[0736] An example of the SLPP PDU method - C content is as follows:

[0737] – SLPP - PDU - Method - C - Contents

[0738] -- ASN1START

[0739] SLPP - PDU - Method - C - Contents

[0740] DEFINITIONS AUTOMATIC TAGS ::=

[0741] BEGIN

[0742] -- ASN1STOP

[0743] – Method - C - Request Capabilities

[0744] -- ASN1START

[0745] Method - C - Request Capabilities ::= SEQUENCE {

[0746] }

[0747] -- ASN1STOP

[0748] – Method - C - Provide Capabilities

[0749] -- ASN1START

[0750] Method-C-ProvideCapabilities ::= SEQUENCE {

[0751] }

[0752] -- ASN1STOP

[0753] –Method-C-RequestAssistanceData

[0754] -- ASN1START

[0755] Method-C-RequestAssistanceData ::= SEQUENCE {

[0756] }

[0757] -- ASN1STOP

[0758] –Method-C-ProvideAssistanceData

[0759] -- ASN1START

[0760] Method-C-ProvideAssistanceData ::= SEQUENCE {

[0761] }

[0762] -- ASN1STOP

[0763] –Method-C-RequestLocationInformation

[0764] -- ASN1START

[0765] Method-C-RequestLocationInformation ::= SEQUENCE {

[0766] }

[0767] -- ASN1STOP

[0768] –Method-C-ProvideLocationInformation

[0769] -- ASN1START

[0770] Method-C-ProvideLocationInformation ::= SEQUENCE {

[0771] }

[0772] --ASN1STOP

[0773] –End of SLPP-PDU-Method-C-Contents

[0774] --ASN1START

[0775] END

[0776] --ASN1STOP

[0777] Sidelink ranging and positioning use cases involving multiple target UEs in the same positioning session may be supported, including support for sidelink ranging and positioning control via multicast or broadcast. In one aspect, at least unicast SLPP / RSPP "centralized" operation, where one UE performs range and / or position calculations based on measurement / position information related to itself and / or other UEs, may be supported. In one aspect, if group positioning is determined to be supported, performing at least ranging at multiple UEs using estimated calculations may be feasible.

[0778] In one aspect, it may be feasible to send at least the following positioning signaling for multicast / broadcast (in addition to unicast):

[0779] •SL positioning capability

[0780] •SL positioning assistance data

[0781] •SL location information and measurements

[0782] In one aspect, group positioning may be utilized to obtain position estimates for multiple target UEs (absolute positioning) or multiple UE pairs (ranging / relative positioning) per LCS request.At least part of the group management for group positioning is performed at the upper / application layer.

[0783] Regarding the overall signaling procedure for PC5-only positioning (including at least IC and OOC), the sidelink positioning procedure may include the following series of operations between the LMF / location server UE / NG-RAN / candidate anchor UE and the target UE as a baseline:

[0784] 1. Triggering events

[0785] 2. Sidelink Positioning Capability Exchange

[0786] 3. Sidelink positioning assistance data transmission

[0787] 4. SL positioning request location information

[0788] 5. Measurement of SL-PRS

[0789] 6. Position calculation

[0790] 7. SL positioning provides location information

[0791] The order (1-7) is an example and may be modified. In one aspect, the discovery and selection of the anchor UE and / or server UE may be part of the positioning layer.

[0792] In one aspect, the anchor UE and target UE roles may be illustrated in the sidelink positioning process of stage 2. For at least the case where the server UE is separated from the target and anchor, further discussion of the server UE may be provided. In one aspect, at least for out-of-coverage scenarios, the discovery process may be included in the sidelink positioning process.

[0793] Example SLPP procedure operations and call flows aligned with the above aspects are described and illustrated below for both UE-assisted (centralized) sidelink ranging and positioning and UE-based (distributed) sidelink ranging and positioning. These flows illustrate sidelink ranging and positioning for both a single target UE and multiple target UEs, and show that the same SLPP messages and message sequences can be used regardless of whether the sidelink positioning SLPP session involves a single target UE or multiple target UEs. Specifically, it is shown that the SLPP call flow can be independent of the number of participating UEs and the number of target UEs.

[0794] On one hand, there has been some discussion and debate about whether additional SLPP messages are needed to manage service requirements and SLPP sessions. In LPP, there is no explicit management of LPP sessions and services. This is possible because an LPP session is always between a UE and a location server (e.g., the LMF in the case of NR access). The location server is always assumed to control the LPP session (not the UE), and any association with separate service requests (e.g., MO-LR supplementary service requests or periodically triggered location supplementary service requests) can be indicated or implied using the same Correlation ID / Routing ID value (for periodically triggered location supplementary service requests) or at least temporal association (for MO-LR supplementary service requests). These restrictions and associations do not always apply to SLPP sessions between pairs or groups of UEs, where any one UE (e.g., for V2X or MCX) may be participating in multiple SLPP sessions with other UEs, where, for each SLPP session, the service requirements and identities of the other UEs need to be precisely and unambiguously known. This leads to the assumption that additional SLPP messages may be required to manage SLPP sessions (e.g., regarding establishment, modification, and termination) and the services enabled by each session (e.g., location results). However, these additional SLPP messages are not required in all cases where the SLPP session may be implicitly defined in some other way (e.g. for LPP) and may then be omitted.

[0795] Figure 32

[00106] A UE-assisted (centralized) sidelink-only positioning process 3200 for a single target UE is shown in accordance with aspects of the present disclosure. Figure 32 A UE-assisted sidelink positioning session for a single target UE is shown, where a server UE (UE-A) initiates an SLPP session and performs positioning calculations based on SL-PRS measurements received from the single target UE and other (e.g., anchor) UEs. Following UE discovery, the SLPP message flow consists of session establishment, capability and assistance data exchange, location information transfer, and session termination.

[0796] Figure 32 An SLPP session including session establishment, session modification, and positioning actions is shown, and includes operations 0 to 11, which are summarized as follows:

[0797] Figure 32 , operation 0: The application layer in UE-A and other UEs can perform UE discovery, determine and verify the requested services, and perform group management (e.g., create a group containing UEs A, B and E, F, G). The application layer in UE-A also verifies that all UEs support SLPP. The application layer in UE-A then requests the sidelink ranging and positioning results of a single target UE-B from the SLPP layer in UE-A, and provides the application layer ID and layer 2 ID of each of UEs A to E to the SLPP layer in UE-A, and can provide the application layer group ID and layer 2 group ID for a group of one or more UEs A to E. Note: The exact API between the application layer and the SLPP layer may be considered to depend on the implementation.

[0798] Figure 32 , Operation 1 : The initiating UE (server UE-A) establishes an SLPP session (e.g. Figure 9 as shown) so that all participating UEs know each other.

[0799] Figure 32 , Operation 2 : The initiating UE (server UE-A) sends the SLPP request capability message to a single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G). Depending on the specific scenario, the SLPP request capability message can be sent by the initiating UE (server UE-A) to the single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast.

[0800] Figure 32 , Operation 3 : A single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) respond to the initiating UE (server UE-A) with an SLPP Offer Capabilities message. Depending on the scenario, the SLPP Offer Capabilities message can be sent by the single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) to the initiating UE (server UE-A) via unicast, multicast, or broadcast.

[0801] Figure 32 , Operation 4 : The SLPP session may be modified based on the capability information from operation 3 (e.g. Figure 10 as shown) (e.g., removing UEs with incompatible capabilities such as SL positioning methods, etc.).

[0802] Figure 32 , Operation 5The initiating UE (server UE-A) sends a SLPP Provide Assistance Data message to a single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G). Depending on the scenario, the SLPP Provide Assistance Data message can be sent by the initiating UE (server UE-A) to the single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Provide Assistance Data message includes the SL-PRS configuration for each UE in the session. After receiving the assistance data (or at the indicated start time included in the message), each UE in the session transmits its corresponding SL-PRS. The duration of SL-PRS transmission can be controlled by a timer provided in the message or can continue until the SLPP session is terminated in operation 11.

[0803] Figure 32 , Operation 6 The initiating UE (server UE-A) sends a SLPP Request Location Information message to a single target UE (UE-B) and / or anchor UEs (UE-E, UE-F, UE-G), depending on the desired positioning method. Depending on the specific scenario, the SLPP Request Location Information message can be sent by the initiating UE (server UE-A) to the single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Request Location Information message indicates the type of location information required and the associated QoS (e.g., desired accuracy, response time, etc.). It also includes an indication that the range / positioning calculation will be performed by the initiating UE (server UE-A).

[0804] Figure 32 , Operation 7 : Each participating UE performs the requested SL-PRS transmission and measurement. NOTE: A server UE-A may participate in the sidelink positioning session by transmitting and measuring SL-PRS (e.g. also acting as an anchor UE), or may only participate in managing the session and performing and propagating positioning calculations.

[0805] Figure 32 , Operation 8A single target UE (UE-B) and / or anchor UEs (UE-E, UE-F, UE-G) respond to the initiating UE (server UE-A) with an SLPP Provide Location Information message. Depending on the scenario, the SLPP Provide Location Information message can be sent by the single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) to the initiating UE (server UE-A) via unicast, multicast, or broadcast. The SLPP Provide Location Information message can be sent upon completion of transmission and measurement, periodically, or after the expiration of the response time received in operation 6. It can also include an indication of whether to request the other UE (in this case, the initiating server UE-A) to provide location results (e.g., calculated range and / or position) back to the UE. Based on the configuration received in the SLPP Provide Assistance Data message, SL-PRS transmission and SL-PRS measurement can be performed periodically.

[0806] Figure 32 , Operation 9 : The initiating UE (server UE-A) performs range / positioning calculations using the location result received at operation 8 and the location result already obtained by UE A at operation 7 .

[0807] Figure 32 , Operation 10 If distribution of the location result is requested in operation 8, the initiating UE (server UE-A) may distribute the location result by sending an SLPP Provide Location Information message to a single target UE-B. Depending on the specific scenario, the SLPP Provide Location Information message may be sent by the initiating UE (server UE-A) to a single target UE (UE-B) via unicast, multicast, or broadcast.

[0808] Figure 32 , Operation 11 : The SLPP session can be terminated.

[0809] Figure 33

[00106] Shown is a UE-assisted (centralized) sidelink-only positioning multiple target UEs process 3300 according to aspects of the present disclosure. Figure 33 A UE-assisted sidelink positioning session for multiple target UEs is shown, where a server UE (UE-A) initiates an SLPP session and performs position calculations based on SL-PRS measurements received from multiple target UEs and an anchor UE. Figure 1 The flow for UE-assisted sidelink positioning of a single target UE is the same as shown in .After UE discovery, the UE performs session establishment, capability and assistance data exchange, location information transfer and session termination. Figure 33 This includes operations 0 to 11, which are summarized as follows:

[0810] Figure 33 , operation 0: The application layer in UE-A and other UEs can perform UE discovery, determine and verify the requested services, and perform group management (e.g., create a group containing UEs A to G). The application layer in UE-A also verifies that all UEs support SLPP. The application layer in UE-A then requests sidelink ranging and positioning results for multiple target UEs (UE-B, UE-C, UE-D) from the SLPP layer in UE-A, and provides the application layer ID and layer 2 ID of each of UE-A to E to the SLPP layer in UE-A, and can provide the application layer group ID and layer 2 group ID for the group of one or more UEs A to E. Note: The exact API between the application layer and the SLPP layer may be considered to depend on the implementation.

[0811] Figure 33 , Operation 1 : The initiating UE (server UE-A) establishes an SLPP session (e.g. Figure 9 as shown) so that all participating UEs know each other.

[0812] Figure 33 , Operation 2 : The initiating UE (server UE-A) sends the SLPP request capability message to multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G). Depending on the specific scenario, the SLPP request capability message can be sent by the initiating UE (server UE-A) to multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast.

[0813] Figure 33 , Operation 3 : Multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) respond to the initiating UE (server UE-A) with an SLPP OfferCapabilities message. Depending on the scenario, the SLPP OfferCapabilities message can be sent by the multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) to the initiating UE (server UE-A) via unicast, multicast, or broadcast.

[0814] Figure 33 , Operation 4 : The SLPP session may be modified based on the capability information from operation 3 (e.g. Figure 10 as shown) (e.g., removing UEs with incompatible capabilities such as SL positioning methods, etc.).

[0815] Figure 33 , Operation 5The initiating UE (server UE-A) sends a SLPP Provide Assistance Data message to multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G). Depending on the scenario, the SLPP Provide Assistance Data message can be sent by the initiating UE (server UE-A) to the multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Provide Assistance Data message includes the SL-PRS configuration for each UE participating in the SLPP session. After receiving the assistance data (or at a start time indicated in the message), each UE in the session transmits its corresponding SL-PRS. The duration of SL-PRS transmission can be controlled by a timer provided in the message or can continue until the SLPP session is terminated in operation 11.

[0816] Figure 33 , Operation 6 The initiating UE (server UE-A) sends a SLPP Request Location Information message to multiple target UEs (UE-B, UE-C, UE-D) and / or anchor UEs (UE-E, UE-F, UE-G), depending on the desired positioning method. Depending on the specific scenario, the SLPP Request Location Information message can be sent by the initiating UE (server UE-A) to the multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Request Location Information message indicates the type of location information required and the associated QoS (e.g., desired accuracy, response time, etc.). It also includes an indication that the range / positioning calculation will be performed by the initiating UE (server UE-A).

[0817] Figure 33 , Operation 7 : Each participating UE performs the requested SL-PRS transmission and measurement. NOTE: A server UE-A may participate in the sidelink positioning session by transmitting and measuring SL-PRS (e.g. also acting as an anchor UE), or may only participate in managing the session and performing and propagating positioning calculations.

[0818] Figure 33 , Operation 8Multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) respond to the initiating UE (server UE-A) with an SLPP Provide Location Information message. Depending on the scenario, the SLPP Provide Location Information message may be sent by the multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) to the initiating UE (server UE-A) via unicast, multicast, or broadcast. The SLPP Provide Location Information message may be sent upon completion of transmission and measurement, periodically, or after the expiration of the response time received in operation 6. It may also include an indication of whether to request the other UE (in this case, the initiating server UE-A) to provide location results (e.g., calculated range and / or position) back to the UE. Based on the configuration received in the SLPP Provide Assistance Data message, SL-PRS transmission and SL-PRS measurement may be performed periodically.

[0819] Figure 33 , Operation 9 : The initiating UE (server UE-A) performs range / positioning calculations using the location result received at operation 8 and the location result already obtained by UE B at operation 7.

[0820] Figure 33 , Operation 10 If distribution of the location result is requested in operation 8, the initiating UE (server UE-A) may distribute the location result by sending an SLPP Provide Location Information message to multiple target UEs (UE-B, UE-C, UE-D). Depending on the specific scenario, the SLPP Provide Location Information message may be sent by the initiating UE (server UE-A) to the multiple target UEs (UE-B, UE-C, UE-D) via unicast, multicast, or broadcast.

[0821] Figure 33 , Operation 11 : The SLPP session can be terminated.

[0822] refer to Figure 33 , the SLPP messages and message call flow for a UE-assisted sidelink positioning session for multiple target UEs may be the same as the SLPP messages and message call flow for a UE-assisted sidelink positioning session for a single target UE. In one aspect, a UE-assisted sidelink positioning SLPP session uses the same SLPP messages and SLPP message call flow regardless of whether the session is for a single target UE or multiple target UEs.

[0823] refer to Figure 33On the one hand, if an SLPP positioning session is restricted to supporting only a single target UE, an application layer request to perform sidelink positioning of multiple target UEs will require as many SLPP positioning sessions as there are target UEs. Each separate session will require its own separate capability negotiation, assistance data exchange, SL-PRS configuration, SL-PRS transmission, and location information transfer, resulting in significantly less efficient and time-prolonged sidelink positioning transactions compared to the case where the SLPP session supports multiple target UEs. On the other hand, if an SLPP session does not support multiple target UEs, an application layer request to locate multiple UEs will require as many SLPP sessions as there are target UEs. Each SLPP session will require its own capability negotiation, assistance data exchange, SL-PRS configuration, SL-PRS transmission, and location information exchange. The resulting positioning session will be inefficient in terms of resource utilization and will take longer to complete than a session supporting multiple target UEs.

[0824] Figure 34

[00106] Shown is a UE-assisted (centralized) sidelink-only ranging procedure 3400 for a single target UE in accordance with aspects of the present disclosure. Figure 35 A UE-assisted (centralized) sidelink-only ranging procedure 3500 for multiple target UEs is shown in accordance with aspects of the present disclosure. Figure 34-35 In the , the server UE (UE-A) performs range calculation based on SL-PRS measurements received from a single target UE or from multiple target UEs. The SLPP message flow is the same for ranging to a single target UE and ranging to multiple target UEs and is the same as Figure 32-Figure 33 The flows shown for UE-assisted sidelink positioning for single target UE and multiple target UEs are the same.After UE discovery, the UE performs session establishment, capability and assistance data exchange, location information transfer and session termination. Figure 34-Figure 35 Each consists of operations 0 to 11, which are summarized as follows:

[0825] Figure 34-35 , operation 0 : The application layer in UE-A and other UEs can perform UE discovery, determine and verify the requested services, and perform group management (for example, creating a group containing UE A and UE B or a group containing UE AD). The application layer in UE-A also verifies that all UEs support SLPP. The application layer in UE-A then requests the sidelink ranging and positioning results of a single target UE-B from the SLPP layer in UE-A, and provides the application layer ID and layer 2 ID of each of UE-A to E to the SLPP layer in UE-A, and can provide the application layer group ID and layer 2 group ID for a group of one or more UEs A to E. Note: The exact API between the application layer and the SLPP layer may be considered to depend on the implementation.

[0826] Figure 34-35 , Operation 1 : The initiating UE (server UE-A) establishes an SLPP session (e.g. Figure 9 as shown) so that all participating UEs know each other.

[0827] Figure 34-Figure 35 , Operation 2 : The initiating UE (server UE-A) sends the SLPP Request Capability message: Single Target UE: The SLPP Request Capability message is sent by the initiating UE (server UE-A) to a single target UE, UE-B. Multiple Target UEs: The SLPP Request Capability message is sent by the initiating UE (server UE-A) to multiple target UEs (UE-B, UE-C, UE-D). Depending on the specific scenario, the SLPP Request Capability message can be sent by the initiating UE (server UE-A) to a single target UE (UE-B) or multiple target UEs (UE-B, UE-C, UE-D) via unicast, multicast, or broadcast.

[0828] Figure 34-35 , Operation 3 : SLPP Offer Capabilities: Single Target UE: A single target UE (UE-B) responds to the initiating UE (server UE-A) with an SLPP Offer Capabilities message. Multiple Target UEs: Multiple target UEs (UE-B, UE-C, UE-D) respond to the initiating UE (server UE-A) with an SLPP Offer Capabilities message. Depending on the scenario, the SLPP Offer Capabilities message can be sent by a single target UE (UE-B) to the initiating UE (server UE-A) via unicast, multicast, or broadcast, or by multiple target UEs (UE-B, UE-C, UE-D) to the initiating UE (server UE-A) via unicast, multicast, or broadcast.

[0829] Figure 34-Figure 35 , Operation 4 : The SLPP session may be modified based on the capability information from operation 3 (e.g. Figure 10 as shown) (e.g., removing UEs with incompatible capabilities such as SL positioning method, anchor capability, etc.).

[0830] Figure 34-Figure 35 , Operation 5The initiating UE (server UE-A) sends an SLPP Offer Assistance Data message. For a single target UE, the SLPP Offer Assistance Data message is sent by the initiating UE (server UE-A) to target UE-B. For multiple target UEs, the SLPP Offer Assistance Data message is sent by the initiating UE (server UE-A) to multiple target UEs (UE-B, UE-C, and UE-D) established in operations 1 or 4. Depending on the scenario, the SLPP Offer Assistance Data message can be sent by the initiating UE (server UE-A) to a single target UE (UE-B) or multiple target UEs (UE-B, UE-C, and UE-D) via unicast, multicast, or broadcast. The SLPP Offer Assistance Data message includes the SL-PRS configuration for each UE participating in the SLPP session. After receiving the assistance data (or at the indicated start time included in the message), each UE in the session transmits its corresponding SL-PRS. The duration of SL-PRS transmission can be controlled by a timer provided in the message or can continue until the SLPP session is terminated in operation 11.

[0831] Figure 34-35 , Operation 6 : The initiating UE (server UE-A) sends an SLPP Request Location Information message: Single Target UE: The initiating UE (server UE-A) sends an SLPP Request Location Information message to target UE-B. Multiple Target UEs: The initiating UE (server UE-A) sends an SLPP Request Location Information message to multiple target UEs (UE-B, UE-C, UE-D). Depending on the implementation, the SLPP Request Location Information message can be sent by the initiating UE (server UE-A) to a single target UE (UE-B) or multiple target UEs (UE-B, UE-C, UE-D) via unicast, multicast, or broadcast. The SLPP Request Location Information message indicates the type of location information required and the associated QoS (e.g., desired accuracy, response time, etc.). The message also includes an indication that the range / positioning calculation will be performed by the initiating UE (server UE-A).

[0832] Figure 34-Figure 35 , Operation 7 : Each participating UE performs the requested SL-PRS transmission and measurement.

[0833] Figure 34-35 , Operation 8SLPP Provides Location Information: Single Target UE: A single target UE (UE-B) responds to the initiating UE (server UE-A) with an SLPP Provides Location Information message. Multiple Target UEs: Multiple target UEs (UE-B, UE-C, UE-D) respond to the initiating UE (server UE-A) with an SLPP Provides Location Information message. Depending on the scenario, the SLPP Provides Location Information message can be sent by the single target UE (UE-B) to the initiating UE (server UE-A) via unicast, multicast, or broadcast, or by multiple target UEs (UE-B, UE-C, UE-D) to the initiating UE (server UE-A) via unicast, multicast, or broadcast. The SLPP Provides Location Information message can be sent upon completion of transmission and measurement, periodically, or after the response time received in operation 6 has expired. It can also include an indication of whether to request other UEs (in this case, the initiating server UE-A) to provide location results (e.g., calculated range and / or position) back to the UE. Based on the configuration received in the SLPP Provides Assistance Data message, SL-PRS transmission and SL-PRS measurement can be performed periodically.

[0834] Figure 34-35 , Operation 9 : The initiating UE (server UE-A) performs range / positioning calculations using the location result received at operation 8 and the location result already obtained by UE B at operation 7.

[0835] Figure 34-35 , Operation 10 If distribution of location results is requested in operation 8, the initiating UE (server UE-A) may distribute the location results by sending an SLPP Provide Location Information message. Single Target UE: The initiating UE (server UE-A) sends an SLPP Provide Location Information message to a single target UE-B. Multiple Target UEs: The initiating UE (server UE-A) sends an SLPP Provide Location Information message to multiple target UEs (UE-B, UE-C, UE-D). Depending on the implementation, the SLPP Provide Location Information message may be sent by the initiating UE (server UE-A) to a single target UE (UE-B) or to multiple target UEs (UE-B, UE-C, UE-D) via unicast, multicast, or broadcast.

[0836] Figure 34-35 , Operation 11 : The SLPP session can be terminated.

[0837] Figure 34-35It is shown that the SLPP messages and message call flow for an SLPP UE-assisted sidelink ranging session for multiple target UEs can be the same as the SLPP messages and message call flow for an SLPP UE-assisted sidelink ranging session for a single target UE. In addition, the SLPP messages and message call flow for an SLPP UE-assisted sidelink ranging session for a single or multiple target UEs are the same as the SLPP messages and message flow for an SLPP UE-assisted sidelink positioning session for a single target UE or multiple target UEs.

[0838] refer to Figure 34-35 In one aspect, a UE-assisted sidelink ranging SLPP session for a single target UE and a UE-assisted sidelink ranging SLPP session for multiple target UEs use the same SLPP message and SLPP message call flow.

[0839] refer to Figure 34-35 In one aspect, the same SLPP messages and SLPP message call flows are used for both the UE-assisted sidelink ranging SLPP session and the UE-assisted sidelink positioning SLPP session, regardless of whether the SLPP session is for a single target UE or for multiple target UEs.

[0840] refer to Figure 34-Figure 35 On the one hand, as in UE-assisted sidelink positioning, for UE-assisted sidelink ranging, if an SLPP ranging session is restricted to support only a single target UE, an application layer request to perform sidelink ranging for multiple target UEs will require as many SLPP ranging sessions as there are target UEs, with each separate session requiring its own separate capability negotiation, assistance data exchange, SL-PRS configuration, SL-PRS transmission, and location information delivery. The resulting multiple ranging sessions are much less efficient and result in longer delays for determining the multiple ranging sessions than if the SLPP ranging session supported multiple target UEs.

[0841] refer to Figure 34-Figure 35 On the one hand, if the SLPP session does not support multiple target UEs, the application layer request for ranging for multiple UEs will require as many SLPP sessions as target UEs, where each SLPP session includes its own capability negotiation, assistance data exchange, SL-PRS configuration, SL-PRS transmission and location information exchange, resulting in resource-inefficient and time-extended sidelink ranging sessions.

[0842] Figure 36 A UE-based (distributed) sidelink-only positioning single target UE process 3600 is shown according to aspects of the present disclosure. Figure 36A UE-based sidelink positioning session for a single target UE is shown, where a server UE (UE-A) initiates the SLPP session and subsequent positioning calculations are performed by participating UEs based on SL-PRS measurements received from the single target UE and the anchor UE. Following UE discovery, the SLPP message flow consists of session establishment, capability and assistance data exchange, location information transfer, and session termination. Figure 36 This includes operations 0 to 11, which are summarized as follows:

[0843] Figure 36 , Operation 0-5 :and Figure 32 same.

[0844] Figure 36 , Operation 6 The initiating UE (server UE-A) sends a SLPP Request Location Information message to a single target UE-B and / or anchor UEs (UE-E, UE-F, UE-G), depending on the desired positioning method. Depending on the specific scenario, the SLPP Request Location Information message can be sent by the initiating UE (server UE-A) to the single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Request Location Information message indicates the type of location information required and the associated QoS (e.g., desired accuracy, response time, etc.). The message also includes an indication that each participating UE (the initiating server UE-A and the target UEs) should perform range / positioning calculations.

[0845] Figure 36 , Operation 7 : Each participating UE performs the requested SL-PRS transmission and measurement. NOTE: A server UE-A may participate in the sidelink positioning session by transmitting and measuring SL-PRS (e.g. also acting as an anchor UE), or may only participate in managing the session and performing and propagating positioning calculations.

[0846] Figure 36 , Operation 8 : A single target UE (UE-B), an initiating UE (server UE-A), and anchor UEs (UE-E, UE-F, UE-G) transmit an SLPP Provide Location Information message. Depending on the scenario, the SLPP Provide Location Information message can be sent by the single target UE (UE-B), the initiating UE (server UE-A), and the anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Provide Location Information message can be sent upon completion of transmission and measurement, periodically, or after the response time received in operation 6 has expired. It can also include an indication of whether other UEs are requested to provide location results (e.g., calculated range and / or position) to the transmitting UE. Based on the configuration received in the SLPP Provide Assistance Data message, SL-PRS transmission and SL-PRS measurement can be performed periodically.

[0847] Figure 36 , Operation 9 : Each participating UE performs range / positioning calculations using the position result received at operation 8 and its own position result obtained at operation 7.

[0848] Figure 36 , Operation 10 If requested in operation 8, each UE may distribute its location results to other UEs in the session by sending an SLPP Provide Location Information message. Depending on the specific scenario, the SLPP Provide Location Information message may be sent by a single target UE (UE-B), an initiating UE (server UE-A), and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast.

[0849] Figure 36 , Operation 11 : The SLPP session can be terminated.

[0850] Figure 37 A UE-based (distributed) sidelink-only positioning multiple target UEs process 3700 is shown according to aspects of the present disclosure. Figure 37 A UE-based sidelink positioning session for multiple target UEs is shown, where a server UE (UE-A) initiates the SLPP session, and subsequent positioning calculations are performed by participating UEs based on SL-PRS measurements received from multiple target UEs and an anchor UE. After UE discovery, the SLPP message flow consists of session establishment, capability and assistance data exchange, location information transfer, and session termination. Figure 37 This includes operations 0 to 11, which are summarized as follows:

[0851] Figure 37 , Operation 0-5 :and Figure 33 same

[0852] Figure 37 , Operation 6 The initiating UE (server UE-A) sends a SLPP Request Location Information message to multiple target UEs (UE-B, UE-C, UE-D) and / or anchor UEs (UE-E, UE-F, UE-G), depending on the desired positioning method. Depending on the specific scenario, the SLPP Request Location Information message can be sent by the initiating UE (server UE-A) to the multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Request Location Information message indicates the type of location information required and the associated QoS (e.g., expected accuracy, response time, etc.). It also includes an indication that each participating UE (the initiating server UE-A and the target UEs) should perform range / positioning calculations.

[0853] Figure 37 , Operation 7: Each participating UE performs the requested SL-PRS transmission and measurement. NOTE: A server UE-A may participate in the sidelink positioning session by transmitting and measuring SL-PRS (e.g. also acting as an anchor UE), or may only participate in managing the session and performing and propagating positioning calculations.

[0854] Figure 37 , Operation 8 Multiple target UEs (UE-B, UE-C, UE-D), an initiating UE (server UE-A), and anchor UEs (UE-E, UE-F, UE-G) transmit an SLPP Provide Location Information message. Depending on the scenario, the SLPP Provide Location Information message may be transmitted by the multiple target UEs (UE-B, UE-C, UE-D), the initiating UE (server UE-A), and the anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast. The SLPP Provide Location Information message may be sent upon completion of transmission and measurement, periodically, or after the expiration of the response time received in operation 6. It may also include an indication of whether other UEs are requested to provide location results (e.g., calculated range and / or position) to the transmitting UE. SL-PRS transmission and SL-PRS measurement may be performed periodically based on the configuration received in the SLPP Provide Assistance Data message.

[0855] Figure 37 , Operation 9 : Each participating UE performs range / positioning calculations using the position result received at operation 8 and its own position result obtained at operation 7.

[0856] Figure 37 , Operation 10 If requested in operation 8, each UE may distribute its location results to other UEs in the session by sending an SLPP Provide Location Information message. Depending on the specific scenario, the SLPP Provide Location Information message may be sent by multiple target UEs (UE-B, UE-C, UE-D), the initiating UE (server UE-A), and the anchor UEs (UE-E, UE-F, UE-G) via unicast, multicast, or broadcast.

[0857] Figure 37 , Operation 11 : The SLPP session can be terminated.

[0858] like Figure 37 As shown, the SLPP messages and message call flow for a UE-based sidelink positioning session for multiple target UEs can be the same as the SLPP messages and message call flow for a UE-based sidelink positioning session for a single target UE. In addition, regardless of whether the session is for a single target UE or for multiple target UEs, both UE-based and UE-assisted sidelink positioning use the same SLPP messages and SLPP message call flow.

[0859] refer to Figure 37In one aspect, a UE-based sidelink positioning SLPP session may use the same SLPP messages and SLPP message call flow regardless of whether the session is for a single target UE or multiple target UEs.

[0860] refer to Figure 37 In one aspect, a SLPP sidelink positioning session (UE-assisted or UE-based) may use the same SLPP messages and SLPP message call flow regardless of whether the SLPP session is for a single target UE or multiple target UEs.

[0861] Figure 38 A UE-based (distributed) sidelink-only ranging procedure 3800 for a single target UE is shown in accordance with aspects of the present disclosure. Figure 39

[00106] A UE-based (distributed) sidelink-only ranging procedure 3900 for multiple target UEs is shown in accordance with aspects of the present disclosure. Figure 38-Figure 39 UE-based sidelink ranging for single target UE and multiple target UEs is shown, where the server UE (UE-A) initiates the SLPP session and subsequent range calculations are performed by participating UEs based on SL-PRS measurements received from the single target UE or multiple target UEs. The SLPP message flow is the same for ranging for single target UE and ranging for multiple target UEs, and the UE-based sidelink positioning for single target UE and multiple target UEs are the same as Figure 36 and 37 After UE discovery, the UE performs session establishment, capability and assistance data exchange, location information transfer, and session termination. Figure 38-Figure 39 Each consists of operations 0 to 11, which are summarized as follows:

[0862] Figure 38-Figure 39 , Operation 0-5 :and Figure 34-Figure 35 Same as in.

[0863] Figure 38-Figure 39 , Operation 6: The initiating UE (server UE-A) sends the SLPP Request Location Information message: Single Target UE: The initiating UE (server UE-A) sends the SLPP Request Location Information message to target UE-B. Multiple Target UEs: The initiating UE (server UE-A) sends the SLPP Request Location Information message to multiple target UEs (UE-B, UE-C, UE-D). Depending on the specific scenario, the SLPP Request Location Information message can be sent by the initiating UE (server UE-A) to a single target UE (UE-B) or multiple target UEs (UE-B, UE-C, UE-D) via unicast, multicast, or broadcast. The SLPP Request Location Information message indicates the type of location information required and the associated QoS (e.g., expected accuracy, response time, etc.). The message also includes an indication that each participating UE (the initiating server UE-A and the target UEs) should perform range / positioning calculations.

[0864] Figure 38-Figure 39 , Operation 7 : Each participating UE performs the requested SL-PRS transmission and measurement.

[0865] Figure 38-Figure 39 , Operation 8 SLPP Provides Location Information: Single Target UE: A single target UE (UE-B) and an initiating UE (server UE-A) send the SLPP Provides Location Information message. Multiple Target UEs: Multiple target UEs (UE-B, UE-C, UE-D) and an initiating UE (server UE-A) send the SLPP Provides Location Information message. Depending on the scenario, the SLPP Provides Location Information message can be sent by a single target UE (UE-B) to the initiating UE (server UE-A) via unicast, multicast, or broadcast, or by multiple target UEs (UE-B, UE-C, UE-D) to the initiating UE (server UE-A) via unicast, multicast, or broadcast. The SLPP Provides Location Information message can be sent upon completion of transmission and measurement, periodically, or after the expiration of the response time received in operation 6. It can also include an indication of whether to request other UEs (in this case, the initiating server UE-A) to provide location results (e.g., calculated range and / or position) back to this UE. Based on the configuration received in the SLPP Provide Assistance Data message, SL-PRS transmission and SL-PRS measurement may be performed periodically.

[0866] Figure 38-Figure 39 , Operation 9 : Each participating UE performs range / positioning calculations using the position result received at operation 8 and its own position result obtained at operation 7.

[0867] Figure 38-Figure 39 , Operation 10If requested in operation 8, each UE can distribute its location results to other UEs in the session by sending an SLPP Provide Location Information message. Single Target UE: The SLPP Provide Location Information message is sent by the initiating UE (server UE-A) and a single target UE-B. Multiple Target UEs: The SLPP Provide Location Information message is sent by the initiating UE (server UE-A) and multiple target UEs (UE-B, UE-C, UE-D). Depending on the specific implementation, the SLPP Provide Location Information message can be sent by the initiating UE (server UE-A) to a single target UE (UE-B) or multiple target UEs (UE-B, UE-C, UE-D) via unicast, multicast, or broadcast.

[0868] Figure 38-Figure 39 , Operation 11 : The SLPP session can be terminated.

[0869] On the one hand, Figure 38-Figure 39 It is demonstrated that SLPP messages and message sequences can be the same regardless of whether an SLPP session is established to perform ranging / positioning for a single target UE or for a collection of multiple target UEs. In one aspect, there is no difference in SLPP signaling between SLPP sessions for a single target UE or for multiple target UEs. Furthermore, implementing an SLPP session to support only a single target UE may not be necessary, and any ranging / positioning session involving more than one target UE may require invoking multiple SLPP sessions. The resulting performance may be inefficient in the use of air resources and extend the time required to obtain range and / or positioning results.

[0870] refer to Figure 38-Figure 39 In one aspect, the same SLPP message and the same SLPP message sequence may be used regardless of whether an SLPP session is established for ranging and / or positioning a single target UE or a set of multiple target UEs.

[0871] refer to Figure 38-Figure 39 In one aspect, invoking multiple SLPP sessions to perform ranging and / or positioning for a set of multiple target UEs consumes more air resources than a single SLPP session involving the set of multiple target UEs and requires a longer period of time to obtain range / positioning results for all UEs.

[0872] refer to Figure 38-Figure 39In one aspect, sidelink ranging / positioning of a group of one or more UEs (a collection of multiple target UEs) can be applicable to a variety of use cases, including IIoT, commercial, public safety, and V2X. Specifically, V2X use cases may involve large groups of UEs that may participate in sidelink ranging / positioning. In one aspect, the same SLPP messages and SLPP message sequences can be applied to both a single target UE and multiple target UEs, eliminating the additional burden of specification development to support multiple target UEs. In one aspect, SLPP supports a single target UE or multiple target UEs within the same SLPP ranging / SL positioning session.

[0873] In some designs, the unicast link setup signaling overhead and the requirement for at least as many unicast links as UE participants (for centralized operation, (n-1) unicast links are required) significantly limits the scalability of unicast as a general solution for sidelink positioning and ranging. This is understood for the V2X use case, which is a key use case proposed in the SID. As the number of participating UEs (vehicles) increases, the number of required additional unicast links also increases, resulting in increased signaling overhead, bandwidth consumption, and latency, which reduces efficiency and limits the number of participants. For example, in high traffic conditions, the V2X UE may be larger than Figure 8C Much more than shown. For public safety, commercial, and IIoT use cases, unicast performance will be impacted as the number of UEs participating in sidelink positioning and ranging increases. Therefore, multicast / broadcast for sidelink positioning and ranging may benefit a variety of use cases. Such use cases may involve roadside units (RSUs) and multiple vehicles, or multiple vehicles in a fleet, etc. In addition, MCX services that rely on group communication will also benefit from multicast / broadcast signaling support. Furthermore, for ranging-based services, there are multiple use cases involving groups of UEs performing ranging / sidelink positioning services, for example, museum tours, etc.

[0874] On the one hand, PC5-U features clearly defined Quality of Service (QoS) management procedures, enabling upper layers to specify exact QoS requirements to the AS layer. PC5-U supports QoS by mapping PC5 QoS Flow Identifiers (PFIs) from the application layer to the AS layer, including resource type, priority level, packet delay budget, and packet error rate, thus providing flexibility in QoS specification for different use cases. This contrasts with the PDCP approach, where only default QoS settings can be applied to assigned SRBs. There is no mechanism to differentiate messages sent over an SRB based on QoS (all messages use the same default QoS).

[0875] In one aspect, regarding broadcast type support, SLPP transport over PC5-U as a payload on the V2X / ProSe layer enables the reuse of existing procedures for broadcast type specifications. In this case, no additional standardization work is required. In contrast, for SLPP rather than PDCP, new processing procedures and broadcast type specifications may need to be developed.

[0876] In one aspect, sidelink positioning / ranging PC5-U provides flexibility in QoS, broadcast type, and reduced link establishment latency for one-to-one, one-to-many, and many-to-one, and requires minimal standards specification work. In one aspect, no modification to the PC5 reference point is required for SLPP transport over the PC5 user plane.

[0877] In addition to the total number of UEs communicating via the sidelink at any one time, the rate at which the number of UEs communicating via the sidelink changes also impacts scalability. For example, if traffic (the number of vehicles) increases over a time interval T, the RSU may be required to establish communication with each new vehicle over time interval T. The rate at which new connections must be established will be N / T (where N is the number of vehicles entering the intersection during T). Solutions that can establish (and release) connections more quickly are preferred.

[0878] Aspects of the present disclosure are directed to the SLPP session establishment process. In the current design, the sidelink positioning session establishment process is not defined in the relevant standards and is left to the implementation. Such aspects related to the SLPP session establishment process can provide various technical advantages, such as reliable SLPP session establishment, which can provide improved positioning estimate accuracy, positioning estimate latency, etc.

[0879] Figure 40A 、 Figure 40B and Figure 40CSeveral example components (represented by corresponding blocks) are shown. These components may be incorporated into a UE 4002 (which may correspond to any UE described herein), a base station 4004 (which may correspond to any base station described herein), and a network entity 4006 (which may correspond to or embody any network function described herein, including a location server and LMF, or alternatively may be independent of the NG-RAN and / or 5GC infrastructure, such as a dedicated network) to support the operations described herein. It should be understood that these components may be implemented in different types of devices (e.g., in an ASIC, a system-on-chip (SoC), etc.) in different embodiments. The illustrated components may also be incorporated into other devices in a communications system. For example, other devices in the system may include components similar to those described to provide similar functionality. Furthermore, a given device may include one or more components. For example, a device may include multiple transceiver components that enable the device to operate on multiple carriers and / or communicate via different technologies.

[0880] UE 4002 and base station 4004 each include one or more wireless wide area network (WWAN) transceivers 4010 and 4050, respectively, to provide means (e.g., means for transmitting, means for receiving, means for measuring, means for tuning, means for suppressing transmission, etc.) for communicating via one or more wireless communication networks (not shown) (such as NR networks, LTE networks, GSM networks, etc.). WWAN transceivers 4010 and 4050 can each be connected to one or more antennas 4016 and 4056, respectively, for communicating with other network nodes (such as other UEs, access points, base stations (e.g., eNBs, gNBs), etc.) via at least one designated RAT (e.g., NR, LTE, GSM, etc.) over a wireless communication medium of interest (e.g., a certain set of time / frequency resources in a specific spectrum). WWAN transceivers 4010 and 4050 can be configured differently to transmit and encode signals 4018 and 4058 (e.g., messages, indicators, information, etc.) according to a specified RAT, and conversely, receive and decode signals 4018 and 4058 (e.g., messages, indicators, information, pilots, etc.), respectively. Specifically, WWAN transceivers 4010 and 4050 include one or more transmitters 4014 and 4054 and one or more receivers 4012 and 4052, the one or more transmitters 4014 and 4054 being used to transmit and encode signals 4018 and 4058, respectively, and the one or more receivers 4012 and 4052 being used to receive and decode signals 4018 and 4058, respectively.

[0881] In at least some cases, the UE 4002 and the base station 4004 each further include one or more short-range wireless transceivers 4020 and 4060, respectively. The short-range wireless transceivers 4020 and 4060 can be connected to one or more antennas 4026 and 4066, respectively, and provide means (e.g., means for transmitting, means for receiving, means for measuring, means for tuning, means for suppressing transmission, etc.) for communicating with other network nodes, such as other UEs, access points, base stations, etc., over the wireless communication medium of interest via at least one designated RAT (e.g., WiFi, LTE-D, Bluetooth®, Zigbee®, Z-Wave®, PC5, Dedicated Short Range Communications (DSRC), Wireless Access for Vehicular Environments (WAVE), Near Field Communication (NFC), Ultra-Wideband (UWB), etc.). Depending on the designated RAT, short-range wireless transceivers 4020 and 4060 can be configured differently to transmit and encode signals 4028 and 4068 (e.g., messages, indications, information, etc.), respectively, and conversely, receive and decode signals 4028 and 4068 (e.g., messages, indications, information, pilots, etc.), respectively. Specifically, short-range wireless transceivers 4020 and 4060 include one or more transmitters 4024 and 4064 for transmitting and encoding signals 4028 and 4068, respectively, and one or more receivers 4022 and 4062 for receiving and decoding signals 4028 and 4068, respectively. As specific examples, short-range wireless transceivers 4020 and 4060 can be WiFi transceivers, Bluetooth® transceivers, Zigbee® and / or Z-Wave® transceivers, NFC transceivers, UWB transceivers, or vehicle-to-vehicle (V2V) and / or vehicle-to-everything (V2X) transceivers.

[0882] At least in some cases, UE 4002 and base station 4004 also include satellite signal receivers 4030 and 4070. Satellite signal receivers 4030 and 4070 can be connected to one or more antennas 4036 and 4076, respectively, and can provide components for receiving and / or measuring satellite positioning / communication signals 4038 and 4078, respectively. If satellite signal receivers 4030 and 4070 are satellite positioning system receivers, satellite positioning / communication signals 4038 and 4078 can be Global Positioning System (GPS) signals, Global Navigation Satellite System (GLONASS) signals, Galileo signals, BeiDou signals, Indian Regional Navigation Satellite System (NAVIC), Quasi-Zenith Satellite System (QZSS), etc. If satellite signal receivers 4030 and 4070 are non-terrestrial network (NTN) receivers, satellite positioning / communication signals 4038 and 4078 can be communication signals originating from a 5G network (e.g., carrying control and / or user data). Satellite signal receivers 4030 and 4070 may include any suitable hardware and / or software for receiving and processing satellite positioning / communication signals 4038 and 4078, respectively. Satellite signal receivers 4030 and 4070 may request appropriate information and operations from other systems and, at least in some cases, perform calculations using measurements obtained by any suitable satellite positioning system algorithm to determine the positions of UE 4002 and base station 4004, respectively.

[0883] Base station 4004 and network entity 4006 each include one or more network transceivers 4080 and 4090, respectively, to provide means (e.g., means for transmitting, means for receiving, etc.) for communicating with other network entities (e.g., other base stations 4004, other network entities 4006). For example, base station 4004 may employ one or more network transceivers 4080 to communicate with other base stations 4004 or network entities 4006 via one or more wired or wireless backhaul links. As another example, network entity 4006 may employ one or more network transceivers 4090 to communicate with one or more base stations 4004 via one or more wired or wireless backhaul links, or to communicate with other network entities 4006 via one or more wired or wireless core network interfaces.

[0884] A transceiver can be configured to communicate over a wired or wireless link. A transceiver (whether wired or wireless) includes transmitter circuitry (e.g., transmitters 4014, 4024, 4054, 4064) and receiver circuitry (e.g., receivers 4012, 4022, 4052, 4062). In some embodiments, a transceiver can be an integrated device (e.g., transmitter circuitry and receiver circuitry embodied in a single device), in some embodiments can include separate transmitter circuitry and separate receiver circuitry, or in other embodiments can be embodied in other ways. The transmitter circuitry and receiver circuitry of a wired transceiver (e.g., network transceivers 4080 and 4090 in some embodiments) can be coupled to one or more wired network interface ports. Wireless transmitter circuitry (e.g., transmitters 4014, 4024, 4054, 4064) may include or be coupled to multiple antennas (e.g., antennas 4016, 4026, 4056, 4066), such as antenna arrays, which allows a corresponding device (e.g., UE 4002, base station 4004) to perform transmit "beamforming," as described herein. Similarly, wireless receiver circuitry (e.g., receivers 4012, 4022, 4052, 4062) may include or be coupled to multiple antennas (e.g., antennas 4016, 4026, 4056, 4066), such as antenna arrays, which allows a corresponding device (e.g., UE 4002, base station 4004) to perform receive beamforming, as described herein. In one aspect, the transmitter circuitry and the receiver circuitry may share the same multiple antennas (e.g., antennas 4016, 4026, 4056, 4066), such that the corresponding device can only receive or transmit at a given time, but not simultaneously. The wireless transceivers (eg, WWAN transceivers 4010 and 4050 , short-range wireless transceivers 4020 and 4060 ) may also include a network listening module (NLM) or the like for performing various measurements.

[0885] As used herein, various wireless transceivers (e.g., transceivers 4010, 4020, 4050, and 4060 and network transceivers 4080 and 4090 in some embodiments) and wired transceivers (e.g., network transceivers 4080 and 4090 in some embodiments) may be generally characterized as a "transceiver," "at least one transceiver," or "one or more transceivers." Thus, whether a particular transceiver is a wired or wireless transceiver can be inferred from the type of communication being performed. For example, backhaul communications between network devices or servers typically involve signaling via a wired transceiver, while wireless communications between a UE (e.g., UE 4002) and a base station (e.g., base station 4004) typically involve signaling via a wireless transceiver.

[0886] UE 4002, base station 4004, and network entity 4006 also include other components that can be used in conjunction with the operations disclosed herein. UE 4002, base station 4004, and network entity 4006 each include one or more processors 4032, 4084, and 4094 for providing functionality related to, for example, wireless communication and for providing other processing functionality. Processors 4032, 4084, and 4094 can thus provide means for processing, such as means for determining, means for computing, means for receiving, means for transmitting, means for indicating, and the like. In one aspect, processors 4032, 4084, and 4094 can include, for example, one or more general-purpose processors, multi-core processors, central processing units (CPUs), ASICs, digital signal processors (DSPs), field programmable gate arrays (FPGAs), other programmable logic devices or processing circuits, or various combinations thereof.

[0887] UE 4002, base station 4004, and network entity 4006, respectively, include memory circuitry implementing memories 4040, 4086, and 4096 (e.g., each including a memory device) for maintaining information (e.g., information indicating reserved resources, thresholds, parameters, etc.). Thus, memories 4040, 4086, and 4096 may provide means for storing, means for retrieving, means for maintaining, etc. In some cases, UE 4002, base station 4004, and network entity 4006 may include SLPP components 4042, 4088, and 4098, respectively. SLPP components 4042, 4088, and 4098 may be part of or hardware circuitry coupled to processors 4032, 4084, and 4094, respectively, which, when executed, cause UE 4002, base station 4004, and network entity 4006 to perform the functions described herein. In other aspects, the SLPP components 4042, 4088, and 4098 can be external to the processors 4032, 4084, and 4094 (e.g., part of a modem processing system, integrated with another processing system, etc.). Alternatively, the SLPP components 4042, 4088, and 4098 can be memory modules stored in the memories 4040, 4086, and 4096, respectively, which, when executed by the processors 4032, 4084, and 4094 (or a modem processing system, another processing system, etc.), cause the UE 4002, the base station 4004, and the network entity 4006 to perform the functions described herein. Figure 40A Possible locations for the SLPP component 4042 are shown, which may be, for example, part of the one or more WWAN transceivers 4010, the memory 4040, the one or more processors 4032, or any combination thereof, or may be a standalone component. Figure 40BPossible locations for the SLPP component 4088 are shown, which may be, for example, part of the one or more WWAN transceivers 4050, the memory 4086, the one or more processors 4084, or any combination thereof, or may be a standalone component. Figure 40C Possible locations for the SLPP component 4098 are shown, which may be, for example, part of one or more network transceivers 4090, memory 4096, one or more processors 4094, or any combination thereof, or may be a standalone component.

[0888] UE 4002 may include one or more sensors 4044 coupled to one or more processors 4032 to provide means for sensing or detecting movement and / or orientation information independent of motion data derived from signals received by one or more WWAN transceivers 4010, one or more short-range wireless transceivers 4020, and / or satellite signal receiver 4030. For example, sensors 4044 may include an accelerometer (e.g., a microelectromechanical system (MEMS) device), a gyroscope, a geomagnetic sensor (e.g., a compass), an altimeter (e.g., a barometric altimeter), and / or any other type of motion detection sensor. Furthermore, sensors 4044 may include multiple different types of devices and combine their outputs to provide motion information. For example, sensors 4044 may use a combination of a multi-axis accelerometer and an orientation sensor to provide the ability to calculate a position in a two-dimensional (2D) and / or three-dimensional (3D) coordinate system.

[0889] In addition, the UE 4002 includes a user interface 4046, which provides a means for providing indications to the user (e.g., auditory and / or visual indications) and / or for receiving user input (e.g., when the user activates a sensing device such as a keyboard, touch screen, microphone, etc.). Although not shown, the base station 4004 and the network entity 4006 may also include a user interface.

[0890] Referring to the one or more processors 4084 in more detail, in a downlink, IP packets from the network entity 4006 may be provided to the processor 4084. The one or more processors 4084 may implement the functions of the RRC layer, the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, and the Medium Access Control (MAC) layer. One or more processors 4084 may provide RRC layer functions associated with broadcasting of system information (e.g., Master Information Block (MIB), System Information Block (SIB)), RRC connection control (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), inter-RAT mobility, and measurement configuration for UE measurement reporting; PDCP layer functions associated with header compression / decompression, security (ciphering, deciphering, integrity protection, integrity verification), and handover support functions; RLC layer functions associated with transmission of upper layer PDUs, error correction through automatic repeat request (ARQ), concatenation, segmentation, and reassembly of RLC service data units (SDUs), resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority handling, and logical channel prioritization.

[0891] The transmitter 4054 and receiver 4052 can implement Layer 1 (L1) functions associated with various signal processing functions. Layer 1, including the physical (PHY) layer, can include error detection on the transport channel, forward error correction (FEC) encoding / decoding of the transport channel, interleaving, rate matching, mapping to physical channels, modulation / demodulation of the physical channels, and MIMO antenna processing. The transmitter 4054 handles the mapping to the signal constellation based on various modulation schemes (e.g., binary phase-shift keying (BPSK), quadrature phase-shift keying (QPSK), M-phase-shift keying (M-PSK), and M-quadrature amplitude modulation (M-QAM)). The coded and modulated symbols can then be split into parallel streams. Each stream can then be mapped to orthogonal frequency-division multiplexing (OFDM) subcarriers, multiplexed with reference signals (e.g., pilots) in the time and / or frequency domains, and then combined using an inverse fast Fourier transform (IFFT) to produce a physical channel carrying the time-domain OFDM symbol stream. The OFDM symbol stream is spatially precoded to generate multiple spatial streams. Channel estimates from a channel estimator can be used to determine the coding and modulation schemes as well as spatial processing. The channel estimates can be derived from a reference signal and / or channel condition feedback sent by the UE 4002. Each spatial stream can then be provided to one or more different antennas 4056. The transmitter 4054 can modulate an RF carrier with the corresponding spatial stream for transmission.

[0892] At UE 4002, receiver 4012 receives the signal via its corresponding antenna 4016. Receiver 4012 recovers the information modulated onto the RF carrier and provides this information to one or more processors 4032. Transmitter 4014 and receiver 4012 implement Layer 1 functionality associated with various signal processing functions. Receiver 4012 can perform spatial processing on this information to recover any spatial streams destined for UE 4002. If multiple spatial streams are destined for UE 4002, receiver 4012 can combine them into a single OFDM symbol stream. Receiver 4012 then uses a Fast Fourier Transform (FFT) to convert the OFDM symbol stream from the time domain to the frequency domain. The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols and reference signals on each subcarrier are recovered and demodulated by determining the most likely signal constellation transmitted by base station 4004. These soft decisions can be based on channel estimates calculated by a channel estimator. The soft decisions are then decoded and deinterleaved to recover the data and control signals originally sent on the physical channel by the base station 4004. The data and control signals are then provided to one or more processors 4032, which implement layer 3 (L3) and layer 2 (L2) functionality.

[0893] In the downlink, one or more processors 4032 provide demultiplexing between transport and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the core network. One or more processors 4032 are also responsible for error detection.

[0894] Similar to the functions described in conjunction with downlink transmission of base station 4004, one or more processors 4032 provide RRC layer functions associated with system information (e.g., MIB, SIB) acquisition, RRC connection and measurement reporting; PDCP layer functions associated with header compression / decompression and security (encryption, decryption, integrity protection, integrity verification); RLC layer functions associated with transmission of upper layer PDUs, error correction through ARQ, concatenation, segmentation and reassembly of RLC SDUs, resegmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functions associated with mapping between logical channels and transport channels, multiplexing of MAC SDUs on transport blocks (TBs), demultiplexing of MAC SDUs from TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), priority handling and logical channel prioritization.

[0895] The transmitter 4014 may select an appropriate coding and modulation scheme and facilitate spatial processing using channel estimates derived by a channel estimator from a reference signal or feedback transmitted by the base station 4004. The spatial streams generated by the transmitter 4014 may be provided to different antennas 4016. The transmitter 4014 may modulate an RF carrier with the corresponding spatial stream for transmission.

[0896] At the base station 4004, the uplink transmission is processed in a manner similar to that described in conjunction with the receiver functionality at the UE 4002. The receivers 4052 receive the signals through their respective antennas 4056. The receivers 4052 recover the information modulated onto the RF carrier and provide the information to one or more processors 4084.

[0897] In the uplink, one or more processors 4084 provide demultiplexing between transport channels and logical channels, packet reassembly, decryption, header decompression, and control signal processing to recover IP packets from the UE 4002. The IP packets from the one or more processors 4084 can be provided to the core network. The one or more processors 4084 are also responsible for error detection.

[0898] For convenience, UE 4002, base station 4004 and / or network entity 4006 are Figure 40A 、 Figure 40B and Figure 40C The illustrative embodiment of the present invention is shown as including various components that can be configured according to the various examples described herein. However, it should be understood that the components shown can have different functions in different designs. Specifically, Figures 40A to 40C The various components in are optional in alternative configurations, and various aspects include configurations that may vary due to design choice, cost, use of the device, or other considerations. For example, in Figure 40A In the case of , a particular embodiment of the UE 4002 may omit the WWAN transceiver 4010 (e.g., a wearable device or tablet or PC or laptop may have Wi-Fi and / or Bluetooth capabilities but no cellular capabilities), or may omit the short-range wireless transceiver 4020 (e.g., only cellular, etc.), or may omit the satellite signal receiver 4030, or may omit the sensor 4044, etc. In another example, in Figure 40B In certain embodiments, the base station 4004 may omit the WWAN transceiver 4050 (e.g., a Wi-Fi "hotspot" access point without cellular capabilities), or may omit the short-range wireless transceiver 4060 (e.g., cellular only, etc.), or may omit the satellite signal receiver 4070, etc. For the sake of brevity, illustrations of various alternative configurations are not provided herein, but will be readily apparent to those skilled in the art.

[0899] The various components of the UE 4002, base station 4004, and network entity 4006 may be communicatively coupled to one another via data buses 4034, 4082, and 4092, respectively. In one aspect, the data buses 4034, 4082, and 4092 may form or be part of a communication interface for the UE 4002, base station 4004, and network entity 4006, respectively. For example, where different logical entities are embodied in the same device (e.g., gNB and location server functionality are incorporated into the same base station 4004), the data buses 4034, 4082, and 4092 may provide communication therebetween.

[0900] Figure 40A 、 Figure 40B and Figure 40C The components of can be implemented in various ways. In some embodiments, Figure 40A 、 Figure 40B and Figure 40C The components may be implemented in one or more circuits, such as one or more processors and / or one or more ASICs (which may include one or more processors). Each circuit may utilize and / or incorporate at least one memory component to store information or executable code used by the circuit to provide the functionality. For example, some or all of the functionality represented by blocks 4010 through 4046 may be implemented by the processor and memory components of UE 4002 (e.g., by executing appropriate code and / or by appropriately configuring the processor components). Similarly, some or all of the functionality represented by blocks 4050 through 4088 may be implemented by the processor and memory components of base station 4004 (e.g., by executing appropriate code and / or by appropriately configuring the processor components). Furthermore, some or all of the functionality represented by blocks 4090 through 4098 may be implemented by the processor and memory components of network entity 4006 (e.g., by executing appropriate code and / or by appropriately configuring the processor components). For simplicity, various operations, actions, and / or functions may be described herein as being performed by a "UE," a "base station," a "network entity," or the like. However, it should be understood that these operations, actions and / or functions may actually be performed by specific components or combinations of components of the UE 4002, base station 4004, network entity 4006, etc., such as processors 4032, 4084, 4094, transceivers 4010, 4020, 4050 and 4060, memories 4040, 4086 and 4096, SLPP components 4042, 4088 and 4098, etc.

[0901] In some designs, network entity 4006 may be implemented as a core network component. In other designs, network entity 4006 may be distinct from the operations of a network operator or cellular network infrastructure (e.g., NG RAN and / or 5GC). For example, network entity 4006 may be a component of a private network that may be configured to communicate with UE 4002 via base station 4004 or independently of base station 4004 (e.g., via a non-cellular communication link such as WiFi).

[0902] Figure 41 An exemplary process 4100 for communicating according to aspects of the present disclosure is shown. Figure 41 The process 4100 is performed by a UE such as UE 4002. Specifically, as described above, Figure 41 The process 4100 is performed by an initiator UE (eg, an initiator of an SLPP session). In some designs, Figure 41 Process 4100 can be performed during the above-described device and service discovery.

[0903] refer to Figure 41 At 4110 , an initiator UE (eg, transmitter 4014 or 4024 , etc.) sends a first request to create a Sidelink Positioning Protocol (SLPP) session to each recipient UE in a set of one or more recipient UEs.

[0904] refer to Figure 41 At 4120 , the initiator UE (eg, receiver 4012 or 4022 , etc.) receives a first response from each receiving UE in the set of one or more receiving UEs, wherein each first response indicates that the corresponding receiving UE accepts or rejects the SLPP session.

[0905] refer to Figure 41 At 4130, the initiating UE (e.g., processor 4032, SLPP component 4042, etc.) determines a group of one or more UEs participating in the SLPP session from among the receiving UEs (e.g., based on signal strength, based on a spatial or distance separation parameter of the UEs in the group, etc.), and receives a corresponding first response from the receiving UE indicating acceptance of the SLPP session.

[0906] refer to Figure 41 At 4140 , the initiator UE (eg, transmitter 4014 or 4024 , etc.) sends a second request to start an SLPP session to the group of one or more UEs.

[0907] refer to Figure 41 At 4150 , the initiator UE (eg, recipient 4012 or 4022 , etc.) receives second responses from the group of one or more UEs, each second response confirming the second request.

[0908] refer to Figure 41 In some designs, the first request is sent via unicast, multicast, or broadcast, or each first response is received via unicast, multicast, broadcast, or a combination thereof, or the second request is sent via unicast, multicast, or broadcast, or each second response is received via unicast, multicast, broadcast, or a combination thereof, or any combination thereof.

[0909] refer to Figure 41 In some designs, the first request includes a session identifier associated with the SLPP session.

[0910] refer to Figure 41 In some designs, the first request includes a layer 2 (L2) group identifier associated with the SLPP session.

[0911] refer to Figure 41 In some designs, the group of one or more UEs includes each recipient UE that indicates acceptance of the SLPP session via a corresponding first response (e.g., all accepting recipient UEs, while in alternative embodiments, the fastest N responding UEs that respond within a time window or all accepting recipient UEs are added to the group, etc.), or the group of one or more UEs omits one or more recipient UEs that indicate rejection of the SLPP session via one or more corresponding first responses (e.g., because not all recipient UEs can accept the first request, etc.). In some designs, the initiator UE also sends (e.g., during the SLPP session) a third request to modify the SLPP session to the group of one or more UEs and any new recipient UEs to be added to the group of one or more UEs, the third request indicating whether the corresponding recipient UE is to be included or excluded from the modified SLPP session associated with the modified group of one or more UEs. In some designs, the modified group of one or more UEs includes each recipient UE that indicates acceptance of the modified SLPP session via a corresponding third response, or the modified group of one or more UEs omits one or more recipient UEs that indicate rejection of the modified SLPP session via one or more corresponding third responses.

[0912] refer to Figure 41 In some designs, the second request includes layer 2 (L2) and layer 3 (L3) (e.g., application layer) identifiers associated with the SLPP session, a UE identifier associated with the initiating UE, and a UE identifier associated with each UE in the group of one or more UEs.

[0913] refer to Figure 41In some designs, the initiator UE may also obtain a set of sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session and determine a positioning estimate for the initiator UE, one or more UEs in a group of one or more UEs, or a combination thereof based on the set of SL-PRS measurements. Note that the initiator UE may directly measure some or all of its own SL-PRS measurements, or alternatively, other UEs may directly measure some or all of the SL-PRS measurements and then communicate them (in whole or in part) to the initiator UE. Combinations of these methods are also possible. In some designs, one or more positioning estimates for one or more UEs are determined and sent to the one or more UEs.

[0914] Figure 42 An exemplary process 4200 for communicating according to aspects of the present disclosure is shown. Figure 42 The process 4200 is performed by a UE (such as UE 4002). Specifically, as described above, Figure 42 The process 4200 is performed by the receiving UE. In some designs, Figure 42 The process 4200 can be performed during the device and service discovery described above. In some designs, Figure 42 The course 4200 can be combined with Figure 42 Process 4100 is executed.

[0915] refer to Figure 42 At 4210 , a receiving UE (eg, receiver 4012 or 4022 , etc.) receives a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiating UE.

[0916] refer to Figure 42 At 4220 , the receiving UE (eg, transmitter 4014 or 4024 , etc.) sends a first response to the initiating UE indicating that the receiving UE accepts or rejects the SLPP session.

[0917] refer to Figure 42In some designs, the first response indicates that the receiving UE accepts the SLPP session. In some designs, the receiving UE may also receive a second request from the initiating UE to start the SLPP session and send a second response acknowledging the second request. In some designs, the second request is received via unicast, multicast, or broadcast, or the second response is sent via unicast, multicast, or broadcast, or any combination thereof. In some designs, the second request includes Layer 2 (L2) and Layer 3 (L3) (e.g., application layer) identifiers associated with the SLPP session, a UE identifier associated with the initiating UE, and a UE identifier associated with each UE in the group of one or more UEs associated with the SLPP session. In some designs, the receiving UE may also receive a third request from the initiating UE (e.g., during the SLPP session) to modify the SLPP session, the third request indicating whether the receiving UE will be included or excluded from the modified SLPP session. In some designs, the receiving UE may also send a third response to the initiating UE, indicating the receiving UE's acceptance, rejection, or acknowledgment of the modified SLPP session. In some designs, the receiving UE may also send sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session to the initiating UE. In some designs, the receiving UE may also receive a positioning estimate of the receiving UE from the initiating UE.

[0918] refer to Figure 42 In some designs, the first request is received via unicast, multicast, or broadcast, or the first response is sent via unicast, multicast, or broadcast, or any combination thereof. In some designs, the first request includes a session identifier associated with the SLPP session. In some designs, the first request includes a set of group identifiers associated with the SLPP session.

[0919] Figure 43 An exemplary process 4300 for communicating according to aspects of the present disclosure is shown. Figure 43 The process 4300 is performed by a UE (e.g., UE 4002). In some designs, the execution Figure 43 The UE of the process may be an initiator UE or a recipient UE.

[0920] refer to Figure 43 At 4310, the UE (e.g., processor 4032, SLPP component 4042, etc.) determines a first broadcast mode associated with a Sidelink Positioning Protocol (SLPP) message associated with an SLPP session. As used herein, "broadcast mode" may be used interchangeably with "broadcast type," such as unicast, multicast, or broadcast.

[0921] refer to Figure 43At 4320, the UE (eg, processor 4032, SLPP component 4042, etc.) determines a second broadcast mode associated with one or more SLPP response messages to the SLPP message. Note that not all SLPP messages must be configured to trigger such a response.

[0922] refer to Figure 43 At 4330, a UE (eg, transmitter 4014 or 4024, etc.) sends an SLPP message to a set of one or more UEs according to the first broadcast mode. In one aspect, the SLPP message includes an indication of both the first broadcast mode and the second broadcast mode.

[0923] refer to Figure 43 ,In some designs, the first broadcast mode is unicast, multicast, or broadcast, and the second broadcast mode is unicast, multicast, or broadcast.

[0924] refer to Figure 43 In some designs, the first broadcast mode is unicast, and the set of one or more UEs includes a single target UE. In some designs, the SLPP message includes a session identifier for the SLPP session, a first set of identifiers associated with the UE, and a second set of identifiers associated with the target UE. In some designs, the second broadcast mode is unicast, and the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode. In one aspect, the UE may also receive a response to the SLPP message from the target UE via unicast.

[0925] refer to Figure 43 In some designs, the first broadcast mode is multicast, and the set of one or more UEs includes a group of one or more UEs. In some designs, the SLPP message includes a session identifier of the SLPP session and a set of group identifiers associated with the SLPP session. In some designs, the second broadcast mode is multicast, and the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode. In this case, on the one hand, the UE may also receive a response to the SLPP message from at least one UE in the group of one or more UEs via multicast. In other designs, the second broadcast mode is unicast, and the SLPP message also includes an indication of the second broadcast mode. In this case, on the one hand, the UE may also receive a response to the SLPP message from at least one UE in the group of one or more UEs via unicast.

[0926] refer to Figure 43In some designs, the first broadcast mode is broadcast. In some designs, the SLPP message includes a session identifier for the SLPP session. In some designs, the second broadcast mode is broadcast, and the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode. In some designs, the UE may also receive a response to the SLPP message from at least one UE in the set of one or more UEs via broadcast.

[0927] Figure 44 An exemplary process 4400 for communications according to aspects of the present disclosure is shown. Figure 44 Process 4400 is performed by a UE, such as UE 4002. In some designs, the execution Figure 44 The UE of the process can be an initiator UE or a recipient UE. In some designs, Figure 44 The 4400 process can be combined with Figure 43 Process 4300 is executed.

[0928] refer to Figure 44 At 4410, a UE (e.g., receiver 4012 or 4022, etc.) receives a sidelink positioning protocol (SLPP) message associated with a SLPP session, wherein the SLPP message is received according to a first broadcast mode and includes an indication of both the first broadcast mode and a second broadcast mode associated with one or more SLPP response messages to the SLPP message.

[0929] refer to Figure 44 At 4420 , the UE (eg, transmitter 4014 or 4024 , etc.) sends an SLPP response message in response to the SLPP message according to the second broadcast mode.

[0930] refer to Figure 44 In some designs, the first broadcast mode is unicast, multicast, or broadcast, and the second broadcast mode is unicast, multicast, or broadcast.

[0931] refer to Figure 44 In some designs, the first broadcast mode is unicast, and the set of one or more UEs includes a single target UE. In some designs, the SLPP message includes a session identifier for the SLPP session, a first set of identifiers associated with the UEs, and a second set of identifiers associated with the target UEs. In some designs, the SLPP message also includes an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, and the second broadcast mode is unicast.

[0932] refer to Figure 44In some designs, the first broadcast mode is multicast, and the set of one or more UEs comprises a group of one or more UEs. In some designs, the SLPP message comprises a session identifier for the SLPP session and a set of group identifiers associated with the SLPP session. In some designs, the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, and the second broadcast mode is multicast. In other designs, the SLPP message further comprises an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, and the second broadcast mode is unicast.

[0933] refer to Figure 44 In some designs, the first broadcast mode is broadcast. In some designs, the SLPP message includes a session identifier for the SLPP session. In some designs, the SLPP message also includes an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, the second broadcast mode being broadcast.

[0934] refer to Figure 44 In some designs, SLPP can support at least the following common transaction modes:

[0935] • unicast transactions,

[0936] • Group transactions with group replies,

[0937] • Group transactions with unicast replies, and

[0938] • Broadcasting affairs.

[0939] In the detailed description above, it can be seen that different features are grouped together in the examples. This disclosure should not be interpreted as an intention that the example clauses have more features than explicitly mentioned in each clause. On the contrary, various aspects of the present disclosure may include fewer than all the features of the individual example clauses disclosed. Therefore, the following clauses can be considered to be combined in the specification, where each clause itself can serve as a separate example. Although each dependent clause can be referenced in a clause in a specific combination with one of the other clauses, the aspects of the dependent clause are not limited to that specific combination. It should be understood that other example clauses may also include combinations of dependent clause aspects with the subject matter of any other dependent clause or independent clause, or combinations of any features with other dependent and independent clauses. Various aspects disclosed herein explicitly include these combinations unless it is expressly stated or can be easily inferred that a particular combination is not intended (for example, contradictory aspects, such as defining an element as both an electrical insulator and an electrical conductor). In addition, various aspects of a clause may also be intended to be included in any other independent clause, even if the clause is not directly subordinate to the independent clause.

[0940] Examples of implementation are described in the following numbered clauses:

[0941] Clause 1. A method of operating an initiator user equipment (UE), comprising: sending a first request to each recipient UE from a set of one or more recipient UEs to create a Sidelink Positioning Protocol (SLPP) session; receiving a first response from the set of one or more recipient UEs, each indicating that the recipient UE accepts or rejects the SLPP session; determining a group of one or more UEs participating in the SLPP session from the recipient UEs from which respective first responses indicating acceptance of the SLPP session were received; sending a second request to the group of one or more UEs to start the SLPP session; and receiving a second response from the group of one or more UEs, each confirming the second request.

[0942] Clause 2. The method of clause 1, wherein the first request is sent via unicast, multicast, or broadcast, or wherein the first response is received via unicast, multicast, broadcast, or a combination thereof, or wherein the second request is sent via unicast, multicast, or broadcast, or wherein the second response is received via unicast, multicast, broadcast, or a combination thereof, or any combination thereof.

[0943] Clause 3. The method of any of clauses 1 to 2, wherein the first request includes a session identifier associated with the SLPP session.

[0944] Clause 4. The method of any of clauses 1 to 3, wherein the first request includes an L2 group identifier associated with the SLPP session.

[0945] Clause 5. A method according to any of clauses 1 to 4, wherein the group of one or more UEs includes each recipient UE that accepts the SLPP session via a respective first response indication, or wherein the group of one or more UEs omits one or more recipient UEs that reject the SLPP session via one or more respective first response indications.

[0946] Clause 6. The method of clause 5, further comprising: sending a third request to modify the SLPP session to the group of one or more UEs and any new recipient UE to be added to the group of one or more UEs, the third request indicating whether the respective recipient UE is to be included or excluded from the modified SLPP session associated with the modified group of one or more UEs.

[0947] Clause 7. A method according to clause 6, wherein the modified group of one or more UEs includes each recipient UE that accepts the modified SLPP session via a respective third response indication, or wherein the modified group of one or more UEs omits one or more recipient UEs that reject the modified SLPP session via the one or more respective third response indications.

[0948] Clause 8. A method according to any of clauses 1 to 7, wherein the second request comprises the L2 and L3 identifiers associated with the SLPP session, the UE identifier associated with the initiating UE, and the UE identifier associated with each UE in the group of one or more UEs.

[0949] Clause 9. A method according to any of clauses 1 to 8, further comprising: obtaining a set of sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session; and determining a positioning estimate for the initiating UE, one or more UEs in the group of one or more UEs, or a combination thereof based on the set of SL-PRS measurements.

[0950] Clause 10. The method of clause 9, wherein one or more positioning estimates for one or more UEs are determined and sent to the one or more UEs.

[0951] Clause 11. A method of operating a recipient user equipment (UE), comprising: receiving a first request from an initiator UE to create a Sidelink Positioning Protocol (SLPP) session; and sending a first response to the initiator UE indicating acceptance or rejection of the SLPP session by the recipient UE.

[0952] Clause 12. The method of clause 11, wherein the first response indicates acceptance of the SLPP session by the recipient UE.

[0953] Clause 13. The method of clause 12, further comprising: receiving a second request from the initiator UE to start the SLPP session; and sending a second response confirming the second request.

[0954] Clause 14. The method of clause 13, wherein the second request is received via unicast, multicast, or broadcast, or wherein the second response is sent via unicast, multicast, or broadcast, or any combination thereof.

[0955] Clause 15. A method according to any of clauses 13 to 14, wherein the second request comprises the L2 and L3 identifiers associated with the SLPP session, a UE identifier associated with the initiating UE, and a UE identifier associated with each UE in the group of one or more UEs associated with the SLPP session.

[0956] Clause 16. A method according to any of clauses 12 to 15, further comprising receiving a third request from the initiating UE to modify the SLPP session, the third request indicating whether the receiving UE is to be included or excluded from the modified SLPP session.

[0957] Clause 17. A method as described in clause 16, sending a third response to the initiating UE indicating acceptance or rejection or confirmation of the modified SLPP session by the receiving UE.

[0958] Clause 18. A method as described in any of clauses 12 to 17, further comprising sending Sidelink Positioning Reference Signal (SL-PRS) measurements associated with the SLPP session to the initiating UE.

[0959] Clause 19. A method as described in any of clauses 12 to 18, further comprising receiving a positioning estimate of the recipient UE from the originating UE.

[0960] Clause 20. The method of any of clauses 11 to 19, wherein the first request is received via unicast, multicast or broadcast, or wherein the first response is sent via unicast, multicast or broadcast, or any combination thereof.

[0961] Clause 21. The method of any of clauses 11 to 20, wherein the first request includes a session identifier associated with the SLPP session.

[0962] Clause 22. The method of clause 21, wherein the first request includes a set of group identifiers associated with the SLPP session.

[0963] Clause 23. A method of operating a user equipment (UE), comprising: determining a first broadcast mode associated with a Sidelink Positioning Protocol (SLPP) message, the SLPP message being associated with an SLPP session; selectively determining a second broadcast mode associated with any SLPP response message to the SLPP message based on whether the SLPP message is configured to trigger a response; and sending the SLPP message to a set of one or more UEs according to the first broadcast mode, wherein the SLPP message includes an indication of the first broadcast mode or both the first broadcast mode and the second broadcast mode.

[0964] Clause 24. The method of clause 23, wherein the first broadcast mode is unicast, multicast, or broadcast, and wherein the second broadcast mode is unicast, multicast, or broadcast.

[0965] Clause 25. A method as set forth in any of clauses 23 to 24, wherein the first broadcast mode is unicast, and wherein the set of one or more UEs comprises a single target UE.

[0966] Clause 26. The method of clause 25, wherein the SLPP message comprises a session identifier of the SLPP session, a first set of identifiers associated with the UE, and a second set of identifiers associated with the target UE.

[0967] Clause 27. A method according to any of clauses 25 to 26, wherein the selective determination determines that the second broadcast mode is unicast, and wherein the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, further comprising: receiving a response to the SLPP message from the target UE via unicast.

[0968] Clause 28. A method as set forth in any of clauses 23 to 27, wherein the first broadcast mode is groupcast, and wherein the set of one or more UEs comprises a group of one or more UEs.

[0969] Clause 29. The method of clause 28, wherein the SLPP message includes a session identifier of the SLPP session and a set of group identifiers associated with the SLPP session.

[0970] Clause 30. A method according to any of clauses 28 to 29, wherein the selective determination determines that the second broadcast mode is multicast, and wherein the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, further comprising: receiving a response to the SLPP message from at least one UE in the group of one or more UEs via multicast.

[0971] Clause 31. The method of any of clauses 28 to 30, wherein the selective determination determines that the second broadcast mode is unicast, and wherein the SLPP message further includes an indication of the second broadcast mode, further comprising: receiving a response to the SLPP message from at least one UE in the group of one or more UEs via unicast.

[0972] Clause 32. The method of any one of clauses 23 to 31, wherein the first broadcast mode is broadcast.

[0973] Clause 33. The method of clause 32, wherein the SLPP message includes a session identifier of the SLPP session.

[0974] Clause 34. A method according to any of clauses 32 to 33, wherein the selective determination determines that the second broadcast mode is broadcast, and wherein the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, further comprising: receiving a response to the SLPP message from at least one UE in the set of one or more UEs via the broadcast.

[0975] Clause 35. A method of operating a user equipment (UE), comprising: receiving a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, wherein the SLPP message is received according to a first broadcast mode and includes an indication of the first broadcast mode or both the first broadcast mode and a second broadcast mode associated with any SLPP response message to the SLPP message; and determining whether to respond to the SLPP message according to the second broadcast mode based on whether the SLPP message is configured to trigger a response.

[0976] Clause 36. The method of clause 35, wherein the first broadcast mode is unicast, multicast, or broadcast, and wherein the second broadcast mode is unicast, multicast, or broadcast.

[0977] Clause 37. The method of any of clauses 35 to 36, wherein the first broadcast mode is unicast.

[0978] Clause 38. The method of clause 37, wherein the SLPP message comprises a session identifier of the SLPP session, a first set of identifiers associated with another UE, and a second set of identifiers associated with the UE.

[0979] Clause 39. A method according to any of clauses 37 to 38, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is unicast, and wherein the determination is to respond to the SLPP message via unicast.

[0980] Clause 40. The method of any of clauses 35 to 39, wherein the first broadcast mode is multicast.

[0981] Clause 41. The method of clause 40, wherein the SLPP message includes a session identifier of the SLPP session and a set of group identifiers associated with the SLPP session.

[0982] Clause 42. The method of any of clauses 40 to 41, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is multicast, and wherein the determination is to respond to the SLPP message via multicast.

[0983] Clause 43. The method of any of clauses 40 to 42, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is unicast, and wherein the determination is to respond to the SLPP message via unicast.

[0984] Clause 44. The method of any one of clauses 35 to 43, wherein the first broadcast mode is broadcast.

[0985] Clause 45. The method of clause 44, wherein the SLPP message includes a session identifier of the SLPP session.

[0986] Clause 46. A method according to any of clauses 44 to 45, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is broadcast, and wherein the determination is to respond to the SLPP message via broadcast.

[0987] Clause 47. An initiator user equipment (UE), comprising: a memory; and at least one processor communicatively coupled to the memory, the at least one processor configured to: send a first request to each recipient UE from a set of one or more recipient UEs to create a sidelink positioning protocol (SLPP) session; receive a first response from the set of one or more recipient UEs, each indicating that the recipient UE accepts or rejects the SLPP session; determine a group of one or more UEs participating in the SLPP session from the recipient UEs from which respective first responses indicating acceptance of the SLPP session are received; send a second request to the group of one or more UEs to start the SLPP session; and receive a second response from the group of one or more UEs, each confirming the second request.

[0988] Clause 48. An initiator UE according to clause 47, wherein the first request is sent via unicast, multicast or broadcast, or wherein the first response is received via unicast, multicast, broadcast or a combination thereof, or wherein the second request is sent via unicast, multicast or broadcast, or wherein the second response is received via unicast, multicast, broadcast or a combination thereof, or any combination thereof.

[0989] Clause 49. The initiator UE of any of clauses 47 to 48, wherein the first request comprises a session identifier associated with the SLPP session.

[0990] Clause 50. The initiator UE of any of clauses 47 to 49, wherein the first request comprises an L2 group identifier associated with the SLPP session.

[0991] Clause 51. An initiator UE as described in any of clauses 47 to 50, wherein the group of one or more UEs includes each recipient UE that accepts the SLPP session via a respective first response indication, or wherein the group of one or more UEs omits one or more recipient UEs that reject the SLPP session via the one or more respective first response indications.

[0992] Clause 52. The initiator UE of clause 51, wherein the at least one processor is further configured to: send a third request to modify the SLPP session to the group of one or more UEs and any new recipient UE to be added to the group of one or more UEs, the third request indicating whether the respective recipient UE is to be included or excluded from the modified SLPP session associated with the modified group of one or more UEs.

[0993] Clause 53. An initiator UE according to clause 52, wherein the modified group of one or more UEs includes each recipient UE that accepts the modified SLPP session via a respective third response indication, or wherein the modified group of one or more UEs omits one or more recipient UEs that reject the modified SLPP session via the one or more respective third response indications.

[0994] Clause 54. An initiator UE as set forth in any of clauses 47 to 53, wherein the second request comprises the L2 and L3 identifiers associated with the SLPP session, a UE identifier associated with the initiator UE, and a UE identifier associated with each UE in the group of one or more UEs.

[0995] Clause 55. An initiator UE according to any of clauses 47 to 54, wherein the at least one processor is further configured to: obtain a set of sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session; and determine a positioning estimate for the initiator UE, one or more UEs in the set of one or more UEs, or a combination thereof based on the set of SL-PRS measurements.

[0996] Clause 56. The initiator UE of clause 55, wherein one or more positioning estimates for the one or more UEs are determined and sent to the one or more UEs.

[0997] Clause 57. A receiving user equipment (UE), comprising: a memory; and at least one processor communicatively coupled to the memory, the at least one processor configured to: receive a first request from an initiator UE to create a Sidelink Positioning Protocol (SLPP) session; and send a first response to the initiator UE indicating that the recipient UE accepts or rejects the SLPP session.

[0998] Clause 58. The recipient UE of clause 57, wherein the first response indicates acceptance of the SLPP session by the recipient UE.

[0999] Clause 59. The recipient UE of clause 58, wherein the at least one processor is further configured to: receive a second request from the initiator UE to start the SLPP session; and send a second response confirming the second request.

[1000] Clause 60. The recipient UE of clause 59, wherein the second request is received via unicast, multicast or broadcast, or wherein the second response is sent via unicast, multicast or broadcast, or any combination thereof.

[1001] Clause 61. A recipient UE as set forth in any of clauses 59 to 60, wherein the second request comprises the L2 and L3 identifiers associated with the SLPP session, the UE identifier associated with the initiating UE, and the UE identifier associated with each UE in the group of one or more UEs associated with the SLPP session.

[1002] Clause 62. A recipient UE as set forth in any of clauses 58 to 61, wherein the at least one processor is further configured to receive, from the initiating UE, a third request to modify the SLPP session, the third request indicating whether the recipient UE is to be included or excluded from the modified SLPP session.

[1003] Clause 63. The recipient UE of clause 62, sending a third response to the initiating UE indicating acceptance or rejection or confirmation of the modified SLPP session by the recipient UE.

[1004] Clause 64. The recipient UE of any of clauses 58 to 63, wherein the at least one processor is further configured to send Sidelink Positioning Reference Signal (SL-PRS) measurements associated with the SLPP session to the initiating UE.

[1005] Clause 65. A recipient UE as set forth in any of clauses 58 to 64, wherein the at least one processor is further configured to receive a positioning estimate for the recipient UE from the originating UE.

[1006] Clause 66. A recipient UE as set forth in any of clauses 57 to 65, wherein the first request is received via unicast, multicast or broadcast, or wherein the first response is sent via unicast, multicast or broadcast, or any combination thereof.

[1007] Clause 67. A recipient UE as set forth in any of clauses 57 to 66, wherein the first request comprises a session identifier associated with the SLPP session.

[1008] Clause 68. The recipient UE of clause 67, wherein the first request includes a set of group identifiers associated with the SLPP session.

[1009] Clause 69. A user equipment (UE), comprising: a memory; and at least one processor communicatively coupled to the memory, the at least one processor configured to: determine a first broadcast mode associated with a Sidelink Positioning Protocol (SLPP) message, the SLPP message being associated with an SLPP session; selectively determine a second broadcast mode associated with any SLPP response message to the SLPP message based on whether the SLPP message is configured to trigger a response; and send the SLPP message to a set of one or more UEs according to the first broadcast mode, wherein the SLPP message includes an indication of the first broadcast mode or both the first broadcast mode and the second broadcast mode.

[1010] Clause 70. The UE of clause 69, wherein the first broadcast mode is unicast, multicast, or broadcast, and wherein the second broadcast mode is unicast, multicast, or broadcast.

[1011] Clause 71. A UE as set forth in any of clauses 69 to 70, wherein the first broadcast mode is unicast, and wherein the set of one or more UEs comprises a single target UE.

[1012] Clause 72. The UE of clause 71, wherein the SLPP message comprises a session identifier of the SLPP session, a first set of identifiers associated with the UE, and a second set of identifiers associated with the target UE.

[1013] Clause 73. A UE according to any of clauses 71 to 72, wherein the selective determination determines that the second broadcast mode is unicast, and wherein the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, further comprising: receiving a response to the SLPP message from the target UE via unicast.

[1014] Clause 74. A UE as set forth in any of clauses 69 to 73, wherein the first broadcast mode is groupcast, and wherein the set of one or more UEs comprises a group of one or more UEs.

[1015] Clause 75. The UE of clause 74, wherein the SLPP message comprises a session identifier of the SLPP session and a set of group identifiers associated with the SLPP session.

[1016] Clause 76. A UE according to any of clauses 74 to 75, wherein the selective determination determines that the second broadcast mode is groupcast, and wherein the SLPP message also includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, further comprising: receiving a response to the SLPP message from at least one UE in the group of one or more UEs via groupcast.

[1017] Clause 77. A UE according to any of clauses 74 to 76, wherein the selective determination determines that the second broadcast mode is unicast, and wherein the SLPP message further includes an indication of the second broadcast mode, further comprising: receiving a response to the SLPP message from at least one UE in the group of one or more UEs via unicast.

[1018] Clause 78. A UE as set forth in any of clauses 69 to 77, wherein the first broadcast mode is broadcast.

[1019] Clause 79. The UE of clause 78, wherein the SLPP message includes a session identifier of the SLPP session.

[1020] Clause 80. A UE as set forth in any of clauses 78 to 79, wherein the selective determination determines that the second broadcast mode is broadcast, and wherein the SLPP message further includes an indication of the second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, further comprising: receiving a response to the SLPP message from at least one UE in the set of one or more UEs via broadcast.

[1021] Clause 81. A user equipment (UE), comprising: a memory; and at least one processor communicatively coupled to the memory, the at least one processor configured to: receive a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, wherein the SLPP message is received according to a first broadcast mode and includes an indication of the first broadcast mode or both the first broadcast mode and a second broadcast mode associated with any SLPP response message to the SLPP message; and determine whether to respond to the SLPP message according to the second broadcast mode based on whether the SLPP message is configured to trigger a response.

[1022] Clause 82. The UE of clause 81, wherein the first broadcast mode is unicast, multicast, or broadcast, and wherein the second broadcast mode is unicast, multicast, or broadcast.

[1023] Clause 83. A UE as set forth in any of clauses 81 to 82, wherein the first broadcast mode is unicast.

[1024] Clause 84. The UE of clause 83, wherein the SLPP message comprises a session identifier of the SLPP session, a first set of identifiers associated with the other UE, and a second set of identifiers associated with the UE.

[1025] Clause 85. A UE according to any of clauses 83 to 84, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is unicast, and wherein the determination is to respond to the SLPP message via unicast.

[1026] Clause 86. A UE as set forth in any of clauses 81 to 85, wherein the first broadcast mode is multicast.

[1027] Clause 87. The UE of clause 86, wherein the SLPP message comprises a session identifier of the SLPP session and a set of group identifiers associated with the SLPP session.

[1028] Clause 88. A UE according to any of clauses 86 to 87, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is multicast, and wherein the determination is to respond to the SLPP message via multicast.

[1029] Clause 89. A UE according to any of clauses 86 to 88, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is unicast, and wherein the determination is to respond to the SLPP message via unicast.

[1030] Clause 90. A UE as set forth in any of clauses 81 to 89, wherein the first broadcast mode is broadcast.

[1031] Clause 91. The UE of clause 90, wherein the SLPP message includes a session identifier of the SLPP session.

[1032] Clause 92. A UE according to any of clauses 90 to 91, wherein the SLPP message further comprises an indication of a second broadcast mode, or the second broadcast mode is implicitly indicated from the first broadcast mode, wherein the second broadcast mode is broadcast, and wherein the determination is to respond to the SLPP message via broadcast.

[1033] Clause 93. An initiator user equipment (UE), comprising: means for sending a first r...

Claims

1. A method for operating an initiator user equipment (UE), comprising: sending a first request to create a Sidelink Positioning Protocol (SLPP) session to each recipient UE in the set of one or more recipient UEs; receiving a first response from each recipient UE among the set of one or more recipient UEs, wherein each first response indicates acceptance or rejection of the SLPP session by the corresponding recipient UE; determining a group of one or more UEs participating in the SLPP session from among the recipient UEs from which respective first responses indicating acceptance of the SLPP session are received; sending a second request to start an SLPP session to the group of one or more UEs; and A second response is received from each UE in the group of one or more UEs, wherein each second response confirms the second request.

2. The method according to claim 1, in, The first request is sent via unicast, multicast, or broadcast, or wherein each first response is received via unicast, multicast, broadcast, or a combination thereof, or wherein the second request is sent via unicast, multicast or broadcast, or wherein each second response is received via unicast, multicast, broadcast, or a combination thereof, or Any combination of them.

3. The method according to claim 1, wherein The first request includes a session identifier associated with the SLPP session.

4. The method according to claim 1, wherein The first request includes a layer 2 (L2) group identifier associated with the SLPP session.

5. The method according to claim 1, in, The group of one or more UEs includes each recipient UE that accepts the SLPP session via a corresponding first response indication, or The group of one or more UEs omits one or more recipient UEs that reject the SLPP session via one or more corresponding first response indications.

6. The method according to claim 1, further comprising: A third request to modify the SLPP session is sent to the group of one or more UEs and any new recipient UE to be added to the group of one or more UEs, the third request indicating whether the corresponding recipient UE is to be included or excluded from the modified SLPP session associated with the modified group of one or more UEs.

7. The method according to claim 6, in, The modified group of one or more UEs includes each recipient UE that accepts the modified SLPP session via a respective third response indication, or The modified group of one or more UEs omits one or more recipient UEs that reject the modified SLPP session via one or more corresponding third response indications.

8. The method according to claim 1, wherein The second request includes layer 2 (L2) and application layer identifiers associated with the SLPP session, a UE identifier associated with the initiator UE, and a UE identifier associated with each UE in the group of one or more UEs.

9. The method according to claim 1, further comprising: Obtain a set of Sidelink Positioning Reference Signal (SL-PRS) measurements associated with an SLPP session; as well as A positioning estimate is determined for the initiating UE, one or more UEs in a group of one or more UEs, or a combination thereof based on the set of SL-PRS measurements.

10. The method according to claim 9, wherein: One or more positioning estimates for the one or more UEs are determined and sent to the one or more UEs.

11. A method of operating a receiving user equipment (UE), comprising: receiving a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiator UE; as well as A first response is sent to the initiating UE indicating acceptance or rejection of the SLPP session by the receiving UE.

12. The method according to claim 11, wherein The first response indicates acceptance of the SLPP session by the receiving UE.

13. The method according to claim 12, further comprising: receiving a second request to start an SLPP session from the initiator UE; as well as A second response is sent confirming the second request.

14. The method according to claim 13, in, The second request is received via unicast, multicast or broadcast, or wherein the second response is sent via unicast, multicast or broadcast, or Any combination of them.

15. The method according to claim 13, wherein The second request includes layer 2 (L2) and application layer identifiers associated with the SLPP session, a UE identifier associated with the initiator UE, and a UE identifier associated with each UE in the group of one or more UEs associated with the SLPP session.

16. The method according to claim 12, further comprising: A third request to modify the SLPP session is received from the initiating UE, the third request indicating whether the receiving UE is to be included or excluded from the modified SLPP session.

17. The method according to claim 16, A third response is sent to the initiating UE, where the third response indicates that the receiving UE accepts, rejects, or confirms the modified SLPP session.

18. The method according to claim 12, further comprising: Send Sidelink Positioning Reference Signal (SL-PRS) measurements associated with the SLPP session to the initiating UE.

19. The method according to claim 12, further comprising: A positioning estimate for the recipient UE is received from the originating UE.

20. The method according to claim 11, in, The first request is received via unicast, multicast, or broadcast, or Wherein the first response is sent via unicast, multicast or broadcast, or Any combination of them.

21. The method according to claim 11, wherein The first request includes a session identifier associated with the SLPP session.

22. The method according to claim 21, wherein The first request includes a set of group identifiers associated with the SLPP session.

23. A method of operating a user equipment (UE), comprising: determining a first broadcast mode associated with a Sidelink Positioning Protocol (SLPP) message associated with the SLPP session; determining a second broadcast mode associated with one or more SLPP response messages to the SLPP message; as well as Send SLPP message to a set of one or more UEs according to the first broadcast mode, The SLPP message includes indications of both the first broadcast mode and the second broadcast mode.

24. The method according to claim 23, in, The first broadcast mode is unicast, multicast, or broadcast, and The second broadcast mode is unicast, multicast or broadcast.

25. The method according to claim 23, in, The first broadcast mode is unicast, and The set of one or more UEs includes a single target UE.

26. The method according to claim 23, in, The first broadcast mode is multicast, and The set of one or more UEs includes a group of one or more UEs.

27. The method according to claim 23, wherein The first broadcast mode is broadcast.

28. A method of operating a user equipment (UE), comprising: receiving a sidelink positioning protocol (SLPP) message associated with a SLPP session, wherein the SLPP message is received according to a first broadcast mode and includes an indication of both the first broadcast mode and a second broadcast mode associated with one or more SLPP response messages to the SLPP message; and An SLPP response message in response to the SLPP message is sent according to the second broadcast mode.

29. The method according to claim 28, in, The first broadcast mode is unicast, multicast, or broadcast, and The second broadcast mode is unicast, multicast or broadcast.

30. The method according to claim 28, in, The first broadcast mode is broadcast, and The SLPP message includes a session identifier of the SLPP session, or The SLPP message includes an indication of a second broadcast mode, or implicitly indicates the second broadcast mode from the first broadcast mode, and the second broadcast mode is broadcast.

Images