ULR

Update Location Request

Core Network →
Introduced in Rel-15

ULR is a Diameter command sent from an AMF to a UDM in a 5G core network to register a UE's location, retrieve its subscription data, and authenticate the user.

Category
Core Network
Introduced
Rel-15
Where
Security
Specifications
1 specs
ULR Description Purpose Related Classification Detected Changes Specifications

Description

The Update Location Request (ULR) is a critical Diameter-based command message defined in 3GPP TS 29.272 and TS 33.501 for the 5G System (5GS). It is used on the N8 interface (in 5G) between the Access and Mobility Management Function (AMF) and the Unified Data Management (UDM). The primary function of the ULR command is to inform the UDM of the UE's current serving network node (AMF) and to request the UE's subscription profile and authentication data. This procedure is central to the initial registration, mobility registration updates, and periodic registration processes in 5G.

Architecturally, the AMF acts as the Diameter client, initiating the ULR command towards the UDM, which acts as the Diameter server. The message contains a wealth of information in its Attribute-Value Pairs (AVPs). Key AVPs include the User-Name (containing the SUPI or SUCI), the Visited-PLMN-Id, the RAT-Type (e.g., NR, E-UTRA), and the AMF's identity. Upon receiving a ULR, the UDM validates the request, checks the subscriber's status, and may trigger authentication procedures with the Authentication Server Function (AUSF).

How it works is integrated into the UE registration flow. When a UE attempts to register with the 5G network, the AMF, after initial interaction with the UE, sends a ULR command to the UDM. The UDM processes this request: it authenticates the subscriber, authorizes the registration for the given PLMN and access type, and retrieves the subscriber's profile from its database. The UDM then responds with an Update Location Answer (ULA) command. The ULA carries essential data back to the AMF, including the subscriber's Access and Mobility Subscription data, Session Management Subscription data, and potentially authentication vectors.

Its role is foundational for mobility, security, and policy enforcement. The ULR/ULA exchange ensures the UDM, as the central repository of subscriber data, is always aware of the UE's serving AMF. This enables features like lawful interception, subscription-based service restrictions, and mobility event notifications to other Network Functions (NFs). It replaces the Update Location Request procedure used in the Diameter-based S6a/S6d interface between MME and HSS in 4G EPS, adapted for the service-based architecture of 5GC.

Purpose & Motivation

The ULR command exists to provide a standardized, secure, and efficient mechanism for location update and subscription data retrieval in the service-based 5G Core network. It addresses the need for a decoupled, scalable procedure in the new cloud-native architecture, moving away from the point-to-point GTP and Diameter interfaces of previous generations. In 4G EPS, a similar Update Location Request existed on the S6a interface between MME and HSS, but the 5G ULR is adapted for the new network functions (AMF/UDM) and supports enhanced security features like subscription concealment (SUCI).

The problem it solves is maintaining accurate and timely knowledge of a subscriber's point of attachment within the network for mobility management, service delivery, and regulatory compliance. Without this procedure, the core network would not know which AMF is serving a UE, preventing the routing of mobile-terminated sessions, applying correct mobility policies, or ensuring the subscriber is authorized to use the network. It is the primary trigger for the UDM to provision the AMF with the subscriber's service profile.

Furthermore, its creation was motivated by the 5G design principles of network slicing, stateless NFs, and service-based interactions. The ULR procedure, using HTTP/2 with JSON or Diameter over SBA, allows the AMF to subscribe to changes in the UDM data, enabling more dynamic and efficient updates compared to the static pull model, thereby supporting advanced use cases like network slicing and edge computing.

Classification

Part ofAMF
Related approachesUDM

Detected Changes Across Releases

from 3GPP Change Requests

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

Rel-15 30 changes

In Release 15, the Update Location Request (ULR) procedure was enhanced with new security mechanisms for subscriber privacy and network function authorization. Specifically, it introduced the requirement for the AUSF to provide the SUPI to the serving network only after successful authentication when a SUCI was used, and it mandated that the UDM's Subscription Identifier De-concealing Function (SIDF) resolve the SUPI from the SUCI. Furthermore, the release established security requirements for service-based interfaces, including that NF service requests shall support mutual authentication and that the NRF shall act as an authorization server for access token requests.

  • Security mechanism for UE Parameters Update via UDM Control Plane Procedure TS 33.501CR0484
  • Authorization of Application Function's requests TS 33.501CR0213
  • Update on SEAF requirements TS 33.501CR0223
  • Clause 6.7.3.5 - Correct reference for RNA update procedure TS 33.501CR0240
  • Deletion of Requester ID from 'Nausf_UEAuthentication_authenticate' TS 33.501CR0252
  • AS SMC Handling Update TS 33.501CR0272

+ 24 more changes

Rel-16 9 changes

In Release 16, the Update Location Request (ULR) procedure was enhanced with stricter security measures for handling the subscriber identifier (SUPI). Specifically, it mandated that the SUPI must never be sent in clear text outside the 3GPP operator domain and required its confidentiality protection when sent over the N32-f interface. Furthermore, the release reinforced that the AUSF shall only provide the SUPI to a visited network after successful authentication confirmation when the initial request used a concealed identifier (SUCI).

  • SUCI computation: implementers' test data for network specific identifier-based SUPI TS 33.501CR0847
  • Update to User Plane Integrity Protection TS 33.501CR0852
  • Input parameters of access token request addition and verification TS 33.501CR0972
  • Updates to Counter Check Procedure TS 33.501CR0691
  • Clarification on the use of SUPI as the Identity in EAP-AKA' key derivation TS 33.501CR0762
  • Update the N32-f context ID negotiation procedure TS 33.501CR0917

+ 3 more changes

Rel-17 11 changes

In Release 17, updates to the Update Location Request (ULR) function included clarifications for handling the Registration Request during a direct AMF re-allocation procedure. The release also defined new security containers, specifically the SoR-XMAC-IUE and UPU-XMAC-IUE, for enhanced integrity protection of Steering of Roaming and User Parameters Update information sent to the UE. Furthermore, corrections and updates were made to the service request process, including aspects related to OAuth 2.0 based authorization and the role of the NRF as an authorization server.

  • Removing Editor's note on SUPI sent to AAA TS 33.501CR1289
  • Update of references for the GBA related UDM service operations TS 33.501CR1343
  • Clarification of the Registration Request handling for the direct AMF re-allocation TS 33.501CR1344
  • Update A.17 for SoR transparent container TS 33.501CR1513
  • Update A.18 to define SoR-XMAC-IUE TS 33.501CR1514
  • Update A.20 to define UPU-XMAC-IUE TS 33.501CR1515

+ 5 more changes

Rel-18 21 changes

In Release 18, the Update Location Request (ULR) procedure was enhanced with stricter validation of access token request parameters, particularly for roaming, interconnect, and hierarchical NRF deployment scenarios. These updates ensure that attributes like the requested network slices are properly validated by both the NRF and the NF service producer during service authorization. Furthermore, the release introduced clarifications and security improvements for AI/ML model sharing and federated learning processes within the 5G core network.

  • Security in 5G system location services to support user plane positioning TS 33.501CR1765
  • Updates to Federated Learning TS 33.501CR1935
  • SCPAC: Updates to Security for Selective SCG Activation TS 33.501CR1970
  • Access token request handling by NRF TS 33.501CR1667
  • Clarification on access token request for accessing services TS 33.501CR1728
  • Validation of the parameters sent by OAuth 2.0 client (NF Service Consumer) in the access token request. TS 33.501CR1760

+ 15 more changes

Rel-19 3 changes

In Release 19, the Update Location Request (ULR) function was enhanced with updates to cryptographic profiles and security handling for scenarios where a Central Unit (CU) acts as the Master Node (MN) while the Secondary Node (SN) remains unchanged. Furthermore, the release deprecated the use of the `requesterPlmnList` parameter within the Access Token Request procedure. These changes collectively refine the security and authorization mechanisms for network function interactions and subscriber data protection.

  • Updates to cryptographic profiles TS 33.501CR2087
  • Update to security handling when CU is acting as MN and SN is unchanged TS 33.501CR2188
  • Deprecation of the use of the requesterPlmnList in the Access Token Request TS 33.501CR2192

Explore further

Broader topics and technologies where ULR plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20