Deferred Location Request

Description

A Deferred Location Request is a fundamental concept in 3GPP location services (LCS) that defines a type of positioning request where the location response is not returned immediately. Instead, the location response (or responses) is provided after a specific event has occurred. The event may happen immediately, after some delay, or may never occur at all, and it may recur multiple times. This contrasts with an immediate location request, where the position of the target user equipment (UE) is determined and returned as soon as possible after the request is received.

The concept is specified across a family of LCS specifications, including TS 22.071 (Location Services requirements), TS 23.171 (functional stage 2 for LCS in the pre-IMS architecture), TS 23.271 (functional stage 2 for LCS in the evolved packet core and UTRAN), TS 23.273 (5G System location services), and the feasibility study TS 22.935. These documents collectively define how the network handles location requests originating from external LCS clients, the UE itself, or the network operator, and how event triggers are configured and monitored.

Architecturally, a deferred location request involves several key entities: the LCS Client (the application requesting location), the Gateway Mobile Location Centre (GMLC) that authenticates and authorizes the request, the core network nodes (e.g., MME, AMF/SMF, MSC, SGSN), and the radio access network elements responsible for performing measurements. When a deferred request is submitted, the client specifies an event type — for example, the UE becoming available, entering or leaving a geographic area, or a periodic timer expiring. The network then monitors for that event and, upon detection, initiates the positioning procedures and returns the result to the client.

The event types that can trigger a deferred location request are defined in the specifications and include: UE available (when the target becomes reachable), area event (entering, leaving, or being inside/outside a defined geographic area), periodic location (reporting at regular intervals), motion event (movement of the UE), and deferred location for a specific event as configured. The client can also request that multiple reports be generated, for example periodic reports while the UE remains inside an area, or a single report when the event first occurs.

Deferred location requests matter because many real-world location applications do not need the position immediately. Fleet management, asset tracking, geofencing, and emergency or lawful interception scenarios often require notification only when a condition is met. This reduces signaling overhead, saves network and battery resources, and enables efficient event-driven services that would be impractical if continuous polling were used. The mechanism also supports privacy and authorization checks at the time the event triggers, ensuring that location information is only released when permitted.

Purpose & Motivation

Deferred location requests exist to solve the problem of event-driven positioning, where an application needs to know not where a device is right now, but when and if a specific condition is satisfied. Before this mechanism, LCS clients could only request immediate positioning, forcing them to repeatedly poll the network to detect a condition. Polling wastes signaling and radio resources, drains UE battery, and creates a race between polling intervals and the actual event.

By allowing the client to register an event trigger with the network, the deferred location request offloads monitoring responsibility to the network infrastructure, which can efficiently track conditions in the radio access network, core network, or location servers. This was particularly important for early LCS deployments in R99, where location was tightly coupled to mobility management and periodic reporting could be integrated with existing paging and tracking procedures.

The concept also addressed privacy and regulatory requirements. A deferred request can be authorized once at submission, but the actual location release can be gated by the event and re-checked against privacy rules. Over successive releases, the mechanism was extended to support richer event types, multiple reports, and integration with 5G location services under TS 23.273, ensuring that event-driven location remains a first-class capability across generations.