Description
The Subscription Location Function (SLF) is a critical component within the IP Multimedia Subsystem (IMS) and 5G Core (5GC) architectures, specifically designed to resolve which Home Subscriber Server (HSS) or Unified Data Management (UDM) function holds the subscription data for a given user. It operates as a simple query-response mechanism. When an IMS Call Session Control Function (CSCF) or a 5G Network Function (NF) like the Authentication Server Function (AUSF) needs to access subscriber data but does not know the specific HSS/UDM instance, it sends a Diameter or HTTP-based query to the SLF. This query contains a user identifier, such as the IMS Private User Identity (IMPI) or Subscription Permanent Identifier (SUPI). The SLF, using a configured mapping database or algorithm, returns the address (e.g., hostname, IP address) of the HSS or UDM that serves that subscriber. This process is transparent to the end-user and is a foundational element for subscriber data management in multi-HSS/UDM environments.
Architecturally, the SLF is defined as a standalone logical function but can be co-located with an HSS for simplicity in smaller deployments. In a pure 5G Core network, the UDM incorporates the SLF functionality internally through its UDR (Unified Data Repository) discovery mechanisms, making a standalone SLF less common. However, in IMS and during interworking scenarios between 4G EPC and 5GC, the SLF remains a vital entity. Its primary interface is the Dx interface (based on Diameter protocol) towards the I-CSCF and S-CSCF in IMS, and the N10/N11 interfaces (based on HTTP/2) in the 5G Service-Based Architecture (SBA) when interacting with the UDM.
The SLF's role is purely for discovery and does not store actual subscriber profile data itself. This separation of concerns allows for flexible network scaling. Operators can deploy multiple HSS/UDM instances to handle large subscriber bases or for redundancy, with the SLF providing the necessary indirection layer. It supports load balancing and geographic distribution of user data. For instance, subscribers in different regions can be homed to different HSS instances, and the SLF ensures that queries from the network are always directed to the correct regional database. This capability is crucial for maintaining low-latency access to subscriber data and for implementing disaster recovery schemes where user data is replicated across sites.
Purpose & Motivation
The SLF was introduced to solve a fundamental scaling problem in early IMS deployments. As networks grew beyond a single HSS, there was no standard mechanism for network functions to determine which HSS instance contained the data for a specific user. Without an SLF, network elements would need pre-configured, static mappings or would have to broadcast queries to all HSS instances, which is inefficient and does not scale. The SLF provides a centralized, standardized lookup service, enabling the deployment of multiple, independent HSS databases. This allows operators to scale their subscriber capacity horizontally by adding more HSS nodes without reconfiguring every CSCF in the network.
Its creation was motivated by the move towards distributed, carrier-grade architectures. In 2G/3G circuit-switched cores, the HLR (Home Location Register) was typically a monolithic, centralized database. IMS, designed for IP-based multimedia services, required a more flexible and scalable approach. The SLF facilitated this by decoupling the subscriber location logic from the service logic in the CSCFs. This design principle carried forward into 5G, where the concept is embedded within the UDM's service-based architecture. The SLF addresses the limitations of monolithic databases by enabling stateless, scalable control plane functions (like CSCFs) to dynamically locate stateful data repositories, which is a cornerstone of cloud-native network design.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (34 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-2, normative work from Rel-15.
In Release 15, the SLF function saw updates primarily concerning location information handling for 5GS, including the introduction of Sh location information and the SMSF address within the 5GS Location Information. The release also introduced clarifications for reporting location to an SCS/AS for a group of UEs via the PCRF. Furthermore, specific changes were made to the cardinality and content of Reference Location Information.
- Enable minimum time interval for Continuous Location Reporting TS 23.682CR0322
- TMGI and Location changes for GMD TS 23.682CR0274
- Making the T8 Destination Address Mandatory for APIs that Create a Subscription TS 23.682CR0390
- Clarifications on report location to SCS/AS for a group of UEs via PCRF TS 23.682CR0361
- Change of Reference Location Information TS 29.228CR0688
- P-CSCF restoration for 5GC TS 29.228CR0689
+ 5 more changes
In Release 16, the enhancements for the Subscription Location Function (SLF) were primarily indirect, focusing on supporting new procedures for P-CSCF and S-CSCF discovery and restoration using the NRF, rather than direct modifications to the SLF itself. The updates enabled the SMF to perform P-CSCF discovery via the NRF and introduced support for PCRF-based P-CSCF restoration. Furthermore, corrections were made to S-CSCF discovery during registration and to location services, including providing user location during IP messaging.
- eIMS P-CSCF use of NRF TS 23.228CR1199
- Allowing SMF to perform P-CSCF Discovery using NRF TS 23.228CR1202
- Providing User Location during IP Messaging TS 23.228CR1237
- Update P-CSCF Registration with NRF TS 23.228CR1219
- Corrections to S-CSCF discovery during RLOS IMS registration TS 23.228CR1228
- Correction on enhancements to Location Services for CIoT TS 23.682CR0435
+ 5 more changes
In Release 17, updates for the SLF function included enhancements for handling group-based event subscriptions by supporting the addition of UEs and enabling subscription to notifications for IMEI changes. The release also introduced procedures to manage scenarios with unavailable location information and addressed failures related to the P-CSCF. These changes were facilitated through the Dx reference point between an I-CSCF and an SLF.
In Release 18, the SLF function was updated to support DCM (Data Channel Management) selection based on a user's IP address and location, enhancing routing decisions for IMS services. This builds upon the existing Dx reference point between an I‑CSCF and an SLF for querying subscriber data. Furthermore, the release included updates to the subscription data for the IMS Data Channel Service, which interfaces with application servers via reference points like Sh and ISC.
In Release 19, the SLF function's enhancements included a new capability for the HSS to manage subscriptions to an IMS Application Server (IMA AS) and its associated event notification procedure via the Sh interface. Furthermore, clarifications were introduced for the User Plane path event subscription procedures, specifically for UE-satellite-UE communication scenarios, and for the P-CSCF's behavior in those same scenarios. The release also standardized input parameter alignment for UP path change subscriptions and defined an MPS for Messaging indication check over the Cx reference point.
- Add HSS subscription to IMA AS and event notification procedure via Sh interface TS 29.328CR0661
- Clarification on UP path event subscription for UE-satellite-UE communication TS 23.228CR1630
- Input Parameter Alignment for UP Path Change Subscription in TS 23. 228 TS 23.228CR1656
- Clarification of P-CSCF Behavior for UE-Satellite-UE Communication TS 23.228CR1685
- MPS for Messaging Indication Cx subscription check TS 29.228CR0701
Explore further
Broader topics and technologies where SLF plays a role.
Defining Specifications
3GPP specifications that define or reference SLF, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 23.228 vj50 | IMS Stage-2 Service Description | Rel-19 |
| TS 23.271 vj00 | LCS Stage 2 Specification | Rel-19 |
| TS 23.417 v1700 | IMS Core Component for NGN Architecture | Rel-7 |
| TS 23.517 v1800 | IMS Core Component for NGN Architecture | Rel-8 |
| TS 23.682 vj30 | 3GPP TS 23682: MTC Architecture Enhancements | Rel-19 |
| TS 23.845 va00 | UDC Evolution Study | Rel-10 |
| TS 24.229 vj50 | IMS call control protocol based on SIP and SDP | Rel-19 |
| TS 24.407 v830 | OIP and OIR Simulation Services Protocol | Rel-8 |
| TS 24.508 v820 | TIP and TIR Service Protocol Description | Rel-8 |
| TS 24.524 vj00 | Hosted Enterprise Services Architecture | Rel-19 |
| TS 28.620 vj20 | FMC Federated Network Information Model (FNIM) UIM | Rel-19 |
| TS 28.702 vj00 | Core Network NRM IRP Information Service | Rel-19 |
| TS 28.705 vj00 | IMS NRM IRP Information Service | Rel-19 |
| TS 29.109 vj00 | GAA Bootstrapping Interfaces (Zh, Dz, Zn, Zpn) | Rel-19 |
| TS 29.228 vj20 | Cx and Dx Interface Signaling Flows | Rel-19 |
| TS 29.229 vj10 | Diameter Protocol for Cx/Dx Interfaces | Rel-19 |
| TS 29.328 vj20 | Sh and Dh Interfaces: HSS-AS Interactions | Rel-19 |
| TR 29.949 vj00 | VoLTE IMS Roaming Architecture & Procedures | Rel-19 |
| TS 32.102 vj00 | Telecom Management Physical Architecture Framework | Rel-19 |
| TS 32.632 vb00 | Core Network Resources IRP: Network Resource Model | Rel-11 |
| TS 32.732 vb00 | IMS Network Resource Model IRP: Information Service | Rel-11 |
| TS 32.808 v1800 | Common User Profile Storage Framework | Rel-8 |
| TS 32.820 v1801 | Charging Architecture Study for Evolved 3GPP | Rel-8 |
| TS 33.110 vj00 | UICC-Terminal Key Establishment | Rel-19 |
| TS 33.220 vj00 | Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) | Rel-19 |
| TS 33.259 vj00 | Key Establishment between UICC Hosting & Remote Device | Rel-19 |
| TS 33.804 vc00 | Non-UICC SSO using SIP Digest credentials | Rel-12 |
| TR 33.924 vj00 | GBA-OpenID Interworking Specification | Rel-19 |
| TR 33.978 v1800 | Interim Security for Early IMS | Rel-8 |