Target Area (Location Services Deferred Request Area)

Description

A target area, as defined in 3GPP TS 23.271 and TS 23.369, is a geographical region specified by a Location Services (LCS) client for the purpose of a deferred location request, specifically for a 'change of area' event. In this context, the LCS client defines an area, and the network monitors the location of a target UE; when the UE enters or leaves the target area, the network reports the event to the client. This is a fundamental capability for location-based services such as geo-fencing, asset tracking, and proximity alerts.

The target area can be expressed in several ways, providing flexibility for different applications. It can be a geometric shape as defined in TS 23.032, such as an ellipse, polygon, or circle with a center and radius. It can also be a local coordinate system area, which is useful for indoor or campus environments. Alternatively, it can be an E.164 country code, representing an entire country, or a PLMN identity, representing a mobile network's coverage area. Finally, it can be a geopolitical name, such as 'London' or 'New York', which is a human-readable area name that the network translates into a geographical boundary.

The target area is used in the deferred location request procedure, which is part of the control plane and user plane location architectures. In the control plane (TS 23.271), the LCS client sends a request to the Gateway Mobile Location Centre (GMLC), which forwards it to the serving MME or AMF. The network then configures the UE or the radio access network to monitor the area and report when the event occurs. In the user plane (TS 23.369), the procedure is similar but uses the Secure User Plane Location (SUPL) platform. The target area is included in the request and is used by the location server to determine when to trigger a report.

Architecturally, the target area is a key parameter in the Location Services (LCS) architecture. The LCS client can be an external application, such as a fleet management system, or an internal network function, such as a emergency services dispatcher. The GMLC is the entry point for external clients, and it authenticates and authorizes the request. The target area is then passed to the location management function (e.g., E-SMLC or LMF) which translates it into a set of cells or tracking areas that the network can monitor. The network continuously tracks the UE's location and compares it to the target area; when a boundary crossing is detected, a report is sent back to the client.

The target area concept has evolved over releases. Initially introduced in Release 6, it was defined for change of area deferred location requests. The definition remained largely unchanged through Release 19, with only minor editorial updates. In Release 20, however, the definition was significantly revised to align with the concept of an AIoT (AI and IoT) area. The new definition states: 'An area in which a service operation request towards an AIOTF is intended to operate, identified by a list of AIoT Areas.' This reflects the integration of location services with AI and IoT frameworks, where the target area is now a list of AIoT areas rather than a single geographical shape. This change broadens the applicability of the term to new service paradigms.

Purpose & Motivation

The target area concept was created to enable deferred location services, where a client is not interested in the immediate location of a UE but rather in whether the UE enters or leaves a specific geographic region. This is essential for applications like geo-fencing, where an alert is triggered when a child or vehicle crosses a boundary, or for asset tracking, where a report is generated when a shipment arrives at a warehouse. Without a standardized way to define such areas, each application would need to implement its own location monitoring logic, leading to inefficiency and interoperability issues.

Before the introduction of target area in Release 6, location services were primarily immediate: a client could request the current location of a UE, but there was no standard mechanism to monitor a UE's location over time and report on area changes. This limited the types of services that could be offered. The target area concept solved this by providing a flexible, standardized way to specify a geographic region and to request event-based reporting. It also allowed the network to optimize the monitoring process, as the network could track the UE's location at the cell or tracking area level and only perform more precise positioning when necessary.

The evolution of the target area definition in Release 20 to include AIoT areas reflects the growing convergence of location services with AI and IoT. As networks move towards 5G-Advanced and 6G, location services are expected to support a massive number of IoT devices and AI-driven applications. The new definition allows a service operation request to an AIOTF (AI and IoT Function) to specify a list of AIoT areas, enabling more granular and context-aware location-based services. This change ensures that the target area concept remains relevant in the era of network slicing and edge computing.