SYSTEM AND METHOD FOR SIDELINK POSITIONING PROTOCOL

Abstract

Techniques for sidelink positioning are disclosed. In one aspect, an initiating user equipment (UE) sends a first request to each UE in a set of one or more receiving UEs to create a Sidelink Positioning Protocol (SLPP) session and receives a first response from the set of one or more receiving UEs indicating acceptance or rejection of the SLPP session. A group of one or more UEs for participation in the SLPP session is determined by the initiating UE from among the receiving UEs from which the first response indicating acceptance of the SLPP session is received. In another aspect, a UE transmitting an SLPP message may indicate a first casting mode (e.g., unicast, groupcast, broadcast, etc.) for the SLPP message and may optionally indicate a second casting mode (e.g., unicast, groupcast, broadcast, etc.) for the response to the SLPP message.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This patent application claims the benefit of U.S. Provisional Application No. 63 / 485,378, entitled "SIGNALING ASSOCIATED WITH SIDELINK POSITIONING PROTOCOL SESSION," filed February 16, 2023; U.S. Provisional Application No. 63 / 494,721, entitled "SIGNALING ASSOCIATED WITH SIDELINK POSITIONING PROTOCOL SESSION," filed April 6, 2023; and U.S. Provisional Application No. 63 / 501,664, entitled "SIGNALING ASSOCIATED WITH SIDELINK POSITIONING PROTOCOL SESSION," filed May 11, 2023, each of which is assigned to the assignee of the present application and expressly incorporated herein by reference in its entirety. [Background technology]

[0002] 1. Field of Disclosure 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.

[0003] 2. Description of Related Technology Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, positioning, and broadcasts. Typical wireless communication systems may utilize 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) systems, LTE-Advanced (LTE-A) systems, or LTE-A Pro systems, and fifth-generation (5G) systems, sometimes referred to as New Radio (NR) systems.

[0004] In some examples, a wireless multiple-access communication system may include several base stations, each simultaneously supporting communication for multiple communication devices, otherwise known as user equipment (UEs). A base station may communicate with one or more UEs over a downlink channel (e.g., for transmission from the base station to the UE) and an uplink channel (e.g., for transmission from the UE to the base station). In addition, the UEs may communicate directly with each other using a sidelink channel.

[0005] The location of a UE may be useful or necessary for several applications, including emergency calling, navigation, direction finding, asset tracking, and Internet services. For example, in a cellular network, a base station may send downlink reference signals using which positioning measurements are obtained by the UE and / or the UE may send uplink reference signals using which positioning measurements are obtained by the base station. The UE may calculate an estimate of its own location using the positioning measurements in UE-based positioning, or may send the positioning measurements to a network entity, e.g., a location server, which may calculate the location of the UE based on the positioning measurements in UE-assisted positioning.

[0006] There are several other applications where the location of one or more UEs may be required and where traditional UE-based and UE-assisted positioning may be less useful. Examples of such applications include vehicle-to-everything (V2X) communications 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 effective for UEs to communicate using sidelink signaling and for UEs to be located using sidelink-related positioning measurements and / or sidelink-related control signaling. Furthermore, procedures may be established to allow 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

[0007] The following presents a simplified summary of one or more aspects disclosed herein. As such, the following summary is not intended to be an extensive overview of all contemplated aspects, nor is it intended to identify key or critical elements of all contemplated aspects or to delineate the scope associated with any particular aspect. Thus, the sole purpose of the following summary is to present certain concepts of one or more aspects of the mechanisms disclosed herein in a simplified form as a prelude to the Detailed Description presented below.

[0008] In one aspect, a method of operating an initiating 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, each first response indicating acceptance or rejection of the SLPP session by the respective receiving UE; determining one or more groups of UEs for participation in the SLPP session from among the receiving UEs from which the respective first responses indicating acceptance of the SLPP session are received; sending a second request to initiate the SLPP session to the one or more groups of UEs; and receiving second responses from each UE in the group of one or more UEs, each second response acknowledging the second request.

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

[0010] 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 associated with a SLPP session, determining a second casting mode associated with one or more SLPP response messages to the SLPP message, and transmitting 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.

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

[0012] In one aspect, an initiator user equipment (UE) comprises 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, wherein the one or more processors, either alone or in combination, transmit, via the one or more transceivers, a first request to create a Sidelink Positioning Protocol (SLPP) session to each receiving UE in a set of one or more receiving UEs, and receive, via the one or more transceivers, a first response from each receiving UE in the set of one or more receiving UEs. is configured to receive first responses, each first response indicating acceptance or rejection of the SLPP session by a respective receiving UE, determine a group of one or more UEs for participation in the SLPP session from among the receiving UEs from which each first response indicating acceptance of the SLPP session was received, send a second request to initiate the SLPP session to the group of one or more UEs via one or more transceivers, and receive second responses from each UE in the group of one or more UEs via the one or more transceivers, wherein each second response acknowledges the second request.

[0013] In one aspect, a user equipment (UE) comprises 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, wherein the one or more processors, either alone or in combination, are configured to receive, via the one or more transceivers, a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiating UE, and to transmit, via the one or more transceivers, a first response to the initiating UE indicating acceptance or rejection of the SLPP session by the receiving UE.

[0014] In one aspect, a user equipment (UE) comprises 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, wherein the one or more processors, either alone or in combination, are configured to determine a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, determine a second casting mode associated with one or more SLPP response messages to the SLPP message, and transmit, via the one or more transceivers, 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.

[0015] In one aspect, a user equipment (UE) comprises 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, wherein the one or more processors, either alone or in combination, are configured to: receive, via the one or more transceivers, a Sidelink Positioning Protocol (SLPP) message associated with a Sidelink Positioning Protocol (SLPP) session, wherein the SLPP message is received according to a first casting mode, receive one or more SLPP response messages to the SLPP message including an indication of both the first casting mode and a second casting mode associated with the SLPP message; and transmit, via the one or more transceivers, the SLPP response message in response to the SLPP message according to the second casting mode.

[0016] In one aspect, an initiating user equipment (UE) comprises means for sending a first request to create a Sidelink Positioning Protocol (SLPP) session to each receiving UE in a set of one or more receiving UEs; means for receiving a first response from each receiving UE in the set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the respective receiving UE; means for determining one or more groups of UEs for participation in the SLPP session from among the receiving UEs from which respective first responses indicating acceptance of the SLPP session are received; means for sending a second request to initiate the SLPP session to the one or more groups of UEs; and means for receiving second responses from each UE in the group of one or more UEs, each second response acknowledging the second request.

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

[0018] In one aspect, a user equipment (UE) comprises means for determining a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, means for determining a second casting mode associated with one or more SLPP response messages to the SLPP message, and means for transmitting 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.

[0019] In one aspect, a user equipment (UE) comprises means for receiving a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, the SLPP message being received according to a first casting mode and including an indication of both the first casting mode and a second casting mode associated with one or more SLPP response messages to the SLPP message; and means for transmitting the SLPP response message in response to the SLPP message according to the second casting mode.

[0020] In one aspect, a non-transitory computer-readable medium storing computer-executable instructions that, when executed by an initiating user equipment (UE), cause the initiating UE 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, receive a first response from each receiving UE in the set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the respective receiving UE, determine one or more groups of UEs for participation in the SLPP session from among the receiving UEs from which respective first responses indicating acceptance of the SLPP session were received, send a second request to initiate the SLPP session to the one or more groups of UEs, and receive a second response from each UE in the group of one or more UEs, each second response acknowledging the second request.

[0021] 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 to create a Sidelink Positioning Protocol (SLPP) session from an initiating UE and send a first response to the initiating UE indicating acceptance or rejection of the SLPP session by the receiving UE.

[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 determine a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, determine a second casting mode associated with one or more SLPP response messages to the SLPP message, and transmit 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.

[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 receive a Sidelink Positioning Protocol (SLPP) message associated with a Sidelink Positioning Protocol (SLPP) session, the SLPP message being received according to a first casting mode, the SLPP message including an indication of both the first casting mode and a second casting mode associated with one or more SLPP response messages to the SLPP message, and transmit the SLPP response message in response to the SLPP message according to the second casting mode.

[0024] Other objects and advantages associated with the aspects disclosed herein will become apparent to those skilled in the art based on the accompanying drawings and detailed description.

[0025] The accompanying drawings are presented to aid in the explanation of various aspects of the present disclosure and are provided for purposes of illustration only and not limitation of those aspects. [Brief explanation of the drawings]

[0026] [Figure 1]The architecture of a communication system including several UEs, a Radio Access Network (RAN), and a 5G Core Network (5GC) is shown. [Figure 2] 1 shows a communication system architecture for network-supported sidelink positioning. [Figure 3A] 1 illustrates various scenarios of interest for sidelink-only or joint Uu and sidelink positioning, according to aspects of the present disclosure. [Figure 3B] 1 illustrates various scenarios of interest for sidelink-only or joint Uu and sidelink positioning, according to aspects of the present disclosure. [Figure 4] 1 shows a reference architecture for sidelink positioning and ranging based services for non-roaming and same PLMN operation. [Figure 5] 1 illustrates an overall UE positioning architecture applicable to NG-RAN, according to an aspect of the present disclosure. [Figure 6] 1 illustrates the SLPP protocol layering on the PC5 reference point. [Figure 7] SLPP non-IP type encoding method is shown. [Figure 8A] 1 illustrates an example scenario for sidelink positioning / ranging, in accordance with aspects of the present disclosure. [Figure 8B] 1 illustrates an example scenario for sidelink positioning / ranging, in accordance with aspects of the present disclosure. [Figure 8C] 1 illustrates an example scenario for sidelink positioning / ranging, in accordance with aspects of the present disclosure. [Figure 9] 1 illustrates an SLPP session establishment procedure according to an aspect of the present disclosure. [Figure 10] 1 illustrates an SLPP session modification procedure according to an aspect of the present disclosure. [Figure 11] 1 illustrates sidelink positioning session-less operation according to an aspect of the present disclosure. [Figure 12] 1 illustrates SLPP session-less operation according to an aspect of the present disclosure. [Figure 13] 1 illustrates sidelink-only positioning with UE-assisted initiated (centralized) position calculation for multiple target UEs, according to an aspect of the present disclosure. [Figure 14] 1 illustrates sidelink-only positioning with UE-based (distributed) position calculation with multiple target UEs, according to an aspect of the present disclosure. [Figure 15] 1 illustrates an LMF-assisted sidelink positioning (MO-LR) procedure according to an aspect of the present disclosure. [Figure 16] 1 illustrates LMF-initiated sidelink positioning for MT-LR procedure, according to an aspect of the present disclosure. [Figure 17] 1 illustrates joint Uu-sidelink positioning according to an aspect of the present disclosure. [Figure 18] 1 illustrates an SLPP unicast transaction according to an aspect of the present disclosure. [Figure 19] 1 illustrates an SLPP group transaction with a group response according to an aspect of the present disclosure. [Figure 20] 1 illustrates an SLPP group transaction with unicast response according to an aspect of the present disclosure. [Figure 21] 1 illustrates an SLPP broadcast transaction according to an aspect of the present disclosure. [Figure 22] 1 illustrates an SLPP capability transfer procedure according to an aspect of the present disclosure. [Figure 23] 1 illustrates an SLPP capability indication procedure according to an aspect of the present disclosure. [Figure 24] 1 illustrates an SLPP-assisted data transfer procedure according to an aspect of the present disclosure. [Figure 25] 1 illustrates a SLPP assistance data distribution procedure according to an aspect of the present disclosure. [Figure 26] 1 illustrates a SLPP location information transfer procedure according to an aspect of the present disclosure. [Figure 27] 1 illustrates a SLPP location information distribution procedure according to an aspect of the present disclosure. [Figure 28] 1 illustrates a SLPP session creation request / accept / reject procedure according to an aspect of the present disclosure. [Figure 29]1 illustrates an SLPP session initiation request / response procedure according to an aspect of the present disclosure. [Figure 30] 1 illustrates an SLPP session initiation request / response procedure according to an aspect of the present disclosure. [Figure 31] 1 illustrates an SLPP session initiation request / response procedure according to an aspect of the present disclosure. [Figure 32] 1 illustrates a UE-assisted (centralized) sidelink-only positioning procedure for a single target UE, according to an aspect of the present disclosure. [Figure 33] 1 illustrates a UE-assisted (centralized) sidelink-only positioning-multiple target UE procedure in accordance with an aspect of the present disclosure. [Figure 34] 1 illustrates a UE-assisted (centralized) sidelink-only ranging procedure for a single target UE, according to an aspect of the present disclosure. [Figure 35] 1 illustrates a UE-assisted (centralized) sidelink-only ranging procedure for multiple target UEs, according to an aspect of the present disclosure. [Figure 36] 1 illustrates a UE-based (distributed) sidelink-only positioning-single target UE procedure according to an aspect of the present disclosure. [Figure 37] 1 illustrates a UE-based (distributed) sidelink-only positioning-multiple target UE procedure according to an aspect of the present disclosure. [Figure 38] 1 illustrates a UE-based (distributed) sidelink-only ranging procedure for a single target UE, according to an aspect of the present disclosure. [Figure 39] 1 illustrates a UE-based (distributed) sidelink-only ranging procedure for multiple target UEs, according to an aspect of the present disclosure. [Figure 40A] FIG. 1 is a simplified block diagram of several sample aspects of components that may be employed in a user equipment (UE), a base station, or a network entity and configured to support communication as taught herein; [Figure 40B] FIG. 1 is a simplified block diagram of several sample aspects of components that may be employed in a user equipment (UE), a base station, or a network entity and configured to support communication as taught herein; [Figure 40C] FIG. 1 is a simplified block diagram of several sample aspects of components that may be employed in a user equipment (UE), a base station, or a network entity and configured to support communication as taught herein; [Figure 41] 1 illustrates an exemplary process of communication according to one aspect of the present disclosure. [Figure 42] 1 illustrates an exemplary process of communication according to one aspect of the present disclosure. [Figure 43] 1 illustrates an exemplary process of communication according to one aspect of the present disclosure. [Figure 44] 1 illustrates an exemplary process of communication according to one aspect of the present disclosure.

[0027] According to some example implementations, like reference numerals in various drawings refer to like elements. Additionally, multiple instances of an element may be indicated by the first numeral of that element followed by a letter or hyphen and a second numeral. For example, multiple instances of element 110 may be indicated as 110-1, 110-2, 110-3, etc., or as 110a, 110b, 110c, etc. When referring to such an element using only the first numeral, it should be understood to refer to any instance of that element (e.g., element 110 in the previous example refers to elements 110-1, 110-2, and 110-3, or elements 110a, 110b, and 110c). DETAILED DESCRIPTION OF THE INVENTION

[0028] 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 devised without departing from the scope of the present disclosure. Furthermore, well-known elements of the present disclosure will not be described in detail or will be omitted so as not to obscure the relevant details of the present disclosure.

[0029] Techniques and apparatus for supporting sidelink positioning (SL) between UEs are described herein. The Sidelink Positioning Protocol (SLPP) can be used to support sidelink positioning of UEs in pairwise positioning (referred to as pairwise mode), group operation (referred to as group mode), and network-supported SLPP.

[0030] The words "exemplary" and / or "example" are used herein to 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 present disclosure" does not require that all aspects of the present disclosure include the discussed feature, advantage or mode of operation.

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

[0032] Further, many aspects are described in terms of sequences of actions to be performed by, for example, elements of a computing device. It will be appreciated that various actions described herein can be performed by specific circuitry (e.g., application specific integrated circuits (ASICs)), by program instructions executed by one or more processors, or by a combination of both. In addition, the sequence(s) of actions described herein may be considered to be embodied entirely in any form of non-transitory computer-readable storage medium storing a corresponding set of computer instructions, which, when executed, cause or instruct the associated processor(s) of a device to perform the functionality described herein. Accordingly, various aspects of the present disclosure may be embodied in several different forms, all of which are contemplated to be within the scope of the claimed subject matter. Additionally, 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.

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

[0034] A base station may operate according to one of several RATs with which it communicates with UEs depending on the network in which it is deployed and may alternatively be referred to as an access point (AP), network node, Node B, evolved Node B (eNB), next generation eNB (ng-eNB), New Radio (NR) Node B (also referred to as gNB or gNode B), etc. Base stations may be used primarily to support wireless access by UEs, including supporting data, voice, and / or signaling connections for supported UEs. In some systems, base stations may simply provide edge node signaling functionality, while in other systems, base stations may provide additional control and / or network management functionality. The communication link over which a UE can send signals to a base station is called an uplink (UL) channel (e.g., reverse traffic channel, reverse control channel, access channel, etc.). A communication link through which a base station can send signals to a UE is called a downlink (DL) channel or a forward link channel (e.g., a paging channel, a control channel, a broadcast channel, a forward traffic channel, etc.). As used herein, the term traffic channel (TCH) can refer to either an uplink / reverse traffic channel or a downlink / forward traffic channel.

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

[0036] In some implementations that support UE positioning, a base station may not support wireless access by the UE (e.g., it may not support data, voice, and / or signaling connections for the UE), but instead may transmit reference signals to the UE to be measured by the UE and / or may receive and measure signals transmitted by the UE. Such a base station may be referred to as a positioning beacon (e.g., if it transmits signals to the UE) and / or a position measurement unit (e.g., if it receives and measures signals from the UE).

[0037] An "RF signal" includes electromagnetic waves of a given frequency that transport information through 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, the receiver may receive multiple "RF signals" corresponding to each transmitted RF signal. The same RF signal transmitted over 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" when it is clear from the context that the term "signal" refers to a wireless signal or an RF signal.

[0038] FIG. 1 illustrates an example of a communication system 100 including 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. The 5GC 140 may be, for example, a public land mobile network (PLMN). The UEs 105A, 105B, and 105C may be individually referred to herein as UEs 105 or collectively referred to as UEs 105. The UEs 105 may be, for example, IoT devices, location tracking devices, mobile phones, vehicles, on-board units (OBUs), or other similar types of devices. The UEs 105 may additionally be considered RSUs or PRUs. The 5G network may also be referred to as a New Radio (NR) network, the NG-RAN 135 may also be referred to as a 5G RAN or an NR RAN, and the 5GC 140 may also be referred to as an NG Core network (NGC). The RAN 135 may be another type of RAN, such as a 3G RAN, a 4G Long Term Evolution (LTE) RAN, etc.The communication system 100 may utilize a fleet of satellite vehicles (SVs) 190 that may support a satellite positioning system (SPS) (e.g., Global Navigation Satellite System (GNSS)), such as the Global Positioning System (GPS), Global Navigation Satellite System (GLONASS), Galileo, or Beidou, or some other local or regional SPS, such as the Indian Regional Navigational 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 a RAN node (e.g., gNB 110) or a 5GC 140 node via the SV 190 and an earth station (not shown in FIG. 1 ), in which case the UE 105 may not communicate directly with the RAN node but only via the SV 190. This may be used to increase the coverage and / or capacity of the NG-RAN 135. Additional components of the communications system 100 are described below. The communications system 100 may include additional or alternative components.

[0039] 1, the NG-RAN 135 includes NR NodeBs (gNBs) 110a, 110b, and a next generation eNodeB (ng-eNB) 114, and the 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. The gNBs 110a, 110b, and the ng-eNB 114 are communicatively coupled to each other and configured to each communicate wirelessly bidirectionally with the UE 105, and are communicatively coupled to and configured to each communicate bidirectionally with the AMF 115 and the UPF 118. The gNBs 110a, 110b, and ng-eNB 114 may be referred to as base stations (BSs) or RAN nodes. The AMF 115, SMF 117, LMF 120, and GMLC 125 are communicatively coupled to each other, and the GMLC 125 is communicatively coupled to the external client 130. The AMF 115, SMF 117, UPF 118, and SLP 119 are communicatively coupled to each other, and the SLP 119 is communicatively coupled to the external client 130. According to some embodiments, the server 121, the Internet 122, and the server 123 may be communicatively coupled to the UPF 118 and may facilitate SL positioning. The SMF 117 may further serve as an initial point of contact for a Service Control Function (SCF) (not shown), which creates, controls, and deletes media sessions.The base stations 110a, 110b, 114 may be macrocells (e.g., high-power cellular base stations), or small cells (e.g., low-power cellular base stations), or access points (e.g., short-range base stations configured to communicate with short-range technologies such as Wi-Fi, Wi-Fi Direct (WiFi-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 over multiple carriers. Each of the base stations 110a, 110b, 114 may provide communication coverage for a respective geographic area, e.g., a cell. Each cell may be partitioned into multiple sectors depending on the base station antenna.

[0040] 1 provides a generalized illustration of various components, any or all of which may be utilized as appropriate, and each of which may be duplicated or omitted as desired. In particular, while only the UE 105 is illustrated, many UEs (e.g., hundreds, thousands, millions, etc.) may be utilized in the communications system 100. Similarly, the communications system 100 may include many more (or fewer) SVs (i.e., more or fewer than the four SVs 190 shown), gNBs 110a, 110b, ng-eNB 114, AMF 115, external clients 130, and / or other components. The connections shown connecting the various components in the communications 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, substituted, and / or omitted depending on the desired functionality.

[0041] 1 illustrates a 5G-based network. Similar network implementations and configurations may be used for other communication technologies, such as 3G, Long Term Evolution (LTE), future 6G, etc. Implementations described herein (whether for 5G technology and / or 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., the UE 105) or base station 110a, 110b, 114, and / or provide location assistance to the UE 105 (via the LMF 120 or SLP 119 or other location server), and / or calculate the location of one or both of the UEs 105 at a location-enabled device, such as the UE 105, base station 110a, 110b, LMF 120, or SLP 119, based on measurements received at the UE 105 or base station 110a, 110b, 114 of such directionally transmitted signals. The GMLC 125, LMF 120, AMF 115, SMF 117, UPF 118, SLP 119, ng-eNB (eNodeB) 114, and gNBs (gNodeBs) 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.

[0042] The communications system 100 is capable of wireless communications in that components of the system 100 may communicate with one another (at least sometimes using wireless connections) directly or indirectly, e.g., via the base stations 110a, 110b, 114 and / or the network 140 (and / or one or more other devices, not shown, such as one or more other base transceiver stations). In the case of indirect communications, communications may be altered during transmission from one entity to another, e.g., to alter header information of data packets, to change formatting, etc. The UE 105 may include multiple UEs and may be a mobile wireless communications device, but may communicate wirelessly and via wired connections. The UE 105 may be any of a variety of devices, e.g., a smartphone, a tablet computer, a vehicle-based device, etc., although these are merely examples and other configurations of UEs may be used, as the UE 105 is not required to be any of these configurations. Other UEs may include wearable devices (e.g., a smart watch, smart jewelry, smart glasses, or a headset, etc.). Still other UEs, whether currently existing or developed in the future, may be used. Additionally, other wireless devices (whether mobile or not) may be implemented within system 100 and may communicate with each other and / or with UE 105, base stations 110a, 110b, 114, core network 140, and / or external client 130. For example, such other devices may include IoT or IIoT devices, medical devices, home entertainment and / or automation devices, etc. Core network 140 may communicate with external client 130, server 123, or server 121 (e.g., each of which may be a computer system) to, for example, enable external client 130, server 123, or server 121 to request and / or receive location information regarding UE 105 (e.g., via GMLC 125, SLP 119, or UPF 118).

[0043] The UE 105 or other device may be configured to communicate in different networks and / or for different purposes and / or using different technologies (e.g., 5G, Wi-Fi (also called WiFi) communications, multiple frequencies of Wi-Fi communications, satellite positioning, satellite communications, one or more types of communications (e.g., GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access), LTE (Long Term Evolution), V2X (e.g., V2P (Vehicle-to-Pedestrian), V2I (Vehicle-to-Infrastructure), V2V (Vehicle-to-Vehicle), etc.), IEEE 802.11p, etc.). V2X communications may be cellular (Cellular-V2X, C-V2X) and / or Wi-Fi (e.g., DSRC (Dedicated Short-Range Remote Control)). The system 100 may be a dedicated short-range connection. The system 100 may support operation on multiple carriers (waveform signals at different frequencies). A multi-carrier transmitter can simultaneously transmit modulated signals on multiple carriers. Each modulated signal may 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 may be transmitted on a different carrier and may carry pilot, overhead information, data, etc.The UEs 105 may communicate with each other via UE-to-UE sidelink (SL) communication by transmitting 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).

[0044] The UE 105 may include and / or be referred to as a device, a mobile device, a wireless device, a mobile terminal, a terminal, a mobile station (MS), a Secure User Plane Location (SUPL) Enabled Terminal (SET), or some other name. Generally, although not necessarily, the UE 105 may support wireless communication 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 referred to as Wi-Fi), 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, for example, a Wireless Local Area Network (WLAN), which may connect to other networks (e.g., the Internet) using a Digital Subscriber Line (DSL) or packet cable. Use of one or more of these RATs may enable the UE 105 to communicate with external clients 130, servers 121, and / or servers 123 (e.g., via elements of the 5GC 140 and possibly the Internet 122) and / or enable external clients 130, servers 121, and / or servers 123 to receive location-related information about the UE 105 (e.g., via the GMLC 125, the SLP 119, or the UPF 118).

[0045] 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 and a separate wireline or wireless modem. An estimate of the location of a UE, e.g., UE 105, may be referred to as a location, location estimate, location fix, fix, position, position estimate, or position fix, and may be geodetic and thus provide location coordinates (e.g., latitude and longitude) of the UE that may or may not include an altitude component (e.g., height above sea level, height or depth above ground, floor level, or basement level). Alternatively, the location of the UE may be expressed as a civic location (e.g., as a postal address or as a designation of some point or small area in a building, such as a particular room or floor). The location of the UE may be expressed as an area or volume (defined either geodetically or urbanically) within which the UE is expected to be located with some probability or confidence level (e.g., 67%, 95%, etc.). The location of a UE may be expressed as a relative location comprising, for example, a distance and a direction from a known location. The relative location may be expressed as relative coordinates (e.g., X, Y (and Z) coordinates) defined relative to some origin in the known location, which may be defined, for example, geodesically, in terms of cities, or by reference to a point, area, or volume shown on a map, floor plan, or building plan. In the description contained herein, use of the term location may include any of these variations unless otherwise indicated.

[0046] When sidelink positioning is used, an absolute (e.g., global) or relative location of the UE may not always be obtained. Instead, location results may be obtained for the UE, 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 location of the UE relative to the locations of some other UEs, the locations of one or more other UEs relative to the UE's location, the velocity of the UE, and / or the velocity of each of the one or more other UEs. The velocity of a UE may be absolute (e.g., with respect to the Earth) or relative to some other UE, and may then be referred to as a "relative velocity." The relative velocity of UE B with respect to another UE A may include a "radial velocity" component, which may be equal to the rate of change of range from UE A to UE B, and a "lateral velocity" component, which may be orthogonal to the radial velocity component from the perspective of 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, the use of the term "location result(s)" for sidelink positioning of a UE or a group of one or more UEs may include any of these variations, unless otherwise indicated.

[0047] As used herein, the term "target UE" may refer to a UE for which a location 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, since location results may already be known or may not be needed for other UEs. However, for generality, when describing the techniques described herein for positioning of one or more groups of UEs, all of the UEs may be considered to be potentially target UEs, since there may be little or no difference in how the techniques described herein are used for positioning.

[0048] The UE 105 may be configured to communicate with other entities using one or more of a variety of technologies. The 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. A D2D P2P link may be an example of (or may be supported by) a sidelink and may be supported using any suitable D2D radio access technology (RAT), such as LTE Direct (LTE-D), Wi-Fi Direct (Wi-Fi D), Bluetooth, etc. One or more of the groups of one or more UEs utilizing D2D communication may be within the geographic coverage area of ​​a Transmission / Reception Point (TRP), such as one or more of the gNBs 110a, 110b, and / or ng-eNB 114. Other UEs in such a group may be outside such geographic coverage area or may otherwise 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 may transmit to other UEs in the group. The TRP may facilitate scheduling of resources for D2D communication. In other cases, D2D communication may be performed between UEs without the involvement of a TRP. One or more of the groups of one or more UEs utilizing D2D communication may be within the geographic coverage area of ​​the TRP. Other UEs in such a group may be outside such geographic coverage area or may otherwise 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 may transmit to other UEs in the group. The TRP may facilitate scheduling of resources for D2D communication. In other cases, D2D communication may be performed between UEs without the involvement of a TRP.

[0049] The base stations (BSs) in the NG-RAN 135 shown in FIG. 1 include NR Node Bs referred to as gNBs 110a and 110b. The pair of gNBs 110a, 110b in the NG-RAN 135 may be connected to each other through one or more other gNBs. Access to the 5G network is provided to the UE 105 via wireless communication between the UE and one or more of the gNBs 110a, 110b, and the gNBs 110a, 110b may provide wireless communication access to the 5G Grid Control System 140 for UEs using 5G. In FIG. 1, the serving gNB for UE 105A is assumed to be gNB 110b, while the serving gNB for UE 105B is assumed to be gNB 110a; however, another gNB may serve as the serving gNB if the UE 105 moves to another location, or may serve as a secondary gNB to provide additional throughput and bandwidth to the UE 105, and the UEs 105 may share the same serving gNB.

[0050] 1 may include the ng-eNB 114, also referred to as a next generation evolved Node B. The ng-eNB 114 may be connected to one or more of the 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 wireless access and / or evolved LTE (eLTE) wireless access to the UE 105. One or more of the gNBs 110a, 110b and / or ng-eNB 114 may be configured to function as positioning-only beacons that may transmit signals to assist in determining the location of the UE 105 but may not receive signals from the UE 105 or from other UEs.

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

[0052] The base station 110a, 110b, 114 may configure PRS transmissions on one or more PRS resources of a channel. A PRS resource may span resource elements of multiple physical resource blocks (PRBs) within one or more OFDM symbols of a slot, depending on the configured number of ports. 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, PRS transmissions may be mapped to consecutive OFDM symbols of a slot. In other examples, PRS transmissions may be mapped to interspersed OFDM symbols of a slot. Additionally, PRS transmissions may support frequency hopping within a PRB of a channel.

[0053] One or more PRS resources may span several PRS resource sets according to the PRS resource configuration of the base station 110 a, 110 b, 114. 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 station 110 a, 110 b, 114 may include multiple PRS resource sets, and each PRS resource set may include a set of PRS resources (such as a set of four PRS resources).

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

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

[0056] A UE's position estimate may be determined using reference signals, such as PRS or SRS for positioning signals or other reference signals from one or more base stations 110a, 110b, 114 or the UE. 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 may be used to estimate a UE's position using reference signals from base stations. For example, DL-TDOA relies on measuring the reference signal time difference (RSTD) between a downlink (DL) signal received from a base station for a reference cell and a DL signal received from a base station(s) for one or more neighboring cells. DL signals from which RTSD may be obtained include cell-specific reference signals (CRS) and positioning reference signals (PRS).

[0057] Other positioning methods may 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, for example, 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. In addition, sidelink-based positioning may be used, in which the UE transmits and / or receives sidelink positioning reference signals that are measured and used for positioning.

[0058] As noted, while FIG. 1 illustrates nodes configured to communicate according to 5G communication protocols, nodes configured to communicate according to other communication protocols, such as, for example, the LTE protocol or the IEEE 802.11x protocol, or future 6G protocols, may also be used. For example, in an Evolved Packet System (EPS) providing LTE wireless access to the 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 comprise an Evolved Packet Core (EPC). The EPS may include the E-UTRAN plus the EPC, where in FIG. 1, the E-UTRAN corresponds to the NG-RAN 135 and the EPC corresponds to the 5GC 140.

[0059] The gNBs 110a, 110b, and ng-eNB 114 may communicate with the AMF 115, which in turn communicates with the LMF 120 for positioning functions. The AMF 115 may support mobility of the UE 105, including cell changes and handovers, and may be responsible for supporting signaling connections to the UE 105 and possibly data and voice bearers for the UE 105. The LMF 120 may communicate directly or indirectly with the UE 105 or with the base stations 110a, 110b, 114, for example, via wireless communication. The LMF 120 may support positioning of the UE 105 when the UE 105 accesses the NG-RAN 135 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 Kinematic (RTK), Precise Point Positioning (PPP), Differential GNSS (DGNSS), Extended 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 running LMF 120 may additionally or alternatively run 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 a portion of the positioning functionality (including derivation of the UE's location) may be performed in the UE (e.g., using signal measurements obtained by the UE for signals transmitted by wireless nodes such as the gNBs 110a, 110b and / or the ng-eNB 114 and / or assistance data provided to the UE by the LMF 120, for example). At least a portion of the positioning functionality (including derivation of the UE's location) may alternatively be performed in the LMF 120 (e.g., using signal measurements obtained by the gNBs 110a, 110b and / or the ng-eNB 114). The AMF 115 may act as a control node that handles signaling between the UE 105 and the core network 140 and provides quality of service (QoS) flow and session management. The AMF 115 may support the mobility of the UE 105, including cell changes and handovers, and may be responsible for supporting signaling connections to the UE 105.

[0060] 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 request directly to the LMF 120. A location response (e.g., including a location estimate or sidelink location result for the UE 105) from the LMF 120 may be returned to the GMLC 125 either directly or via the AMF 115, which may then return a location response (e.g., including the location estimate or sidelink location result) to the external client 130. Although the GMLC 125 is shown connected to both the AMF 115 and the LMF 120, in some implementations, only one of these connections may be supported by the 5GC 140.

[0061] The user plane function (UPF) 118 may support voice and data bearers for the UE 105 and enable voice and data access for the UE 105 to other networks, such as the Internet 122, and servers, such as server 121 and server 123. The UPF 118 may be connected to the gNB 110 and the ng-eNB 114. The functions of the UPF 118 may include external Protocol Data Unit (PDU) session points for interconnection to data networks, packet (e.g., Internet Protocol (IP)) routing and forwarding, the user plane portion of packet inspection and policy rule enforcement, Quality of Service (QoS) handling for the user plane, downlink packet buffering, and triggering of downlink data notifications. The UPF 118 may be connected to the SLP 119 to enable support for positioning of the UE 105 using SUPL. The SLP 119 may further be connected to or accessible by the external client 130.

[0062] As shown, a session management function (SMF) 117 connects the AMF 115 and the UPF 118. The SMF 117 may have the ability to control both the local UPF and the central UPF 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 for the UE 105.

[0063] 1, the LMF 120 may communicate with the gNBs 110a, 110b, and / or the ng-eNB 114 using the New Radio Position Protocol A (NRPPa), which may be defined in 3GPP Technical Specification (TS) 38.455. NRPPa messages may be transferred between the gNB 110a (or gNB 110b) and the LMF 120 and / or between the ng-eNB 114 and the LMF 120 via the AMF 115. As further shown in FIG. 1, 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 transferred 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, LPP messages may be transferred between the LMF 120 and the AMF 115 using service operations based on the Hypertext Transfer Protocol (HTTP), and may be transferred between the AMF 115 and the UE 105 using a 5G Non-Access Stratum (NAS) protocol.

[0064] 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 in conjunction with measurements obtained by the gNBs 110a, 110b, or ng-eNB 114), and / or may be used by the LMF 120 to obtain location-related information from the gNBs 110a, 110b, and / or ng-eNB 114, such as parameters defining directional synchronization signal (SS) transmissions from the gNBs 110a, 110b, and / or ng-eNB 114. While the LMF 120 is shown in FIG. 1 as being located in the core network 140, it may also be outside of the core network 140, e.g., in the NG-RAN. For example, the LMF120 may be co-located or integrated with the gNB, or may be located remotely from the gNB, and may be configured to communicate directly or indirectly with the gNB.

[0065] In a UE-assisted positioning method, a UE, e.g., UE 105A or UE 105B, may obtain location measurements and send the measurements to a location server (e.g., LMF 120) for calculation of a location estimate for the UE. For example, the location measurements may include one or more of a Received Signal Strength Indication (RSSI), a Round Trip Signal Propagation Time (RTT), a Reference Signal Time Difference (RSTD), a Reference Signal Received Power (RSRP) and / or a Reference Signal Received Quality (RSRQ), an AOA, and an AOD for the gNB 110a, 110b, the ng-eNB 114, and / or a WLAN AP. The location measurements may also or instead include measurements of GNSS pseudorange, code phase, and / or carrier phase for SV 190-193.

[0066] In a UE-based positioning method, a UE, for example, UE 105A or UE 105B, may obtain location measurements (which may, for example, be the same as or similar to location measurements for a UE-assisted positioning method) and may calculate the location of the UE (e.g., with the help 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).

[0067] In a network-based positioning method, 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) measurements for 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 calculation of a location estimate for the UE.

[0068] As mentioned, although the communications system 100 is described with respect to 5G technology, the communications system 100 may be implemented to support other communications technologies, such as GSM, WCDMA, LTE, etc., used to support and interact with mobile devices such as the UEs 105 (e.g., to perform voice, data, positioning, and other functions). For example, in an EPS, the NG-RAN 135 may be replaced with an E-UTRAN including an eNB, and the 5GC 140 may be replaced with an EPC including a Mobility Management Entity (MME) in place of the AMF 115, an E-SMLC in place of the LMF 120, and a GMLC, which may be similar to the GMLC 125.

[0069] Positioning for a UE in a wireless network, such as the communication system 100 shown in FIG. 1, typically uses the Uu interface, i.e., the air interface between the UE 105 and the radio access network, for DL ​​PRS and / or UL PRS. Positioning for a UE may also or instead use sidelink PRS (SL-PRS), which may be a specific sidelink-defined reference signal for positioning, or may reuse Uu PRS, e.g., UL PRS, sometimes referred to as Sounding Reference Signals for positioning (SRSPos), or other reference signals may be transmitted in the sidelink channel. Sidelink positioning may extend the positioning of a UE by providing additional transmitting (or receiving) nodes. A UE, such as UE 105B, with a known location may be used to support the position determination of another target UE, such as UE 105A, and UE 105B may be referred to as an anchor node.

[0070] Using the sidelink positioning method, the UE 105A may transmit, for example, a sidelink PRS or a sidelink (SL) SRS signal to be received and measured by another UE 105B. Additionally or alternatively, the UE 105B may transmit, for example, a sidelink PRS or a sidelink SRS signal to be received and measured by the UE 105A. The sidelink PRS may be similar to the PRS (e.g., DL PRS) transmitted by the gNB 110, for example, as described above. The sidelink SRS may be similar to the SRS (e.g., uplink) SRS transmitted by the UE 105 for measurement by the gNB 110, for example, as described above. The SL PRS may be transmitted over a separate, short period (e.g., approximately 1 millisecond in duration) called an "SL PRS occasion" or "SL PRS positioning occasion." Measurements of SL PRS or SL SRS signals may include reception to transmission 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 may include SL round trip signal propagation time (RTT) (also called ranging), SL AOA, and SL AOD.

[0071] 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 an SL PRS or SL SRS signal that can be measured by some or all of the other UEs 105 in the group (e.g., UEs 105B and 105C). Some or all of the other UEs 105 in the group may also transmit SL PRS or SL SRS signals, respectively, that can be measured by some or all of the other UEs 105 in the group that are different from the UE 105 transmitting the UL PRS or ULS SRS (e.g., each UE 105 transmits the SL SRS or SL PRS 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). Measurements made by the UE 105 that are 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. 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 the positioning method, each UE 105 may determine a location result for itself and / or one or more other UEs 105 in the group. As mentioned above, the location result for a UE 105 may include the range or distance between the UE 105 and each of the one or more other UEs 105 in the group, the direction from the UE 105 to each of the one or more other UEs 105 in the group, the direction from each of the one or more other UEs 105 in the group to the UE 105, the location of the UE 105 relative to the locations of any other UEs 105 in the group, the location of the UE 105 relative to some other known location, the absolute location of the UE 105, the velocity of the UE 105, or the velocity of the UE 105 relative to some other UEs 105.

[0072] Sidelink positioning can be used for positioning a UE independent of the core network (e.g., 5GC 140) or the serving PLMN. One example implementation of sidelink positioning can be found in vehicular communication systems such as V2X, which can be used for safety-related applications such as safety warnings, traffic congestion (e.g., automated traffic control), and cooperative or automated vehicle steering. One aspect of sidelink positioning that may require a standardization solution is the Sidelink Positioning Protocol (SLPP), which can be used between a UE and a location server, including between an RSU and a UE. SLPP can support sidelink positioning, for example, between a UE, an RSU, and a PRU with network access independence. SLPP can provide support for sidelink positioning for pairs of UEs (e.g., ranging), groups of UEs (V2X), and UEs that are members of multiple different groups. By way of example, SLPP may provide support for various positioning techniques currently standardized for UE-based and UE-assisted support by location servers (e.g., LMF 120), such as PRS RTT, AOA, Differential AOA (DAOA), AOD, and Differential AOD (DAOD), but may also enable support for other PRS and SRS-based positioning methods, as well as non-PRS methods such as RTK later. By allowing for the addition of new capabilities and methods later, SLPP may avoid the need to define a new positioning protocol separate and distinct from SLPP. By way of example, additional positioning methods that may later be included in SLPP may include RTK, Wi-Fi, Ultra-Wideband (UWB), and BT positioning methods.

[0073] SLPP may initially enable direct sidelink operation (UEs communicate and coordinate positioning by exchanging SLPP messages using sidelink signaling) and may later be extended to sidelink operation via relays and network-mediated operation, where UEs may exchange SLPP messages via the network or via intermediate relay UEs. For example, this may be used to coordinate positioning of two vehicles on a collision course at a corner where direct SL signaling between the two vehicles is not possible. Therefore, SLPP may initially define support for SL PRS-based positioning in a general manner to simplify later extension to support other positioning methods. For example, SLPP may define general SLPP messages similar to the general LPP messages defined for LPP in 3GPP TS 37.355. SLPP may support distinct positioning methods (e.g., SL PRS RTT, SL PRS AOA, SL PRS AOD) using common procedures and common parameters, where feasible. SLPP may define procedures that can be reused for multiple positioning methods and is not limited to just one or a few positioning methods. SLPP may be enabled to be forwarded and used by various entities, such as UEs, RSUs, PRUs, and location servers such as LMFs and SUPL SLPs. Location servers (e.g., LMFs and SUPL SLPs) may forward SLPP messages within LPP messages to enable UE-assisted positioning by the LMF or SUPL SLPs. Alternatively, location servers (e.g., LMFs and SUPL SLPs) may forward SLPP messages that are not associated with LPP messages to enable UE-assisted positioning by the LMF or SUPL SLPs. SLPP may further support relative (local) and global positioning.

[0074] FIG. 2 illustrates, by way of example, the architecture of a communication system 200 capable of network-supported sidelink positioning. As illustrated in FIG. 2, for sidelink positioning, several UEs (e.g., UEs 105) may be combined into the same group 210. Within the group 210, there may be various subgroups of UEs. For example, the group 210 of UEs may 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 outside the coverage of either network and not served by either network. One or more of the UEs served by the network, e.g., the UEs in the subgroup 212 served by PLMN1 140a or the UEs in the subgroup 214 served by PLMN2 140b, may include an RSU.

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

[0076] Location server (e.g., LMF / SUPL SLP / Server1 / Server2 / Server3) 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 determining or verifying SL PRS configurations and calculating location results for UEs, including supported and unsupported UEs (e.g., calculating location results for UEs in the supported subgroup and, if location information for UEs in the unsupported subgroup is provided to the location server, location results for UEs in the unsupported subgroup). In some implementations, signaling between location servers in separate networks can be used to provide more complete network support. As shown, LMF-LMF or SUPL SLP-SUPL SLP signaling may be used (e.g., SLPP in FIG. 2) to enable more complete network support. ** An extension to SLPP (called

[0077] SLPP message types may be consistent with LPP message types to allow LPP messages to include embedded SLPP messages and / or to allow SLPP procedures to be consistent with LPP procedures, which may reduce implementation and / or testing. Figure 2 shows signaling (e.g., SLPP messages or SLPP messages embedded in LPP messages) between LMF1 120a and one or more of the UEs in subgroup 212, and signaling between LMF2 120b and one or more of the UEs in subgroup 214. Figure 2 also shows LPP messages, or LPP messages including embedded SLPP messages, embedded in SUPL ULP messages exchanged between SUPL SLP1 119a and one or more of the UEs in subgroup 212, and between SUPL SLP2 119b and one or more of the UEs in subgroup 214. SLPP may include messages similar to the LPP capability request and capability provision messages, which may be referred to, for example, in SLPP as "capability and resource requests" and "capability and resource provision." Capability and resource requests / provisions in SLPP may initially be limited to NR SL PRS capabilities and resources, but may later be expanded to capabilities and resources for LTE SL PRS, RTK, Wi-Fi, BT, etc.

[0078] In another example, the SLPP may include messages similar to the LPP Provide Assistance Data message, which may be referred to in SLPP as a "positioning signal configuration provide" (or simply as an "assistance data provide"). A positioning signal configuration provide in SLPP may include, for example, one or more of the SL PRS configurations to be transmitted by each UE and measured by other UEs, the start time and duration of transmission and the status for the end of transmission, and the type of SL PRS measurement requested, such as Rx-Tx, AOA, RSRP, RSRD, TOA, TDOA, etc. In some implementations, the positioning signal configuration provide in 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 positioning signal configuration provide in SLPP may include additional information, for example, to assist the UE in acquiring and measuring signals (e.g., SL PRS signals) and to determine the times of transmission and measurement.

[0079] In another example, SLPP may include messages such as "positioning signal configuration confirm" (or "assistance data confirmation provide"), which do not have an analogous LPP message. The positioning signal configuration confirm in SLPP may, for example, confirm whether the positioning signal configuration provide (or assistance data provide) is agreeable. If the positioning signal configuration provide is not (partially) agreeable, a different configuration may be provided as the positioning signal configuration provide. Since LPP does not have an analogous message, if SLPP messages are embedded in LPP messages, a new LPP message type may be added to carry the positioning signal configuration confirm SLPP message. However, such a new LPP message type may not be needed when SLPP messages are not embedded in LPP messages.

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

[0081] As shown in FIG. 2 , UEs in each subgroup and UEs in different subgroups may signal each other using SLPP (e.g., when a UE sends an SLPP message to one or more other UEs). In addition, a location server (e.g., an LMF, a SUPL SLP, or Servers 1-3) may support UEs using SLPP (as described above). As previously mentioned, according to some embodiments, SLPP may be embedded in LPP, or embedded in both LPP and SUPL, or may be transmitted without being embedded in LPP. Thus, a first UE may receive a first SLPP message from a second UE and may send the first SLPP message to a location server supporting the first UE. The first UE may receive a second SLPP message from the location server in response to the first SLPP message and may send the second SLPP message to the second UE.

[0082] NR can support or enable various sidelink positioning techniques. Figure 3A illustrates various scenarios of interest for sidelink-only or joint Uu and sidelink positioning according to aspects of the present disclosure. In scenario 310, at least one peer UE with a known location can improve the 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 may obtain the assistance of a premium UE to determine its location, e.g., using a sidelink positioning and ranging procedure 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 capabilities, access to additional frequency bands, or any combination thereof. In scenario 330, a relay UE (e.g., with a known location) participates in the positioning estimation of a remote UE 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 locations can locate together in non-line-of-sight (NLOS) conditions by utilizing constraints from nearby UEs.

[0083] 3B illustrates additional scenarios of interest for sidelink-only or joint Uu and sidelink positioning in accordance with aspects of the present disclosure. In scenario 350, UEs used for public safety (e.g., by police, firefighters, etc.) may perform peer-to-peer (P2P) positioning and ranging for public safety and other uses. For example, in scenario 350, the public safety UEs are out of network coverage and may use sidelink positioning techniques to determine locations or relative distances and positions between the public safety UEs. Similarly, scenario 360 illustrates multiple UEs that are out of coverage and use sidelink positioning techniques such as SL-RTT to determine locations or relative distances and positions.

[0084] Using the SL positioning method (also referred to as "SLPP positioning"), a first UE may transmit an SL-PRS or SL-SRS signal that is received and measured by a second UE. Additionally or alternatively, the second UE may transmit an SL-PRS or SL-SRS signal that is received and measured by the first UE. Measurements of the SL PRS or SL SRS signal may include Rx-Tx, TOA, RSRP, RSRQ, and AOA. The SL positioning method may include SL RTT (also referred to 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 an SL PRS or SRS signal that can be measured by some or all of the other UEs in the group. Some or all of the other UEs in the group may also transmit SL PRS or SRS signals that can be measured by some or all of the other UEs in the group different from the UE transmitting the UL PRS or ULS SRS (e.g., each UE transmits the SL SRS or PRS at one or more times different from the times at which other UEs in the group transmit the SL PRS or SRS). Measurements made by the UE applicable to the transmission of the SL PRS or SRS by one or more groups of 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 the positioning method(s), each UE may determine the relative or absolute location of itself and / or the other UEs. For example, the relative location of a UE may include the locations of one or more other UEs in the group.

[0085] In some designs, location server (e.g., LMF / SUPL SLP) support for a UE may be invisible to other UEs in the group (e.g., out-of-coverage UEs). The support provided by the location server to the UE may include determining or verifying PRS configuration and calculating the relative location of the UE, including UEs in supported subgroups as well as UEs in unsupported subgroups, e.g., if location information for UEs in an unsupported subgroup is proven to the location server. For example, in some implementations, signaling between location servers in separate networks may be used to provide more complete network support.

[0086] In some designs, SLPP message types may be aligned with LPP to allow LPP messages to include SLPP messages. In some designs, LPP messages, including SLPP messages, may be embedded in Secure User Plane Location (SUPL) User Plane Location Protocol (ULP) messages. For example, SLPP may include messages similar to LPP capability requests and capability provisioning, which may be referred to, e.g., as capability and resource requests and capability and resource provisioning in SLPP. Capability and resource request / provisioning in SLPP may be limited to NR PRS but may be extended to LTE PRS, real-time kinematics (RTK), WiFi, BT, etc.

[0087] In another example, SLPP may include messages similar to LPP assistance data offers, which may be referred to in SLPP as positioning signal configuration offers. A positioning signal configuration offer in SLPP may include, for example, one or more of the PRS configurations to be transmitted by each UE and measured by other UEs, start time, duration, and status for termination, and the type of measurement requested, such as Rx-Tx, AOA, RSRP, TDOA, etc. In some implementations, a positioning signal configuration offer in SLPP may be extended to define other types of signals, such as RTK signals to be measured, WiFi signals to be transmitted and measured, etc. A positioning signal configuration offer in SLPP may include additional information, for example, to assist the UE in acquiring and measuring signals and to determine the time of transmission.

[0088] In another example, the SLPP may include messages such as a positioning signal configuration confirm, which does not have an analogous LPP message. The positioning signal configuration confirm in the SLPP may, for example, confirm whether the positioning signal configuration provision is agreeable. If the positioning signal configuration provision is not (partially) agreeable, a different configuration may be provided as the positioning signal configuration provision. Because the LPP does not have an analogous message, a new LPP message type may be added to carry the positioning signal configuration confirm SLPP message.

[0089] In another example, SLPP may include messages similar to LPP location information offers, which may be referred to as location information offers in SLPP. Location information offers in SLPP may provide PRS measurements of other UEs and / or relative locations to other UEs. Location information offers in SLPP may be extended to other measurements, such as RTK, WiFi, BT, etc. measurements.

[0090] In some designs such as those 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 resulting from the performed measurements. Depending on the deployment scenario and operational use case, sidelink positioning and ranging may occur across multiple cast types, between UEs, or between the UE and the LMF.

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

[0092] FIG. 4 shows a reference architecture 400 for sidelink positioning and ranging-based services for non-roaming and same-PLMN operation. This architecture supports sidelink positioning and ranging for in-coverage (IC), out-of-coverage (OOC), and partial coverage (PC) operation and is suitable for both PC5-only positioning 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 may also provide location and distance calculations on behalf of other UEs. For scenarios involving an LMF, through the SPRF, the LMF may request UE capability information, configure measurements, receive measurement results, and perform location and distance calculations for and / or on behalf of participating UEs. Two or more UEs may participate in one-to-many or many-to-one sidelink positioning and ranging sessions using the discovery and positioning protocol over the SR5 reference point. SR5 is carried over the PC5 reference point and provides the interface for UE-to-UE discovery and the SLPP positioning protocol.

[0093] The terms target UE and anchor refer to specific UE functions or capabilities that a UE may exercise when participating in sidelink positioning (described in more detail below). These roles are not architectural entities, but rather UE functions. The architectural entity / node is still the "UE," and each UE in the architecture may function as a "target," "anchor," "server," etc., depending on its respective capabilities. In particular, a UE may support several roles simultaneously. For example, a UE may be a target of positioning while also assisting other UEs in positioning. Thus, the NG-RAN positioning architecture may be independent of "UE roles" (functions), and there is no need to define separate architectural diagrams for in-coverage, partial-coverage, or out-of-coverage UEs.

[0094] The reference architecture described in Figure 4 can be directly mapped to an overall positioning architecture as shown in Figure 5, which illustrates a UE positioning architecture 500 applicable to NG-RAN for all coverage scenarios (e.g., separate architectures for in-coverage or out-of-coverage scenarios are not required). In-coverage UEs (UE A, UE B) and out-of-coverage UEs (UE C, UE D) perform sidelink positioning and ranging over PC5 reference points using SLPP. Network elements such as the LMF that support SLPP can provide UE assistance by requesting UE capabilities, configuring measurements, receiving measurement results, and calculating a resultant position or relative location, as described further below.

[0095] In some designs, PC5-U is used for the transport of SLPP. FIG. 6 shows SLPP protocol layering 600 on the PC5 reference point. FIG. 7 shows SLPP non-IP type encoding scheme 700. In some designs, for protocol layering, SLPP on PC5-U can reuse the existing SDU header type "non-IP" by simply defining one additional V2X message family encoding value for the non-IP type used by SLPP (e.g., "SR5"), as shown in FIG. 7. This allows SLPP signaling over SR5 to be treated as a V2X application and as payload over the V2X / ProSe layer using the PC5 user plane protocol layering shown in FIG. 6.

[0096] Sidelink communications may be susceptible to packet loss due to changes in UE separation / proximity, such as when moving a UE, or due to blockages between UEs. Such behavior is characteristic of sidelink communications, regardless of the broadcast or transport type. This packet loss may lead to the loss of SLPP messages.

[0097] In the case of LPP for Uu operation, LPP message loss can also occur when an LPP message is not successfully forwarded by the MME or AMF. Therefore, LPP already includes a reliable transport mechanism, including acknowledgment and retransmission capabilities at the LPP level. Because PC5-U transport does not natively provide a reliable transport mechanism, LPP acknowledgment and retransmission capabilities can also be supported by SLPP, allowing SLPP procedures to be designed with redundancy and tolerance to transport failures. With redundancy, a UE can send an SLPP request message to one or a group of UEs, and each UE in the group responds to acknowledge receipt of the message or to acknowledge that it has performed, or can later perform, the requested action (e.g., sidelink reference signal transmission and / or measurement). 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. With LPP-based reliability applied to SLPP, a sender of an SLPP request message to a group of one or more UEs can determine when the message is not received by the target UEs and then take appropriate action(s), such as retransmitting the request message at a later time or not expecting the non-responsive UEs to perform the requested action.

[0098] The LPP-based reliability implemented in SLPP relates to session-based operation, and a group of one or more UEs involved in a sidelink ranging and positioning session will benefit from reliable transport, especially when the obtained distance / location applies to group operation. The session leader (initiator) can choose to invoke reliability if the leader determines it is appropriate for the session. In contrast, session-less operation seeks to minimize overhead and latency for ranging / positioning between UEs with short interactions and therefore may not require reliable transport. Therefore, the initiator of a session-based or session-less sidelink ranging and positioning transaction may have the flexibility to decide whether to invoke SLPP reliable transport. The LPP-based reliability implemented in SLPP provides the additional advantage that SLPP can operate reliably between the UE and the LMF, as described further below.

[0099] In some designs, communication over the sidelink may incur packet loss due to changes in the relative locations of participating UEs and / or blockages, potentially leading to SLPP message loss. Mechanisms may be added to support SLPP robustness, such as redundancy, acknowledgments and retransmissions, and / or tolerance to transport failures.

[0100] In some designs, LPP's reliable transport mechanisms of duplicate detection, acknowledgment, and retransmission can be applied to SLPP.

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

[0102] In some designs, with regard to session-based and session-less operation, sidelink positioning supports the session-based concept in SLPP, where signaling messages within a session can be correlated by participating UEs. In some designs, session-less operation may be supported.

[0103] In some designs, with respect to session-based and session-less operation, SLPP session-less operation may be supported at least if a positioning method that does not require mutual exchange of associated SLPP messages between UEs is supported. In some designs, session-less operation may be operated with security.

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

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

[0106] In some designs, for session-based SLPP, SLPP transactions are indicated at the SLPP protocol level with a transaction ID to associate messages with each other (eg, request and response).

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

[0108] In some designs, group positioning may be utilized to collect location estimates (absolute positioning) for multiple target UEs or location estimates (ranging / relative positioning) for multiple UE pairs per LCS request. In some designs, at least a portion of the group management for group positioning may be performed at an upper / application layer.

[0109] Sidelink positioning can support multiple use cases, including V2X, public safety (PS), commercial, and industrial Internet of Things (IIOT). These use cases may involve stationary UEs, moving UEs, or a combination / group of stationary and moving UEs. An individual UE in one of these use cases may initiate a sidelink positioning session with one or more UEs in its vicinity (UEs with which it can establish sidelink communication). These UEs may comprise all UEs in the initiating UE's vicinity, a subset of UEs in the initiating UE's vicinity, or only a single UE in the initiating UE's vicinity. Group-based use cases for sidelink ranging and positioning include V2X with an RSU and multiple vehicles, multiple vehicles in a platoon, and scenarios for mission-critical (MCX) services and museum tours or other tours.

[0110] Exemplary use cases are illustrated in Figures 8A-8C. Figures 8A-8C illustrate exemplary scenarios 800, 820, and 830 for sidelink positioning / ranging, respectively, according to aspects of the present disclosure. In this example, UE1 initiates a sidelink positioning session with only one UE in its vicinity in Figure 8A. In Figure 8B, UE1 initiates a sidelink positioning session with a subset of four UEs in its vicinity, and in Figure 8C, UE1 initiates a sidelink positioning session with all UEs in its vicinity. Note that while the examples in Figures 8A-8C are for a V2X use case, 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 UEs in its vicinity. When initiating a sidelink positioning session with a group of one or more UEs, the group may comprise all or a subset of the UEs in the vicinity of the initiating UE.

[0111] For sidelink positioning and ranging scenarios where participating UEs are aware of each other's presence (e.g., when three participating UEs in FIG. 8B or five participating UEs in FIG. 8C have established awareness or association), positioning can be supported using session-based operation. For sidelink positioning and ranging scenarios that do not require the mutual exchange of associated SLPP messages (e.g., when participating UEs do not have established association), session-less operation can be used. The decision to use session-based or session-less operation can be made by the application layer based on the specific scenario, use case, and participant UE decision (e.g., the location / range of a specific set of one or more UEs, or the location / range of a group of nearby UEs). Subsequent session-based or session-less transactions are then instantiated by SLPP. The following description provides a description of possible SLPP session establishment, termination, and modification.

[0112] LPP does not support explicit management of LPP sessions and services. An LPP session is always a one-to-one association between one UE and one location server, and it is always assumed that the location server (e.g., LMF in the case of NR) controls the LPP session, not the UE. In contrast, for sidelink positioning, a UE may simultaneously participate in multiple SLPP sessions (V2X, MCX, public safety, etc.). Each separate SLPP session may be with a different UE, with one or more different groups of UEs, or with 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, each with different session participants and different session requirements, must maintain knowledge and status of the separate sessions and session participants. To adapt to UE operational considerations, including power consumption and privacy, the UE may also be able to accept or reject session participation. Furthermore, given the mobility of sidelink UEs, the configuration of session participants may change during the course of a session, implying the ability to support session modification and session termination. These aspects of sidelink positioning session operation (explicit session acceptance, rejection, modification, and termination) cannot be directly supported using SLPP's LPP-based capabilities, assistance data, and location information. Instead, new SLPP messages are required that can be considered part of SLPP session and service management.

[0113] The following description of SLPP session establishment and session modification assumes SLPP support for session acceptance, rejection, termination, and modification. Note that for session-less operation, these SLPP capabilities are not required.

[0114] 9 illustrates an SLPP session establishment procedure 900 according to an aspect of the present disclosure. In some designs, SLPP is carried as a payload over the V2X / ProSe layer, with interactions and exchanges between the application layer and the SLPP layer. FIG. 9 includes actions 0 through 8, which are summarized as follows:

[0115] 9, action 0: The application layer in UE1 and other UEs may perform UE discovery, determine and verify required services, and perform group management (e.g., create a group including UE1-n). The application layer in UE1 also verifies that all of UE1-n support SLPP. The application layer in UE1 may then request sidelink ranging and positioning results for UE1-n from the SLPP layer in UE1, provide the SLPP layer in UE1 with an application layer ID and a Layer 2 ID for each of UE1-n, and provide the SLPP layer in UE1 with an application layer group ID and a Layer 2 group ID for a group of one or more UE1-n. In some designs, the exact API between the application layer and the SLPP layer may be considered implementation-dependent.

[0116] Figure 9, action 1: UE1 sends a Create SLPP Session Request message to each of UE2-n. The message includes an SLPP session ID assigned by UE1 and may include a Layer 2 group ID for the SLPP session. The Create SLPP Session Request message also includes an SLPP transaction ID for associating the Create SLPP Session Request message with received Create SLPP Session Accept and Create SLPP Session Reject messages. The Create SLPP Session Request message may be sent via unicast, groupcast, or broadcast.

[0117] Figure 9, Action 2: Each UE (UE 2 through n) that can accept the session request sends a Create SLPP Session Accept message to UE 1. Otherwise, the UE sends a Create SLPP Session Reject message to UE 1. The Create SLPP Session Accept message and the Create SLPP Session Reject message include the SLPP Transaction ID associated with the Create SLPP Session Request message. The Create SLPP Session Accept message and the Create SLPP Session Reject message may be sent via unicast, groupcast, or broadcast.

[0118] Figure 9, Operation 3: UE1 determines the UEs for the SLPP session from the UEs that return an SLPP session creation accept in Operation 2. In this example of Figure 9, it is assumed that all UEs 2 to n accept the SLPP session request.

[0119] 9, operation 4: UE1 sends an SLPP session start request message to UE2-n determined for the session in operation 3 to initiate an SLPP session. The SLPP session start request message includes an application layer ID and a layer 2 ID for each UE in the session and a UE1-assigned SLPP UE ID for each UE in the positioning session. The SLPP UE ID may be an integer (e.g., in the range of 1 to n) that identifies each UE in the SLPP session. The SLPP session start request message also includes an SLPP transaction ID for associating the SLPP session start request message with a received SLPP session start response message. The SLPP session start request message may be sent via unicast, groupcast, or broadcast.

[0120] 9, operation 5: UE2-n acknowledges the session initiation with an SLPP Session Initiation Response:Accept message and can then begin positioning within the session. The SLPP Session Initiation Response:Accept message includes the SLPP transaction ID associated with the SLPP Session Initiation Create Request message. The SLPP Session Initiation Response:Accept message may be sent via unicast, groupcast, or broadcast. In one aspect, after performing session establishment in operations 4 and 5, all UEs 1-n will know all other UEs in the session, including their application layer IDs, Layer 2 IDs, SLPP IDs, Layer 2 group IDs, etc. Then, only the SLPP UE ID and SLPP Session ID are needed in subsequent SLPP transactions (e.g., in operation 6).

[0121] FIG. 9, Operation 6: Perform SL positioning / ranging procedure.

[0122] 9, actions 7-8: Once positioning is complete (e.g., once the application layer requirements in action 0 are satisfied), UE1 may send an SLPP Session Termination Request message to each participant UE2-n, which each UE acknowledges by sending an SLPP Session Termination Response message back to UE1. The SLPP Session Termination Request and SLPP Session Termination Response messages include an SLPP transaction ID for associating the request and response messages. The SLPP Session Termination Request and SLPP Session Termination Response messages may be sent via unicast, groupcast, or broadcast.

[0123] 9, in one aspect, the SLPP layer may assign a unique SLPP session ID to a particular sidelink positioning session and assign an individual SLPP ID to each UE participating in that 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 indication of UE1 plus a local numeric ID assigned to UE1.

[0124] An SLPP session may be modified, for example, through the addition or removal of a UE, as shown in Figure 10. Figure 10 illustrates an SLPP session modification procedure 1000 according to an aspect of the present disclosure.

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

[0126] FIG. 10 shows a procedure 1000 for modifying an SLPP session (which may have been established, for example, using procedure 900 of FIG. 9), and includes actions 0-4 summarized as follows:

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

[0128] FIG. 10, action 1: UE1 sends an SLPP session modification request to a modified set of one or more UEs in the SLPP session (UEs in the current session and any new UEs included in the modified session). The SLPP session modification request message may be unicast, groupcast, or broadcast to both the current UEs and the new UEs (e.g., using the new Layer 2 group ID provided by the application layer in action 0). The SLPP session modification request message may include a new Layer 2 group ID and a new SLPP session ID for the SLPP modified session. UEs currently included 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 groupcasting or broadcasting a message to both the current UEs and the new UEs is not possible or not allowed (e.g., for policy reasons), UE1 performs actions 1 and 2 of the SLPP establishment procedure 900 of FIG. 9 to create the SLPP modified session for the new UEs. For existing UEs that may not be part of the modified session, UE1 may perform operations 7 and 8 of the SLPP establishment procedure 900 of Figure 9 to terminate the SLPP session for these UEs. The SLPP Session Modify Request message includes an SLPP Transaction ID to associate the SLPP Session Modify Request message with the received SLPP Session Modify Accept / Reject message.

[0129] 10, Action 2: Each UE (UE2-n) that can accept the session modification request sends an SLPP session modification accept message to UE1. Otherwise, the UE sends an SLPP session modification reject message to UE1. The SLPP session modification accept message and the SLPP session modification reject message may be sent via unicast, groupcast, or broadcast. The SLPP session modification accept message and the SLPP session modification reject message include the SLPP transaction ID associated with the SLPP session modification request message.

[0130] Figure 10, Action 3: UE1 determines the UE for the SLPP modification session from the UE that returns the SLPP session modify accept message in action 2, or the SLPP session create accept message if actions 1 and 2 of Figure 9 are performed for any new UE.

[0131] Figure 10, Operation 4: UE1 continues the SLPP modification session according to operations 4 to 8 in Figure 9 to establish an SLPP session. In this case, new SLPP UE IDs are assigned to all UEs by UE1 in operation 4.

[0132] Referring to FIG. 10, in one aspect, SLPP may support at least the following message types for SLPP session-based operations: SLPP session creation request / accept / reject SLPP session initiation request / response ( * ) SLPP session termination request / response ( * ) SLPP Session Modification Request / Accept / Reject ( * )

[0133] asterisk( * Note that the messages indicated above by ) can be combined into a single SLPP message using the setup / modify / release mechanism.

[0134] In addition to session-based operation, many sidelink positioning / ranging use cases can benefit from session-less operation, and the following may be supported: SLPP session-less operation may be supported at least if a positioning method that does not require mutual exchange of associated SLPP messages between UEs is supported. In some designs, session-less operation can operate with security.

[0135] Use cases for session-less operation include scenarios involving dynamic or mobile UEs where it is desirable to minimize the signaling overhead and associated session establishment latency that can occur with session-based operation. Applicable scenarios include the need for one UE to determine the location / range to its neighboring UEs for a brief or short time interval, such as a vehicle crossing an intersection, a vehicle entering a highway from an on-ramp, or a public safety individual moving around an operating room. An example scenario 1100 is shown for the V2X use case in FIG. 11.

[0136] 11, consider the case where a vehicle crosses an intersection with an RSU UE performing sidelink positioning / ranging to the UE. In such a scenario, the set of one or more UEs that are in proximity to and interested in the RSU for sidelink positioning often changes, making session-less operation more flexible. Note that while this scenario illustrates the benefits of session-less operation for stationary UEs (RSUs in FIG. 11), session-less operation is equally applicable and beneficial for mobile UEs (vehicles) initiating sidelink positioning.

[0137] In some designs, session-less operation, signaling overhead is minimized to adapt to dynamic UE conditions, as described below with respect to FIG.

[0138] 12 illustrates SLPP session-less operation 1200 according to an aspect of the present disclosure. FIG. 12 includes operations 1 through 6, which are summarized as follows:

[0139] Figure 12, Action 1: The application layer in UE1 may request the SLPP layer to initiate sidelink positioning for UEs that may be in its vicinity. The application layer in UE1 may make this request of the SLPP layer periodically through configuration, based on determination of its vicinity UEs, or by other means. UE1 sends an SLPP Provide Assistance Data message via connectionless groupcast or broadcast. The SLPP Provide Assistance Data message includes SL-PRS configurations for UEs that are able to participate (e.g., 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.

[0140] It should be noted that a UE receiving an SLPP Provide Assistance Data message without the reciprocal exchange of an SLPP Session Establishment message may determine that this is for a sessionless sidelink ranging / positioning session from the allocated space of SLPP Session IDs, by omission of the SLPP Session ID or by other means.

[0141] 12, operation 2: In 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 in operation 1. Optionally, each of UEs 2-n transmits an SLPP Provide Assistance Data message via connectionless groupcast or broadcast. The SLPP Provide Assistance Data message includes the SL-PRS configuration that each UE may transmit in operation 4 and the UE's identification information (e.g., application layer ID).

[0142] Figure 12, action 3: UE1 and optionally each of UEs 2-n transmit an SLPP Location Information Request message via connectionless groupcast or broadcast. The SLPP Location Information Request message indicates the measurements obtained in action 5 and / or the location results sent in action 6. The SLPP Location Information Request message includes an SLPP transaction ID to associate the SLPP Location Information Request message with the received SLPP Provide Assistance Data message.

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

[0144] FIG. 12, Action 5: Each participating UE performs SL-PRS measurements according to the configuration in the Provide SLPP Assistance Data message as requested in Action 1 or Action 2, or in Action 3.

[0145] 12, Action 6: Once the SL-PRS transmission and SL-PRS measurement are completed, or periodically during this time, the participating UE transmits an SLPP Provide Location Information message with the measurement results obtained in Action 5. The SL-PRS transmission and SL-PRS measurement may be performed periodically based on the configuration received in the SLPP Provide Assistance Data message. 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.

[0146] Referring to FIG. 12 , in some designs, session-less operation is established without the mutual exchange of SLPP session establishment signaling via transmission of a Provide SLPP Assistance Data message. In some designs, the SLPP Session ID may be assigned a specific ID value to indicate session-less operation. In one aspect, the importance of group positioning for sidelink ranging and positioning is evident. Since SLPP over PC5-U is carried as a V2X payload, group management may be implemented using an upper / application layer that provides group information to the V2X (SLPP) layer. The upper / application layer manages group configuration, group identity information, and provides overall group management to the lower (SLPP) layer.

[0147] Referring to FIG. 12, in some designs, group positioning involves collecting location estimates (absolute positioning) for multiple target UEs or location estimates (ranging / relative positioning) for multiple UE pairs per LCS request.

[0148] Referring to FIG. 12, in some designs, at least a portion of the group management for group positioning is performed at an upper / application layer.

[0149] Distance and location calculations by UEs participating in sidelink positioning and ranging, including distance / location calculations by one UE on behalf of other target UEs (UE-assisted) and distance / location calculations by multiple target UEs (UE-based), may be supported at least via unicast SLPP / RSPP "centralized" operation, i.e., one UE performs distance and / or location calculations based on measurements / location information for itself and / or other UEs. If it is determined to support group positioning, it may be feasible to perform at least ranging with estimate calculations at multiple UEs.

[0150] Exemplary procedure flows for SLPP UE-assisted (one UE performs distance / location calculations on behalf of other target UEs) and UE-based (multiple target UEs perform distance / location calculations) are shown in Figures 12 and 13, respectively. Note that both UE-assisted and UE-based operation follow the same first seven operations (session establishment, capability transfer, and assistance data exchange).

[0151] 13 illustrates a session-based sidelink-only positioning with UE-assisted initiated (centralized) position calculation 1300 for multiple target UEs according to an aspect of the present disclosure. FIG. 13 includes actions 1 through 11, which are summarized as follows:

[0152] Figure 13, Action 1: UE B performs the SLPP session establishment procedure described (e.g., as in Figure 9)

[0153] Figure 13, Action 2: UE B sends an SLPP Capability Request message to the group of target UEs established in Action 1, requesting SL positioning capability from the UEs participating in this session. The SLPP Capability Request message can be sent by UE B to UE A, UE C, and UE D via broadcast, groupcast, or unicast, depending on the specific scenario.

[0154] Figure 13, Action 3: The target UEs in Action 2 addressed by UE B respond with SLPP capability provision messages. The UE capabilities may refer to a specific sidelink positioning method (e.g., SL-RTT, SL-AoA, SL-TDOA, etc.) or may be common to multiple positioning methods. The capabilities may also include SL-PRS capability, an indication of whether the UE can function as an anchor UE and / or a location server UE, position / distance calculation capability, etc. If the UE can function as an anchor UE, the SLPP capability provision message may also include location coordinates. The SLPP capability provision message may be sent by UE A, UE C, and UE D via broadcast, groupcast, or unicast, depending on the specific scenario.

[0155] FIG. 13, Action 4: The SLPP session may be modified as described in FIG. 10 based on the capability information from Action 3 (e.g., removal of UEs with incompatible capabilities such as SL positioning methods, anchor capabilities, etc.).

[0156] Figure 13, operation 5: UE B sends an SLPP Provide Assistance Data message to the group of target UEs established in operation 1 or 4. The SLPP Provide Assistance Data message includes an SL-PRS configuration for each of the UEs in the group. The SLPP Provide Assistance Data message may be transmitted via broadcast, groupcast, 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 target UEs transmits its respective SL-PRS. The duration of the 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. The SL-PRS may be transmitted via broadcast, groupcast, or unicast, depending on the specific scenario.

[0157] Figure 13, action 6: UE B sends an SLPP Location Information Request message to a group of one or more 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 distance / position calculations may be performed by the initiating UE (UE B). The SLPP Location Information Request message may be sent via broadcast, groupcast, or unicast, depending on the particular scenario.

[0158] FIG. 13, action 7: Each participating UE performs the requested SL-PRS transmissions and measurements.

[0159] 13, operation 8: Upon completion of transmission and measurement, or periodically, or after the response time received in operation 6 has expired, the multiple target UEs each transmit an SLPP Provide Location Information message with the location results requested in operation 6. The message may also include an indication of whether another UE (in this case, initiating UE B) is requested to return location results (e.g., calculated distance and / or position) to this UE. SL-PRS transmission and SL-PRS measurement may be performed periodically based on the configuration received in the SLPP Provide Assistance Data message. The SLPP Provide Location Information message may be transmitted via broadcast, groupcast, or unicast, depending on the particular scenario.

[0160] FIG. 13, Operation 9: Initiating UE B performs a distance / position calculation using the location result received in operation 8 and the location result UE B obtained in operation 7.

[0161] Figure 13, action 10: If requested in action 8, UE B may distribute location results for UEs A, C, D to other UEs A, C, D in this session. The location results may be distributed via broadcast, groupcast, or unicast, depending on the particular scenario.

[0162] FIG. 13, action 11: The SLPP session may be terminated (eg, as in FIG. 9).

[0163] 14 illustrates session-based sidelink-only positioning 1400 with UE-based (distributed) position calculation with multiple target UEs according to an aspect of the present disclosure. FIG. 14 includes actions 1 through 11, which are summarized as follows:

[0164] FIG. 14, operations 1 to 5: same as FIG.

[0165] Figure 14, action 6: UE B sends an SLPP Location Information Request 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 distance / position calculations may be performed by each of the participating UEs. The SLPP Location Information Request message may be sent by UE B to UE A, UE C, and UE D via broadcast, groupcast, or unicast, depending on the particular scenario.

[0166] FIG. 14, operations 7 and 8: Same as FIG.

[0167] FIG. 14, Operation 9: Each participating UE performs distance / position calculations using the location result received in Operation 8 and its own location result obtained in Operation 7.

[0168] 14, action 10: If requested in action 8, each UE may distribute its location results to other UEs in this session. The location results may be distributed via broadcast, groupcast, or unicast, depending on the particular scenario.

[0169] FIG. 14, action 11: The SLPP session may be terminated (eg, as in FIG. 9).

[0170] 14, in some designs, UE-based (distributed) sidelink positioning and ranging may enable UE position calculation without relying on a separate UE and may reduce overall SLPP signaling required for sidelink positioning. In one aspect, SLPP may support UE-based (distributed) sidelink positioning, which allows multiple target UEs to determine position and range based on exchanged location information.

[0171] Regarding groupcast and broadcast transmission of SLPP, in some designs, it may be feasible to transmit at least the following positioning signaling for groupcast / broadcast (in addition to unicast): SL positioning capability SL positioning assistance data SL Location Measurements and Information

[0172] In some designs, both UE-assisted (FIG. 13) and UE-based (FIG. 14) sidelink ranging and positioning involve capability exchange and assistance data transfer to and between multiple target UEs, as shown in FIGS. 13 and 14. In some designs, unicast, groupcast, or broadcast may be used for transmission of the capability exchange and assistance data transfer. In some designs, security for sidelink ranging and positioning signaling via groupcast and broadcast may be achieved. With regard to location information exchange, groupcast / broadcast transmission may be supported for location information exchange.

[0173] In some designs, sidelink ranging and positioning signaling transmitted via groupcast or broadcast may be supported. The solution for secure SLPP transmission via groupcast or broadcast eliminates any impediments or impediments to secure delivery of capabilities, assistance data, and location information via groupcast or broadcast.

[0174] In some designs, for 3GPP precursors, existing application layer messages carried as 3GPP V2X payloads defined by SDOs, including ETSI-ITS, SAE, and CSAE, include the UE GNSS position and UE GNSS position accuracy (e.g., CAM, BSM, CPM, SDSM, etc.) may be supported. Because SLPP is also carried as a V2X payload, conveying location information may not present a risk to UE operation.

[0175] In some designs for transmitting UE discretion, delivery of location information can be at the discretion or choice of the transmitting (sending) UE. If the sender is subject to policy or other restrictions on location information exchange, the sender may choose not to deliver the location information. In an aspect, security for groupcast or broadcast transmissions is not an obstacle to location information exchange via groupcast / broadcast. In an aspect, existing 3GPP V2X payload standardized messages support exchange of UE GNSS location and UE GNSS location accuracy via groupcast and broadcast. In an aspect, SLPP supports location information exchange via unicast, groupcast, and broadcast.

[0176] The basic SLPP transaction types (Capability Transfer, Assistance Data Transfer, Location Information Transfer) suitable for supporting out-of-coverage sidelink positioning and ranging scenarios can also be applied to 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 enabled via subscription to access the PLMN, 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 have PLMN access and are supported by the LMF or provide support for the LMF (LMF support may be limited to only some UEs). Possible examples of LMF-assisted (MO-LR) and LMF-initiated (MT-LR) sidelink positioning and ranging are shown in Figures 15 and 16, respectively.

[0177] FIG. 15 illustrates an LMF-assisted sidelink positioning mobile-originated location request (MO-LR) procedure 1500 according to an aspect of the present disclosure. In particular, FIG. 15 illustrates an example of LMF-assisted sidelink positioning and ranging, where the LMF acts as an adjunct to UE B, which is in network coverage and initiates a sidelink positioning and ranging session. FIG. 15 includes actions 1 through 16, which are summarized as follows:

[0178] FIG. 15, operations 1 to 4: These are the same as operations 1 to 4 in FIG.

[0179] Figure 15, action 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 can indicate whether LMF assistance is required in the form of assistance data and / or location calculation.

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

[0181] Figure 15, action 7: If UE B requested location calculation assistance in action 5, the LMF sends an SLPP Location Information Request to UE B to request location measurement results consistent with all UE SL-PRS capabilities received in action 6b and any assistance data sent in action 6d.

[0182] FIG. 15, operations 8 to 11: These are the same as operations 5 to 8 in FIG.

[0183] FIG. 15, Action 12: If action 7 did not occur, initiating UE B may perform distance / position calculations using the location result received in action 11 and the location result UE B obtained in action 10.

[0184] FIG. 15, Action 13: If action 7 occurs, UE B provides the obtained location measurements from all participating UEs in the session to the LMF in a SLPP Provide Location Information message.

[0185] FIG. 15, action 14: The LMF performs distance / position calculations.

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

[0187] FIG. 15, action 16: The SLPP session may be terminated as described in FIG.

[0188] Referring to FIG. 15, in one aspect, MO-LR or new supplementary service operations for UE-initiated SLPP transactions towards the LMF may be supported.

[0189] FIG. 16 illustrates an LMF-initiated sidelink positioning for a Mobile Terminated Location Request (MT-LR) procedure 1600 according to an aspect of the present disclosure. FIG. 16 illustrates an example of an LMF-initiated sidelink positioning and ranging operation with a target UE (UE B) in network coverage to obtain an MT-LR location result. The MT-LR may have been triggered by an external client or AF (not shown in FIG. 16), which would have provided all necessary information for the MT-LR to the LMF (e.g., via GMLC and AMF). FIG. 16 includes actions 1 through 10, which are summarized as follows:

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

[0191] FIG. 16, Action 2: UE B attempts to discover other UEs A, C, D if they have not been discovered yet, as described in FIG. 9, and establishes SLPP sessions.

[0192] FIG. 16, Operation 3: UE B sends an SLPP Capability Request message to the group of one or more UEs established in Operation 2, requesting SL positioning capability from the UEs participating in this session.

[0193] FIG. 16, Action 4: The UE in Action 3 addressed by UE B responds with an SLPP Capability Provision message.

[0194] FIG. 16, Action 5: UE B may trigger an SLPP session modification procedure as described in FIG.

[0195] FIG. 16, Action 6: UE B confirms or acknowledges the supplementary service request from Action 1 with a supplementary service response, which may indicate whether the requested UEs are available for positioning (e.g., whether UEs A, C, and D have been discovered by UE B).

[0196] FIG. 16, Operation 7 Sidelink positioning / ranging is performed as in operations 5 to 10 in FIG. 13, operations 5 to 10 in FIG. 14, or operations 5 to 12 in FIG.

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

[0198] Figure 16, action 9: If not already included in action 8, the LMF performs distance / position calculations for the UE(s) and returns the location(s) to the external client or AF. For deferred (periodic or triggered) location, SLPP positioning by UE B and returning the location results to the LMF may be repeated.

[0199] FIG. 16, action 10: The SLPP session may be terminated as described in FIG.

[0200] Referring to FIG. 16, in one aspect, MT-LR or new supplementary service operations for LMF initiated SLPP transactions towards the UE may be supported.

[0201] In one aspect, the basic SLPP transaction types and procedures of Capability Transfer, Assistance Data Transfer, and Location Information Transfer are suitable for supporting in-coverage, partial coverage, and out-of-coverage sidelink positioning and ranging scenarios and can be applied to support joint sidelink-Uu positioning. This can be simply achieved by jointly executing the SLPP, LPP, and NRPPa procedures for the desired positioning method, as shown in Figure 17. For Uu-only positioning, LPP and NRPPa are used together 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(s) (UL, DL, SL positioning).

[0202] 17 illustrates a joint Uu-sidelink positioning procedure 1700 according to an embodiment of the present disclosure. FIG. 17 includes actions 1 to 7, which are summarized as follows:

[0203] FIG. 17, action 1: The LMF may obtain sidelink positioning capability from the target UE and may request a sidelink location result from the target UE.

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

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

[0206] FIG. 17, Action 4: The target device performs the sidelink positioning procedure as described in FIG. 13.

[0207] FIG. 17, action 5: The target device provides the SLPP location result to the LMF.

[0208] FIG. 17, operation 6: The target device provides the LMF with the LPP location result.

[0209] FIG. 17, action 7: The TRP provides the NRPPa location results to the LMF.

[0210] In one aspect, the procedural process 1700 of FIG. 17 may support hybrid / joint Uu (including RAT-independent methods) and sidelink positioning in the same manner as supported today with LPP (and possibly NRPPa). For example, several LPP positioning methods may be used for the same positioning session. The LMF knows that different positioning methods apply to the same positioning session. The UE does not know 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 the different positioning methods refer to the same or different LPP sessions. When both Uu and PC5-based procedures and signaling are used, from the perspective of the coordinating entity (in this case, the LMF), the Uu and PC5-based positioning procedures are part of the same positioning session. This method allows SLPP, LPP, and NRPPa to be defined and used independently, even if a coordinating entity such as the LMF can recognize a common positioning session. In particular, this means that SLPP signaling does not need to carry LPP session related information, and similarly, LPP signaling does not need to carry SLPP session related information, which can significantly reduce the impact of SLPP and LPP, the impact of standardization, and the requirements imposed on UEs and networks.

[0211] Referring to FIG. 17, in one aspect, hybrid Uu, SL, and RAT independent positioning may be supported by using SLPP, LPP, and NRPPa procedures together.

[0212] Referring to Figure 17, in one aspect, 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, decoding of the LPP message may need to be "sidelink-capable" even if this content is not supported. Similarly, if a sidelink positioning or ranging device (or LMF) does not need to support LPP positioning, it does not need to support LPP just for the sidelink positioning or ranging content. This allows for the definition of smaller protocols to reduce the memory footprint size for the Abstract Syntax Notation One (ASN.1) definition of the protocol and associated processing support. This can simplify the UE implementation when LPP does not need to be supported.

[0213] Referring to FIG. 17, in one aspect, using the LMF as an SLPP endpoint not only allows SLPP messages to be embedded into supplementary service operations (e.g., MT-LR, MO-LR, etc.), but also enables joint sidelink and Uu positioning with minimal changes to existing protocols.

[0214] Referring to FIG. 17, in one aspect, using an LMF as an SLPP endpoint enables sidelink-only positioning (with LMF support) without the requirement of LPP support, which reduces the complexity of sidelink-only capable positioning and ranging devices and the LMF.

[0215] Referring to Figure 17, in one aspect, specifying separate sidelink positioning functions within the SLPP does not require modifications to the LPP and therefore does not increase the LPP ASN.1 footprint for non-sidelink capable UEs and LMFs.

[0216] Referring to FIG. 17, in one aspect, the LMF may be a protocol endpoint for SLPP.

[0217] In one aspect, SLPP messages may be transmitted via broadcast, groupcast, or unicast, depending on the particular scenario. SLPP may indicate (e.g., in a common SLPP message header) the transaction (communication) mode to be used for each SLPP message, i.e., whether broadcast, groupcast, or unicast mode should be used. SLPP may support at least the following common transaction modes: Unicast Transactions Group Transaction with Group Response Group Transactions with Unicast Responses Broadcast Transactions

[0218] The exact API between the SLPP layer and the transport layer may be implementation dependent.

[0219] 18 illustrates an SLPP unicast transaction 1800 according to an aspect of the present disclosure. FIG. 18 includes actions 1-2, which are summarized as follows:

[0220] Figure 18, Action 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, transaction ID, and source and destination UE IDs (e.g., application layer ID, Layer 2 ID, SLPP UE ID), if applicable.

[0221] Figure 18, Action 2: If the SLPP message from action 1 requires a response, UE B sends an SLPP message to UE A with the SLPP mode set to "unicast" and the transaction ID and destination ID for UE A received in action 1.

[0222] 19 illustrates an SLPP group transaction 1900 using a group response according to an aspect of the present disclosure. FIG. 19 includes actions 1-2, which are summarized as follows:

[0223] Figure 19, Action 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-group response", indicating that the destination UEs may respond via groupcast, or set to "groupcast" if the SLPP message does not require a response. The message includes the SLPP session ID, transaction ID, and group ID (e.g., application layer group ID, Layer 2 group ID, or SLPP group ID), if applicable.

[0224] Figure 19, Action 2: If the SLPP message from action 1 received by destination UE B, C, D, etc. requires a response (SLPP mode set to "groupcast-group response"), UE B, C, D, etc. will send an SLPP message with SLPP mode set to "groupcast" (and therefore also returned to other UEs in the group). The message includes the session ID, transaction ID, if applicable, and the group ID received in action 1.

[0225] 20 illustrates an SLPP group transaction 2000 using a unicast response according to an aspect of the present disclosure. FIG. 20 includes actions 1-2, which are summarized as follows:

[0226] Figure 20, Action 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 response", indicating that the destination UEs may respond via unicast. If no response is required, the SLPP mode may indicate "groupcast". The message includes an SLPP session ID, transaction ID, and group ID (e.g., application layer group ID, Layer 2 group ID, or SLPP group ID), if applicable.

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

[0228] 21 illustrates an SLPP broadcast transaction 2100 according to an aspect of the present disclosure. FIG. 21 includes actions 1-2, which are summarized as follows:

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

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

[0231] 21, in one aspect, SLPP may indicate (e.g., in a common SLPP message header) the transaction (communication) mode to be used for each SLPP message, i.e., whether broadcast mode, groupcast mode, or unicast mode should be used. At least the following common transaction modes may be supported: Unicast Transactions Group Transaction with Group Response Group Transactions with Unicast Responses Broadcast transaction.

[0232] Note that not all SLPP message types may be permitted for all transaction modes.

[0233] In one aspect regarding SLPP functionality, to enable sidelink positioning, SLPP / RSPP may support at least the following functions: 1.SL positioning capability transfer 2. SL Positioning Assistance Data Exchange 3.SL location information transfer 4. Error Handling 5. Cancellation

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

[0235] The exchange of capabilities between different endpoints can be initiated by a request or sent as unsolicited information. When a request is used, an endpoint sends an SLPP Capability Request message using one of the allowed transaction modes with a request for capability information. The addressed endpoint(s) then respond with an SLPP Capability Offer message.

[0236] It should be noted that an endpoint may include one or more UEs or LMFs.

[0237] 22 illustrates an SLPP capability transfer procedure 2200 according to an aspect of the present disclosure. FIG. 22 includes actions 1-2, which are summarized as follows:

[0238] FIG. 22, Action 1: A transmitting endpoint may send a request for SLPP-related capabilities to one or more receiving endpoints using one of the SLPP transaction modes described above.

[0239] Figure 22, action 2: The receiving endpoint(s) transfer their SLPP-related capabilities to the transmitting endpoint using one of the SLPP transaction modes described above. The capabilities may refer to a specific positioning method or may be common to multiple positioning methods.

[0240] Referring to FIG. 22, in one aspect, the SLPP capability indication procedure is used for unsolicited capability transfer.

[0241] 23 illustrates an SLPP capability indication procedure 2300 according to an aspect of the present disclosure. FIG. 23 includes operation 1, which is summarized as follows:

[0242] FIG. 23, Action 1: A transmitting endpoint provides SLPP-related capabilities to one or more receiving endpoints using one of the SLPP transaction modes described above.

[0243] Referring to FIG. 23, in one aspect, the SLPP-related capabilities may include the general information summarized in Table 1 below.

[0244] [Table 1]

[0245] Referring to FIG. 23, in one aspect, the SLPP Capability Provision message may provide information regarding the device's capabilities 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 some UE role-specific features (e.g., the ability to act as a server or anchor UE, etc.).

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

[0247] 24 illustrates an SLPP-assisted data transfer procedure 2400 according to an aspect of the present disclosure. FIG. 24 includes operations 1-3, which are summarized as follows:

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

[0249] 24, Action 2: The receiving endpoint transfers the Assistance Data to the sending endpoint using one of the SLPP transaction modes described above. The transferred Assistance Data may match any Assistance Data requested in Action 1.

[0250] FIG. 24, Action 3: The receiving endpoint may forward the additional assistance data to the transmitting endpoint in one or more additional SLPP Provide Assistance Data messages.

[0251] Referring to FIG. 24, in one aspect, the SLPP assistance data delivery procedure is used for unsolicited assistance data transfer.

[0252] 25 illustrates an SLPP assistance data distribution procedure 2500 according to an aspect of the present disclosure. FIG. 25 includes actions 1-2, which are summarized as follows:

[0253] FIG. 25, Action 1: The transmitting endpoint transfers assistance data to one or more receiving endpoint(s) using one of the SLPP transaction modes described above.

[0254] FIG. 25, Action 2: The transmitting endpoint may forward the additional assistance data to the receiving UE(s) in one or more additional SLPP Provide Assistance Data messages.

[0255] Referring to FIG. 25, in one aspect, the assistance data may include the general information summarized in Table 2.

[0256] [Table 2]

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

[0258] The term "location information" applies to both actual position estimates and values ​​used in calculating position (SL positioning measurements). It can be delivered in response to a request or unsolicited.

[0259] 26 illustrates an SLPP location information transfer procedure 2600 according to an aspect of the present disclosure. FIG. 26 includes actions 1-3, which are summarized as follows:

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

[0261] 26, Action 2: In response to Action 1, the receiving endpoint(s) transfer location information to the sending endpoint using one of the SLPP transaction modes described above. The transferred location information may match the location information requested in Action 1.

[0262] Figure 26, Action 3: The receiving endpoint(s) may transfer additional location information to the sending endpoint in one or more additional SLPP Provide Location Information messages using one of the SLPP transaction modes described above.

[0263] Referring to FIG. 26, in one aspect, the SLPP location information delivery procedure is used for unsolicited location information transfer.

[0264] 27 illustrates an SLPP location information distribution procedure 2700 according to an aspect of the present disclosure. FIG. 27 includes actions 1-2, which are summarized as follows:

[0265] FIG. 27, Action 1: The transmitting endpoint transfers location information to one or more receiving endpoints using one of the SLPP transaction modes described above.

[0266] FIG. 27, action 2: The transmitting endpoint may transfer additional location information to one or more receiving endpoints using one of the SLPP transaction modes described above.

[0267] Table 3 shows the information contained in the signaling of FIG.

[0268] [Table 3]

[0269] Referring to FIG. 27, in one aspect, the SLPP Request / Provide Location Information message may enable an SLPP-enabled endpoint to request / provide location measurements or location estimates to participant UEs in a session.

[0270] An SLPP-enabled UE can initiate sidelink ranging and positioning sessions to other SLPP-enabled UEs. Initiation of an SLPP session by an SLPP-enabled UE can be unsolicited based on an application layer request for sidelink positioning and ranging results from one or more SLPP-enabled UEs.

[0271] 28 illustrates an SLPP create session request / accept / reject procedure 2800 according to an aspect of the present disclosure. FIG. 28 includes actions 1-3, which are summarized as follows:

[0272] 28, Action 1: A transmitting UE may send a request to one or more receiving UEs to create a sidelink ranging and positioning session. The create SLPP session request message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0273] 28, Action 2: The receiving UE(s) that choose to participate in the sidelink ranging and positioning session proposed by the transmitting UE respond to the transmitting UE with a Create SLPP Session Accept message. The Create SLPP Session Accept message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0274] 28, action 3: The receiving UE(s) that choose not to participate in the sidelink ranging and positioning session proposed by the transmitting UE respond to the transmitting UE with a Create SLPP Session Reject message. The Create SLPP Session Reject message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0275] Referring to FIG. 28, the SLPP Create Session Request / Accept / Reject message may include the general information summarized in Table 4 below.

[0276] [Table 4]

[0277] 28, in an aspect, a create SLPP session request message may enable an SLPP UE to request creation of a sidelink ranging and positioning session and provide information regarding the proposed sidelink ranging and positioning session, including SLPP and Layer 2 IDs. In an aspect, a create SLPP session accept message may enable an SLPP UE to accept an SLPP session proposed by an SLPP-enabled UE. In an aspect, a create SLPP session reject message may enable an SLPP UE to reject an SLPP session proposed by an SLPP-enabled UE.

[0278] An SLPP-enabled UE that has created a sidelink ranging and positioning session (SLPP session) to another SLPP-enabled UE may initiate that SLPP session for the SLPP-enabled UE that accepts the proposed SLPP session request.

[0279] 29 illustrates an SLPP session initiation request / response procedure 2900 according to an aspect of the present disclosure. FIG. 29 includes actions 1-2, which are summarized as follows:

[0280] 29, Action 1: A transmitting UE may initiate an SLPP session to one or more receiving UEs using an SLPP Session Start Request message. The SLPP Session Start Request message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0281] Figure 29, Action 2: The receiving UE(s) respond to the transmitting UE with an SLPP Session Start Response message. The SLPP Session Start Response message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0282] Referring to FIG. 29, the SLPP session initiation request / response message may include the general information summarized in Table 5 below.

[0283] [Table 5]

[0284] 29, in an aspect, the SLPP Session Start Request message may enable an SLPP UE to request the initiation of a proposed sidelink ranging and positioning session using a SLPP Session Create Request / Response message and provide information about the session-joining SLPP UEs. In an aspect, the SLPP Session Start Response message may enable an SLPP UE to acknowledge the initiation of the SLPP session.

[0285] An SLPP-enabled UE that has created and initiated a sidelink ranging and positioning session (SLPP session) to another SLPP-enabled UE can modify that SLPP session for any SLPP-enabled UE that accepts the proposed SLPP session.

[0286] 30 illustrates an SLPP session modify request / response procedure 3000 according to an aspect of the present disclosure. FIG. 30 includes actions 1-3, which are summarized as follows:

[0287] 30, Action 1: A transmitting UE may send a request to modify a sidelink ranging and positioning session (SLPP session) for SLPP UEs participating in the SLPP session. The SLPP session modification request message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0288] Figure 30, Action 2: The receiving UE(s) participating in the SLPP session that choose to accept the proposed session modification respond to the transmitting UE with an SLPP Session Modification Accept message. The SLPP Session Modification Accept message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0289] 30, Action 3: The receiving UE(s) participating in the SLPP session that choose not to participate in the sidelink ranging and positioning session proposed by the transmitting UE respond to the transmitting UE with an SLPP Session Modify Reject message. The SLPP Session Modify Reject message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0290] Referring to FIG. 30, the SLPP Session Modify Request / Accept / Reject message may include the general information summarized in Table 6 below.

[0291] [Table 6]

[0292] 30, in one aspect, an SLPP session modification request message may enable an SLPP UE to request modification of an existing SLPP session and may provide information about the proposed modified SLPP session and session participating SLPP UEs, including SLPP and Layer 2 IDs. In one aspect, an SLPP session modification accept message may enable an SLPP UE to accept an SLPP session modification proposed by an SLPP-enabled UE. In one aspect, an SLPP session modification reject message may enable an SLPP UE to reject an SLPP session modification proposed by an SLPP-enabled UE.

[0293] An SLPP-enabled UE that has created a sidelink ranging and positioning session (SLPP session) to another SLPP-enabled UE may terminate that SLPP session for the SLPP-enabled UEs participating in the SLPP session.

[0294] 31 illustrates an SLPP session termination request / response procedure 3100 according to an aspect of the present disclosure. FIG. 31 includes actions 1-2, which are summarized as follows:

[0295] 31, Action 1: A transmitting UE may terminate a sidelink ranging and positioning session (SLPP session) for an SLPP UE participating in the SLPP session by sending a Terminate SLPP Session Request message. The Terminate SLPP Session Request message may be sent by the transmitting UE using one of the SLPP transaction modes described above.

[0296] Figure 31, Action 2: The receiving UE(s) respond to the transmitting UE with a SLPP Session Termination Response message. The SLPP Session Termination Response message may be sent by the transmitting UE using one of the SLPP transaction modes described above. The receiving UE(s) deletes the SLPP Session ID and SLPP ID once the session is terminated.

[0297] Referring to FIG. 31, the SLPP Session Termination Request / Response message may include the general information summarized in Table 7 below.

[0298] [Table 7]

[0299] 31, in one aspect, a Terminate SLPP Session Request message may enable an SLPP UE to request termination of a sidelink ranging and positioning session. In one aspect, a Terminate SLPP Session Response message may enable an SLPP UE to acknowledge termination of an SLPP session.

[0300] In one aspect related to discovery for sidelink positioning, a discovery procedure is included in the sidelink positioning procedure for at least out-of-coverage scenarios. In one aspect, a discovery message may be used to carry information for target discovery and candidate selection for SL positioning UEs, including indications of at least the roles of anchor UE, target UE, and server UE. Various information about the anchor UE (e.g., location knowledge) may be indicated. In one aspect, UE role information is indicated in the discovery SLPP metafield. In one aspect, this may apply to both discovery modes and any message.

[0301] 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, SL-MO-LR) describe the LCS client and UE operations, respectively, for obtaining sidelink positioning / ranging results via PC5 for a group of n UEs (n≧2). For both the SL-MT-LR and SL-MO-LR procedures, the UE performs discovery via 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).

[0302] Structuring SLPP ASN.1 in a manner similar to LPP allows for reuse of existing LPP designs and facilitates commonality between the two designs. Specifically, SLPP messages may include common header information (e.g., session ID, UE ID, transaction ID, etc.) and a message body implementing individual SLPP transaction types (capability transfer, assistance data transfer, location information transfer, etc.). In one aspect, SLPP messages include a common header (e.g., including a session ID, UE ID, transaction ID, etc.) and a message body implementing individual SLPP transaction types (capability transfer, assistance data transfer, location information transfer, etc.). In LPP, each message body information element (IE) is a sequence of individual IEs applicable to all or individual positioning methods. For example, the LPP Capability Request message body includes the relevant IEs for each LPP positioning method (and similarly for all other LPP message body IEs) using the following ASN.1 definition:

[0303] [Table 8]

[0304] An implementation using this approach would have to compile the entire LPP ASN.1 even for a single supported positioning method. This is because each field in the sequence has an explicit ASN.1 definition (e.g., IECommonIEsRequestCapabilities, A-GNSS-RequestCapabilities, etc.). Therefore, the footprint size of the actual LPP encoder / decoder is the same regardless of which / how many positioning methods are supported by the device. This could be a potential problem and cost barrier for low-cost devices with limited memory to support only a small subset of the positioning methods they require. This issue was already discussed during Rel-14, when NB-IoT support was added to LPP.

[0305] Given that SLPP may evolve / grow in future releases, the SLPP ASN.1 design may allow for "selective ASN.1 compilation," where an implementation needs to compile ASN.1 only for the SLPP features that are supported. This may be achieved by grouping "SLPP features" into separate standalone modules. Using LPP as an example, each SLPP module / group could be an individual positioning method. Instead of using explicit ASN.1 definitions for each message body IE, it could be defined as a simple octet string. For example, the RequestCapabilities -r9-IE above could be defined in ASN.1 as follows:

[0306] [Table 9]

[0307] In one aspect, the positioning method IE will be defined in a separate ASN.1 PDU that is imported by the main SLPP PDU. In this way, any (sub)PDUs that contain unsupported positioning methods or features can be omitted from the protocol and do not need to be compiled in. Thus, the message encoder / decoder footprint size is reduced since it does not include the entire SLPP. Unsupported received IEs / messages are still decoded correctly (as octet strings) and ignored, just as in the case of explicit ASN.1 definitions. However, in the above example, the contents of unsupported octet strings do not need to be decoded separately.

[0308] An example structure using LPP as a baseline is provided below. Note that this does not mean that the SLPP must be structured like the LPP as shown. It is used only 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 (e.g., similar to LPP) to allow additional positioning methods to be added in future releases. In one aspect, the SLPP ASN.1 design may allow for "selective ASN.1 compilation." The entire SLPP functionality is divided into "groups," with each group defined as a separate ASN.1 module. A "group" may correspond to a positioning method, although other groupings may be possible. An implementation need only compile SLPP modules that contain supported "groups" (features, positioning methods, etc.).

[0309] An exemplary SLPP PDU ASN.1 structure for the SLPP-PDU definition is as follows:

[0310] [Table 10-1] [Table 10-2] [Table 10-3] [Table 10-4] [Table 10-5] [Table 10-6] [Table 10-7]

[0311] An exemplary SLPP PDU comment content is as follows:

[0312] [Table 11-1] [Table 11-2] [Table 11-3]

[0313] Exemplary SLPP PDU Method-A Contents are as follows:

[0314] [Table 12-1] [Table 12-2] [Table 12-3]

[0315] Exemplary SLPP PDU Method-B Contents are as follows:

[0316] [Table 13-1] [Table 13-2] [Table 13-3]

[0317] Exemplary SLPP PDU Method-C Contents are as follows:

[0318] [Table 14-1] [Table 14-2]

[0319] Sidelink ranging and positioning use cases involving multiple target UEs for the same positioning session may be supported, including sidelink ranging and positioning control use case support for groupcast or broadcast. In one aspect, at least unicast SLPP / RSPP "centralized" operation may be supported, i.e., one UE performs distance and / or position calculations based on measurements / location information for itself and / or other UEs. In one aspect, if it is determined to support group positioning, performing at least ranging with estimate calculations in multiple UEs is feasible.

[0320] In one aspect, it may be feasible to transmit at least the following positioning signaling for groupcast / broadcast (in addition to unicast): SL positioning capability SL positioning assistance data SL location information and measurements

[0321] In one aspect, group positioning may be utilized to collect location estimates for multiple target UEs (absolute positioning) or location estimates for multiple UE pairs (ranging / relative positioning) per LCS request, with at least part of the group management for group positioning being performed at the higher / application layer.

[0322] Regarding the overall signaling procedure for PC5-only positioning (including at least IC and OOC), the sidelink positioning procedure may include the following sequence of operations as a baseline between the LMF / Positioning Server UE / NG-RAN / Candidate Anchor UE(s) and the target UE(s): 1. Trigger Event 2. Sidelink Positioning Capability Exchange 3. Sidelink Positioning Assistance Data Transmission 4.SL positioning location information request 5. Measurement of SL-PRS 6. Location Calculation 7. SL positioning location information provision

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

[0324] In one aspect, the roles of anchor UE and target UE can be indicated in the sidelink positioning procedure in stage 2. The server UE can be further described, at least for the case where the server UE is separate from the target and anchor. In one aspect, a discovery procedure is included in the sidelink positioning procedure, at least for out-of-coverage scenarios.

[0325] Exemplary SLPP procedure operations and call flows consistent with the above aspects are described and shown below for UE-assisted (centralized) sidelink ranging and positioning, as well as for UE-based (distributed) sidelink ranging and positioning. These flows demonstrate sidelink ranging and positioning for a single target UE and for multiple target UEs, and show that the same SLPP messages and message sequences can be used regardless of whether a 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.

[0326] In one aspect, there has been some discussion and controversy 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 one UE and one location server (e.g., the LMF in the case of NR access), the location server is always assumed to control the LPP session (rather than the UE), and any association with distinct service requests (e.g., MO-LR supplementary service request or periodic triggered location supplementary service request) can be indicated or implied using the same correlation ID / routing ID value (in the case of a periodic triggered location supplementary service request) or at least association in time (in the case of an MO-LR supplementary service request). These restrictions and associations do not always apply to SLPP sessions between pairs or groups of UEs; any one UE (e.g., for V2X or MCX) may participate in multiple SLPP sessions with other UEs, in which case the service requirements and identities of the other UEs need to be precisely and unambiguously known for each SLPP session. This leads to the following assumption: additional SLPP messages may be required to manage SLPP sessions (e.g., for establishment, modification, and termination) and the services each session enables (e.g., location results). However, these additional SLPP messages may not be required in all cases, in which case the SLPP session may be implicitly defined in some other way (e.g., with respect to LPP) and then omitted.

[0327] Figure 32 illustrates a UE-assisted (centralized) sidelink-only positioning procedure 3200 for a single target UE according to an aspect of the present disclosure. Figure 32 illustrates a UE-assisted sidelink positioning session for a single target UE, in which a server UE (UE-A) initiates an SLPP session and performs position 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.

[0328] FIG. 32 shows an SLPP session including session establishment, session modification, and positioning actions, and includes operations 0 to 11 summarized as follows:

[0329] Figure 32, Action 0: The application layer in UE-A and other UEs may perform UE discovery, determine and verify required services, and perform group management (e.g., create a group including UEs A, B, E, F, and G). The application layer in UE-A also verifies that all of the UEs support SLPP. The application layer in UE-A may then request sidelink ranging and positioning results for the single target UE-B from the SLPP layer in UE-A and provide the SLPP layer in UE-A with an application layer ID and Layer 2 ID for each of UE-A-E, and with an application layer group ID and Layer 2 group ID for a group of one or more UEs A-E. Note: The exact API between the application layer and the SLPP layer may be considered implementation dependent.

[0330] FIG. 32, Action 1: The initiating UE (server UE-A) establishes an SLPP session (eg, as in FIG. 9) to make all participating UEs aware of each other.

[0331] Figure 32, Action 2: The initiating UE (server UE-A) sends an SLPP capability request message to a single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G). The SLPP capability request message may 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, groupcast, or broadcast, depending on the particular scenario.

[0332] 32, action 3: The single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) respond with an SLPP capability provision message to the initiating UE (server UE-A). The SLPP capability provision message may be sent to the initiating UE (server UE-A) by the single target UE (UE-B) and by the anchor UEs (UE-E, UE-F, UE-G) via unicast, groupcast, or broadcast, depending on the particular scenario.

[0333] FIG. 32, Action 4: The SLPP session may be modified (eg, as in FIG. 10) based on the capability information from Action 3 (eg, removal of UEs with incompatible capabilities such as SL positioning methods).

[0334] Figure 32, operation 5: The initiating UE (server UE-A) sends an SLPP Provide Assistance Data message to a single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G). The SLPP Provide Assistance Data message may be sent by the initiating UE (server UE-A) to a single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) via unicast, groupcast, or broadcast, depending on the particular scenario. The SLPP Provide Assistance Data message includes an SL-PRS configuration for each of the UEs in the session. After receiving the assistance data (or at an indicated start time included in the message), each UE in the session transmits its respective SL-PRS. The duration of the 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.

[0335] Figure 32, action 6: The initiating UE (server UE-A) sends an SLPP Location Information Request message to a single target UE (UE-B) and / or anchor UEs (UE-E, UE-F, UE-G) depending on the desired positioning method. The SLPP Location Information Request message may 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, groupcast, or broadcast depending on the particular scenario. The SLPP Location Information Request 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 distance / position calculation will be performed by the initiating UE (server UE-A).

[0336] Figure 32, action 7: Each participating UE performs the requested SL-PRS transmissions and measurements. Note: The server UE-A may participate in the sidelink positioning session through SL-PRS transmissions and measurements (e.g., also take on the role of anchor UE), or may only participate in managing the session and performing and disseminating position calculations.

[0337] Figure 32, operation 8: A 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. The SLPP Provide Location Information message may be sent to the initiating UE (server UE-A) by the single target UE (UE-B) and by the anchor UEs (UE-E, UE-F, UE-G) via unicast, groupcast, or broadcast, depending on the particular scenario. The SLPP Provide Location Information message may be sent upon completion of transmission and measurement, periodically, or after the response time received in operation 6 has expired, and may also include an indication of whether other UEs (in this case, the initiating server UE-A) are requested to provide location results (e.g., calculated distance and / or position) back to this UE. SL-PRS transmission and SL-PRS measurement may be performed periodically based on the configuration received in the Provide SLPP Assistance Data message.

[0338] FIG. 32, Operation 9: The initiating UE (server UE-A) performs distance / position calculation using the location result received in Operation 8 and the location result obtained by UE A in Operation 7.

[0339] 32, operation 10: If requested to distribute the location result in operation 8, the initiating UE (server UE-A) may distribute the location result by sending an SLPP Provide Location Information message to the single target UE-B. The SLPP Provide Location Information message may be sent by the initiating UE (server UE-A) to the single target UE (UE-B) via unicast, groupcast, or broadcast, depending on the particular scenario.

[0340] FIG. 32, action 11: The SLPP session may be terminated.

[0341] Figure 33 illustrates a UE-assisted (centralized) sidelink-only positioning procedure 3300 for multiple target UEs according to an aspect of the present disclosure. Figure 33 illustrates a UE-assisted sidelink positioning session for multiple target UEs, in which a server UE (UE-A) initiates an SLPP session and performs position calculations based on SL-PRS measurements received from multiple target UEs and the anchor UE. The SLPP message flow is identical to that shown in Figure 1 for UE-assisted sidelink positioning for a single target UE. Following UE discovery, the UE performs session establishment, capability and assistance data exchange, location information transfer, and session termination. Figure 33 includes actions 0 through 11, which are summarized as follows:

[0342] Figure 33, action 0: The application layer in UE-A and other UEs may perform UE discovery, determine and verify required services, and perform group management (e.g., create a group including UEs A-G). The application layer in UE-A also verifies that all of the UEs support SLPP. The application layer in UE-A may then request sidelink ranging and positioning results for multiple target UEs (UE-B, UE-C, UE-D) from the SLPP layer in UE-A and provide the SLPP layer in UE-A with an application layer ID and Layer 2 ID for each of UE-A-E, and with an application layer group ID and Layer 2 group ID for a group of one or more UEs A-E. Note: The exact API between the application layer and the SLPP layer may be considered implementation dependent.

[0343] FIG. 33, Action 1: The initiating UE (server UE-A) establishes an SLPP session (eg, as in FIG. 9) to make all participating UEs aware of each other.

[0344] Figure 33, Action 2: The initiating UE (server UE-A) sends an SLPP capability request message to multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G). The SLPP capability request 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, groupcast, or broadcast, depending on the particular scenario.

[0345] Figure 33, action 3: The multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) respond with an SLPP capability provision message to the initiating UE (server UE-A). The SLPP capability provision message may be sent to the initiating UE (server UE-A) by the multiple target UEs (UE-B, UE-C, UE-D) and by the anchor UEs (UE-E, UE-F, UE-G) via unicast, groupcast, or broadcast, depending on the particular scenario.

[0346] FIG. 33, Action 4: The SLPP session may be modified (eg, as in FIG. 10) based on the capability information from Action 3 (eg, removal of UEs with incompatible capabilities such as SL positioning methods).

[0347] Figure 33, operation 5: The initiating UE (server UE-A) transmits an SLPP Provide Assistance Data message to multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G). The Provide SLPP Assistance Data message may be transmitted 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, groupcast, or broadcast, depending on the specific scenario. The Provide SLPP Assistance Data message includes an SL-PRS configuration for each of the UEs participating in the SLPP session. After receiving the assistance data (or at an indicated start time included in the message), each UE in the session transmits its respective SL-PRS. The duration of the 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.

[0348] Figure 33, Action 6: The initiating UE (server UE-A) sends an SLPP Location Information Request 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. The SLPP Location Information Request message may 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, groupcast, or broadcast depending on the particular scenario. The SLPP Location Information Request 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 distance / position calculation will be performed by the initiating UE (server UE-A).

[0349] Figure 33, action 7: Each participating UE performs the requested SL-PRS transmissions and measurements. Note: The server UE-A may participate in the sidelink positioning session through SL-PRS transmissions and measurements (e.g., also take on the role of anchor UE), or it may only participate in managing the session and performing and disseminating position calculations.

[0350] Figure 33, operation 8: Multiple target UEs (UE-B, UE-C, UE-D) and anchor UEs (UE-E, UE-F, UE-G) respond with an SLPP Provide Location Information message to the initiating UE (server UE-A). The SLPP Provide Location Information message may be transmitted to the initiating UE (server UE-A) by the multiple target UEs (UE-B, UE-C, UE-D) and by the anchor UEs (UE-E, UE-F, UE-G) via unicast, groupcast, or broadcast, depending on the particular scenario. The SLPP Provide Location Information message may be transmitted upon completion of transmission and measurement, periodically, or after the response time received in operation 6 has expired, and may also include an indication of whether another UE (in this case, the initiating server UE-A) is requested to provide location results (e.g., calculated distance and / or position) back to this UE. SL-PRS transmission and SL-PRS measurement may be performed periodically based on the configuration received in the Provide SLPP Assistance Data message.

[0351] FIG. 33, Operation 9: The initiating UE (server UE-A) performs distance / position calculation using the location result received in Operation 8 and the location result obtained by UE B in Operation 7.

[0352] 33, operation 10: If requested to deliver the location result in operation 8, the initiating UE (server UE-A) may deliver the location result by sending an SLPP Provide Location Information message to multiple target UEs (UE-B, UE-C, UE-D). The SLPP Provide Location Information message may be sent by the initiating UE (server UE-A) to multiple target UEs (UE-B, UE-C, UE-D) via unicast, groupcast, or broadcast, depending on the particular scenario.

[0353] FIG. 33, action 11: The SLPP session may be terminated.

[0354] 33, the SLPP message and message call flow for a UE-assisted sidelink positioning session for multiple target UEs may be identical to the SLPP message 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.

[0355] Referring to Figure 33, in one aspect, if an SLPP positioning session is constrained to support only a single target UE, an application layer request to perform sidelink positioning for multiple target UEs requires as many SLPP positioning sessions as there are target UEs. Each separate session requires its own separate capability negotiation, assistance data exchange, SL-PRS configuration, SL-PRS transmission, and location information transfer, resulting in a much less efficient and longer sidelink positioning transaction than if the SLPP session supported multiple target UEs. In one aspect, if an SLPP session does not support multiple target UEs, an application layer request to position multiple UEs requires as many SLPP sessions as there are target UEs. Each SLPP session requires its own capability negotiation, assistance data exchange, SL-PRS configuration, SL-PRS transmission, and location information exchange. The resulting positioning sessions are inefficient in resource utilization and require a longer time to complete compared to sessions supporting multiple target UEs.

[0356] FIG. 34 illustrates a UE-assisted (centralized) sidelink-only ranging procedure 3400 for a single target UE according to an embodiment of the present disclosure. FIG. 35 illustrates a UE-assisted (centralized) sidelink-only ranging procedure 3500 for multiple target UEs according to an embodiment of the present disclosure. In FIGS. 34-35, the server UE (UE-A) performs distance calculations based on SL-PRS measurements received from a single target UE or 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 identical to the flows shown in FIGS. 32-33 for UE-assisted sidelink positioning for a single target UE and multiple target UEs, respectively. Following UE discovery, the UE performs session establishment, capability and assistance data exchange, location information transfer, and session termination. Each of FIGS. 34-35 includes actions 0-11, which are summarized as follows:

[0357] 34-35, Action 0: The application layer in UE-A and other UEs may perform UE discovery, determine and verify required services, and perform group management (e.g., create a group including UE A and UE B, or a group including UEs A-D). The application layer in UE-A also verifies that all of the UEs support SLPP. The application layer in UE-A may then request sidelink ranging and positioning results for the single target UE-B from the SLPP layer in UE-A and provide the SLPP layer in UE-A with an application layer ID and Layer 2 ID for each of UE-A-E, and with an application layer group ID and Layer 2 group ID for a group of one or more UEs A-E. Note: The exact API between the application layer and the SLPP layer may be considered implementation dependent.

[0358] 34-35, Operation 1: The initiating UE (server UE-A) establishes an SLPP session (eg, as in FIG. 9) to make all participating UEs aware of each other.

[0359] 34-35, Action 2: Initiating UE (Server UE-A) sends an SLPP Capability Request message. Single Target UE: The SLPP Capability Request message is sent by the initiating UE (Server UE-A) to a single target UE-B. Multiple Target UEs: The SLPP Capability Request message is sent by the initiating UE (Server UE-A) to multiple target UEs (UE-B, UE-C, UE-D). The SLPP Capability Request 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, groupcast, or broadcast, depending on the particular scenario.

[0360] 34-35, Operation 3: SLPP Capability Provision: Single Target UE: A single target UE (UE-B) responds to the initiating UE (server UE-A) with an SLPP Capability Provision message. Multiple Target UEs: Multiple target UEs (UE-B, UE-C, UE-D) respond to the initiating UE (server UE-A) with an SLPP Capability Provision message. The SLPP Capability Provision message can be sent via unicast, groupcast, or broadcast by a single target UE (UE-B) to the initiating UE (server UE-A) or by multiple target UEs (UE-B, UE-C, UE-D) to the initiating UE (server UE-A), depending on the particular scenario.

[0361] Figures 34-35, Operation 4: The SLPP session may be modified (e.g., as in Figure 10) based on capability information from Operation 3 (e.g., removal of UEs with incompatible capabilities such as SL positioning methods, anchor capabilities, etc.).

[0362] 34-35, Operation 5: The initiating UE (server UE-A) transmits an SLPP Provide Assistance Data message. Single target UE: The SLPP Provide Assistance Data message is transmitted by the initiating UE (server UE-A) to target UE-B. Multiple target UEs: The SLPP Provide Assistance Data message is transmitted by the initiating UE (server UE-A) to multiple target UEs (UE-B, UE-C, UE-D) established in operation 1 or 4. The SLPP Provide Assistance Data message may be transmitted by the initiating UE (server UE-A) via unicast, groupcast, or broadcast to a single target UE (UE-B) or multiple target UEs (UE-B, UE-C, UE-D), depending on the specific scenario. The SLPP Provide Assistance Data message includes the SL-PRS configuration for each of the UEs 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 respective SL-PRS. The duration of the SL-PRS transmission may be controlled by a timer provided in the message, or may continue until the SLPP session is terminated in act 11.

[0363] 34-35, Action 6: The initiating UE (server UE-A) sends an SLPP Location Information Request message. Single target UE: The SLPP Location Information Request message is sent by the initiating UE (server UE-A) to target UE-B. Multiple target UEs: The SLPP Location Information Request message is sent by the initiating UE (server UE-A) to multiple target UEs (UE-B, UE-C, UE-D). The SLPP Location Information Request message may 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, groupcast, or broadcast, depending on the particular scenario. The SLPP Location Information Request 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 distance / position calculations will be performed by the initiating UE (server UE-A).

[0364] 34-35, Action 7: Each participating UE performs the requested SL-PRS transmission and measurements.

[0365] 34-35, Operation 8: SLPP Provide Location Information: Single Target UE: A single target UE (UE-B) responds to the initiating UE (server UE-A) with an SLPP Provide 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 Provide Location Information message. The SLPP Provide Location Information message may be sent via unicast, groupcast, or broadcast by a single target UE (UE-B) to the initiating UE (server UE-A) or by multiple target UEs (UE-B, UE-C, UE-D) to the initiating UE (server UE-A), depending on the particular scenario. The SLPP Provide Location Information message may be sent upon completion of transmission and measurement, periodically, or after the response time received in operation 6 has expired, and may also include an indication of whether other UEs (in this case, the initiating server UE-A) are requested to provide location results (e.g., calculated distance and / or position) back to this UE. SL-PRS transmissions and SL-PRS measurements may be performed periodically based on the configuration received in the SLPP Provide Assistance Data message.

[0366] 34-35, Operation 9: The initiating UE (server UE-A) performs distance / position calculation using the location result received in Operation 8 and the location result obtained by UE B in Operation 7.

[0367] 34-35, Operation 10: If disseminating the location result is requested in Operation 8, the initiating UE (server UE-A) can disseminate the location result 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) to a single target UE-B. Multiple target UEs: The SLPP Provide Location Information message is sent by the initiating UE (server UE-A) to multiple target UEs (UE-B, UE-C, UE-D). 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, groupcast, or broadcast, depending on the specific scenario.

[0368] 34-35, Action 11: The SLPP session may be terminated.

[0369] 34-35 show that the SLPP message and message call flow for an SLPP UE-assisted sidelink ranging session for multiple target UEs can be identical to the SLPP message and message call flow for an SLPP UE-assisted sidelink ranging session for a single target UE. Furthermore, the SLPP message and message call flow for an SLPP UE-assisted sidelink ranging session for a single or multiple target UEs is identical to the SLPP message and message flow for an SLPP UE-assisted sidelink positioning session for a single or multiple target UEs.

[0370] Referring to Figures 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 messages and SLPP message call flow.

[0371] Referring to Figures 34-35, in one aspect, the same SLPP messages and SLPP message call flow are used for 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 multiple target UEs.

[0372] 34-35, in one aspect, for UE-assisted sidelink ranging, if an SLPP ranging session is constrained to support only a single target UE, as in the case of UE-assisted sidelink positioning, an application layer request to perform sidelink ranging for multiple target UEs would 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 transfer. The resulting multiple ranging sessions are much less efficient and incur higher latency for determining multiple ranges than if the SLPP ranging session supported multiple target UEs.

[0373] Referring to Figures 34-35, in one aspect, if an SLPP session does not support multiple target UEs, an application layer request for ranging multiple UEs requires as many SLPP sessions as there are target UEs, with each SLPP session including its own capability negotiation, assistance data exchange, SL-PRS configuration, SL-PRS transmission, and location information exchange, resulting in a resource-inefficient, time-extended sidelink ranging session.

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

[0375] FIG. 36, operations 0 to 5: are the same as FIG.

[0376] Figure 36, action 6: The initiating UE (server UE-A) sends an SLPP Location Information Request message to a single target UE-B and / or anchor UEs (UE-E, UE-F, UE-G) depending on the desired positioning method. The SLPP Location Information Request message may be sent by the initiating UE (server UE-A) to a single target UE (UE-B) and anchor UEs (UE-E, UE-F, UE-G) via unicast, groupcast, or broadcast depending on the particular scenario. The SLPP Location Information Request 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 distance / position calculations should be performed by each of the participating UEs (initiating server UE-A and target UEs).

[0377] Figure 36, action 7: Each participating UE performs the requested SL-PRS transmissions and measurements. Note: The server UE-A may participate in the sidelink positioning session through SL-PRS transmissions and measurements (e.g., also take on the role of anchor UE), or may only participate in managing the session and performing and disseminating position calculations.

[0378] Figure 36, operation 8: A single target UE (UE-B), an initiating UE (server UE-A), and an anchor UE (UE-E, UE-F, UE-G) transmit an SLPP Provide Location Information message. The SLPP Provide Location Information message may be transmitted 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, groupcast, or broadcast, depending on the particular scenario. The SLPP Provide Location Information message may be transmitted upon completion of transmission and measurement, periodically, or after the response time received in operation 6 has expired, and may also include an indication of whether other UEs are requested to provide location results (e.g., calculated distance and / or position) back to the transmitting UE. SL-PRS transmission and SL-PRS measurement may be performed periodically based on the configuration received in the Provide SLPP Assistance Data message.

[0379] FIG. 36, Operation 9: Each participating UE performs a distance / position calculation using the location result received in Operation 8 and its own location result obtained in Operation 7.

[0380] 36, action 10: If requested in action 8, each UE may distribute its location results to other UEs in this session by sending an SLPP Provide Location Information message. The SLPP Provide Location Information message may be sent by a single target UE (UE-B), the initiating UE (server UE-A), and the anchor UEs (UE-E, UE-F, UE-G) via unicast, groupcast, or broadcast, depending on the particular scenario.

[0381] FIG. 36, action 11: The SLPP session may be terminated.

[0382] FIG. 37 illustrates a UE-based (distributed) sidelink-only positioning—multiple target UEs procedure 3700 according to an aspect of the present disclosure. FIG. 37 illustrates a UE-based sidelink positioning session for multiple target UEs, where a server UE (UE-A) initiates the SLPP session and subsequent position calculations are performed by participating UEs based on SL-PRS measurements received from multiple target UEs and anchor UEs. Following UE discovery, the SLPP message flow consists of session establishment, capability and assistance data exchange, location information transfer, and session termination. FIG. 37 includes actions 0 through 11, which are summarized as follows:

[0383] Figure 37, Actions 0 to 5: Same as Figure 33

[0384] Figure 37, action 6: The initiating UE (server UE-A) sends an SLPP location information request 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. The SLPP location information request message may 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, groupcast, or broadcast depending on the particular scenario. The SLPP location information request 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 distance / position calculations should be performed by each of the participating UEs (initiating server UE-A and target UEs).

[0385] Figure 37, action 7: Each participating UE performs the requested SL-PRS transmissions and measurements. Note: The server UE-A may participate in the sidelink positioning session through SL-PRS transmissions and measurements (e.g., also take on the role of anchor UE), or it may only participate in managing the session and performing and disseminating position calculations.

[0386] Figure 37, operation 8: 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) transmit SLPP Provide Location Information messages. The SLPP Provide Location Information messages 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, groupcast, or broadcast, depending on the particular scenario. The SLPP Provide Location Information messages may be transmitted upon completion of transmission and measurement, periodically, or after the response time received in operation 6 expires, and may also include an indication of whether other UEs are requested to provide location results (e.g., calculated distances and / or positions) back to the transmitting UE. SL-PRS transmissions and SL-PRS measurements may be performed periodically based on the configuration received in the Provide SLPP Assistance Data message.

[0387] FIG. 37, Operation 9: Each participating UE performs a distance / position calculation using the location result received in Operation 8 and its own location result obtained in Operation 7.

[0388] Figure 37, action 10: If requested in action 8, each UE may distribute its location results to other UEs in this session by sending an SLPP Provide Location Information message. 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, groupcast, or broadcast, depending on the particular scenario.

[0389] FIG. 37, action 11: The SLPP session may be terminated.

[0390] As shown in Figure 37, the SLPP message and message call flow for a UE-based sidelink positioning session for multiple target UEs may be identical to the SLPP message and message call flow for a UE-based sidelink positioning session for a single target UE. Furthermore, both UE-based and UE-assisted sidelink positioning 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.

[0391] Referring to FIG. 37, in 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.

[0392] Referring to FIG. 37, in one aspect, an 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.

[0393] FIG. 38 illustrates a UE-based (distributed) sidelink-only ranging procedure 3800 for a single target UE according to an embodiment of the present disclosure. FIG. 39 illustrates a UE-based (distributed) sidelink-only ranging procedure 3900 for multiple target UEs according to an embodiment of the present disclosure. FIGS. 38-39 illustrate UE-based sidelink ranging for a single target UE and multiple target UEs, where a server UE (UE-A) initiates an SLPP session and subsequent distance 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 to a single target UE and ranging to multiple target UEs, and is identical to the flows shown in FIGS. 36 and 37 for UE-based sidelink positioning for a single target UE and multiple target UEs, respectively. Following UE discovery, the UE performs session establishment, capability and assistance data exchange, location information transfer, and session termination. Each of FIGS. 38-39 includes operations 0-11, summarized as follows:

[0394] 38-39, Actions 0-5: Same as in FIGS. 34-35.

[0395] 38-39, Action 6: Initiating UE (Server UE-A) Sends SLPP Location Information Request Message: Single Target UE: The SLPP Location Information Request message is sent by the initiating UE (Server UE-A) to target UE-B. Multiple Target UEs: The SLPP Location Information Request message is sent by the initiating UE (Server UE-A) to multiple target UEs (UE-B, UE-C, UE-D). The SLPP Location Information Request message may 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, groupcast, or broadcast, depending on the particular scenario. The SLPP Location Information Request 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 distance / position calculations should be performed by each of the participating UEs (initiating Server UE-A and target UEs).

[0396] 38-39, Action 7: Each participating UE performs the requested SL-PRS transmission and measurements.

[0397] 38-39, Operation 8: SLPP Provide Location Information: Single Target UE: A single target UE (UE-B) and the initiating UE (server UE-A) transmit an SLPP Provide Location Information message. Multiple Target UEs: Multiple target UEs (UE-B, UE-C, UE-D) and the initiating UE (server UE-A) transmit an SLPP Provide Location Information message. The SLPP Provide Location Information message may be sent via unicast, groupcast, or broadcast by a single target UE (UE-B) to the initiating UE (server UE-A) or by multiple target UEs (UE-B, UE-C, UE-D) to the initiating UE (server UE-A), depending on the particular scenario. The SLPP Provide Location Information message may be sent upon completion of transmission and measurement, periodically, or after the response time received in operation 6 has expired, and may also include an indication of whether another UE (in this case, the initiating server UE-A) is requested to provide location results (e.g., calculated distance and / or position) back to this UE. SL-PRS transmissions and SL-PRS measurements may be performed periodically based on the configuration received in the SLPP Provide Assistance Data message.

[0398] 38-39, Operation 9: Each participating UE performs distance / position calculation using the location result received in Operation 8 and its own location result obtained in Operation 7.

[0399] 38-39, action 10: If requested in action 8, each UE may distribute its location results to other UEs in this 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). The SLPP Provide Location Information message can be sent by the initiating UE (server UE-A) to a single target UE (UE-B) or by multiple target UEs (UE-B, UE-C, UE-D) via unicast, groupcast, or broadcast, depending on the particular scenario.

[0400] 38-39, Action 11: The SLPP session may be terminated.

[0401] In one aspect, Figures 38-39 demonstrate that the SLPP messages and message sequences may be the same regardless of whether an SLPP session is established to range / position a single target UE or whether an SLPP session is established to range / position a set of multiple target UEs. In one aspect, there is no difference in SLPP signaling between an SLPP session for a single target UE and an SLPP session for multiple target UEs. Furthermore, conducting an SLPP session to support only a single target UE may be unnecessary and may require any ranging / positioning session involving two or more target UEs to invoke multiple SLPP sessions. The resulting performance may be inefficient in the use of radio resources and may extend the time required to obtain distance and / or location results.

[0402] Referring to Figures 38-39, in one aspect, the same SLPP messages and the same SLPP message sequence may be used regardless of whether an SLPP session is established to range and / or position a single target UE or whether an SLPP session is established to range and / or position a set of multiple target UEs.

[0403] Referring to Figures 38-39, in one aspect, invoking multiple SLPP sessions to range and / or position a set of multiple target UEs consumes more radio resources and requires a longer period of time to obtain distance / location results for all UEs than involving a single SLPP session including the set of multiple target UEs.

[0404] 38-39 , in one aspect, sidelink ranging / positioning for one or more groups of UEs (a set of multiple target UEs) may be applicable to various use cases, including IIoT, commercial, public safety, and V2X. In particular, V2X use cases may involve large groups of UEs that may be involved in sidelink ranging / positioning. In one aspect, the same SLPP messages and SLPP message sequences may apply to a single target UE and to multiple target UEs, thus eliminating the additional burden on specification development due to supporting multiple target UEs. In one aspect, SLPP supports a single target UE or multiple target UEs within the same SLPP ranging / positioning session.

[0405] In some designs, the unicast link establishment signaling overhead and the requirement for at least as many unicast links as UE participants (in the case of centralized operation, (n-1) unicast links are required) significantly limit the scalability of unicast as a general solution for sidelink positioning and ranging. This can be understood for the V2X use case, an important use case invoked in SID. As the number of participating UEs (vehicles) increases, the number of additional unicast links required increases, resulting in increased signaling overhead, bandwidth consumption, and latency, thereby reducing efficiency and limiting the number of participants. For example, in high-traffic conditions, there may be many more V2X UEs than shown in Figure 8C. For public safety, commercial, and IIOT use cases, performance over unicast will be affected as the number of UEs involved in sidelink positioning and ranging increases. For this reason, groupcast / broadcast for sidelink positioning and ranging may be beneficial for various use cases. Such use cases may involve a roadside unit (RSU) and multiple vehicles, or multiple vehicles in a platoon. Furthermore, MCX services that rely on group communication also benefit from groupcast / broadcast signaling support. Additionally, for ranging-based services, there are multiple use cases involving a group of UEs performing ranging / sidelink positioning services, e.g., a museum tour.

[0406] In one aspect, PC5-U has well-defined Quality of Service (QoS) management procedures that allow upper layers to specify precise QoS requirements to the AS layer. PC5-U supports QoS through a mapping of 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 allowing flexibility in the specification of QoS for different use cases. This is in contrast to the PDCP approach, where only default QoS settings can be applied to assigned SRBs. There is no mechanism to differentiate messages sent over SRBs with regard to QoS (all use the same default QoS).

[0407] In one aspect, for cast type support, SLPP transport over PC5-U as a payload on the V2X / ProSe layer allows existing procedures for cast type specification to be reused. In this case, no additional standard specification work is required. In contrast, for SLPP over PDCP, new procedures for cast type handling and specification may need to be developed.

[0408] In one aspect, for point-to-point, point-to-many, and many-to-one cases, sidelink positioning / ranging PC5-U provides flexibility in QoS, cast type, and reduced link establishment latency, with minimum standard specification work required. In one aspect, no modifications to the PC5 reference point for SLPP transport over the PC5 user plane are required.

[0409] In addition to the total number of UEs communicating over the sidelink at any one time, the rate of change of the number of UEs communicating over the sidelink also affects scalability. For example, if traffic (number of vehicles) increases over time interval T, an RSU may be required to establish communication with each new vehicle over time interval T. The rate at which new connections must be established is N / T (where N is the number of vehicles entering the intersection during T). In that case, a solution that allows connections to be established (and released) faster is preferable.

[0410] Aspects of the present disclosure are directed to SLPP session establishment procedures. In current designs, sidelink positioning session establishment procedures are not defined in relevant standards and are instead left to implementation. Such aspects related to SLPP session establishment procedures may provide various technical advantages, such as reliable SLPP session establishment, which may provide improved position estimation accuracy, position estimation latency, etc.

[0411] 40A, 40B, and 40C illustrate several example components (represented by corresponding blocks) that may be incorporated within a UE 4002 (which may correspond to any of the UEs described herein), a base station 4004 (which may correspond to any of the base stations described herein), and a network entity 4006 (which may correspond to or embody any of the network functions described herein, including a location server and an LMF, or alternatively, may be independent of the NG-RAN and / or 5GC infrastructure, such as a private network) to support the operations described herein. It will be understood that these components may be implemented in different types of devices in different implementations (e.g., within an ASIC, within a system-on-chip (SoC), etc.). The illustrated components may also be incorporated into other devices in a communication system. For example, other devices in the system may include components similar to the illustrated components to provide similar functionality. Also, a given device may include one or more of the 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.

[0412] The UE 4002 and the base station 4004 each include one or more wireless wide area network (WWAN) transceivers 4010 and 4050, respectively, providing means for communicating (e.g., means for transmitting, means for receiving, means for measuring, means for tuning, means for refraining from transmitting, etc.) over one or more wireless communications networks (not shown), such as an NR network, an LTE network, a GSM network, etc. The WWAN transceivers 4010 and 4050 may 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., over at least one designated RAT (e.g., NR, LTE, GSM, etc.) over a wireless communications medium of interest (e.g., some set of time / frequency resources in a particular frequency spectrum). The WWAN transceivers 4010 and 4050 may be variously configured to transmit and encode signals 4018 and 4058, respectively (e.g., messages, indications, information, etc.), and conversely, to receive and decode signals 4018 and 4058, respectively (e.g., messages, indications, information, pilots, etc.) in accordance with a designated RAT. Specifically, the WWAN transceivers 4010 and 4050 include one or more transmitters 4014 and 4054, respectively, to transmit and encode signals 4018 and 4058, respectively, and include one or more receivers 4012 and 4052, respectively, to receive and decode signals 4018 and 4058, respectively.

[0413] The UE 4002 and base station 4004 also each, at least in some cases, include one or more short-range wireless transceivers 4020 and 4060, respectively. The short-range wireless transceivers 4020 and 4060 may be connected to one or more antennas 4026 and 4066, respectively, and may provide means for communicating (e.g., means for transmitting, means for receiving, means for measuring, means for tuning, means for refraining from transmitting, etc.) with other network nodes, such as other UEs, access points, base stations, etc., 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.) over a target wireless communications medium. The short-range wireless transceivers 4020 and 4060 may be variously configured to transmit and encode signals 4028 and 4068, respectively (e.g., messages, indications, information, etc.), and conversely, to receive and decode signals 4028 and 4068, respectively (e.g., messages, indications, information, pilots, etc.) in accordance with a specified RAT. Specifically, the short-range wireless transceivers 4020 and 4060 include one or more transmitters 4024 and 4064, respectively, to transmit and encode signals 4028 and 4068, respectively, and include one or more receivers 4022 and 4062, respectively, to receive and decode signals 4028 and 4068, respectively.As specific examples, the short-range wireless transceivers 4020 and 4060 may 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.

[0414] The UE 4002 and base station 4004 also, in at least some cases, include satellite signal receivers 4030 and 4070. The satellite signal receivers 4030 and 4070 may be connected to one or more antennas 4036 and 4076, respectively, and may provide a means for receiving and / or measuring satellite positioning / communication signals 4038 and 4078, respectively. If the satellite signal receivers 4030 and 4070 are satellite positioning system receivers, the satellite positioning / communication signals 4038 and 4078 may be global positioning system (GPS) signals, global navigation satellite system (GLONASS) signals, Galileo signals, Beidou signals, Navigation Satellite System of India (NAVIC), Quasi-Zenith Satellite System (QZSS), etc. If satellite signal receivers 4030 and 4070 are non-terrestrial network (NTN) receivers, satellite positioning / communications signals 4038 and 4078 may be communication signals (e.g., carrying control and / or user data) originating from a 5G network. Satellite signal receivers 4030 and 4070 may include any suitable hardware and / or software for receiving and processing satellite positioning / communications signals 4038 and 4078, respectively. Satellite signal receivers 4030 and 4070 may request information and action from other systems as appropriate and, in at least some cases, perform calculations to determine the locations of UE 4002 and base station 4004, respectively, using the obtained measurements according to any suitable satellite positioning system algorithms.

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

[0416] A transceiver may be configured to communicate over a wired link or a wireless link. The transceiver (whether a wired transceiver or a wireless transceiver) includes transmitter circuitry (e.g., transmitters 4014, 4024, 4054, 4064) and receiver circuitry (e.g., receivers 4012, 4022, 4052, 4062). In some implementations, the transceiver may be an integrated device (e.g., embodying the transmitter circuitry and the receiver circuitry within a single device), in some implementations may comprise separate transmitter circuitry and separate receiver circuitry, or in other implementations may be embodied in other ways. The transmitter and receiver circuitry of a wired transceiver (e.g., network transceivers 4080 and 4090 in some implementations) may be coupled to one or more wired network interface ports. The 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 an antenna array that enables the respective device (e.g., UE 4002, base station 4004) to perform transmit "beamforming," as described herein. Similarly, the wireless receiver circuitry (e.g., receivers 4012, 4022, 4052, 4062) may include or be coupled to multiple antennas (e.g., antenna arrays) that enable the respective device (e.g., UE 4002, base station 4004) to perform receive beamforming, as described herein. In one aspect, the transmitter and receiver circuitry may share multiple identical antennas (e.g., antennas 4016, 4026, 4056, 4066) such that each device can only receive or transmit at a given time, but not both at the same time. The wireless transceivers (e.g., WWAN transceivers 4010 and 4050, short-range wireless transceivers 4020 and 4060) may also include a network listen module (NLM) or the like for performing various measurements.

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

[0418] The UE 4002, base station 4004, and network entity 4006 also include other components that may be used in conjunction with operations as disclosed herein. The UE 4002, base station 4004, and network entity 4006 each include one or more processors 4032, 4084, and 4094, for example, to provide functionality related to wireless communications and to provide other processing functionality. Accordingly, the processors 4032, 4084, and 4094 may provide processing means, such as determining means, calculating means, receiving means, transmitting means, and directing means. In one aspect, the processors 4032, 4084, and 4094 may 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.

[0419] The UE 4002, the base station 4004, and the network entity 4006 include memory circuitry implementing memories 4040, 4086, and 4096, respectively (e.g., each including a memory device) for maintaining information (e.g., information indicating reserved resources, thresholds, parameters, etc.). Thus, the memories 4040, 4086, and 4096 may comprise means for storing, means for retrieving, means for maintaining, etc. In some cases, the UE 4002, the base station 4004, and the network entity 4006 may comprise SLPP components 4042, 4088, and 4098, respectively. The SLPP components 4042, 4088, and 4098 may be hardware circuits that are part of or coupled to the processors 4032, 4084, and 4094, respectively, and that, when executed, cause the UE 4002, the base station 4004, and the network entity 4006 to perform the functions described herein. In other aspects, the SLPP components 4042, 4088, and 4098 may 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 may be memory modules stored in memories 4040, 4086, and 4096, respectively, that, when executed by the processors 4032, 4084, and 4094 (or 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. FIG. 40A illustrates possible locations of the SLPP component 4042, which may be part of, for example, one or more WWAN transceivers 4010, memory 4040, one or more processors 4032, or any combination thereof, or may be a standalone component. FIG. 40B shows possible locations of the SLPP component 4088, which may be, for example, part of one or more WWAN transceivers 4050, memory 4086, one or more processors 4084, or any combination thereof, or may be a standalone component.FIG. 40C shows possible locations of the SLPP component 4098, 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 stand-alone component.

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

[0421] Additionally, the UE 4002 comprises a user interface 4046 that provides an indication to a user (e.g., an audio and / or visual indication) and / or provides a means for receiving user input (e.g., upon user actuation of a sensing device such as a keypad, touch screen, microphone, etc.). Although not shown, the base station 4004 and the network entity 4006 may also comprise user interfaces.

[0422] Referring more particularly to the one or more processors 4084, on the downlink, IP packets from the network entity 4006 may be provided to the processor 4084. The one or more processors 4084 may implement functionality for an RRC layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, and a Medium Access Control (MAC) layer. The one or more processors 4084 may provide RRC layer functionality associated with broadcasting system information (e.g., master information block (MIB), system information blocks (SIBs)), 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 functionality associated with header compression / decompression, security (encryption, decryption, integrity protection, integrity verification), and handover support functions; RLC layer functionality associated with forwarding upper layer PDUs, error correction via automatic repeat request (ARQ), concatenation, segmentation, and reassembly of RLC service data units (SDUs), re-segmentation of RLC data PDUs, and reordering of RLC data PDUs; and MAC layer functionality associated with mapping between logical channels and transport channels, scheduling information reporting, error correction, priority handling, and logical channel prioritization.

[0423] The transmitter 4054 and receiver 4052 may implement Layer-1 (L1) functionality associated with various signal processing functions. Layer-1, including the physical (PHY) layer, may include error detection on transport channels, forward error correction (FEC) coding / decoding of transport channels, interleaving, rate matching, mapping onto physical channels, modulation / demodulation of physical channels, and MIMO antenna processing. The transmitter 4054 handles mapping to signal constellations 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 may then be split into parallel streams. Each stream may then be mapped to orthogonal frequency division multiplexing (OFDM) subcarriers, multiplexed with a reference signal (e.g., pilot) in the time and / or frequency domain, and then combined together using an inverse fast Fourier transform (IFFT) to generate a physical channel carrying a time-domain OFDM symbol stream. The OFDM symbol stream is spatially precoded to generate multiple spatial streams. Channel estimates from a channel estimator may be used to determine the coding and modulation scheme and for spatial processing. The channel estimates may be derived from a reference signal and / or channel condition feedback transmitted by the UE 4002. Each spatial stream may then be provided to one or more different antennas 4056. The transmitter 4054 may modulate an RF carrier with each spatial stream for transmission.

[0424] In the UE 4002, a receiver 4012 receives signals through its respective antenna(s) 4016. The receiver 4012 recovers information modulated onto RF carriers and provides the information to one or more processors 4032. The transmitter 4014 and receiver 4012 implement Layer 1 functionality associated with various signal processing functions. The receiver 4012 may perform spatial processing on the information to recover any spatial streams destined for the UE 4002. If multiple spatial streams are destined for the UE 4002, they may be combined into a single OFDM symbol stream by the receiver 4012. The receiver 4012 then converts the OFDM symbol stream from the time domain to the frequency domain using a fast Fourier transform (FFT). The frequency domain signal includes a separate OFDM symbol stream for each subcarrier of the OFDM signal. The symbols on each subcarrier, as well as the reference signal, are recovered and demodulated by determining the most likely signal constellation point transmitted by the base station 4004. These soft decisions may 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 transmitted by the base station 4004 on the physical channel. The data and control signals are then provided to one or more processors 4032 that implement Layer-3 (L3) and Layer-2 (L2) functionality.

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

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

[0427] Channel estimates derived by a channel estimator from a reference signal or feedback transmitted by the base station 4004 may be used by the transmitter 4014 to select an appropriate coding and modulation scheme and to facilitate spatial processing. The spatial streams generated by the transmitter 4014 may be provided to different antenna(s) 4016. The transmitter 4014 may modulate an RF carrier with each spatial stream for transmission.

[0428] Uplink transmissions are processed at the base station 4004 in a manner similar to that described with respect to the receiver functionality at the UE 4002. The receiver 4052 receives signals through its respective antenna(s) 4056. The receiver 4052 recovers information modulated onto an RF carrier and provides the information to one or more processors 4084.

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

[0430] For convenience, the UE 4002, base station 4004, and / or network entity 4006 are illustrated in Figures 40A, 40B, and 40C as including various components that may be configured in accordance with various examples described herein. However, it will be understood that the illustrated components may have different functionality in different designs. In particular, various components in Figures 40A-40C are optional in alternative configurations, and various aspects include configurations that may vary due to design choice, cost, device usage, or other considerations. For example, in FIG. 40A , a particular implementation of UE 4002 may omit WWAN transceiver(s) 4010 (e.g., a wearable device or tablet computer or PC or laptop may have Wi-Fi and / or Bluetooth capabilities without cellular capabilities), or may omit short-range wireless transceiver(s) 4020 (e.g., cellular only, etc.), or may omit satellite signal receiver 4030, or may omit sensor(s) 4044, etc. In another example, in FIG. 40B , a particular implementation of base station 4004 may omit WWAN transceiver(s) 4050 (e.g., a Wi-Fi “hotspot” access point without cellular capabilities), or may omit short-range wireless transceiver(s) 4060 (e.g., cellular only, etc.), or may omit satellite signal receiver 4070, etc. For the sake of brevity, examples of various alternative configurations are not provided herein, but should be readily apparent to one skilled in the art.

[0431] The various components of the UE 4002, the base station 4004, and the 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 communication interfaces of the UE 4002, the base station 4004, and the network entity 4006, respectively. For example, when different logical entities are embodied within the same device (e.g., gNB and location server functionality incorporated within the same base station 4004), the data buses 4034, 4082, and 4092 may provide communication therebetween.

[0432] The components of Figures 40A, 40B, and 40C may be implemented in various ways. In some implementations, the components of Figures 40A, 40B, and 40C may be implemented in one or more circuits, such as, for example, one or more processors and / or one or more ASICs (which may include one or more processors), where each circuit may use and / or incorporate at least one memory component for storing information or executable code used by the circuit to provide its functionality. For example, some or all of the functionality represented by blocks 4010-4046 may be implemented by the processor and memory component(s) of the UE 4002 (e.g., by execution of appropriate code and / or by appropriate configuration of the processor components). Similarly, some or all of the functionality represented by blocks 4050-4088 may be implemented by the processor and memory component(s) of the base station 4004 (e.g., by execution of appropriate code and / or by appropriate configuration of the processor components). Additionally, some or all of the functionality represented by blocks 4090-4098 may be implemented by the processor and memory component(s) of the network entity 4006 (e.g., by execution of appropriate code and / or by appropriate configuration of the processor components). For simplicity, various operations, actions, and / or functions are described herein as being performed "by the UE," "by the base station," "by the network entity," etc. However, it will be understood that such operations, actions, and / or functions may actually be performed by particular 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.

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

[0434] FIG. 41 shows an example process 4100 of communication according to one aspect of the present disclosure. Process 4100 of FIG. 41 is performed by a UE, such as UE 4002. In particular, process 4100 of FIG. 41 is performed by an initiating UE (e.g., an initiator of an SLPP session), as described above. In some designs, process 4100 of FIG. 41 may be performed during device and service discovery, as described above.

[0435] Referring to FIG. 41, at 4110, an initiating UE (e.g., transmitter 4014 or 4024) sends a first request to each receiving UE in a set of one or more receiving UEs to create a Sidelink Positioning Protocol (SLPP) session.

[0436] Referring to FIG. 41, at 4120, an initiating UE (e.g., receiver 4012 or 4022) receives a first response from each receiving UE of a set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the respective receiving UE.

[0437] Referring to FIG. 41, at 4130, the initiating UE (e.g., processor(s) 4032, SLPP component 4042, etc.) determines a group of one or more UEs for participation in the SLPP session from among the receiving UEs from which respective first responses indicating acceptance of the SLPP session are received (e.g., based on signal strength, based on spatial or distance separation parameters for the UEs in the group, etc.).

[0438] Referring to FIG. 41, at 4140, an initiating UE (eg, transmitter 4014 or 4024) sends a second request to initiate an SLPP session to a group of one or more UEs.

[0439] Referring to FIG. 41, at 4150, the initiating UE (e.g., receiver 4012 or 4022) receives second responses from a group of one or more UEs that each acknowledge the second request.

[0440] Referring to FIG. 41 , in some designs, the first request is sent via unicast, groupcast, or broadcast, or each first response is received via unicast, groupcast, broadcast, or a combination thereof, or the second request is sent via unicast, groupcast, or broadcast, or each second response is received via unicast, groupcast, broadcast, or a combination thereof, or any combination thereof.

[0441] Referring to FIG. 41, in some designs, the first request includes a session identifier associated with the SLPP session.

[0442] Referring to FIG. 41, in some designs, the first request includes a Layer 2 (L2) group identifier associated with the SLPP session.

[0443] 41 , in some designs, the group of one or more UEs includes each receiving UE that indicates acceptance of the SLPP session via a respective first response (e.g., all accepting receiving UEs; in alternative embodiments, the N fastest responding UEs, or all accepting receiving UEs that respond within some time window are added to the group), or the group of one or more UEs omits one or more receiving UEs that indicate rejection of the SLPP session via one or more respective first responses (e.g., because not all receiving UEs may accept the first request). In some designs, the initiating UE further sends a third request to modify the SLPP session to the one or more groups of UEs and to any new receiving UEs to be added to the group of one or more UEs (e.g., during the SLPP session), where the third request indicates whether each receiving 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 receiving UE that indicates acceptance of the modified SLPP session via a respective third response, or the modified group of one or more UEs omits one or more receiving UEs that indicate rejection of the modified SLPP session via one or more respective third responses.

[0444] Referring to FIG. 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 a group of one or more UEs.

[0445] Referring to FIG. 41 , in some designs, the initiating UE may further obtain a set of sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session and may determine a position 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. Note that the initiating UE may directly measure some or all of the SL-PRS measurements itself, or alternatively, other UE(s) may directly measure some or all of the SL-PRS measurements, which are then communicated (in whole or in part) to the initiating UE. A combination of such techniques is also possible. In some designs, one or more position estimates for one or more UEs are determined and transmitted to the one or more UEs.

[0446] FIG. 42 shows an example process 4200 of communication according to one aspect of the present disclosure. Process 4200 of FIG. 42 is performed by a UE, such as UE 4002. In particular, process 4200 of FIG. 42 is performed by a receiving UE, as described above. In some designs, process 4200 of FIG. 42 may be performed during device and service discovery, as described above. In some designs, process 4200 of FIG. 42 may be performed together with process 4100 of FIG. 42.

[0447] Referring to FIG. 42, at 4210, a receiving UE (e.g., receiver 4012 or 4022) receives a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiating UE.

[0448] Referring to FIG. 42, at 4220, the receiving UE (eg, transmitter 4014 or 4024) transmits a first response to the initiating UE indicating acceptance or rejection of the SLPP session by the receiving UE.

[0449] 42 , in some designs, the first response indicates acceptance of the SLPP session by the receiving UE. In some designs, the receiving UE may further receive a second request to start the SLPP session from the initiating UE and send a second response acknowledging the second request. In some designs, the second request is received via unicast, groupcast, or broadcast, or the second response is sent via unicast, groupcast, 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 a group of one or more UEs associated with the SLPP session. In some designs, the receiving UE may further receive a third request to modify the SLPP session from the initiating UE (e.g., during the SLPP session), where the third request indicates whether the receiving UE will be included or excluded from the modified SLPP session. In some designs, the receiving UE may further send a third response to the initiating UE indicating acceptance, rejection, or acknowledgment of the modified SLPP session by the receiving UE. In some designs, the receiving UE may further send sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session to the initiating UE. In some designs, the receiving UE may further receive a position estimate for the receiving UE from the initiating UE.

[0450] 42, in some designs, the first request is received via unicast, groupcast, or broadcast, or the first response is sent via unicast, groupcast, 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.

[0451] 43 shows an example process 4300 of communication according to one aspect of the present disclosure. The process 4300 of FIG. 43 is performed by a UE, such as UE 4002. In some designs, the UE performing the process of FIG. 43 may be either an initiating UE or a receiving UE.

[0452] 43, at 4310, the UE (e.g., processor(s) 4032, SLPP component 4042, etc.) determines a first casting mode associated with an SLPP message associated with a Sidelink Positioning Protocol (SLPP) session. As used herein, "casting mode" is used interchangeably with "cast type," e.g., unicast, groupcast, or broadcast.

[0453] 43, at 4320, the UE (e.g., processor(s) 4032, SLPP component 4042, etc.) determines a second casting mode associated with one or more SLPP response messages to the SLPP message. Note that not all SLPP messages are necessarily configured to trigger such response(s).

[0454] 43, at 4330, a UE (e.g., transmitter 4014 or 4024) transmits an SLPP message to a set of one or more UEs according to a first casting mode. In one aspect, the SLPP message includes an indication of both the first casting mode and the second casting mode.

[0455] Referring to FIG. 43, in some designs, the first casting mode is unicast, groupcast, or broadcast, and the second casting mode is unicast, groupcast, or broadcast.

[0456] 43 , in some designs, the first casting 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 casting mode is unicast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode. In one aspect, the UE may further receive a response to the SLPP message from the target UE via unicast.

[0457] Referring to FIG. 43 , in some designs, the first casting mode is groupcast, and the set of one or more UEs includes one or more groups of UEs. In some designs, the SLPP message includes a session identifier for the SLPP session and a set of group identifiers associated with the SLPP session. In some designs, the second casting mode is groupcast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode. In this case, in one aspect, the UE may further receive a response to the SLPP message from at least one UE in the group of one or more UEs via groupcast. In another design, the second casting mode is unicast, and the SLPP message further includes an indication of the second casting mode. In this case, in one aspect, the UE may further receive a response to the SLPP message from at least one UE in the group of one or more UEs via unicast.

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

[0459] 44 shows an example process 4400 of communication according to one aspect of the present disclosure. Process 4400 of FIG. 44 may be performed by a UE, such as UE 4002. In some designs, the UE performing the process of FIG. 44 may be either an initiating UE or a receiving UE. In some designs, process 4400 of FIG. 44 may be performed together with process 4300 of FIG. 43.

[0460] Referring to FIG. 44, at 4410, a UE (e.g., receiver 4012 or 4022) receives a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, the SLPP message being received according to a first casting mode and including an indication of both the first casting mode and a second casting mode associated with one or more SLPP response messages to the SLPP message.

[0461] Referring to FIG. 44, at 4420, the UE (eg, transmitter 4014 or 4024) transmits an SLPP response message in response to the SLPP message according to the second casting mode.

[0462] Referring to FIG. 44, in some designs, the first casting mode is unicast, groupcast, or broadcast, and the second casting mode is unicast, groupcast, or broadcast.

[0463] 44, in some designs, the first casting 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 SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and the second casting mode is unicast.

[0464] 44 , in some designs, the first casting mode is groupcast, and the set of one or more UEs includes one or more groups of UEs. In some designs, the SLPP message includes 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 includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and the second casting mode is groupcast. In other designs, the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and the second casting mode is unicast.

[0465] 44, in some designs, the first casting mode is broadcast. In some designs, the SLPP message includes a session identifier for the SLPP session. In some designs, the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and the second casting mode is broadcast.

[0466] Referring to FIG. 44, in some designs, the SLPP may support at least the following general transaction modes: Unicast Transactions Group Transaction with Group Response Group transactions with unicast responses, and Broadcast transaction.

[0467] In the above detailed description, it can be seen that different features are grouped together in the examples. This manner of disclosure may not be understood as an intention that the exemplary clauses have more features than are expressly stated in each clause. Rather, various aspects of the present disclosure may include fewer than all features of each disclosed exemplary clause. Thus, the following clauses may be considered incorporated herein, and each clause may stand alone as a separate example. Although each dependent clause may refer to a specific combination with one of the other clauses within that clause, the aspect(s) of that dependent clause are not limited to that specific combination. It will be understood that other exemplary clauses may also include combinations of the aspect(s) of the dependent clause with the subject matter of any other dependent clause or independent clause, or combinations of any features with other dependent clauses and independent clauses. The various aspects disclosed herein expressly include specific combinations (e.g., contradictory aspects, such as defining an element as both an electrical insulator and an electrical conductor) unless these combinations are expressly expressed or can be readily inferred to be unintended. It is further contemplated that aspects of a clause may be included in any other independent clause, even if the clause is not directly dependent on the independent clause.

[0468] The following numbered clauses describe example implementations.

[0469] Clause 1. A method of operating an initiating user equipment (UE), the method comprising: 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 first responses from the set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the receiving UE; determining one or more groups of UEs for participation in the SLPP session from among the receiving UEs from which the respective first responses indicating acceptance of the SLPP session are received; sending a second request to initiate the SLPP session to the one or more groups of UEs; and receiving second responses from the one or more groups of UEs, each second response acknowledging the second request.

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

[0471] Clause 3. The method of clause 1 or 2, wherein the first request includes a session identifier associated with the SLPP session.

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

[0473] Clause 5. A method according to any one of clauses 1 to 4, wherein the group of one or more UEs includes each receiving UE indicating acceptance of the SLPP session via a respective first response, or the group of one or more UEs omits one or more receiving UEs indicating rejection of the SLPP session via one or more respective first responses.

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

[0475] Clause 7. The method of clause 6, wherein the modified group of one or more UEs includes each receiving UE that indicates acceptance of the modified SLPP session via a respective third response, or the modified group of one or more UEs omits one or more receiving UEs that indicate rejection of the modified SLPP session via one or more respective third responses.

[0476] Clause 8. The method of any one of clauses 1 to 7, wherein the second request includes 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 a group of one or more UEs.

[0477] Clause 9. The method of any one 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 position estimate 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.

[0478] Clause 10. The method of clause 9, wherein one or more location estimates for one or more UEs are determined and transmitted to the one or more UEs.

[0479] Clause 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 initiating UE; and transmitting a first response to the initiating UE indicating acceptance or rejection of the SLPP session by the receiving UE.

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

[0481] Clause 13. The method of clause 12, further comprising: receiving a second request from the initiating UE to initiate an SLPP session; and sending a second response acknowledging the second request.

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

[0483] Clause 15. The method of clause 13 or 14, wherein the second request includes 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 a group of one or more UEs associated with the SLPP session.

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

[0485] Clause 17. The method of clause 16, wherein sending the third response to the initiating UE indicates acceptance or rejection or acknowledgment of the modified SLPP session by the receiving UE.

[0486] Clause 18. The method of any one of clauses 12 to 17, further comprising transmitting to the initiating UE Sidelink Positioning Reference Signal (SL-PRS) measurements associated with the SLPP session.

[0487] Clause 19. The method of any one of clauses 12 to 18, further comprising receiving a location estimate of the receiving UE from the initiating UE.

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

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

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

[0491] Clause 23. A method of operating a user equipment (UE), comprising: determining a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session; selectively determining a second casting mode associated with any SLPP response message to the SLPP message based on whether the SLPP message is configured to trigger a response; and transmitting 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 the first casting mode or both the first casting mode and the second casting mode.

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

[0493] Clause 25. The method of clause 23 or 24, wherein the first casting mode is unicast and the set of one or more UEs includes a single target UE.

[0494] Clause 26. The method of clause 25, wherein 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.

[0495] Clause 27. The method of clause 25 or 26, wherein the selective determination determines that the second casting mode is unicast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further includes receiving a response to the SLPP message from the target UE via unicast.

[0496] Clause 28. The method of any one of clauses 23 to 27, wherein the first casting mode is groupcast and the set of one or more UEs comprises one or more groups of UEs.

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

[0498] Clause 30. The method of clause 28 or 29, wherein the selective determination determines that the second casting mode is groupcast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further includes receiving a response to the SLPP message from at least one UE in the group of one or more UEs via groupcast.

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

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

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

[0502] Clause 34. The method of clause 32 or 33, wherein the selective determination determines that the second casting mode is broadcast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further includes receiving a response to the SLPP message from at least one UE in the set of one or more UEs via broadcast.

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

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

[0505] Clause 37. The method of clause 35 or 36, wherein the first casting mode is unicast.

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

[0507] Clause 39. The method of clause 37 or 38, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is unicast, and the determination is to respond to the SLPP message via unicast.

[0508] Clause 40. The method of any one of clauses 35 to 39, wherein the first casting mode is groupcast.

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

[0510] Clause 42. The method of clause 40 or 41, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode being groupcast, and the determination is to respond to the SLPP message via groupcast.

[0511] Clause 43. A method according to any one of clauses 40 to 42, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode being unicast, and the determination is to respond to the SLPP message via unicast.

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

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

[0514] Clause 46. The method of clause 44 or 45, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is broadcast, and the determination is to respond to the SLPP message via broadcast.

[0515] Clause 47. An initiating user equipment (UE), comprising: a memory; and at least one processor communicatively coupled to the memory, wherein the at least one processor is configured to: send a first request to each receiving UE in a set of one or more receiving UEs to create a Sidelink Positioning Protocol (SLPP) session; receive first responses from the set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the receiving UE; determine one or more groups of UEs for participation in the SLPP session from among the receiving UEs from which respective first responses indicating acceptance of the SLPP session have been received; send a second request to the one or more groups of UEs to initiate the SLPP session; and receive second responses from the one or more groups of UEs, each second response acknowledging the second request.

[0516] Clause 48. The initiating UE of clause 47, wherein the first request is sent via unicast, groupcast, or broadcast, or the first response is received via unicast, groupcast, broadcast, or a combination thereof, or the second request is sent via unicast, groupcast, or broadcast, or the second response is received via unicast, groupcast, broadcast, or a combination thereof, or any combination thereof.

[0517] Clause 49. The initiating UE of clause 47 or 48, wherein the first request includes a session identifier associated with the SLPP session.

[0518] Clause 50. The initiating UE of any one of clauses 47 to 49, wherein the first request includes an L2 group identifier associated with the SLPP session.

[0519] Clause 51. An initiating UE as described in any one of clauses 47 to 50, wherein the group of one or more UEs includes each receiving UE indicating acceptance of the SLPP session via a respective first response, or the group of one or more UEs omits one or more receiving UEs indicating rejection of the SLPP session via one or more respective first responses.

[0520] Clause 52. The initiating 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 to any new receiving UEs to be added to the group of one or more UEs, the third request indicating whether each receiving UE is to be included or excluded from the modified SLPP session associated with the modified group of one or more UEs.

[0521] Clause 53. An initiating UE as described in clause 52, wherein the modified group of one or more UEs includes each receiving UE that indicates acceptance of the modified SLPP session via a respective third response, or the modified group of one or more UEs omits one or more receiving UEs that indicate rejection of the modified SLPP session via one or more respective third responses.

[0522] Clause 54. An initiating UE as described in any one of clauses 47 to 53, wherein the second request includes 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 a group of one or more UEs.

[0523] Clause 55. An initiating UE as described in any one of Clauses 47 to 54, wherein 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 position estimate 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.

[0524] Clause 56. The initiating UE of clause 55, wherein one or more location estimates for the one or more UEs are determined and transmitted to the one or more UEs.

[0525] Clause 57. A receiving user equipment (UE), comprising: a memory; and at least one processor communicatively coupled to the memory, wherein the at least one processor is configured to receive a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiating UE; and to send a first response to the initiating UE indicating acceptance or rejection of the SLPP session by the receiving UE.

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

[0527] Clause 59. The receiving UE of Clause 58, wherein the at least one processor is further configured to receive a second request to initiate the SLPP session from the initiating UE and send a second response acknowledging the second request.

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

[0529] Clause 61. A receiving UE as described in clause 59 or 60, wherein the second request includes 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 a group of one or more UEs associated with the SLPP session.

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

[0531] Clause 63. The receiving UE of clause 62, wherein sending a third response to the initiating UE indicates acceptance or rejection or acknowledgment of the modified SLPP session by the receiving UE.

[0532] Clause 64. A receiving UE as described in any one of clauses 58 to 63, wherein at least one processor is further configured to transmit sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session to the initiating UE.

[0533] Clause 65. The receiving UE of any one of clauses 58 to 64, wherein the at least one processor is further configured to receive a position estimate for the receiving UE from the initiating UE.

[0534] Clause 66. A receiving UE according to any one of clauses 57 to 65, wherein the first request is received via unicast, groupcast, or broadcast, or the first response is sent via unicast, groupcast, or broadcast, or any combination thereof.

[0535] Clause 67. The receiving UE of any one of clauses 57 to 66, wherein the first request includes a session identifier associated with the SLPP session.

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

[0537] Clause 69. A user equipment (UE), comprising: a memory; and at least one processor communicatively coupled to the memory, wherein the at least one processor is configured to: determine a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session; selectively determine a second casting mode associated with any SLPP response message to the SLPP message based on whether the SLPP message is configured to trigger a response; and transmit 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 the first casting mode or both the first casting mode and the second casting mode.

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

[0539] Clause 71. The UE of clause 69 or 70, wherein the first casting mode is unicast and the set of one or more UEs includes a single target UE.

[0540] Clause 72. The UE of clause 71, wherein 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.

[0541] Clause 73. The UE of clause 71 or 72, wherein the selective determination determines that the second casting mode is unicast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further includes receiving a response to the SLPP message from the target UE via unicast.

[0542] Clause 74. The UE of any one of clauses 69 to 73, wherein the first casting mode is groupcast and the set of one or more UEs includes one or more groups of UEs.

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

[0544] Clause 76. The UE of clause 74 or 75, wherein the selective determination determines that the second casting mode is groupcast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further includes receiving a response to the SLPP message from at least one UE in the group of one or more UEs via groupcast.

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

[0546] Clause 78. The UE of any one of clauses 69 to 77, wherein the first casting mode is broadcast.

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

[0548] Clause 80. The UE of clause 78 or 79, wherein the selective determination determines that the second casting mode is broadcast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further includes receiving a response to the SLPP message from at least one UE in the set of one or more UEs via broadcast.

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

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

[0551] Clause 83. The UE of clause 81 or 82, wherein the first casting mode is unicast.

[0552] Clause 84. The UE of clause 83, wherein the SLPP message includes a session identifier for the SLPP session, a first set of identifiers associated with another UE, and a second set of identifiers associated with the UE.

[0553] Clause 85. A UE as described in clause 83 or 84, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is unicast, and the determination is to respond to the SLPP message via unicast.

[0554] Clause 86. The UE of any one of clauses 81 to 85, wherein the first casting mode is groupcast.

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

[0556] Clause 88. A UE as described in clause 86 or 87, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode being groupcast, and the determination is to respond to the SLPP message via groupcast.

[0557] Clause 89. A UE described in any one of clauses 86 to 88, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is unicast, and the determination is to respond to the SLPP message via unicast.

[0558] Clause 90. The UE of any one of clauses 81 to 89, wherein the first casting mode is broadcast.

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

[0560] Clause 92. A UE as described in clause 90 or 91, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is broadcast, and the decision is to respond to the SLPP message via broadcast.

[0561] Clause 93. An initiating user equipment (UE), comprising: means for sending a first request to create a Sidelink Positioning Protocol (SLPP) session to each receiving UE in a set of one or more receiving UEs; means for receiving first responses from the set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the receiving UE; means for determining, from among the receiving UEs from which each first response indicating acceptance of the SLPP session is received, one or more groups of UEs for participation in the SLPP session; means for sending a second request to the one or more groups of UEs to initiate the SLPP session; and means for receiving second responses from the one or more groups of UEs, each second response acknowledging the second request.

[0562] Clause 94. The initiating UE of clause 93, wherein the first request is sent via unicast, groupcast, or broadcast, or the first response is received via unicast, groupcast, broadcast, or a combination thereof, or the second request is sent via unicast, groupcast, or broadcast, or the second response is received via unicast, groupcast, broadcast, or a combination thereof, or any combination thereof.

[0563] Clause 95. The initiating UE of clause 93 or 94, wherein the first request includes a session identifier associated with the SLPP session.

[0564] Clause 96. The initiating UE of any one of clauses 93 to 95, wherein the first request includes an L2 group identifier associated with the SLPP session.

[0565] Clause 97. An initiating UE as described in any one of clauses 93 to 96, wherein the group of one or more UEs includes each receiving UE indicating acceptance of the SLPP session via a respective first response, or the group of one or more UEs omits one or more receiving UEs indicating rejection of the SLPP session via one or more respective first responses.

[0566] Clause 98. The initiating UE of clause 97 further comprising means for transmitting a third request to modify the SLPP session to the one or more groups of UEs and to any new receiving UEs to be added to the one or more groups of UEs, the third request indicating whether each receiving UE is to be included or excluded in the modified SLPP session associated with the modified group of one or more UEs.

[0567] Clause 99. An initiating UE as described in clause 98, wherein the modified group of one or more UEs includes each receiving UE that indicates acceptance of the modified SLPP session via a respective third response, or the modified group of one or more UEs omits one or more receiving UEs that indicate rejection of the modified SLPP session via one or more respective third responses.

[0568] Clause 100. An initiating UE as described in any one of clauses 93 to 99, wherein the second request includes 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 a group of one or more UEs.

[0569] Clause 101. An initiating UE as described in any one of clauses 93 to 100, further comprising: means for obtaining a set of sidelink positioning reference signal (SL-PRS) measurements associated with an SLPP session; and means for determining a position estimate 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.

[0570] Clause 102. The initiating UE of clause 101, wherein one or more location estimates for the one or more UEs are determined and transmitted to the one or more UEs.

[0571] Clause 103. A receiving user equipment (UE), comprising: means for receiving a first request to create a Sidelink Positioning Protocol (SLPP) session from an initiating UE; and means for transmitting a first response to the initiating UE indicating acceptance or rejection of the SLPP session by the receiving UE.

[0572] Clause 104. The receiving UE of clause 103, wherein the first response indicates acceptance of the SLPP session by the receiving UE.

[0573] Clause 105. The receiving UE of clause 104, further comprising: means for receiving a second request to initiate an SLPP session from the initiating UE; and means for sending a second response acknowledging the second request.

[0574] Clause 106. The recipient UE of clause 105, wherein the second request is received via unicast, groupcast, or broadcast, or the second response is sent via unicast, groupcast, or broadcast, or any combination thereof.

[0575] Clause 107. The receiving UE of clause 105 or 106, wherein the second request includes 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 a group of one or more UEs associated with the SLPP session.

[0576] Clause 108. The receiving UE of any one of clauses 104 to 107, further comprising means for receiving from the initiating UE a third request to modify the SLPP session, indicating whether the receiving UE is to be included or excluded from the modified SLPP session.

[0577] Clause 109. The receiving UE of clause 108, wherein the means for sending a third response to the initiating UE indicates acceptance or rejection or acknowledgment of the modified SLPP session by the receiving UE.

[0578] Clause 110. The receiving UE of any one of clauses 104 to 109, further comprising means for transmitting Sidelink Positioning Reference Signal (SL-PRS) measurements associated with the SLPP session to the initiating UE.

[0579] Clause 111. The receiving UE of any one of clauses 104 to 110, further comprising means for receiving a location estimate of the receiving UE from the initiating UE.

[0580] Clause 112. A receiving UE according to any one of clauses 103 to 111, wherein the first request is received via unicast, groupcast, or broadcast, or the first response is sent via unicast, groupcast, or broadcast, or any combination thereof.

[0581] Clause 113. The receiving UE of any one of clauses 103 to 112, wherein the first request includes a session identifier associated with the SLPP session.

[0582] Clause 114. The receiving UE of clause 113, wherein the first request includes a set of group identifiers associated with the SLPP session.

[0583] Clause 115. A user equipment (UE), comprising: means for determining a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session; means for selectively determining a second casting mode associated with any SLPP response message to the SLPP message based on whether the SLPP message is configured to trigger a response; and means for transmitting 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 the first casting mode or both the first casting mode and the second casting mode.

[0584] Clause 116. The UE of clause 115, wherein the first casting mode is unicast, groupcast, or broadcast, and the second casting mode is unicast, groupcast, or broadcast.

[0585] Clause 117. The UE of clause 115 or 116, wherein the first casting mode is unicast and the set of one or more UEs includes a single target UE.

[0586] Clause 118. The UE of clause 117, wherein 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.

[0587] Clause 119. The UE described in clause 117 or 118, wherein the selective determination determines that the second casting mode is unicast and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further comprising means for receiving a response to the SLPP message from the target UE via unicast.

[0588] Clause 120. The UE of any one of clauses 115 to 119, wherein the first casting mode is groupcast and the set of one or more UEs includes one or more groups of UEs.

[0589] Clause 121. The UE of clause 120, wherein the SLPP message includes a session identifier for the SLPP session and a set of group identifiers associated with the SLPP session.

[0590] Clause 122. The UE of clause 120 or 121, wherein the selective determination determines that the second casting mode is groupcast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further comprising means for receiving a response to the SLPP message from at least one UE in a group of one or more UEs via groupcast.

[0591] Clause 123. The UE described in any one of clauses 120 to 122, wherein the selective determination determines that the second casting mode is unicast, and the SLPP message further includes an indication of the second casting mode, and further comprising means for receiving a response to the SLPP message from at least one UE in a group of one or more UEs via unicast.

[0592] Clause 124. The UE of any one of clauses 115 to 123, wherein the first casting mode is broadcast.

[0593] Clause 125. The UE of clause 124, wherein the SLPP message includes a session identifier for the SLPP session.

[0594] Clause 126. The UE of clause 124 or 125, wherein the selective determination determines that the second casting mode is broadcast, and the SLPP message further includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and further comprising means for receiving a response to the SLPP message from at least one UE in the set of one or more UEs via broadcast.

[0595] Clause 127. A user equipment (UE), comprising: means for receiving a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, the SLPP message being received according to a first casting mode and including an indication of the first casting mode or both the first casting mode and a second casting mode associated with any SLPP response message to the SLPP message; and means for determining whether to respond to the SLPP message according to the second casting mode based on whether the SLPP message is configured to trigger a response.

[0596] Clause 128. The UE of clause 127, wherein the first casting mode is unicast, groupcast, or broadcast, and the second casting mode is unicast, groupcast, or broadcast.

[0597] Clause 129. The UE of clause 127 or 128, wherein the first casting mode is unicast.

[0598] Clause 130. The UE of clause 129, wherein the SLPP message includes a session identifier for the SLPP session, a first set of identifiers associated with another UE, and a second set of identifiers associated with the UE.

[0599] Clause 131. A UE as described in clause 129 or 130, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is unicast, and the determination is to respond to the SLPP message via unicast.

[0600] Clause 132. The UE of any one of clauses 127 to 131, wherein the first casting mode is groupcast.

[0601] Clause 133. The UE of clause 132, wherein the SLPP message includes a session identifier for the SLPP session and a set of group identifiers associated with the SLPP session.

[0602] Clause 134. The UE of clause 132 or 133, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode being groupcast, and the determination is to respond to the SLPP message via groupcast.

[0603] Clause 135. A UE described in any one of clauses 132 to 134, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is unicast, and the determination is to respond to the SLPP message via unicast.

[0604] Clause 136. The UE of any one of clauses 127 to 135, wherein the first casting mode is broadcast.

[0605] Clause 137. The UE of clause 136, wherein the SLPP message includes a session identifier for the SLPP session.

[0606] Clause 138. The UE of clause 136 or 137, wherein the SLPP message further includes an indication of a second casting mode, or the second casting mode is implicit from the first casting mode, the second casting mode is broadcast, and the decision is to respond to the SLPP message via broadcast.

[0607] Clause 139. A non-transitory computer-readable medium storing computer-executable instructions that, when executed by an initiating user equipment (UE), cause the initiating UE to send a first request to each receiving UE in a set of one or more receiving UEs to create a Sidelink Positioning Protocol (SLPP) session, receive first responses from the set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the receiving UE, determine one or more groups of UEs for participation in the SLPP session from among the receiving UEs from which respective first responses indicating acceptance of the SLPP session were received, send a second request to initiate the SLPP session to the one or more groups of UEs, and receive second responses from the one or more groups of UEs, each second response acknowledging the second request.

[0608] Clause 140. The non-transitory computer-readable medium of clause 139, wherein the first request is sent via unicast, groupcast, or broadcast, or the first response is received via unicast, groupcast, broadcast, or a combination thereof, or the second request is sent via unicast, groupcast, or broadcast, or the second response is received via unicast, groupcast, broadcast, or a combination thereof, or any combination thereof.

[0609] Clause 141. The non-transitory computer-readable medium of clause 139 or 140, wherein the first request includes a session identifier associated with the SLPP session.

[0610] Clause 142. The non-transitory computer-readable medium of any one of clauses 139-141, wherein the first request includes an L2 group identifier associated with the SLPP session.

[0611] Clause 143. A non-transitory computer-readable medium described in any one of clauses 139 to 142, wherein the group of one or more UEs includes each receiving UE that indicates acceptance of the SLPP session via a respective first response, or the group of one or more UEs omits one or more receiving UEs that indicate rejection of the SLPP session via one or more respective first responses.

[0612] Clause 144. The non-transitory computer-readable medium of clause 143, further comprising computer-executable instructions that, when executed by an initiating UE, cause the initiating UE to send a third request to modify the SLPP session to a group of one or more UEs and to any new receiving UEs to be added to the group of one or more UEs, the third request indicating whether each receiving UE is to be included in or excluded from the modified SLPP session associated with the modified group of one or more UEs.

[0613] Clause 145. The non-transitory computer-readable medium of clause 144, wherein the modified group of one or more UEs includes each receiving UE that indicates acceptance of the modified SLPP session via a respective third response, or the modified group of one or more UEs omits one or more receiving UEs that indicate rejection of the modified SLPP session via one or more respective third responses.

[0614] Clause 146. The non-transitory computer-readable medium of any one of clauses 139 to 145, wherein the second request includes an L2 and L3 identifier associated with the SLPP session, a UE identifier associated with the initiating UE, and a UE identifier associated with each UE in a group of one or more UEs.

[0615] Clause 147. A non-transitory computer-readable medium according to any one of clauses 139 to 146, further comprising computer-executable instructions that, when executed by an initiating UE, cause the initiating UE to obtain a set of sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session and determine a position estimate 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.

[0616] Clause 148. The non-transitory computer-readable medium of clause 147, wherein one or more location estimates for one or more UEs are determined and transmitted to the one or more UEs.

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

[0618] Clause 150. The non-transitory computer-readable medium of clause 149, wherein the first response indicates acceptance of the SLPP session by the receiving UE.

[0619] Clause 151. The non-transitory computer-readable medium of clause 150, further comprising computer-executable instructions that, when executed by the receiving UE, cause the receiving UE to receive a second request to initiate an SLPP session from the initiating UE and send a second response acknowledging the second request.

[0620] Clause 152. The non-transitory computer-readable medium of clause 151, wherein the second request is received via unicast, groupcast, or broadcast, or the second response is sent via unicast, groupcast, or broadcast, or any combination thereof.

[0621] Clause 153. The non-transitory computer-readable medium of clause 151 or 152, wherein the second request includes 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 a group of one or more UEs associated with the SLPP session.

[0622] Clause 154. The non-transitory computer-readable medium of any one of clauses 150 to 153, further comprising computer-executable instructions that, when executed by the receiving UE, cause the receiving UE to receive a third request to modify the SLPP session from the initiating UE, indicating whether the receiving UE is to be included in or excluded from the modified SLPP session.

[0623] Clause 155. The non-transitory computer-readable medium of clause 154, wherein sending the third response to the initiating UE indicates acceptance or rejection or acknowledgment of the modified SLPP session by the receiving UE.

[0624] Clause 156. A non-transitory computer-readable medium according to any one of clauses 150 to 155, further comprising computer-executable instructions that, when executed by a receiving UE, cause the receiving UE to transmit Sidelink Positioning Reference Signal (SL-PRS) measurements associated with the SLPP session to the initiating UE.

[0625] Clause 157. The non-transitory computer-readable medium of any one of clauses 150 to 156, further comprising computer-executable instructions that, when executed by the receiving UE, cause the receiving UE to receive a location estimate for the receiving UE from the initiating UE.

[0626] Clause 158. The non-transitory computer-readable medium of any one of clauses 149 to 157, wherein the first request is received via unicast, groupcast, or broadcast, or the first response is sent via unicast, groupcast, or broadcast, or any combination thereof.

[0627] Clause 159. The non-transitory computer-readable medium of any one of clauses 149-158, wherein the first request includes a session identifier associated with the SLPP session.

[0628] Clause 160. The non-transitory computer-readable medium of clause 159, wherein the first request includes a set of group identifiers associated with the SLPP session.

[0629] Clause 161. 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 casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, selectively determine a second casting mode associated with any SLPP response message to the SLPP message based on whether the SLPP message is configured to trigger a response, and transmit 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 the first casting mode or both the first casting mode and the second casting mode.

[0630] Clause 162. The non-transitory computer-readable medium of clause 161, wherein the first casting mode is unicast, groupcast, or broadcast, and the second casting mode is unicast, groupcast, or broadcast.

[0631] Clause 163. The non-transitory computer-readable medium of clause 161 or 162, wherein the first casting mode is unicast and the set of one or more UEs includes a single target UE.

[0632] Clause 164. The non-transitory computer-readable medium of clause 163, wherein 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.

[0633] Clause 165. The non-transitory computer-readable medium of clause 163 or 164, wherein the selective determination determines that the second casting mode is...

Claims

1. 1. A method of operating an initiator user equipment (UE), comprising: 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 of the set of one or more receiving UEs, each first response indicating acceptance or rejection of the SLPP session by the respective receiving UE; determining a group of one or more UEs for participation in the SLPP session from among receiving UEs from which respective first responses indicating the acceptance of the SLPP session are received; sending a second request to initiate the SLPP session to the group of one or more UEs; receiving a second response from each UE of the group of one or more UEs; wherein each second response acknowledges the second request.

2. the first request is transmitted via unicast, groupcast, or broadcast; or Each first response is received via unicast, groupcast, broadcast, or a combination thereof; or the second request is transmitted via unicast, groupcast, or broadcast; or Each second response is received via unicast, groupcast, broadcast, or a combination thereof; or Any combination thereof, The method of claim 1.

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

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

5. the group of one or more UEs includes each receiving UE indicating the acceptance of the SLPP session via a respective first response, or 2. The method of claim 1, wherein the group of one or more UEs omits one or more recipient UEs that indicate the rejection of the SLPP session via one or more respective first responses.

6. 2. The method of claim 1, further comprising: sending a third request to modify the SLPP session to the group of one or more UEs and to any new receiving UEs to be added to the group of one or more UEs, the third request indicating whether each receiving UE is to be included or excluded in the modified SLPP session associated with the modified group of one or more UEs.

7. the modified group of one or more UEs includes each receiving UE indicating the acceptance of the modified SLPP session via a respective third response, or 7. The method of claim 6, wherein the modified group of one or more UEs omits one or more receiving UEs that indicate the rejection of the modified SLPP session via one or more respective third responses.

8. 2. The method of claim 1, wherein the second request includes a Layer 2 (L2) and application layer identifier 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.

9. obtaining a set of Sidelink Positioning Reference Signal (SL-PRS) measurements associated with the SLPP session; and 2. The method of claim 1, further comprising: determining a position estimate for an 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.

10. The method of claim 9 , wherein one or more position estimates for the one or more UEs are determined and transmitted to the one or more UEs.

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

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

13. receiving a second request to initiate the SLPP session from the initiating UE; 13. The method of claim 12, further comprising: sending a second response confirming the second request.

14. the second request is received via unicast, groupcast, or broadcast; or the second response is transmitted via unicast, groupcast, or broadcast; or Any combination thereof, The method of claim 13.

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

16. 13. The method of claim 12, 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 in the modified SLPP session.

17. 17. The method of claim 16, further comprising sending a third response to the initiating UE indicating acceptance or rejection or acknowledgment of the modified SLPP session by the receiving UE.

18. 13. The method of claim 12, further comprising transmitting sidelink positioning reference signal (SL-PRS) measurements associated with the SLPP session to the initiating UE.

19. The method of claim 12 , further comprising receiving a location estimate of the receiving UE from the initiating UE.

20. the first request is received via unicast, groupcast, or broadcast; or the first response is transmitted via unicast, groupcast, or broadcast; or Any combination thereof, The method of claim 11.

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

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

23. 1. A method of operating a user equipment (UE), comprising: determining a first casting mode associated with a Sidelink Positioning Protocol (SLPP) message associated with the SLPP session; determining a second casting mode associated with one or more SLPP response messages to the SLPP message; transmitting 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.

24. the first casting mode is unicast, groupcast, or broadcast; 24. The method of claim 23, wherein the second casting mode is unicast, groupcast, or broadcast.

25. the first casting mode is unicast; 24. The method of claim 23, wherein the set of one or more UEs includes a single target UE.

26. the first casting mode is groupcast; 24. The method of claim 23, wherein the set of one or more UEs comprises a group of one or more UEs.

27. 24. The method of claim 23, wherein the first casting mode is broadcast.

28. 1. A method of operating a user equipment (UE), comprising: receiving a Sidelink Positioning Protocol (SLPP) message associated with a SLPP session, the SLPP message being received according to a first casting mode and including an indication of both the first casting mode and a second casting mode associated with one or more SLPP response messages to the SLPP message; sending an SLPP response message in response to the SLPP message according to the second casting mode; A method comprising:

29. the first casting mode is unicast, groupcast, or broadcast; 29. The method of claim 28, wherein the second casting mode is unicast, groupcast, or broadcast.

30. the first casting mode is broadcast; the SLPP message includes a session identifier for the SLPP session; or 29. The method of claim 28, wherein the SLPP message includes an indication of the second casting mode, or the second casting mode is implicit from the first casting mode, and the second casting mode is broadcast.

Images