SL-MT-LR

Sidelink Mobile Terminating Location Request

Services →
Introduced in Rel-18

SL-MT-LR is a service where an external entity or another UE requests the location of a target UE using sidelink communication, enabling device-to-device location tracking for applications like V2X networks.

Category
Services
Introduced
Rel-18
Where
Services › IMS
Specifications
3 specs
SL-MT-LR Description Purpose Related Classification Detected Changes Specifications

Description

SL-MT-LR (Sidelink Mobile Terminating Location Request) is a location service within 3GPP standards that permits an external entity, such as a location server or another UE, to request the geographical position of a target UE using sidelink communication. Unlike SL-MO-LR where the UE initiates the request, here the target UE receives the request terminated from an external source over the PC5 interface. This service is crucial for scenarios where a third party needs to ascertain the location of a device, such as in public safety operations, vehicle tracking, or network-assisted positioning. The procedures are detailed in specifications 23.273 for architectural aspects, 24.514 for protocol layers, and 38.355 for radio access network integration, ensuring a standardized approach across different network deployments.

The architecture for SL-MT-LR involves several key components: the requesting entity, which could be a UE or a network-based location server; the target UE, which is the device whose location is being sought; and the PC5 interface, which facilitates the direct sidelink communication. The requesting entity sends a location request message via the PC5 interface, containing parameters like target UE identification, required accuracy, and positioning method. Upon receipt, the target UE processes the request, which may involve activating its positioning modules, measuring signals such as SL-PRS from neighboring devices, or coordinating with other UEs for collaborative positioning. The target UE then computes or assists in computing its location, often using techniques like time-of-arrival or angle-of-arrival measurements, and returns the result to the requesting entity over the same sidelink channel.

SL-MT-LR operates through a series of signaling exchanges defined in the relevant 3GPP specs. Initially, the requesting entity formulates a location request message based on the application needs—for instance, in a V2X scenario, a roadside unit might request the location of nearby vehicles for traffic management. This message is transmitted over the SL-SCH (Sidelink Shared Channel) using the PC5 interface. The target UE, upon decoding the request, engages in measurement procedures, potentially involving reference signal exchanges with other UEs or infrastructure. If the target UE lacks sufficient capability, it may relay the request to a location server or use hybrid methods combining sidelink and cellular measurements. The computed location data is then encapsulated in a response message and sent back via PC5. This service is designed to be efficient, with mechanisms for privacy and security, such as authentication of requesting entities, to prevent unauthorized tracking. Its role in the network extends beyond mere positioning; it enables dynamic resource allocation and enhanced situational awareness in sidelink ecosystems, supporting everything from logistics to disaster recovery.

Purpose & Motivation

SL-MT-LR was developed to address the need for external entities to locate UEs in sidelink environments, where traditional network-based terminating location services are not feasible. In applications like V2X and ProSe, there is often a requirement for one device or system to determine the position of another—for example, emergency services locating a vehicle after a crash or a fleet manager tracking assets in remote areas. Previous methods relied on cellular network involvement, which could fail in coverage gaps or congested scenarios. SL-MT-LR enables direct, device-to-device location requests, improving reliability and reducing latency for critical operations.

Historically, Mobile Terminating Location Request (MT-LR) services in 3GPP were confined to core network interactions, requiring base station and core network elements to mediate requests. With the rise of sidelink communication in releases like Rel-16 for NR, this approach proved inadequate for direct communication use cases. SL-MT-LR emerged as a solution, extending terminating location capabilities to the PC5 interface. This was motivated by automotive and public safety sectors demanding robust positioning for collaborative awareness, such as in platooning or search-and-rescue missions, where devices must share location data without network overhead.

The creation of SL-MT-LR also supports regulatory compliance and commercial applications, enabling services like lawful interception or location-based advertising in sidelink contexts. By standardizing it in 3GPP, interoperability is ensured across diverse devices and networks, addressing the fragmentation seen in proprietary solutions. This evolution reflects a broader trend towards decentralized network functions, empowering devices to perform complex tasks independently while maintaining seamless integration with existing cellular infrastructure.

Classification

Part ofMT-LR
Related approachesSL-MO-LR

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (7 CRs across 2 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-18 6 changes

In Release 18, the SL-MT-LR function was enhanced to support periodic and triggered location events, introducing a dedicated procedure for these event types. The enhancements include embedding SLPP (Sidelink Positioning Protocol) messages within the supplementary service response to convey UE ranging capabilities and specifying the inclusion of a deferred routing identifier and event reporting address in the request. Furthermore, the release provided updates and corrections to the procedure, such as clarifying the usage of SUPI and the application ID, and refining UE capability signaling for SL-MT-LR.

  • SL-MT-LR for periodic, triggered Location Events corrections TS 23.273CR0418
  • Adding SLPP to SL-MT-LR supplementary service response TS 23.273CR0472
  • UE Capability Update for SL-MT-LR and SL-MO-LR TS 23.273CR0486
  • Update about the usage of SUPI in SL-MT-LR TS 23.273CR0443
  • Corrections to SL-MT-LR procedure TS 23.273CR0505
  • Corrections to application ID in SL-MT-LR and LMF service operation TS 23.273CR0545
Rel-19 1 change

In Release 19, the SL-MT-LR function was updated to support periodic and triggered location events, introducing a dedicated procedure for these event types. The enhancements specify that the Location Management Function (LMF) includes a deferred routing identifier and an LDR reference number in the request, and the response now indicates whether the UEs accept the periodic or triggered request. Furthermore, the procedure clarifies the selection mechanism for a Located UE, detailing whether the Target UE or the LMF performs the selection and what corresponding information is exchanged in the request and response messages.

  • Update on SL-MT-LR for periodic, triggered Location Events TS 24.514CR0050

Explore further

Broader topics and technologies where SL-MT-LR plays a role.

Defining Specifications

3GPP specifications that define or reference SL-MT-LR, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 23.273 vj50 5G Location Services Stage 2 Architecture Rel-19
TS 24.514 vj30 Ranging & Sidelink Positioning in 5GS Rel-19
TS 38.355 vj00 Sidelink Positioning Protocol (SLPP) Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.