[go: up one dir, main page]

WO2024104628A1 - Prise en charge de multiples sessions de positionnement de liaison latérale dans un système de communication sans fil - Google Patents

Prise en charge de multiples sessions de positionnement de liaison latérale dans un système de communication sans fil Download PDF

Info

Publication number
WO2024104628A1
WO2024104628A1 PCT/EP2023/073805 EP2023073805W WO2024104628A1 WO 2024104628 A1 WO2024104628 A1 WO 2024104628A1 EP 2023073805 W EP2023073805 W EP 2023073805W WO 2024104628 A1 WO2024104628 A1 WO 2024104628A1
Authority
WO
WIPO (PCT)
Prior art keywords
positioning
session
identifier
initiator
slpp
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2023/073805
Other languages
English (en)
Inventor
Hyung-Nam Choi
Robin Rajan THOMAS
Dimitrios Karampatsis
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Lenovo Singapore Pte Ltd
Original Assignee
Lenovo Singapore Pte Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lenovo Singapore Pte Ltd filed Critical Lenovo Singapore Pte Ltd
Publication of WO2024104628A1 publication Critical patent/WO2024104628A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/18—Interfaces between hierarchically similar devices between terminal devices

Definitions

  • the subject matter disclosed herein relates generally to the field of implementing the supporting of multiple sidelink positioning sessions in a wireless communication system.
  • This document defines a user equipment (UE), a processor for a UE, a location management function (LMF), and methods in a UE, a processor for a UE and an LMF.
  • UE user equipment
  • LMF location management function
  • a wireless communications system may include one or multiple network communication devices, such as base stations, which may support wireless communications for one or multiple user communication devices, which may be otherwise known as user equipment (UE), or other suitable terminology.
  • the wireless communications system may support wireless communications with one or multiple user communication devices by utilizing resources of the wireless communication system (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers, or the like).
  • the wireless communications system may support wireless communications across various radio access technologies including third generation (3G) radio access technology, fourth generation (4G) radio access technology, fifth generation (5G) radio access technology, among other suitable radio access technologies beyond 5G (e.g., sixth generation (6G)).
  • SL positioning is intended to be applied for a variety of use-cases such as Vehicle-to-Everything (V2X), public safety, Industrial Internet of Things (IIoT) and commercial use cases.
  • V2X Vehicle-to-Everything
  • IIoT Industrial Internet of Things
  • the aim of SL positioning is to determine the position of a User Equipment (UE) by using SL positioning methods such as Round Trip Time (RTT)-type solutions using SL, SL-Angle of Arrival (AoA) and SL-Time Difference of Arrival (TDOA).
  • RTT Round Trip Time
  • AoA SL-Angle of Arrival
  • TDOA SL-Time Difference of Arrival
  • SL positioning will be based on new SL Positioning Reference Signals (PRS) that are transmitted over the PC5 interface and will be supported in all coverage scenarios (i.e. in-coverage, partial coverage and out-of-coverage scenarios) and for PC5-only-based and joint PC5-Uu-based operation scenarios.
  • PRS SL Positioning Reference Signals
  • LMF Location Management Function
  • SLPP Sidelink Positioning Protocol
  • the present disclosure relates to methods, apparatuses, and systems for supporting multiple SL positioning sessions in a wireless communication system.
  • a user equipment (UE) for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit, to at least a first apparatus of a wireless communication system, a first sidelink positioning protocol (SLPP) message for a sidelink (SL) positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; an initiator identifier for an initiator of the SL positioning session; and a message payload.
  • SLPP sidelink positioning protocol
  • a method in a UE for wireless communication comprising: transmitting, to at least a first apparatus of a wireless communication system, a first SLPP message for a SL positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; and initiator identifier for an initiator of the SL positioning session; and a message payload.
  • a processor for a UE for wireless communication comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output a first SLPP message for a SL positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; an initiator identifier for an initiator of the SL positioning session; and a message payload.
  • a method in a processor for a UE for wireless communication comprising: outputting a first SLPP message for a SL positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; an initiator identifier for an initiator of the SL positioning session; and a message payload.
  • an LMF for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the LMF to: transmit, to a UE of a wireless communication system, a first SLPP request for a SL positioning session, wherein the first SLPP request comprises: a session identifier for the SL positioning session; and an initiator identifier for an initiator of the SL positioning session; receive, from the UE, a first SLPP message in response to the first SLPP request, wherein the first SLPP message comprises the session identifier, the initiator identifier and a message payload.
  • a method in an LMF for wireless communication comprising: transmitting, to a UE of a wireless communication system, a first SLPP request for a SL positioning session, wherein the first SLPP request comprises: a session identifier for the SL positioning session; and an initiator identifier for an initiator of the SL positioning session; receiving, from the UE, a first SLPP message in response to the first SLPP request, wherein the first SLPP message comprises the session identifier, the initiator identifier and a message payload.
  • the invention disclosed herein tends to ensure that SL positioning capable UEs are enabled to support multiple SL positioning sessions by allowing them to distinguish between multiple SL positioning sessions.
  • the invention disclosed herein tends to ensure SL positioning can be supported for all coverage and positioning scenarios, and with or without involvement of a core mobile network of a wireless communication system.
  • the phrase “based on” shall not be construed as a reference to a closed set of conditions. For example, an example step that is described as “based on condition A” may be based on both a condition A and a condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase “based on” shall be construed in the same manner as the phrase “based at least in part on. Further, as used herein, including in the claims, a “set” may include one or more elements.
  • Figure 1 illustrates an example of a wireless communications system in accordance with aspects of the present disclosure.
  • Figure 2 illustrates an example, useful for understanding aspects of the present disclosure, of LPP message transfer 200.
  • Figure 3 illustrates an example, useful for understanding aspects of the present disclosure, of an LCS architecture 300.
  • Figure 4 illustrates an example, useful for understanding aspects of the present disclosure, of a 5GC-MT-LR procedure 400.
  • Figure 5 illustrates an example, useful for understanding aspects of the present disclosure, of a 5GC-MO-LR procedure 500.
  • Figures 6a-6c illustrate examples, useful for understanding aspects of the present disclosure, of coverage scenarios 610-630.
  • Figure 7 illustrates an example 700, useful for understanding aspects of the present disclosure, of the use of identifiers for the transfer of LPP messages.
  • Figure 8 shows an example 800, useful for understanding aspects of the present disclosure, of an SLP-initiated positioning session in SUPL.
  • Figure 9 shows an example 900, useful for understanding aspects of the present disclosure, of a SET-initiated positioning session in SUPL.
  • Figure 10 shows an example 1000, useful for understanding aspects of the present disclosure, of an SLPP message flow for session-based SL positioning.
  • Figures 1 la-1 lb shows two examples 1110 and 1120, useful for understanding aspects of the present disclosure, of exemplary V2X scenarios for such session-based SL positioning.
  • Figure 12 shows an example 1200, useful for understanding aspects of the present disclosure, of an SLPP message flow for an alternative session-based SL positioning.
  • Figure 13 illustrates an embodiment of an SLPP message 1300 according to aspects of the present disclosure.
  • Figure 14 illustrates an example 1400 of message flows in accordance with aspects of the present disclosure.
  • Figure 15 illustrates a further example 1500 of message flows in accordance with aspects of the present disclosure.
  • FIG. 16 illustrates an example of a user equipment (UE) 1600 in accordance with aspects of the present disclosure.
  • Figure 17 illustrates an example of a processor 1700 in accordance with aspects of the present disclosure.
  • Figure 18 illustrates an example of a network equipment (NE) 1800 in accordance with aspects of the present disclosure.
  • Figure 19 illustrates a flowchart of a method 1900 performed by a UE in accordance with aspects of the present disclosure.
  • Figure 20 illustrates a flowchart of a method 2000 performed by a processor in accordance with aspects of the present disclosure.
  • Figure 21 illustrates a flowchart of a method 2100 performed by an NE in accordance with aspects of the present disclosure.
  • the following functionalities shall be supported by the new SLPP: SL Positioning Capability Transfer; SL Positioning Assistance Data exchange; SL Location Information Transfer; Error handling; Abort.
  • the cast types which are considered for SLPP signaling over the PC5 interface include unicast, groupcast and broadcast, but unicast/one-to-one operation is assumed as baseline for exchange of SLPP signaling between UEs.
  • the SLPP will support session-based SL positioning operation between two endpoints, e.g. between i) Target UE and LMF; or ii) between Target UE and Server UE, in order to obtain location related measurements or a location estimate or to transfer assistance data.
  • session-based SL positioning operation a single SLPP session is used to support a single location request (e.g., a Mobile Terminated Location Request (MT-LR), or a Mobile Originated Location Request (MO-LR)).
  • MT-LR Mobile Terminated Location Request
  • MO-LR Mobile Originated Location Request
  • Each SLPP session comprises one or more SLPP transactions, with each SLPP transaction performing a single operation (capability exchange, assistance data transfer, or location information transfer). Furthermore, multiple SLPP sessions can be used between the involved endpoints to support multiple different location requests. As a consequence, each endpoint may be involved in multiple SL positioning sessions.
  • a straightforward solution for supporting multiple SL positioning sessions is to adopt a solution similar to what has been specified in SUPL. That means an SLPP message carries a session ID that comprises a concatenated pair of session IDs from two endpoints. However, this solution would result in additional signaling overhead and complexity when multiple endpoints are involved in an SL positioning session.
  • the format of an SLPP message comprises the parameters “Session ID”, “Initiator ID” and the Message payload.
  • the parameter “Session ID” is set by the initiator of the SL positioning session and tends to be used in all SLPP messages associated to this SL positioning session.
  • the parameter “Initiator ID” is set by the initiator of the SL positioning session and tends to be used in all SLPP messages associated to this SL positioning session. This tends to allow, SL positioning capable UEs to be enabled to support multiple SL positioning sessions by allowing them to distinguish between multiple SL positioning sessions. This also tends to allow SL positioning to be supported for all coverage and positioning scenarios, and with or without involvement of a core mobile network of a wireless communications network.
  • FIG. 1 illustrates an example of a wireless communications system 100 in accordance with aspects of the present disclosure.
  • the wireless communications system 100 may include one or more NE 102, one or more UE 104, and a core network (CN) 106.
  • the wireless communications system 100 may support various radio access technologies.
  • the wireless communications system 100 may be a 4G network, such as an LTE network or an LTE- Advanced (LTE-A) network.
  • the wireless communications system 100 may be an NR network, such as a 5G network, a 5G-Advanced (5G-A) network, or a 5G ultrawideband (5G-UWB) network.
  • 5G-A 5G-Advanced
  • 5G-UWB 5G ultrawideband
  • the wireless communications system 100 may be a combination of a 4G network and a 5G network, or other suitable radio access technology including Institute of Electrical and Electronics Engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20.
  • IEEE Institute of Electrical and Electronics Engineers
  • Wi-Fi Wi-Fi
  • WiMAX IEEE 802.16
  • IEEE 802.20 The wireless communications system 100 may support radio access technologies beyond 5G, for example, 6G. Additionally, the wireless communications system 100 may support technologies, such as time division multiple access (TDMA), frequency division multiple access (FDMA), or code division multiple access (CDMA), etc.
  • TDMA time division multiple access
  • FDMA frequency division multiple access
  • CDMA code division multiple access
  • the one or more NE 102 may be dispersed throughout a geographic region to form the wireless communications system 100.
  • One or more of the NE 102 described herein may be or include or may be referred to as a network node, a base station, a network element, a network function, a network entity, a radio access network (RAN), a NodeB, an eNodeB (eNB), a next-generation NodeB (gNB), or other suitable terminology.
  • An NE 102 and a UE 104 may communicate via a communication link, which may be a wireless or wired connection.
  • an NE 102 and a UE 104 may perform wireless communication (e.g., receive signaling, transmit signaling) over a Uu interface.
  • An NE 102 may provide a geographic coverage area for which the NE 102 may support services for one or more UEs 104 within the geographic coverage area.
  • an NE 102 and a UE 104 may support wireless communication of signals related to services (e.g., voice, video, packet data, messaging, broadcast, etc.) according to one or multiple radio access technologies.
  • an NE 102 may be moveable, for example, a satellite associated with a non-terrestrial network (NTN).
  • NTN non-terrestrial network
  • different geographic coverage areas associated with the same or different radio access technologies may overlap, but the different geographic coverage areas may be associated with different NE 102.
  • the one or more UE 104 may be dispersed throughout a geographic region of the wireless communications system 100.
  • a UE 104 may include or may be referred to as a remote unit, a mobile device, a wireless device, a remote device, a subscriber device, a transmitter device, a receiver device, or some other suitable terminology.
  • the UE 104 may be referred to as a unit, a station, a terminal, or a client, among other examples.
  • the UE 104 may be referred to as an Internet-of-Things (loT) device, an Internet-of-Everything (loE) device, or machine-type communication (MTC) device, among other examples.
  • LoT Internet-of-Things
  • LoE Internet-of-Everything
  • MTC machine-type communication
  • a UE 104 may be able to support wireless communication directly with other UEs 104 over a communication link.
  • a UE 104 may support wireless communication directly with another UE 104 over a device-to-device (D2D) communication link.
  • D2D device-to-device
  • the communication link may be referred to as a sidelink.
  • a UE 104 may support wireless communication directly with another UE 104 over a PC5 interface.
  • An NE 102 may support communications with the CN 106, or with another NE 102, or both.
  • an NE 102 may interface with other NE 102 or the CN 106 through one or more backhaul links (e.g., SI, N2, or network interface).
  • the NE 102 may communicate with each other directly.
  • the NE 102 may communicate with each other or indirectly (e.g., via the CN 106.
  • one or more NE 102 may include subcomponents, such as an access network entity, which may be an example of an access node controller (ANC).
  • An ANC may communicate with the one or more UEs 104 through one or more other access network transmission entities, which may be referred to as a radio heads, smart radio heads, or transmission-reception points (TRPs).
  • TRPs transmission-reception points
  • the CN 106 may support user authentication, access authorization, tracking, connectivity, and other access, routing, or mobility functions.
  • the CN 106 may be an evolved packet core (EPC), or a 5G core (5GC), which may include a control plane entity that manages access and mobility (e.g., a mobility management entity (MME), an access and mobility management function (AMF)) and a user plane entity that routes packets or interconnects to external networks (e.g., a serving gateway (S-GW), a Packet Data Network (PDN) gateway (P-GW), or a user plane function (UPF)).
  • EPC evolved packet core
  • 5GC 5G core
  • MME mobility management entity
  • AMF access and mobility management function
  • S-GW serving gateway
  • PDN gateway Packet Data Network gateway
  • UPF user plane function
  • control plane entity may manage non-access stratum (NAS) functions, such as mobility, authentication, and bearer management (e.g., data bearers, signal bearers, etc.) for the one or more UEs 104 served by the one or more NE 102 associated with the CN 106.
  • NAS non-access stratum
  • the CN 106 may communicate with a packet data network over one or more backhaul links (e.g., via an SI, N2, or another network interface).
  • the packet data network may include an application server.
  • one or more UEs 104 may communicate with the application server.
  • a UE 104 may establish a session (e.g., a protocol data unit (PDU) session, or the like) with the CN 106 via an NE 102.
  • the CN 106 may route traffic (e.g., control information, data, and the like) between the UE 104 and the application server using the established session (e.g., the established PDU session).
  • the PDU session may be an example of a logical connection between the UE 104 and the CN 106 (e.g., one or more network functions of the CN 106).
  • the NEs 102 and the UEs 104 may use resources of the wireless communications system 100 (e.g., time resources (e.g., symbols, slots, subframes, frames, or the like) or frequency resources (e.g., subcarriers, carriers)) to perform various operations (e.g., wireless communications).
  • the NEs 102 and the UEs 104 may support different resource structures.
  • the NEs 102 and the UEs 104 may support different frame structures.
  • the NEs 102 and the UEs 104 may support a single frame structure.
  • the NEs 102 and the UEs 104 may support various frame structures (i.e., multiple frame structures).
  • the NEs 102 and the UEs 104 may support various frame structures based on one or more numerologies.
  • One or more numerologies may be supported in the wireless communications system 100, and a numerology may include a subcarrier spacing and a cyclic prefix.
  • a first subcarrier spacing e.g., 15 kHz
  • a normal cyclic prefix e.g. 15 kHz
  • the first subcarrier spacing e.g., 15 kHz
  • a time interval of a resource may be organized according to frames (also referred to as radio frames).
  • Each frame may have a duration, for example, a 10 millisecond (ms) duration.
  • each frame may include multiple subframes.
  • each frame may include 10 subframes, and each subframe may have a duration, for example, a 1 ms duration.
  • each frame may have the same duration.
  • each subframe of a frame may have the same duration.
  • a time interval of a resource may be organized according to slots.
  • a subframe may include a number (e.g., quantity) of slots.
  • the number of slots in each subframe may also depend on the one or more numerologies supported in the wireless communications system 100.
  • Each slot may include a number (e.g., quantity) of symbols (e.g., OFDM symbols).
  • the number (e.g., quantity) of slots for a subframe may depend on a numerology.
  • a slot may include 14 symbols.
  • a slot may include 12 symbols.
  • an electromagnetic (EM) spectrum may be split, based on frequency or wavelength, into various classes, frequency bands, frequency channels, etc.
  • the wireless communications system 100 may support one or multiple operating frequency bands, such as frequency range designations FR1 (410 MHz - 7.125 GHz), FR2 (24.25 GHz - 52.6 GHz), FR3 (7.125 GHz - 24.25 GHz), FR4 (52.6 GHz - 114.25 GHz), FR4a or FR4-1 (52.6 GHz - 71 GHz), and FR5 (114.25 GHz - 300 GHz).
  • FR1 410 MHz - 7.125 GHz
  • FR2 24.25 GHz - 52.6 GHz
  • FR3 7.125 GHz - 24.25 GHz
  • FR4 (52.6 GHz - 114.25 GHz
  • FR4a or FR4-1 52.6 GHz - 71 GHz
  • FR5 114.25 GHz - 300 GHz
  • the NEs 102 and the UEs 104 may perform wireless communications over one or more of the operating frequency bands.
  • FR1 may be used by the NEs 102 and the UEs 104, among other equipment or devices for cellular communications traffic (e.g., control information, data).
  • FR2 may be used by the NEs 102 and the UEs 104, among other equipment or devices for short-range, high data rate capabilities.
  • FR1 may be associated with one or multiple numerol ogies (e.g., at least three numerologies).
  • FR2 may be associated with one or multiple numerologies (e.g., at least 2 numerologies).
  • 3GPP Rel-15 only Cell-ID and RAT -independent positioning methods (e.g. GNSS) are supported in NR.
  • RAT-dependent for both FR1 and FR2
  • RAT-independent positioning methods such as PPP and RTK
  • Table 3 shows the list of RAT- dependent positioning methods which were specified in 3GPP Rel-16.
  • LPP LTE Positioning Protocol
  • Figure 2 illustrates an example, useful for understanding aspects of the present disclosure, of LPP message transfer 200 between an LMF and a UE.
  • the figure shows a UE 210, an NG-RAN node 220, an AMF 230 and an LMF 240.
  • the figure also shows the messaging 201-206 between the UE 210, NG-RAN node 220, AMF 230 and LMF 240.
  • LPP messages are shown as being carried as transparent PDUs across intermediate network interfaces using the appropriate protocols.
  • the LMF 240 sends an LPP message to the AMF 230.
  • the LPP message may be the Request Capabilities message to request the UE 210 to send its positioning capabilities.
  • the AMF 230 transports the received LPP message to the NG-RAN node 220 by including the LPP message into the LPP message container of the DL NAS Transport message.
  • the NG-RAN node 220 transports the received LPP message container to the UE 210 by including the LPP message container into the RRC DLInformationTransfer message as specified in 3GPP Technical Specification 38.331 titled “NR Radio Resource Control (RRC) Protocol specification”.
  • RRC Radio Resource Control
  • a further step 204 upon receiving the Request Capabilities message, the UE 210 generates the Provide Capabilities message as response.
  • the UE 210 sends the Provide Capabilities message to the NG-RAN node 220 by including the LPP message into the RRC ULInformationTransfer message as specified in 3GPP Technical Specification 38.331 titled “NR Radio Resource Control (RRC) Protocol specification.
  • RRC Radio Resource Control
  • the NG-RAN node 220 transports the LPP message received from the UE 210 to the AMF 230 by including the LPP message into the LPP message container of the UL NAS Transport message.
  • the AMF 230 extracts the LPP message from the received NAS message/LPP message container and sends it to the LMF 240.
  • 3GPP includes a Location Services (LCS) feature, that provides the mechanisms to support mobile location services for operators, subscribers and third-party service providers.
  • LCS Location Services
  • Examples of location-based services include emergency services, tracking services, location-based information services (navigation, city sightseeing, location dependent content broadcast, mobile yellow pages etc.).
  • the location information may be requested by and reported to a client (application) associated with a UE, or by a client within or attached to the 5GC.
  • FIG. 3 illustrates an example, useful for understanding aspects of the present disclosure, of an LCS architecture 300 where an external LCS client requests the 5GC for the current location of the Target UE.
  • the relation of the LCS entities is shown.
  • the architecture 300 comprises a target UE 310, a gNB 320, an AMF 330, an LMF 340, a GMLC 350 and an LCS Client 360.
  • the various interactions of these entities will now be briefly described.
  • the external LCS Client 360 interacts with the GMLC 350 for the purpose of obtaining location information for one or more (Target) UEs 310.
  • the LCS Client 360 may reside in a UE and may be implemented as hardware (HW) or software (SW) (i.e., an application). Examples for the LCS client 360 include 911 emergency dispatch centre (PSAP), and Google maps.
  • PSAP 911 emergency dispatch centre
  • Google maps Google maps.
  • the GMLC 350 is the first node an external LCS client 360 accesses in a public land mobile network (PLMN) and works as a location server to an external application, for location information.
  • PLMN public land mobile network
  • the LMF 340 manages the overall co-ordination and scheduling of resources required for the location of a UE 310 that is registered with or accessing 5GC. It also calculates or verifies a final location and any velocity estimate and may estimate the achieved accuracy.
  • the LMF 340 processes the location services request which may include transferring assistance data to the Target UE 310 to assist with UE-based and/or UE-assisted positioning and/or may include positioning of the Target UE 310.
  • the LMF 340 then returns the position estimate for a UE 310 back to the AMF 330.
  • the AMF 330 In the case of a location service requested by an entity other than the AMF 330 (e.g., a GMLC 350 or UE 310), the AMF 330 returns the location result to this entity.
  • the LMF 340 works as location server.
  • the AMF 330 contains functionality responsible for managing positioning for a Target UE 310 for all types of location request.
  • the AMF 330 receives a request for some location services associated with a particular Target UE 310 from another entity (e.g., GMLC 350 or UE 310) or the AMF 330 itself decides to initiate some location service on behalf of a particular Target UE 310 (e.g., for an emergency call from the UE 310).
  • the AMF 330 then sends a location services request to an LMF 340.
  • the NG-RAN node (i.e. gNB) 320 is involved in the handling of various positioning procedures including positioning of a Target UE 310, provision of location related information not associated with a particular Target UE 310 and transfer of positioning messages between an AMF 330 or LMF 340 and a Target UE 310.
  • the Target UE 310 is the UE whose position (absolute or relative) is to be obtained by the network or by the UE itself.
  • NRPPa is the C-plane radio network layer signaling protocol between a NG- RAN node (gNB) 320 and the LMF 340.
  • LPP is a point-to-point positioning protocol that supports positioning and location related services for a Target device 310.
  • LPP is terminated between a Target device 310 and an LMF 340.
  • 3GPP specifies a number of different types of location requests. The types of location requests will now be briefly introduced.
  • a Network Induced Location Request is where a serving AMF for a UE initiates localization of the UE for a regulatory service (e.g. an emergency call from the UE) or for verification of a UE location (country or international area) for NR satellite access.
  • a regulatory service e.g. an emergency call from the UE
  • a UE location country or international area
  • a Mobile Terminated Location Request is where an LCS client external to or internal to a serving PLMN sends a location request to the PLMN for the location of a Target UE.
  • a Mobile Originated Location Request is where a UE sends a request to a serving PLMN for location related information for the UE itself.
  • An Immediate Location Request is where an LCS client sends or instigates a location request for a Target UE (or group of Target UEs) and expects to receive a response containing location information for the Target UE (or group of Target UEs) within a short time period which may be specified using LCS QoS. In regulatory cases, one or more responses of the Target UEs location information can be expected.
  • An immediate location request may be used for an NLLR, MT-LR or MO-LR.
  • a Deferred Location Request is where an LCS client sends a location request to a PLMN for a Target UE (or group of Target UEs) and expects to receive a response containing the indication of event occurrence and location information if requested for the Target UE (or group of Target UEs) at some future time (or times), which may be associated with specific events associated with the Target UE (or group of Target UEs).
  • Deferred location requests are supported only for an MT-LR.
  • FIG 4 illustrates an example, useful for understanding aspects of the present disclosure, of a 5GC -MT-LR procedure 400 for the regulatory location service location service for non-roaming scenario as specified in 3GPP Technical Specification 23.273 titled “5G System (5GS) Location Services (LCS)-Stage 2”.
  • 5GS 5G System
  • LCS Location Services
  • an external LCS client requests the 5GC for the current location of the Target UE. It is assumed that the Target UE is identified using a Subscription Permanent Identifier (SUPI) or a Generic Public Subscription Identifier (GPSI).
  • SUPI Subscription Permanent Identifier
  • GPSI Generic Public Subscription Identifier
  • Figure 4 illustrates a UE 410, an NG-RAN 420, an AMF 430, an LMF 440, a GMLC 450, and an external client 460.
  • the various message flows 401-409 between these entities will now be described.
  • the external client 460 sends a request to the GMLC 450 for the current location of the Target UE 410.
  • the request includes amongst other the requested LCS Quality of Service (QoS).
  • QoS Quality of Service
  • the GMLC 450 sends a
  • Namf Location ProvidePositioninglnfo Request to the AMF 430 to request the current location of the UE 410.
  • the AMF 430 initiates a network triggered Service Request procedure to establish a signaling connection with the UE 410.
  • the AMF 430 selects an LMF 440 based on the available information (e.g. requested LCS QoS, LMF capabilities, LMF load, LMF location) or based on AMF local configuration (if AMF 430 is configured locally with a mapping table of UE identity and LMF address).
  • available information e.g. requested LCS QoS, LMF capabilities, LMF load, LMF location
  • AMF local configuration if AMF 430 is configured locally with a mapping table of UE identity and LMF address.
  • the AMF 430 sends a Nlmf Location DetermineLocation Request to the selected LMF 440 to request the current location of the UE 410.
  • the request includes amongst other items, the requested LCS QoS and the UE positioning capability, if available.
  • the LMF 440 performs positioning procedures and determines the geographical location of the UE 410.
  • the AMF 430 returns the Namf Location ProvidePositioninglnfo Response towards the GMLC 450 to return the current location of the UE 410.
  • the GMLC 450 sends the location service response, including the location information of the UE 410, to the external client 460.
  • FIG. 5 illustrates an example, useful for understanding aspects of the present disclosure, of a 5GC-MO-LR procedure 500 as specified in 3GPP Technical Specification 23.273 titled “5G System (5GS) Location Services (LCS)-Stage 2”, where a UE requests the serving PLMN to obtain the location of itself or just provide positioning assistance data. It is assumed that an LCS client resides in the UE and initiates the MO-LR.
  • 5GS 5G System
  • LCS Location Services
  • the figure shows a UE 515, an NG-RAN 520, an AMF 530, an LMF 540, a GMLC 550 and an external client 560.
  • the message flows 501-511 between these entities will now be described.
  • a first step 501 if the UE 515 is in a CM-IDLE state, the UE 515 instigates the UE triggered Service Request procedure in order to establish a signaling connection with the AMF 530.
  • the UE 515 sends an MO-LR Request message included in a UL NAS TRANSPORT message to the AMF 530.
  • location services can be requested i.e., location estimate of the UE 515, location estimate of the UE 515 to be sent to an LCS client 560, or positioning assistance data. If the UE 515 is requesting its own location or that its own location be sent to an LCS client 560 (e.g. for using a locationbased service), this message carries the requested LCS QoS information (e.g. accuracy, response time).
  • the message also includes the identity of the LCS client 560 and the address of the GMLC 550 through which the LCS client 560 should be accessed. If the UE 515 is instead requesting positioning assistance data, the embedded LPP message specifies the type of assistance data and the positioning method for which the assistance data applies.
  • the AMF 530 selects an LMF 540 based on the available information (e.g. requested LCS QoS, LMF capabilities, LMF load, LMF location) or based on AMF local configuration (if AMF 530 is configured locally with a mapping table of UE identity and LMF address).
  • available information e.g. requested LCS QoS, LMF capabilities, LMF load, LMF location
  • AMF local configuration if AMF 530 is configured locally with a mapping table of UE identity and LMF address.
  • the AMF 530 sends a Nlmf Location DetermineLocation Request to the selected LMF 540.
  • the request includes amongst other an indication whether a location estimate, or positioning assistance data is requested.
  • a further step 505 if the UE 515 is requesting its own location, the LMF 540 performs positioning procedures and determines the geographical location of the UE 515. If the UE 515 is instead requesting positioning assistance data, the LMF 540 transfers this data to the UE 515.
  • a further step 506 when a location estimate best satisfying the requested LCS QoS has been obtained or when the requested location assistance data has been transferred to the UE 515, the LMF 540 returns a Nlmf Location DetermineLocation Response towards the AMF 530.
  • the response includes the location estimate, its age and accuracy. If the UE 515 is requesting positioning assistance data, steps 507 to 511 are skipped.
  • the AMF 530 sends a Ngmlc Location LocationUpdate Request to the GMLC 550.
  • the request carries the identity of the UE 515, the event causing the location estimate (5GC- MO-LR) and the location estimate, its age and obtained accuracy indication.
  • the request includes the identity of the LCS Client 560.
  • the GMLC 550 transfers the Location Information message to the LCS client 560, carrying the identity of the UE 515, the event causing the location estimate (5GC-M0 LR) and the location estimate in accordance with the LCS QoS requested by the UE 515.
  • the LCS Client 560 sends the GMLC 550 a Location Information Ack message signaling that the location estimate of the UE 515 has been received successfully.
  • the GMLC 550 sends a Ngmlc Location LocationUpdate Response to AMF 530 to acknowledge the successful reception of the location estimate by the LCS Client 560.
  • the AMF 530 sends an MO-LR Response message included in a DL NAS TRANSPORT message. If the UE 515 is requesting its own location, the response carries any location estimate requested by the UE 515 and the timestamp of the location estimate (if available) including the indication received from LMF 540 whether the obtained location estimate satisfies the requested accuracy or not, or an indicator whether a location estimate was successfully transferred to the identified LCS client 560.
  • the feature SL communication and discovery was introduced in 3GPP Rel-16 NR to support V2X and non-V2X services.
  • the interface used for SL communication (transmission/reception of user traffic) and discovery between two UEs (i.e., UE1 and UE2) in proximity is denoted as PC5.
  • Table 5 defines the different coverage scenarios which are supported for SL communication and discovery where UE1 and UE2 are located incoverage (IC), partial coverage (PC) and out-of-coverage (OOC) of a cell.
  • Figures 6A-6C illustrate examples, useful for understanding aspects of the present disclosure, of the coverage scenarios defined in Table 5. More specifically, Figure 6A shows a first scenario 610 where a UE1 611 and a UE2 612 are located OOC of a cell 613. Figure 6B shows a further scenario 620 where a UE1 621 and a UE2 622 are located in PC of a cell 623. Figure 6C shows a further scenario 630 where a UE1 631 and a UE2 632 are located IC of a cell 633.
  • a SL communication over PC5 is defined as a logical connection between two UEs and is identified by a pair of Source and Destination Layer-2 IDs.
  • Source and Destination Layer-2 IDs identify the source and the target of the SL communication, respectively.
  • a corresponding pair of a Source Layer-2 ID and a Destination Layer-2 ID is used.
  • the Layer-2 IDs are transmitted in the MAC subheader associated with the SL-SCH.
  • the SL communication is based on the Proximity-based Services (ProSe) feature.
  • the SL discovery procedure may need to be performed by the UEs.
  • the SL discovery procedure is used by UE(s) to discover or to be discovered by other UE(s) in proximity. For instance, a UE that wants to discover other UE(s) in proximity transmits a discovery message over PC5. Other UE(s) in proximity monitor the discovery message and if they want to be discovered they respond with a discovery response message. After discovery, the UE can establish a SL communication connection with each of the UE(s) which responded.
  • SL discovery messages and SL communication user traffic are sent on the same physical sidelink shared channel (PSSCH) but using different SL resources.
  • PSSCH physical sidelink shared channel
  • the range for SL communication and discovery may vary from 50m up to 1000m. More details relating to NR sidelink communication and discovery can be found in the 3GPP Technical Specification 23.304 titled, “Proximity based Services (ProSe) in the 5G System (5GS) ” .
  • the LPP supports session-based positioning operation between two endpoints, i.e., the Target UE and the LMF, in order to obtain location related measurements or a location estimate or to transfer assistance data.
  • a single LPP session is used to support a single location request (e.g., for a single MT-LR, MO-LR or NI-LR). Multiple LPP sessions can be used between the same endpoints to support multiple different location requests.
  • Each LPP session comprises one or more LPP transactions, with each LPP transaction performing a single operation (capability exchange, assistance data transfer, or location information transfer).
  • FIG. 7 illustrates an example 700, useful for understanding aspects of the present disclosure, of the use of identifiers for the transfer of LPP messages in the current Uu-based positioning operation.
  • the example 700 shows a target UE 710, an NG-RAN node 720, an AMF 730, and an LMF 740.
  • the AMF 730 is the central entity that manages the LCS service requests (e.g. MT-LR, MO-LR, NI-LR).
  • the AMF 730 initiates a location/positioning session for a Target UE 710.
  • the AMF 730 selects an LMF 740.
  • the AMF 730 assigns a Routing ID/LCS Correlation ID for the LPP message transfer 703-704 between the selected LMF 740 and the Target UE 710.
  • the Routing ID is used for the LPP message transfer 704 between AMF 730 and UE 710 via the DL NAS TRANSPORT/UL NAS TRANSPORT messages.
  • the LCS Correlation ID is used for the LPP message transfer 703 between AMF 730 and LMF 740.
  • the Routing ID and the LCS Correlation ID are identical and according to 3GPP Technical Specification 29.572 (titled, “5G System Location Management Services-Stage 3”) the Routing ID/LCS Correlation ID is a character string of length 1-255 characters.
  • the AMF 730 assigns the IDs to uniquely identify the LMF 740 and the positioning session between the AMF 730 and LMF 740 when a positioning session is being used. That means, if the Target UE 710 may be involved in multiple positioning sessions, different Routing IDs/LCS Correlation IDs are used to distinguish the different sessions. Furthermore, in LPP the different sessions can be distinguished by using transaction identifiers.
  • SUPL is a Secure User-Plane Location protocol as defined by the OMA LOC WG in OMA-TS-ULP-V2 0 6 titled, “User Plane Location Protocol Approved Version 2.0.6” .
  • SUPL employs secure TCP/IP protocol stack over a data radio bearer for transferring location related information between the SUPL server in the network (SLP) and the SUPL client in the device (SET).
  • Figure 8 shows an example 800, useful for understanding aspects of the present disclosure, of an SLP-initiated positioning session in SUPL for the non-roaming case and when there is a direct communication between the SLP and SET.
  • the example 800 shows a SUPL agent 810, a SLP 820 and a Target SET 830.
  • the message flow 801-808 between the SUPL agent 810, SLP 820 and Target SET 830, will now be briefly described.
  • a first step 801 the SUPL Agent 810 in the SLP 820 sends an MLP SLIR message to the SLP 820 in order to request the current location of the Target SET 830.
  • the SLP 820 verifies that the Target SET 830 supports SUPL and is currently not roaming. This is illustrated as, ‘SET Lookup, Routing Info ’.
  • the SLP 820 initiates a SUPL session with the Target SET 830 by sending a SUPL INIT message.
  • the message contains the requested positioning method.
  • a further step 804 when the SUPL INIT message is received by the Target SET 830 it establishes a secure TCP/IP connection to the SLP 820. This is illustrated as, ‘Data Connection Setup
  • the Target SET 830 sends a SUPL POS INIT message to start a positioning session with the SLP 820.
  • the message contains the Target SET capabilities including the supported positioning methods, positioning modes and positioning protocols, e.g. LPP.
  • the SLP 820 determines the positioning method and exchanges with the Target SET 830 several successive positioning procedure messages using LPP, as needed to determine the position.
  • the LPP messages are carried in the Positioning Payload IE of the SUPL POS message.
  • the SLP 820 calculates the position estimate based on the received positioning measurements (in case of SET-assisted positioning mode) or the Target SET 830 calculates the position estimate based on assistance data obtained from the SLP 820 (in case of SET -based positioning mode).
  • a further step 807 when the position calculation is complete the SLP 820 sends the SUPL END message to the Target SET 830 informing it that the SUPL session is finished.
  • the Target SET 830 then releases the secure TCP/IP connection to the SLP 820.
  • the SLP 820 sends the position estimate back to the SUPL Agent 810 in an MLP SLIA message.
  • Figure 9 shows an example 900, useful for understanding aspects of the present disclosure, of a SET-initiated positioning session in SUPL for the non-roaming case and when there is a direct communication between the SLP and SET.
  • the example 900 comprises a SLP 920 and a SUPL agent/target SET 930.
  • the message flows 901-907 between the SLP 920 and SUPL agent/target SET 930 will now be briefly described.
  • a first step 901 the SUPL Agent in the Target SET 930 receives a request for the current location of the device from an application running on the device.
  • the Target SET 930 establishes a secure TCP/IP connection to the SLP 920. This is illustrated as, ‘Data Connection Setup
  • the Target SET 930 sends a SUPL START message to start a SUPL session with the SLP 920.
  • the message contains the Target SET capabilities including the supported positioning methods, positioning modes and positioning protocols, e g. LPP.
  • the SLP 920 verifies that the Target SET 930 is currently not roaming. This is illustrated as, ‘Routing Info
  • the SLP 920 responds with a SUPL RESPONSE message to the Target SET 930.
  • the message contains the requested positioning method.
  • the Target SET 930 sends a SUPL POS INIT message to start a positioning session with the SLP 920.
  • the SLP 920 and Target SET 930 exchange several successive positioning procedure messages using LPP, as needed to determine the position.
  • the LPP messages are carried in the Positioning Payload IE of the SUPL POS message.
  • the SLP 920 calculates the position estimate based on the received positioning measurements (in case of SET-assisted positioning mode) or the SET 930 calculates the position estimate based on assistance data obtained from the SLP 920 (in case of SETbased positioning mode).
  • a further step 907 when the position calculation is complete the SLP 920 sends the SUPL END message to the Target SET 930 informing it that the SUPL session is finished.
  • the Target SET 930 then releases the secure TCP/IP connection to the SLP 920.
  • Each SUPL message as shown in Figure 8 and Figure 9 contains a unique session ID.
  • the main purpose of the session ID is to allow for multiple simultaneous positioning sessions on both the SLP 820, 920 and the SET 830, 930, and to allow both SLP 820, 920 and SET 830, 930 to distinguish between multiple simultaneous positioning sessions.
  • the session ID consists of two parts, a SET value (SET Session ID) concatenated with an SLP value (SLP Session ID), as described in Table 6 below.
  • the SLP 820, 920 assigns only a value to the SLP Session ID since the SET 830, 930 assigns a value to the SET Session ID when it receives the SUPL INIT message. Any further SUPL messages contain the resultant combined session ID for the remainder of the session.
  • the SET 830, 930 assigns only a value to the SET Session ID.
  • the SET 830, 930 does not send an SLP Session ID in the message since no SLP Session ID yet exists.
  • the SLP 820, 920 assigns a value to the SLP Session ID when it receives the SUPL START message. All further SUPL messages contain the resultant combined session ID for the remainder of the session.
  • Figure 10 shows an example 1000, useful for understanding aspects of the present disclosure, of an SLPP message flow for session-based SL positioning. More specifically, Figure 10 shows an MT-LR procedure in which the UE1 1010, e.g. Server UE, calculates the location of the UE2 1015, e.g. Target UE, based on positioning measurements received from the UE2 1015.
  • the UE1 1010 e.g. Server UE
  • the UE2 1015 e.g. Target UE
  • a first step 1001a the UE1 1010 starts the SL discovery procedure to discover the UE2 1015. It is assumed that the UE1 1010 was able to discover the UE2 1015.
  • the UE1 1010 sends the UE2 1015 an SLPP Requestcapabilities message to request the UE2’s 1015 capability information for SL positioning.
  • the UE2 1015 sends the UE1 1010 an SLPP ProvideCapabilities message to indicate its SL positioning capabilities including the supported positioning modes and positioning methods.
  • SLPP ProvideCapabilities message to indicate its SL positioning capabilities including the supported positioning modes and positioning methods.
  • the UE2 1015 supports only a UE-assisted positioning mode, and SL-AoA and SL-TDOA positioning methods.
  • the UE1 1010 sends the UE2 1015 an SLPP RequestLocationlnformation message to request positioning measurements for SL-TDOA from the UE2 1015.
  • the UE2 1015 has no stored SL-TDOA assistance data and therefore, sends the UE1 1010 an SLPP RequestAssistanceData message to request SL- TDOA assistance data from the UE1 1010.
  • the UE1 1010 sends the UE2 1015 an SLPP ProvideAssistanceData message that contains the requested SL-TDOA assistance data.
  • step 1006 in accordance with the assistance data received from the UE1 1010 in step 1005 the UE2 1015 performs positioning measurements for SL-TDOA.
  • a further step 1007 upon completing the positioning measurements the UE2 1015 sends the UE1 1010 an SLPP ProvideLocationlnformation message that contains the positioning measurements for SL-TDOA. Based on the received positioning measurements the UE1 1010 then calculates the UE2’s 1015 location.
  • the involved UEs 1010, 1015 mutually exchange a series of messages over a period of time during the established SL positioning session.
  • This kind of structured message flow ensures that location related information is only exchanged that is needed to determine the position of a UE in accordance with the requested LCS QoS. For instance, if UE1 1010 has already stored UE2’s 1015 SL positioning capability information (e.g. from a previous SL positioning session) then Step 1001b and Step 1002 can be omitted. Likewise, if UE2 1015 has already stored SL-TDOA assistance data then Step 1004 and Step 1005 can be omitted as well.
  • FIG. 1 la-1 lb shows two examples 1110 and 1120, useful for understanding aspects of the present disclosure, of exemplary V2X scenarios for such session-based SL positioning.
  • a traffic light 1111 and a vehicle 1112 are equipped with UEs (UE1 1111a, UE2 1112a) which are capable of SL positioning.
  • the UE2 1112a is in the vicinity of UE1 1111a and wants to determine its distance to UE1 111 la.
  • a second scenario 1120 and denoted “scenario B” three vehicles 1121, 1122, 1123 are equipped with UEs (UE1 1121a, UE2 1122a, UE3 1123a) which are capable of SL positioning.
  • the UE2 1122a is in the vicinity of UE1 1121a and UE3 1123a, and wants to determine its distance to the other UEs 1121a, 1123a.
  • the distance of UE2 1122a to other UE(s) 1121a, 1123a needs to be determined relatively fast, so that there may be not sufficient time to perform a session-based SL positioning procedure between the involved UEs 1121a, 1122a, 1123a.
  • Figure 12 shows an example 1200, useful for understanding aspects of the present disclosure, of an SLPP message flow for an alternative session-based SL positioning according to the scenario 1110 of Figure 11 A. More specifically, the example shows a first UE 1210 “UE1” and a second UE 1215 “UE2”. The message flows 1201-1206 between the UEs 1210, 1215, will now be briefly described.
  • a first step 1201a the UE2 1215 starts the SL discovery procedure to discover other UEs in its vicinity. It is assumed that the UE2 1215 was able to discover the UE1 1210.
  • the UE1 1210 (i.e., the UE1 111 la in the traffic light 1111 of Figure 11 A) broadcasts in an unsolicited manner its capability information for SL positioning. It is assumed that the UE1 1210 can act as Server UE and Anchor UE, and supports positioning/ranging and SL-TDOA positioning methods.
  • the UE1 1210 broadcasts in an unsolicited manner the SL-TDOA assistance data.
  • the UE2 1215 in accordance with the capability information and assistance data received from the UE1 1210 in Steps 1201 and 1202 performs positioning measurements for SL- TDOA. It is assumed that the UE2 1215 supports SL-TDOA positioning method as well.
  • a further step 1204 upon completing the positioning measurements the UE2 1215 sends the UE1 1210 an SLPP ProvideLocationlnformation message that contains the positioning measurements for SL-TDOA and the request to determine its distance to UE1 1210. It is assumed that the UE2 1215 only supports UE-assisted positioning modes.
  • the SLPP ProvideLocationlnformation message may be sent to UE1 1210 per broadcast or unicast.
  • the UE1 1210 calculates the UE2’s 1215 distance to UE1 1210 in accordance with the received SLPP ProvideLocationlnformation message in Step 1204.
  • the UE1 1210 sends the UE2 1215 the SLPP ProvideLocationlnformation message that contains the calculated distance of UE2 1215 to UE1 1210.
  • the SLPP ProvideLocationlnformation message may be sent to UE2 1215 per broadcast or unicast.
  • An ‘Initiator device’ initiates a SL positioning/ranging session. It may be a network entity, (e.g., gNB, LMF) or UE/roadside unit (RSU).
  • a network entity e.g., gNB, LMF
  • RSU UE/roadside unit
  • a ‘Responder device’ responds to a SL positioning/ranging session from an initiator device. It may be a network entity, (e.g., gNB, LMF) or UE/roadside unit (RSU).
  • a network entity e.g., gNB, LMF
  • RSU UE/roadside unit
  • a ‘Target UE’ is a UE of interest whose position (absolute or relative) is to be obtained by the network or by the UE itself.
  • Sidelink positioning refers to positioning of a UE using reference signals transmitted over SL, i.e., PC5 interface, to obtain absolute position, relative position, or ranging information.
  • the term ‘Ranging’ refers to- the determination of the distance and/or the direction between a UE and another entity, e.g., Anchor UE.
  • An ‘Anchor UE’ is a UE supporting positioning of a Target UE, e.g., by transmitting and/or receiving reference signals for positioning, providing positioning- related information, etc., over the PC5 interface (also may be referred to as SL Reference UE).
  • An ‘Assistant UE’ is a UE supporting Ranging/Sidelink between a SL Reference UE and a Target UE over PC5, when the direct Ranging/Sidelink positioning between the SL Reference UE/ Anchor UE and the Target UE cannot be supported.
  • the measurement/results of the Ranging/Sidelink Positioning between the Assistant UE and the SL Reference UE, and that between the Assistant UE and the Target UE, are determined and used to derive the Ranging/Sidelink Positioning results between Target UE and SL Reference UE.
  • a ‘SL Positioning Server UE’ is a UE offering location calculation, for SL Positioning and Ranging based service. It interacts with other UEs over PC5 as necessary in order to calculate the location of the Target UE.
  • the Target UE or SL Reference UE can act as a SL Positioning Server UE if location calculation is supported.
  • a ‘ SL Positioning Client UE’ is a third-party UE, other than SL Reference UE and Target UE, which initiates Ranging/Sidelink positioning service request on behalf of the application residing on it.
  • the present disclosure relates to solutions for supporting multiple SL positioning sessions. More specifically, it is proposed that the format of an SLPP message comprises the parameters “Session ID”, “Initiator ID” and the Message payload.
  • Figure 13 illustrates an embodiment of an SLPP message 1300 according to aspects of the present disclosure.
  • the parameter “Session ID” 1310 is set by the initiator of the SL positioning session and used in all SLPP messages associated to this SL positioning session.
  • the value of this parameter shall be unique over all concurrently active SL positioning sessions on the initiator device.
  • This parameter 1310 may be set differently according to coverage and positioning scenario. As a first example, the value of this parameter 1310 is set to the Routing ID/LCS correlation ID provided by an AMF when the target device is in-coverage and an LMF is involved in the SL positioning session.
  • the value of this parameter 1310 is selfassigned by the initiator device when the initiator device is a UE (Target UE, Anchor UE, Server UE) and in UE-only positioning operation, i.e., when the LMF is not involved in the SL positioning session.
  • the value of this parameter may be changed after a period of time or when the coverage situation changes (e.g. the initiator device moves from in-coverage to out-of-coverage or vice versa) or when the content of certain SLPP messages changes (e.g. capability information or assistance data).
  • the parameter “Initiator ID” 1320 is set by the initiator of the SL positioning session and used in all SLPP messages associated to this SL positioning session.
  • This parameter 1320 may be set according to coverage and positioning scenario.
  • the value of this parameter 1320 is set to a network identity, e.g. AMF ID or LMF ID when an LMF is involved in the SL positioning session.
  • the initiator device is a UE (Target UE, Anchor UE, Server UE) and in UE-only positioning operation
  • the value of this parameter 1320 may be set to a temporary UE identifier provided by the network, e.g.
  • An Application layer ID is a unique identifier that identifies a SL positioning capable UE within the context of the Positioning/Ranging application.
  • the value of this parameter 1320 may be set to the Source/Destination Layer-2 ID as used in SL communication and discovery procedures.
  • the Source Layer-2 ID represents the transmitting UE (TX UE) and is self-assigned by the UE.
  • the Destination Layer-2 ID represents the receiving UE (RX UE) and is an ID provided by the V2X/ProSe layer or in case of group communication provided by the Application layer.
  • the initiator device may self-assign a value of this parameter that is independent of any of the above identifiers (5G-S-TMSI, Application layer ID, Source/Destination Layer-2 ID). In this case the initiator device will then map internally the self-assigned identifier to any of the above identifiers.
  • the value of this parameter 1320 may be changed during an ongoing SL positioning session when the coverage situation changes (e.g. the initiator device moves from in-coverage to out-of- coverage or vice versa).
  • the combination of the parameters Session ID 1310, Initiator ID 1320 may be set commonly or differently for the cast types (unicast, groupcast, broadcast).
  • the parameter Session ID 1310 may be set by the initiator device to provide an explicit indication of a standalone SL positioning session (i.e. determining the position of a single Target UE) or a group-based SL positioning session (i.e. determining the position of multiple Target UEs).
  • An explicit indication may comprise a subset of bits of the session ID 1310 used to indicate whether the session ID 1310 refers to a standalone SL positioning session or a group-based SL positioning session.
  • the aim is to infer information from the session ID 1310 on whether the session comprises a standalone SL positioning session or a group-based SL positioning session.
  • the 1st bit (MSB) of the session ID 1310 may be used to indicate the session type. If the bit is set to “0” it indicates a standalone SL positioning session, and if it is set to “1” it indicates a group-based SL positioning session.
  • SL positioning capable UEs are enabled to support multiple SL positioning sessions by allowing them to distinguish between multiple SL positioning sessions. Furthermore, SL positioning tends to be supported for all coverage and positioning scenarios, and with or without involvement of a core network of a wireless communication system.
  • FIG. 14 illustrates an example 1400 of message flows in accordance with aspects of the present disclosure. More specifically the example 1400 shows a target UE 1410, an anchor UE 1415 and an LMF 1440.
  • This particular example 1400 relates to a PC5- only-based positioning operation scenario where the LMF 1440 is involved in SL positioning.
  • LMF 1440 has discovered target UE(s) 1410 to support a ranging/SL positioning service request from a client UE (or from an application client, not shown in the Figure).
  • the Target UE 1410 and Anchor UE 1415 are in network coverage.
  • a MT-LR procedure has been triggered in the network and the LMF 1440 establishes a SL positioning session with the Target 1410 and Anchor UE 1415. Session-based positioning is performed between the Target UE 1410, Anchor UE 1415 and LMF 1440.
  • the SLPP messages are sent per unicast.
  • the message flows 1401-1404 will now be described.
  • the LMF 1440 sends an SLPP Requestcapabilities message to the Target UE 1410 to request its capabilities for SL positioning.
  • the Target UE 1410 sends the LMF 1440 an SLPP ProvideCapabilities message to indicate its SL positioning capabilities including the supported positioning modes and positioning methods.
  • the LMF 1440 sends an SLPP RequestLocationlnformation message to request SL PRS positioning measurements from the Target UE 1410.
  • the LMF 1440 may send an SLPP RequestLocationlnformation message to request location information, e.g. absolute or relative position or distance/direction, from the Target UE 1410.
  • SL positioning is performed between the Target UE 1410, Anchor UE 1415 and LMF 1440 for the established SL positioning session (SL positioning assistance data transfer, SL PRS transmission, SL PRS measurements, SL PRS positioning measurements transfer).
  • Figure 15 illustrates a further example 1500 of message flows in accordance with aspects of the present disclosure. More specifically the example 1500 shows a target UE 1510, an anchor UE 1515 and a server UE 1516.
  • the example 1500 relates to PC5- only-based positioning operation scenarios, where an LMF is not involved in SL positioning because it is not capable of SL positioning.
  • the Target UE 1510, Anchor UE 1515 and Server UE 1516 are in network coverage.
  • An MO-LR procedure has been triggered in the Target UE 1510. Session-based and UE-only positioning is performed between the Target UE 1510, Anchor UE 1515 and Server UE 1516.
  • the SLPP messages are sent per unicast.
  • the message flows 1501-1504 will now be described.
  • a first step 1501a the Target UE 1510 has received a ranging/SL positioning service request over PC5 from a client UE (not shown in the Figure).
  • the Target UE 1510 starts the SL discovery procedure to discover Anchor 1515 and Server 1516 UEs in its vicinity. It is assumed that the Target UE 1510 was able to discover at least one Anchor
  • Anchor 1515 and Server 1516 UE are two Server 1516 UE.
  • Anchor 1515 and Server 1516 UE are two Server 1516 UE.
  • 1516 UE may be the same UE.
  • the Target UE 1510, Anchor UE 1515 and Server UE 1516 perform SL positioning capability exchange. That means each UE 1510, 1515, 1516 provides its SL positioning capabilities including the supported positioning modes and positioning methods to the other UEs 1510, 1515, 1516 by sending an SLPP ProvideCapabilities message.
  • This procedure is initiated by the Target UE 1510 by sending an SLPP Requestcapabilities and/or SLPP ProvideCapabilities message each to the Anchor UE 1515 and Server UE 1516.
  • a further step 1502 based on the SL positioning capability exchange in Step 1501b, the Target UE 1510, Anchor UE 1515 and Server UE 1516 perform SL positioning assistance data transfer. It is assumed that SL positioning is performed based on UE- assisted positioning mode and SL-RTT positioning method, and the Server UE 1516 sends SL positioning assistance data to both the Target 1510 and Anchor UE 1515 to enable them to perform SL PRS measurements for SL-RTT.
  • SL PRS measurement is performed in the Target UE 1510 and Anchor UE 1515.
  • the Target UE 1510 and Anchor UE 1515 transfer their SL PRS measurement data to the Server UE 1516.
  • the Server UE 1516 calculates the position of the Target UE 1510 and sends the result to the Target UE 1510.
  • Each SLPP message that is exchanged in the Steps 1501b, 1502, 1504, carries the parameters “Session ID” and “Initiator ID” as depicted in Figure 13. Since the Target UE 1510 is the initiator of the SL positioning session the value of the parameter “Session ID” is set to a self-assigned value that uniquely identifies the SL positioning session in the Target UE 1510. Furthermore, the value of the parameter “Initiator ID” is set to the 5G-S- TMSI of the Target UE 1510.
  • a further embodiment in accordance with aspects of the present disclosure, is the same as the example 1500 of Figure 15, however the Target UE 1510, Anchor UE 1515 and Server UE 1516 are now out-of-coverage.
  • the message flow as depicted in Figure 15 is also applicable for this embodiment and each SLPP message that is exchanged in the Steps 1501b, 1502, 1504, carries the parameters “Session ID” and “Initiator ID” as depicted in Figure 13. Since the Target UE 1510 is the initiator of the SL positioning session the value of the parameter “Session ID” is set to a self-assigned value that uniquely identifies the SL positioning session in the Target UE 1510. Furthermore, the value of the parameter “Initiator ID” is set to the Application layer ID of the Target UE 1510.
  • a PC5 -only-based positioning operation scenario is used where an LMF is not involved.
  • a UE1 and UE2 are in network coverage.
  • Session-based and UE-only positioning according to scenario A in Figure 1 la is performed between the UE1 and UE2.
  • the message flow 1200 according to Figure 12 is applied.
  • each SLPP message that is exchanged in the Steps 1201b, 1202, 1204, 1206 carries the parameters “Session ID” and “Initiator ID” as depicted in Figure 13. Since the UE1 is the initiator of the SL positioning session the value of the parameter “Session ID” is set to a self-assigned value “SI” that uniquely identifies the SL positioning session in the UE1. Furthermore, the value of the parameter “Initiator ID” is set to the Application layer ID of the UE1.
  • the UE1 decides to change the content of the broadcast SL positioning assistance data, e.g. by increasing or decreasing the number of frequency layers on which SL PRS is transmitted. As a consequence, the UE1 sets the value of the parameter “Session ID” in the Steps 1201b, 1202 to a new value “S2”. The Steps 1204, 1206 are then performed with other UE(s) based on the new value “S2” of the parameter “Session ID”.
  • a user equipment for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the UE to: transmit, to at least a first apparatus of a wireless communication system, a first sidelink positioning protocol (SLPP) message for a sidelink (SL) positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; an initiator identifier for an initiator of the SL positioning session; and a message payload.
  • SLPP sidelink positioning protocol
  • the first apparatus is a location management function (LMF), the LMF being the initiator of the SL positioning session.
  • LMF location management function
  • the session identifier is set by the LMF and uniquely identifies the SL positioning session to the LMF; and/or the initiator identifier is set by the LMF and is an identifier for the LMF.
  • the session identifier comprises at least one of: a routing identifier; and a location services (LCS) identifier.
  • a routing identifier comprises at least one of: a routing identifier; and a location services (LCS) identifier.
  • LCS location services
  • the at least one processor is configured to cause the UE to: receive, from the LMF, a first SLPP request for a SL positioning session, wherein the first SLPP request comprises the session identifier and the initiator identifier; and transmit the first SLPP message to the LMF, in response to the first SLPP request.
  • the first SLPP request may, for instance, be an SLPP Request Capabilities message.
  • the at least one processor is configured to cause the UE to: receive, from the LMF, a second SLPP request for a SL positioning session, the second SLPP request being based on the first SLPP message.
  • the second SLPP request may comprise a request for at least one of: a SL positioning reference signal (PRS) measurement; an absolute or relative position measurement; an absolute or relative direction measurement; and an absolute or relative distance measurement.
  • PRS SL positioning reference signal
  • the second SLPP request is an SLPP Request Location Information message.
  • the first apparatus is at least a second UE, wherein the UE is the initiator of the SL positioning session.
  • the session identifier is set by the UE and comprises a first assigned value uniquely identifying the SL positioning session in the UE; and/or the initiator identifier is set by the UE.
  • the initiator identifier comprises at least one of a temporary UE identifier; an application layer identifier; a source/destination layer-2 identifier; and a second assigned value set by the UE.
  • the temporary UE identifier may be, for instance, a 5G-S-TMSI identifier.
  • the first SLPP message is an SLPP Provide Capabilities message or an SLPP Request Capabilities message.
  • the UE and the at least a second UE are UEs selected from the list of UEs consisting of a target UE; an anchor UE; and a server UE.
  • the session identifier and initiator identifier are used in all SLPP messages that are exchanged, subsequent to the first SLPP message, between the UE and the first apparatus, for the SL positioning session.
  • the session identifier and initiator identifier are based on at least one of a coverage scenario of the initiator of the SL positioning session; a SL positioning operation; a SL positioning; and a cast-type, the cast type comprising unicast, groupcast or broadcast.
  • the at least one processor is configured to cause the UE to: modify the session identifier and/or initiator identifier in response to at least one of a predetermined period of time elapsing after initiation of the SL positioning session; a change in the SL positioning operation; a change in the coverage scenario of the initiator.
  • the session identifier comprises an explicit indication of whether the SL positioning session is a standalone SL positioning session or a group-based SL positioning session.
  • the explicit indication is provided as a subset of bits of the session identifier.
  • the subset of bits comprises the most significant bit (MSB), wherein: the MSB is set to 0 when the SL positioning session is a standalone SL positioning session, and, the MSB is set to 1 when the SL positioning session is a group- based SL positioning session, or vice-versa.
  • MSB most significant bit
  • the at least one processor is configured to cause the UE to: perform SL positioning for the SL positioning session, based on the SL positioning capabilities of the UE.
  • the at least one processor is configured to cause the UE to perform the SL positioning by performing at least one of: a SL positioning assistance data transfer; a SL PRS transmission; a SL PRS measurement; and a SL PRS measurement transfer.
  • a processor for a UE for wireless communication comprising: at least one controller coupled with at least one memory and configured to cause the processor to: output a first SLPP message for a SL positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; an initiator identifier for an initiator of the SL positioning session; and a message payload.
  • the initiator of the SL positioning session is an LMF, wherein the session identifier is set by the LMF and uniquely identifies the SL positioning session to the LMF, and/or the initiator identifier is set by the LMF and is an identifier for the LMF; and/or the initiator of the SL positioning session is the UE, wherein the session identifier is set by the processor and comprises a first assigned value uniquely identifying the SL positioning session in the UE, and/or the initiator identifier is set by the processor.
  • the session identifier and initiator identifier are used in all SLPP messages subsequent to the first SLPP message that are input or output from the processor. [0217] In some embodiments, the session identifier and initiator identifier are based on at least one of a coverage scenario of the initiator of the SL positioning session; a SL positioning operation; a SL positioning; and a cast-type, the cast type comprising unicast, groupcast or broadcast.
  • the at least one controller is configured to cause the processor to: modify the session identifier and/or initiator identifier in response to at least one of a predetermined period of time elapsing after initiation of the SL positioning session; a change in the SL positioning operation; a change in the coverage scenario of the initiator.
  • the session identifier comprises an explicit indication of whether the SL positioning session is a standalone SL positioning session or a group-based SL positioning session.
  • an LMF for wireless communication comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the LMF to: transmit, to a UE of a wireless communication system, a first SLPP request for a SL positioning session, wherein the first SLPP request comprises: a session identifier for the SL positioning session; and an initiator identifier for an initiator of the SL positioning session; receive, from the UE, a first SLPP message in response to the first SLPP request, wherein the first SLPP message comprises the session identifier, the initiator identifier and a message payload.
  • the present disclosure relates to a format of an SLPP message that comprises the parameters “Session ID”, “Initiator ID” and the Message payload.
  • the parameter “Session ID” is set by the initiator of the SL positioning session and tends to be used in all SLPP messages associated to the SL positioning session.
  • the value of the Session ID parameter tends to be unique over all concurrently active SL positioning sessions on the initiator device.
  • the value of the Session ID parameter tends to be set to the Routing ID/LCS correlation ID provided by an AMF when the target device is in-coverage and an LMF is involved in the SL positioning session.
  • the value of the Session ID parameter tends to be self-assigned by the initiator device when the initiator device is a UE (i.e., a Target UE, Anchor UE, or a Server UE) and in UE-only positioning operation, i.e. when the LMF is not involved in the SL positioning session.
  • a UE i.e., a Target UE, Anchor UE, or a Server UE
  • UE-only positioning operation i.e. when the LMF is not involved in the SL positioning session.
  • the value of the Session ID parameter may be changed after a period of time or when the coverage situation changes (e.g., the initiator device moves from in-coverage to out-of-coverage or vice versa) or when the content of certain SLPP messages changes (e.g., changes in capability information or assistance data).
  • the parameter “Initiator ID” is set by the initiator of the SL positioning session and tends to be used in all SLPP messages associated to the SL positioning session.
  • the value of the Initiator ID parameter is set to a network identity when an LMF is involved in the SL positioning session.
  • the value of the Initiator ID parameter may be set to a temporary UE identifier provided by the network or an Application layer ID provided by the initiator device’s Positioning/Ranging application or the Source/Destination Layer-2 ID as used in SL communication and discovery procedures, or the Initiator ID may be a self-assigned identifier.
  • the value of the Initiator ID parameter may be changed during an ongoing SL positioning session when the coverage situation changes (e.g., the initiator device moves from in-coverage to out-of-coverage or vice versa).
  • the combination of the parameters Session ID, Initiator ID may be set commonly or differently for the cast types (unicast, groupcast, broadcast).
  • the parameter Session ID may be set by the initiator device to provide an explicit indication of a standalone SL positioning session (i.e., determining the position of a single Target UE) or a group-based SL positioning session (i.e., determining the position of multiple Target UEs).
  • the disclosure herein provides a method for supporting multiple Sidelink positioning sessions in a wireless communication system, the method comprising: determining by a first communication device to initiate a Sidelink positioning session; transmitting a first Sidelink positioning protocol message by the first communication device to at least one second communication device containing the parameters Session ID, Initiator ID and a Message payload; receiving the first message by at least one second communication device to perform Sidelink positioning in accordance with the received first Sidelink positioning protocol message.
  • the same values of the parameters Session ID and Initiator ID are set in all successive Sidelink positioning protocol messages that are exchanged between the first communication device and the at least one second communication device and that are associated to the same Sidelink positioning session.
  • the parameters Session ID and Initiator ID are set in accordance with the coverage scenario and positioning operation.
  • the parameter Session ID may be changed after a period of time or when the coverage situation of the first communication device that initiates the Sidelink positioning session changes or when the content of a Sidelink positioning protocol message changes.
  • the parameter Initiator ID may be changed when the coverage situation of the first communication device that initiates the Sidelink positioning session changes.
  • the parameters Session ID and Initiator ID are set commonly or differently for the cast types.
  • the parameter Session ID comprises an explicit indication of a standalone Sidelink positioning session or a group-based Sidelink positioning session.
  • FIG. 16 illustrates an example of a UE 1600 in accordance with aspects of the present disclosure.
  • the UE 1600 may include a processor 1602, a memory 1604, a controller 1606, and a transceiver 1608.
  • the processor 1602, the memory 1604, the controller 1606, or the transceiver 1608, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.
  • the processor 1602, the memory 1604, the controller 1606, or the transceiver 1608, or various combinations or components thereof may be implemented in hardware (e.g., circuitry).
  • the hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.
  • DSP digital signal processor
  • ASIC application-specific integrated circuit
  • the processor 1602 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1602 may be configured to operate the memory 1604. In some other implementations, the memory 1604 may be integrated into the processor 1602. The processor 1602 may be configured to execute computer-readable instructions stored in the memory 1604 to cause the UE 1600 to perform various functions of the present disclosure.
  • an intelligent hardware device e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof.
  • the processor 1602 may be configured to operate the memory 1604. In some other implementations, the memory 1604 may be integrated into the processor 1602.
  • the processor 1602 may be configured to execute computer-readable instructions stored in the memory 1604 to cause the UE 1600 to perform various functions of the present disclosure.
  • the memory 1604 may include volatile or non-volatile memory.
  • the memory 1604 may store computer-readable, computer-executable code including instructions when executed by the processor 1602 cause the UE 1600 to perform various functions described herein.
  • the code may be stored in a non-transitory computer-readable medium such the memory 1604 or another type of memory.
  • Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • a non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.
  • the processor 1602 and the memory 1604 coupled with the processor 1602 may be configured to cause the UE 1600 to perform one or more of the functions described herein (e.g., executing, by the processor 1602, instructions stored in the memory 1604).
  • the processor 1602 may support wireless communication at the UE 1600 in accordance with examples as disclosed herein.
  • the UE 1600 may be configured to support a means for supporting multiple SL positioning sessions in accordance with aspects of the disclosure provided herein.
  • the controller 1606 may manage input and output signals for the UE 1600.
  • the controller 1606 may also manage peripherals not integrated into the UE 1600.
  • the controller 1606 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems.
  • the controller 1606 may be implemented as part of the processor 1602.
  • the UE 1600 may include at least one transceiver 1608. In some other implementations, the UE 1600 may have more than one transceiver 1608.
  • the transceiver 1608 may represent a wireless transceiver.
  • the transceiver 1608 may include one or more receiver chains 1610, one or more transmitter chains 1612, or a combination thereof.
  • a receiver chain 1610 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium.
  • the receiver chain 1610 may include one or more antennas for receive the signal over the air or wireless medium.
  • the receiver chain 1610 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal.
  • the receiver chain 1610 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal.
  • the receiver chain 1610 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.
  • a transmitter chain 1612 may be configured to generate and transmit signals (e.g., control information, data, packets).
  • the transmitter chain 1612 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium.
  • the at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM).
  • the transmitter chain 1612 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium.
  • the transmitter chain 1612 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.
  • FIG. 17 illustrates an example of a processor 1700 in accordance with aspects of the present disclosure.
  • the processor 1700 may be an example of a processor configured to perform various operations in accordance with examples as described herein.
  • the processor 1700 may include a controller 1702 configured to perform various operations in accordance with examples as described herein.
  • the processor 1700 may optionally include at least one memory 1704, which may be, for example, an L1/L2/L3 cache. Additionally, or alternatively, the processor 1700 may optionally include one or more arithmetic-logic units (ALUs) 1706.
  • ALUs arithmetic-logic units
  • One or more of these components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces (e.g., buses).
  • the processor 1700 may be a processor chipset and include a protocol stack (e.g., a software stack) executed by the processor chipset to perform various operations (e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) in accordance with examples as described herein.
  • a protocol stack e.g., a software stack
  • operations e.g., receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading
  • the processor chipset may include one or more cores, one or more caches (e.g., memory local to or included in the processor chipset (e.g., the processor 1700) or other memory (e.g., random access memory (RAM), read-only memory (ROM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), static RAM (SRAM), ferroelectric RAM (FeRAM), magnetic RAM (MRAM), resistive RAM (RRAM), flash memory, phase change memory (PCM), and others).
  • RAM random access memory
  • ROM read-only memory
  • DRAM dynamic RAM
  • SDRAM synchronous dynamic RAM
  • SRAM static RAM
  • FeRAM ferroelectric RAM
  • MRAM magnetic RAM
  • RRAM resistive RAM
  • flash memory phase change memory
  • PCM phase change memory
  • the controller 1702 may be configured to manage and coordinate various operations (e.g., signaling, receiving, obtaining, retrieving, transmitting, outputting, forwarding, storing, determining, identifying, accessing, writing, reading) of the processor 1700 to cause the processor 1700 to support various operations in accordance with examples as described herein.
  • the controller 1702 may operate as a control unit of the processor 1700, generating control signals that manage the operation of various components of the processor 1700. These control signals include enabling or disabling functional units, selecting data paths, initiating memory access, and coordinating timing of operations.
  • the controller 1702 may be configured to fetch (e.g., obtain, retrieve, receive) instructions from the memory 1704 and determine subsequent instruction(s) to be executed to cause the processor 1700 to support various operations in accordance with examples as described herein.
  • the controller 1702 may be configured to track memory address of instructions associated with the memory 1704.
  • the controller 1702 may be configured to decode instructions to determine the operation to be performed and the operands involved.
  • the controller 1702 may be configured to interpret the instruction and determine control signals to be output to other components of the processor 1700 to cause the processor 1700 to support various operations in accordance with examples as described herein.
  • the controller 1702 may be configured to manage flow of data within the processor 1700.
  • the controller 1702 may be configured to control transfer of data between registers, arithmetic logic units (ALUs), and other functional units of the processor 1700.
  • ALUs arithmetic logic units
  • the memory 1704 may include one or more caches (e.g., memory local to or included in the processor 1700 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc. In some implementations, the memory 1704 may reside within or on a processor chipset (e.g., local to the processor 1700). In some other implementations, the memory 1704 may reside external to the processor chipset (e.g., remote to the processor 1700). [0254] The memory 1704 may store computer-readable, computer-executable code including instructions that, when executed by the processor 1700, cause the processor 1700 to perform various functions described herein.
  • caches e.g., memory local to or included in the processor 1700 or other memory, such RAM, ROM, DRAM, SDRAM, SRAM, MRAM, flash memory, etc.
  • the memory 1704 may reside within or on a processor chipset (e.g., local to the processor 1700). In some other implementations, the memory 1704 may reside external
  • the code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory.
  • the controller 1702 and/or the processor 1700 may be configured to execute computer-readable instructions stored in the memory 1704 to cause the processor 1700 to perform various functions.
  • the processor 1700 and/or the controller 1702 may be coupled with or to the memory 1704, the processor 1700, the controller 1702, and the memory 1704 may be configured to perform various functions described herein.
  • the processor 1700 may include multiple processors and the memory 1704 may include multiple memories.
  • One or more of the multiple processors may be coupled with one or more of the multiple memories, which may, individually or collectively, be configured to perform various functions herein.
  • the one or more ALUs 1706 may be configured to support various operations in accordance with examples as described herein.
  • the one or more ALUs 1706 may reside within or on a processor chipset (e.g., the processor 1700).
  • the one or more ALUs 1706 may reside external to the processor chipset (e.g., the processor 1700).
  • One or more ALUs 1706 may perform one or more computations such as addition, subtraction, multiplication, and division on data.
  • one or more ALUs 1706 may receive input operands and an operation code, which determines an operation to be executed.
  • One or more ALUs 1706 be configured with a variety of logical and arithmetic circuits, including adders, subtractors, shifters, and logic gates, to process and manipulate the data according to the operation. Additionally, or alternatively, the one or more ALUs 1706 may support logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND), enabling the one or more ALUs 1706 to handle conditional operations, comparisons, and bitwise operations.
  • logical operations such as AND, OR, exclusive-OR (XOR), not-OR (NOR), and not- AND (NAND)
  • the processor 1700 may support wireless communication in accordance with examples as disclosed herein.
  • the processor 1700 may be configured to or operable to support a means for supporting multiple SL positioning sessions in accordance with aspects of the disclosure provided herein.
  • Figure 18 illustrates an example of an NE 1800 in accordance with aspects of the present disclosure.
  • the NE 1800 may include a processor 1802, a memory 1804, a controller 1806, and a transceiver 1808.
  • the processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations thereof or various components thereof may be examples of means for performing various aspects of the present disclosure as described herein. These components may be coupled (e.g., operatively, communicatively, functionally, electronically, electrically) via one or more interfaces.
  • the processor 1802, the memory 1804, the controller 1806, or the transceiver 1808, or various combinations or components thereof may be implemented in hardware (e.g., circuitry).
  • the hardware may include a processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or other programmable logic device, or any combination thereof configured as or otherwise supporting a means for performing the functions described in the present disclosure.
  • DSP digital signal processor
  • ASIC application-specific integrated circuit
  • the processor 1802 may include an intelligent hardware device (e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof). In some implementations, the processor 1802 may be configured to operate the memory 1804. In some other implementations, the memory 1804 may be integrated into the processor 1802. The processor 1802 may be configured to execute computer-readable instructions stored in the memory 1804 to cause the NE 1800 to perform various functions of the present disclosure.
  • an intelligent hardware device e.g., a general- purpose processor, a DSP, a CPU, an ASIC, an FPGA, or any combination thereof.
  • the processor 1802 may be configured to operate the memory 1804. In some other implementations, the memory 1804 may be integrated into the processor 1802.
  • the processor 1802 may be configured to execute computer-readable instructions stored in the memory 1804 to cause the NE 1800 to perform various functions of the present disclosure.
  • the memory 1804 may include volatile or non-volatile memory.
  • the memory 1804 may store computer-readable, computer-executable code including instructions when executed by the processor 1802 cause the NE 1800 to perform various functions described herein.
  • the code may be stored in a non-transitory computer-readable medium such the memory 1804 or another type of memory.
  • Computer-readable media includes both non- transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.
  • a non-transitory storage medium may be any available medium that may be accessed by a general-purpose or special-purpose computer.
  • the processor 1802 and the memory 1804 coupled with the processor 1802 may be configured to cause the NE 1800 to perform one or more of the functions described herein (e.g., executing, by the processor 1802, instructions stored in the memory 1804).
  • the processor 1802 may support wireless communication at the NE 1800 in accordance with examples as disclosed herein.
  • the NE 1800 may be configured to support a means for supporting multiple SL positioning sessions in accordance with aspects of the disclosure provided herein.
  • the controller 1806 may manage input and output signals for the NE 1800.
  • the controller 1806 may also manage peripherals not integrated into the NE 1800.
  • the controller 1806 may utilize an operating system such as iOS®, ANDROID®, WINDOWS®, or other operating systems.
  • the controller 1806 may be implemented as part of the processor 1802.
  • the NE 1800 may include at least one transceiver 1808. In some other implementations, the NE 1800 may have more than one transceiver 1808.
  • the transceiver 1808 may represent a wireless transceiver.
  • the transceiver 1808 may include one or more receiver chains 1810, one or more transmitter chains 1812, or a combination thereof.
  • a receiver chain 1810 may be configured to receive signals (e.g., control information, data, packets) over a wireless medium.
  • the receiver chain 1810 may include one or more antennas for receive the signal over the air or wireless medium.
  • the receiver chain 1810 may include at least one amplifier (e.g., a low-noise amplifier (LN A)) configured to amplify the received signal.
  • the receiver chain 1810 may include at least one demodulator configured to demodulate the receive signal and obtain the transmitted data by reversing the modulation technique applied during transmission of the signal.
  • the receiver chain 1810 may include at least one decoder for decoding the processing the demodulated signal to receive the transmitted data.
  • a transmitter chain 1812 may be configured to generate and transmit signals (e.g., control information, data, packets).
  • the transmitter chain 1812 may include at least one modulator for modulating data onto a carrier signal, preparing the signal for transmission over a wireless medium.
  • the at least one modulator may be configured to support one or more techniques such as amplitude modulation (AM), frequency modulation (FM), or digital modulation schemes like phase-shift keying (PSK) or quadrature amplitude modulation (QAM).
  • the transmitter chain 1812 may also include at least one power amplifier configured to amplify the modulated signal to an appropriate power level suitable for transmission over the wireless medium.
  • the transmitter chain 1812 may also include one or more antennas for transmitting the amplified signal into the air or wireless medium.
  • Figure 1900 illustrates a flowchart of a method in accordance with aspects of the present disclosure.
  • the operations of the method may be implemented by a UE as described herein.
  • the UE may execute a set of instructions to control the function elements of the UE to perform the described functions.
  • the method may include transmitting, to at least a first apparatus of a wireless communication system, a first SLPP message for a SL positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; and initiator identifier for an initiator of the SL positioning session; and a message payload.
  • the operations of 1901 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 1901 may be performed by a UE as described with reference to Figure 16.
  • the first apparatus is a location management function (LMF), the LMF being the initiator of the SL positioning session.
  • LMF location management function
  • the session identifier is set by the LMF and uniquely identifies the SL positioning session to the LMF; and/or the initiator identifier is set by the LMF and is an identifier for the LMF.
  • the session identifier comprises at least one of: a routing identifier; and a location services (LCS) identifier.
  • a routing identifier comprises at least one of: a routing identifier; and a location services (LCS) identifier.
  • LCS location services
  • Some embodiments comprise, receiving from the LMF, a first SLPP request for a SL positioning session, wherein the first SLPP request comprises the session identifier and the initiator identifier; and transmitting the first SLPP message to the LMF, in response to the first SLPP request.
  • the first SLPP request may, for instance, be an SLPP Request Capabilities message.
  • Some embodiments comprise receiving, from the LMF, a second SLPP request for a SL positioning session, the second SLPP request being based on the first SLPP message.
  • the second SLPP request may comprise a request for at least one of: a SL positioning reference signal (PRS) measurement; an absolute or relative position measurement; an absolute or relative direction measurement; and an absolute or relative distance measurement.
  • PRS SL positioning reference signal
  • the second SLPP request is an SLPP Request Location Information message.
  • the first apparatus is at least a second UE, wherein the UE is the initiator of the SL positioning session.
  • the session identifier is set by the UE and comprises a first assigned value uniquely identifying the SL positioning session in the UE; and/or the initiator identifier is set by the UE.
  • the initiator identifier comprises at least one of: a temporary UE identifier; an application layer identifier; a source/destination layer-2 identifier; and a second assigned value set by the UE.
  • the temporary UE identifier may be, for instance, a 5G-S-TMSI identifier.
  • the first SLPP message is an SLPP Provide Capabilities message or an SLPP Request Capabilities message.
  • the UE and the at least a second UE are UEs selected from the list of UEs consisting of: a target UE; an anchor UE; and a server UE.
  • the session identifier and initiator identifier are used in all SLPP messages that are exchanged, subsequent to the first SLPP message, between the UE and the first apparatus, for the SL positioning session.
  • the session identifier and initiator identifier are based on at least one of: a coverage scenario of the initiator of the SL positioning session; a SL positioning operation; a SL positioning; and a cast-type, the cast type comprising unicast, groupcast or broadcast.
  • Some embodiments comprise modifying the session identifier and/or initiator identifier in response to at least one of: a predetermined period of time elapsing after initiation of the SL positioning session; a change in the SL positioning operation; a change in the coverage scenario of the initiator.
  • the session identifier comprises an explicit indication of whether the SL positioning session is a standalone SL positioning session or a group-based SL positioning session.
  • the explicit indication is provided as a subset of bits of the session identifier.
  • the subset of bits comprises the most significant bit (MSB), wherein: the MSB is set to 0 when the SL positioning session is a standalone SL positioning session, and, the MSB is set to 1 when the SL positioning session is a group- based SL positioning session, or vice-versa.
  • MSB most significant bit
  • Some embodiments comprise performing SL positioning for the SL positioning session, based on the SL positioning capabilities of the UE.
  • the performing the SL positioning comprises performing at least one of: a SL positioning assistance data transfer; a SL PRS transmission; a SL PRS measurement; and a SL PRS measurement transfer.
  • Figure 20 illustrates a flowchart of a method 2000 in a processor in accordance with aspects of the present disclosure.
  • the operations of the method 2000 may be implemented by a processor as described herein.
  • the method may include outputting a first SLPP message for a SL positioning session, wherein the first SLPP message comprises: a session identifier for the SL positioning session; an initiator identifier for an initiator of the SL positioning session; and a message payload.
  • the operations of 2001 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2001 may be performed by a processor as described with reference to Figure 17.
  • the initiator of the SL positioning session is an LMF, wherein the session identifier is set by the LMF and uniquely identifies the SL positioning session to the LMF, and/or the initiator identifier is set by the LMF and is an identifier for the LMF; and/or the initiator of the SL positioning session is the UE, wherein the session identifier is set by the processor and comprises a first assigned value uniquely identifying the SL positioning session in the UE, and/or the initiator identifier is set by the processor.
  • the session identifier and initiator identifier are used in all SLPP messages subsequent to the first SLPP message that are input or output from the processor.
  • the session identifier and initiator identifier are based on at least one of: a coverage scenario of the initiator of the SL positioning session; a SL positioning operation; a SL positioning; and a cast-type, the cast type comprising unicast, groupcast or broadcast.
  • Some embodiments comprise modifying the session identifier and/or initiator identifier in response to at least one of: a predetermined period of time elapsing after initiation of the SL positioning session; a change in the SL positioning operation; a change in the coverage scenario of the initiator.
  • the session identifier comprises an explicit indication of whether the SL positioning session is a standalone SL positioning session or a group-based SL positioning session.
  • Figure 21 illustrates a flowchart of a method 2100 in accordance with aspects of the present disclosure.
  • the operations of the method may be implemented by an NE, such as an LMF, as described herein.
  • the NE may execute a set of instructions to control the function elements of the NE to perform the described functions.
  • the method may include transmitting, to a UE of a wireless communication system, a first SLPP request for a SL positioning session, wherein the first SLPP request comprises: a session identifier for the SL positioning session; and an initiator identifier for an initiator of the SL positioning session.
  • the operations of 2101 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2101 may be performed by an NE (i.e., an LMF) as described with reference to Figure 18.
  • the method may include receiving, from the UE, a first SLPP message in response to the first SLPP request, wherein the first SLPP message comprises the session identifier, the initiator identifier and a message payload.
  • the operations of 2102 may be performed in accordance with examples as described herein. In some implementations, aspects of the operations of 2102 may be performed by an NE (i.e., an LMF) as described with reference to Figure 18.

Landscapes

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

Abstract

Divers aspects de la présente divulgation se rapportent à un équipement utilisateur (UE) pour une communication sans fil comprenant : au moins une mémoire ; et au moins un processeur couplé à l'au moins une mémoire et configuré pour amener l'UE : à transmettre, à au moins un premier appareil d'un système de communication sans fil, un premier message de protocole de positionnement de liaison latérale (SLPP) pour une session de positionnement de liaison latérale (SL), le premier message SLPP comprenant : un identifiant de session pour la session de positionnement SL ; un identifiant d'initiateur pour un initiateur de la session de positionnement SL ; et une charge utile de message.
PCT/EP2023/073805 2023-07-21 2023-08-30 Prise en charge de multiples sessions de positionnement de liaison latérale dans un système de communication sans fil Pending WO2024104628A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GR20230100601 2023-07-21
GR20230100601 2023-07-21

Publications (1)

Publication Number Publication Date
WO2024104628A1 true WO2024104628A1 (fr) 2024-05-23

Family

ID=87886765

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/073805 Pending WO2024104628A1 (fr) 2023-07-21 2023-08-30 Prise en charge de multiples sessions de positionnement de liaison latérale dans un système de communication sans fil

Country Status (1)

Country Link
WO (1) WO2024104628A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250159758A1 (en) * 2023-11-09 2025-05-15 Qualcomm Incorporated Sidelink positioning group operation via pairwise managed groupcast replies

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
3GPP TECHNICAL SPECIFICATION 23.273
3GPP TECHNICAL SPECIFICATION 38.331
3GPP TS 37.355
QUALCOMM INCORPORATED: "Sidelink Positioning Protocol (SLPP) Signaling and Procedures", vol. RAN WG2, no. Incheon KR; 20230522 - 20230526, 12 May 2023 (2023-05-12), XP052391104, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_122/Docs/R2-2306422.zip R2-2306422_(Sidelink Positioning).docx> [retrieved on 20230512] *
ROBIN THOMAS ET AL: "Discussion on SL Positioning", vol. 3GPP RAN 2, no. Toulouse, FR; 20230821 - 20230825, 11 August 2023 (2023-08-11), XP052443981, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_123/Docs/R2-2308276.zip R2-2308276_SLPosDiscussion.docx> [retrieved on 20230811] *
XIAOWEI JIANG ET AL: "[Pre122][401][POS] Summary of AI 7.2.2 on sidelink positioning", vol. 3GPP RAN 2, no. Incheon, KR; 20230522 - 20230526, 30 May 2023 (2023-05-30), XP052380874, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_122/Docs/R2-2306757.zip [Pre122][401][POS] Summary of AI 7.2.2 on sidelink positioning(Xiaomi)_v5.1_Rapp.doc> [retrieved on 20230530] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20250159758A1 (en) * 2023-11-09 2025-05-15 Qualcomm Incorporated Sidelink positioning group operation via pairwise managed groupcast replies

Similar Documents

Publication Publication Date Title
JP6203832B2 (ja) デバイスツーデバイス通信およびプロキシミティサービスのためにデバイス間の距離を決定するための方法および装置
WO2018204002A1 (fr) Découverte de pairs dans des applications mobiles transactionnelles
US20240284528A1 (en) Systems and methods for a sidelink positioning protocol
WO2024110081A1 (fr) Collecte et mise en rapport de données dans un système de communication sans fil
WO2024069439A1 (fr) Planification et traitement de ressources pour positionnement de liaison latérale
EP4595615A1 (fr) Configuration de drx pour positionnement de liaison latérale
US20250142523A1 (en) Selection of apparatus for sidelink positioning
US20250031146A1 (en) Signaling and ue behavior for sidelink prs drx configuration in nr sidelink positioning
WO2024104628A1 (fr) Prise en charge de multiples sessions de positionnement de liaison latérale dans un système de communication sans fil
US20250063576A1 (en) Sidelink positioning assistance
WO2024114965A1 (fr) Gestion de surcharge pour positionnement en liaison latérale dans un système de communication sans fil
WO2024153362A1 (fr) Mappage de priorité de signal de référence de positionnement de liaison latérale dans un système de communication sans fil
WO2024251394A1 (fr) Détermination d&#39;emplacement d&#39;équipement utilisateur
US20250280387A1 (en) Error messaging for sidelink positioning
CN113875274B (zh) Lcs和lpp程序的nas信令减少的方法
WO2025088572A1 (fr) Sélection d&#39;appareil pour positionnement de liaison latérale
WO2024234701A1 (fr) Collecte de données assistée par amf pour une lmf
US20250119872A1 (en) Techniques for radio-based sensing
WO2025039569A1 (fr) Procédé et appareil de prise en charge de collecte et de rapport de données
WO2024119942A1 (fr) Détection basée sur la liaison latérale
WO2024148819A1 (fr) Radiomessagerie pour détection d&#39;ue
AU2024326275A1 (en) Sidelink positioning assistance
US20250380298A1 (en) Triggering sensing operations performed by a wireless communications system
US20250379691A1 (en) Management of sensing components for a wireless communications system
WO2025256176A1 (fr) Procédé et appareil de détection basée sur un nœud de réseau d&#39;accès radio

Legal Events

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

Ref document number: 23762489

Country of ref document: EP

Kind code of ref document: A1