LSTF

Location Subscriber Translation Function

Services
Introduced in Rel-6
LSTF is a network function within the Location Services (LCS) architecture that translates subscriber identifiers (like MSISDN) into network routing addresses (like IP addresses or SS7 signaling addresses). It enables location-based services to correctly route requests to the appropriate mobile device or network node, essential for emergency calls, lawful interception, and commercial location applications.

Description

The Location Subscriber Translation Function (LSTF) is a critical component defined in 3GPP TS 23.271 for the Location Services (LCS) architecture. Its primary role is to perform identifier translation, specifically mapping a subscriber's public identity, such as a Mobile Subscriber International ISDN Number (MSISDN) or an International Mobile Subscriber Identity (IMSI), to the current network routing information needed to reach the user's device or serving network node. This routing information typically includes the IP address of the Mobile Switching Center (MSC) or Serving GPRS Support Node (SGSN) in circuit-switched and packet-switched domains respectively, or in later releases, the Mobility Management Entity (MME) or Access and Mobility Management Function (AMF). The LSTF acts as a directory or resolution service within the LCS system.

Architecturally, the LSTF is often implemented as part of or in close association with the Gateway Mobile Location Center (GMLC), which is the primary entry point for external LCS clients requesting location information. When an LCS client (e.g., an emergency services network, a lawful interception agency, or a commercial service provider) sends a location request with a subscriber's MSISDN, the GMLC queries the LSTF to obtain the current serving node's address. The LSTF may perform this translation by querying the Home Location Register (HLR) or Home Subscriber Server (HSS) to retrieve the subscriber's profile and current serving node information. In some deployments, the LSTF functionality may be integrated directly into the GMLC or HLR/HSS, but it is logically a distinct function to abstract the translation process.

How it works involves a sequence of steps: Upon receiving a translation request from the GMLC, the LSTF uses the provided subscriber identifier to interrogate the HLR/HSS via standard interfaces like MAP (Mobile Application Part) or Diameter. The HLR/HSS responds with the address of the MSC, SGSN, MME, or AMF currently serving the subscriber. The LSTF then returns this routing address to the GMLC, which can subsequently forward the location request to the correct serving node (which then engages the Radio Access Network to determine the device's position). This process is crucial because mobile devices are inherently mobile; their point of attachment to the network changes, and a static identifier like MSISDN does not contain routing information. The LSTF ensures that location requests are dynamically routed to the correct part of the network, enabling timely and accurate location retrieval for services like E911, fleet tracking, or location-based advertising.

Purpose & Motivation

The LSTF was created to solve a fundamental routing problem in mobile location services: external clients know a subscriber by a public identifier (like a phone number), but the network needs to know the current technical address of the network node (like an MSC) serving that subscriber to deliver a location request. Before standardized functions like LSTF, location services relied on ad-hoc methods or required clients to have direct access to core network databases, which was insecure, inefficient, and not scalable. The LSTF provides a standardized, secure intermediary that abstracts the network's internal topology and mobility management from external entities.

Historically, as location-based services gained importance for emergency (E112/E911), lawful interception, and commercial applications in 3GPP Release 6, there was a need for a robust architecture that could handle the dynamic nature of mobile networks. The LSTF addresses the limitation of not having a dedicated translation mechanism, which could lead to failed location requests or delays if the wrong network node was contacted. By centralizing the translation function, it simplifies the GMLC's operation, improves reliability, and enhances security by controlling access to subscriber routing information.

Furthermore, the LSTF supports network evolution by providing a consistent interface regardless of the underlying network generation (2G, 3G, 4G, 5G). As the core network evolved from circuit-switched MSCs to packet-switched MMEs and AMFs, the LSTF's translation logic adapted to query the appropriate HLR or HSS and interpret the new node types. This ensured backward compatibility and smooth operation for LCS clients, which do not need to be aware of the specific network technology serving the subscriber, future-proofing location service investments.

Key Features

  • Translates subscriber identifiers (MSISDN, IMSI) to current serving network node addresses (e.g., MSC, SGSN, MME, AMF IP addresses)
  • Integrates with HLR/HSS via MAP or Diameter protocols to retrieve real-time subscriber location data
  • Acts as a critical component within the Gateway Mobile Location Center (GMLC) architecture
  • Enables correct routing of location requests for mobile devices across different network generations
  • Supports essential services like emergency calling (E911/E112) and lawful interception
  • Provides a standardized interface that abstracts network topology from external LCS clients

Evolution Across Releases

Rel-6 Initial

Introduced the LSTF as part of the enhanced Location Services (LCS) architecture. Defined its initial role in translating MSISDN/IMSI to serving MSC/SGSN addresses for circuit-switched and packet-switched domains, enabling reliable routing of location requests from the GMLC to the correct core network node.

Defining Specifications

SpecificationTitle
TS 23.271 3GPP TS 23.271