LMS

Location Management Server

Core Network →
Introduced in Rel-15

LMS is a core network function that manages and provides location data, acting as a central repository and processor for subscriber location information, privacy settings, and service authorization.

Category
Core Network
Introduced
Rel-15
Where
Services › IMS
Specifications
7 specs
LMS Description Purpose Related Classification Detected Changes Specifications

Description

The Location Management Server (LMS) is a functional entity within the 3GPP Location Services (LCS) architecture, introduced as part of the broader evolution towards more flexible and service-based core networks. It is defined as a component that can be deployed within the 5G Core (5GC) or adapted for other architectures. The LMS centralizes the management of location-related data and logic that was previously more distributed among other Network Functions (NFs) like the Gateway Mobile Location Centre (GMLC). Its primary role is to store and handle location service subscriptions, user privacy settings (LCS Client authorizations), and subscriber location data or pointers to such data.

Architecturally, the LMS interacts with other core network functions via service-based interfaces (e.g., Nlmf interface). Key interactions include communication with the Access and Mobility Management Function (AMF) for obtaining location estimates from the access network, with the Unified Data Management (UDM) for subscriber data, and with external Location Service Clients (e.g., from a third-party application or an internal network service). The LMS may store permanent or temporary location information, geofencing definitions, and triggering events for periodic or event-driven location reporting. It implements the logic for evaluating location-based triggers and notifying authorized clients when conditions are met.

How it works: When a location request is received from an authorized LCS Client, the LMS validates the request against the target user's privacy profile. If authorized, it determines the appropriate method to obtain the location. This could involve querying the AMF, which in turn may initiate signaling with the Radio Access Network (RAN) and the UE (using protocols like LTE Positioning Protocol (LPP)) to generate a location estimate using GNSS, OTDOA, or other positioning methods. The LMS then formats and returns the location information to the requesting client. For deferred or triggered location requests, the LMS stores the trigger criteria and manages the ongoing monitoring, initiating location retrievals as needed and sending notifications. By centralizing this management, the LMS simplifies service logic, enhances scalability, and provides a unified point for applying privacy policies and service-level agreements for location information.

Purpose & Motivation

The LMS was created to address the growing complexity and demand for location-based services in mobile networks, which extended far beyond basic emergency caller location. Previous LCS architectures, centered on the GMLC, were often monolithic and tightly coupled with circuit-switched or early packet core elements. As networks evolved towards cloud-native, service-based architectures (SBA) with 5GC, there was a need to decompose functions for greater flexibility, scalability, and independent innovation. The LMS embodies this decomposition by extracting the location management, subscription, and privacy logic into a dedicated, scalable network function.

This separation solves several problems: it allows for more efficient handling of massive numbers of location requests from IoT devices and commercial applications; it provides a clear, standardized interface for application developers to access network location capabilities; and it centralizes the critical privacy control function, which is increasingly important due to regulations like GDPR. The creation of the LMS was motivated by use cases such as connected vehicles, asset tracking, location-based alerts, and enhanced emergency services (e.g., Advanced Mobile Location), which require reliable, low-latency, and policy-controlled access to device location. It enables network operators to offer location as a managed platform service with differentiated QoS and security levels, often in conjunction with network slicing for specific vertical industries.

Classification

Part ofGMLC
Related approachesLPP

Release Timeline

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-15, normative work from Rel-17.

Rel-17 1 change

In Release 17, the specification for the Location Management Server (LMS) was refined by removing an Editor's Note related to functional alias resolution. The primary technical function of the LMS, as defined, is to receive, store, and provide user location information, including obtaining it from the PLMN via the Le reference point and from MC service UEs via the CSC-14 reference point, and to subscribe to group affiliation status updates from the MC service server.

  • Removal of Editors Note related to functional alias resolution by LMS TS 23.280CR0261
Rel-18 1 change

In Release 18, a key enhancement for the Location Management Server (LMS) was granting it access to all MCX user profiles, as defined by the functional model. This builds upon the LMS's existing role of subscribing to, receiving notifications for, and canceling subscriptions to group affiliation status updates from the MC service server via the defined group dynamic data procedures.

  • LMS access to all the MCX user profiles (functional model) TS 23.280CR0340
Rel-19 1 change

In Release 19, the Location Management Server (LMS) introduced a new capability for "LMS assisted NTZ enforcement," as indicated by the Change Request title. This builds upon the LMS's existing core function of receiving, storing, and providing user location information to the MC service server, utilizing established reference points like CSC-14, CSC-23, and Le. The enhancement specifically leverages the LMS's procedures for subscribing to and receiving notifications of group dynamic data, such as affiliation status, from the MC service server to support this new enforcement role.

  • UAE-layer/SEAL/LMS assisted NTZ enforcement TS 24.257CR0054
Rel-20 1 change

In Release 20, the LMS (Location Management Server) was enhanced with new procedures for subscribing, receiving notifications, and cancelling subscriptions for group dynamic data, specifically affiliation status, directly with the MC Service Server. This introduced a more integrated interaction model, allowing the LMS to actively obtain and be informed of updates to group member affiliation status. These changes were detailed under the revised CSC-15 reference point for additional LMS and MC Service Server interactions.

  • Revised CSC-15: Incorporating Additional LMS and MC Service Server Interactions TS 23.280CR0671

Explore further

Broader topics and technologies where LMS plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 23.280 vk10 Common Architecture for Mission Critical Services Rel-20
TS 23.283 vk00 Mission Critical Communication Interworking Rel-20
TS 23.436 vk00 ADAEnabler Functional Architecture and Information Flows Rel-20
TS 23.700 vk00 XR Services Application Enablement Layer Rel-20
TS 24.257 vj40 UAS Application Enabler (UAE) Layer Rel-19
TS 33.127 vj50 Lawful Interception Architecture and Functions Rel-19
TS 38.811 vf40 Study on NR Support for Non-Terrestrial Networks Rel-15
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.