Description
The Update Notification Acknowledgment (UPA) is a specific Diameter Answer message defined in the 3GPP S6a (for LTE/EPC) and S6d (for GTP-based SGSN to HSS) interface specifications. It is the direct response to the Update Notification Request (UPR) command. The S6a/S6d interface is used for authentication, authorization, and mobility management between the Mobility Management Entity (MME) or Serving GPRS Support Node (SGSN) and the Home Subscriber Server (HSS). The UPR/UPA dialog is a critical mechanism for the HSS to proactively notify the MME/SGSN about changes in a subscriber's profile or status stored in the HSS.
Technically, the UPA is a Diameter message with the Command-Code set to 316 (Update-Notification) and the 'R' bit cleared in the Command Flags field, indicating it is an Answer. It is sent from the MME or SGSN back to the HSS. The primary function of the UPA is to inform the HSS that the MME/SGSN has successfully received and processed the corresponding UPR. The UPA message carries a Result-Code AVP (Attribute-Value Pair) which indicates the outcome of the processing. A successful acknowledgment would use a Result-Code like DIAMETER_SUCCESS (2001).
The UPA message may also contain other relevant AVPs. For instance, if the UPR requested the MME to send user data, the UPA could include the requested data in specific AVPs. The exchange ensures synchronization between the HSS (the master database) and the serving node (MME/SGSN) regarding subscriber information. This is crucial for enforcing changes like updated QoS profiles, subscribed Access Point Names (APNs), or barring status in real-time, without waiting for the next periodic update or attach procedure. The reliable delivery of the UPA confirms to the HSS that the serving node is now applying the updated subscriber parameters, maintaining consistent service delivery across the network.
Purpose & Motivation
The UPA exists as part of a reliable notification protocol to keep subscriber data synchronized between the central repository (HSS) and the distributed network nodes (MME/SGSN) that enforce policies and manage sessions. It solves the problem of stale or inconsistent subscriber data in the serving node, which could lead to service issues, incorrect charging, or security vulnerabilities. Before such mechanisms, updating a subscriber's profile often required the subscriber to re-attach to the network or relied on infrequent synchronization, which was inefficient and slow.
Introduced in the context of the Evolved Packet Core (EPC) and Diameter-based interfaces (Release 11 for S6a refinement), the UPR/UPA procedure provides a push model for data updates. The motivation was to support dynamic policy changes and real-time service modifications. For example, an operator could instantly disable a lost device (via IMSI detach) or upgrade a user's service plan, and the HSS could immediately notify the serving MME, which would acknowledge with a UPA. This ensures network responsiveness and enables advanced, real-time subscriber management features, improving both operational efficiency and customer experience.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (5 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-11, normative work from Rel-15.
In Release 15, the UPA (Update Notification Acknowledgment) function was formally introduced as part of the PMIPv6 LMA Initiated Update Notification procedure, which is based on IETF RFC 7077. This procedure allows an LMA to notify a MAG that a Binding Cache Entry is about to be updated, prompting the MAG to send a UPA message for confirmation. The introduction specifically supports handover scenarios with SGW relocation and can trigger the generation of an End Marker by the MAG.
- Update to Rel-15 version (MCC) TS 29.275
In Release 16, the UPA (Update Notification Acknowledgment) function was formally integrated as part of the standardized PMIPv6 LMA Initiated Update Notification procedure, based on IETF RFC 7077. This procedure allows a Local Mobility Anchor (LMA) to notify a Mobile Access Gateway (MAG) of an impending Binding Cache Entry update, with the UPA message serving as the mandatory acknowledgment from the MAG. The procedure was specified to trigger resource updates and, in specific cases like handover with SGW relocation, to initiate the generation of an End Marker by the MAG.
- Update to Rel-16 version (MCC) TS 29.275
In Release 17, the update to the UPA function involved aligning the specification with the Rel-17 version, as indicated by the CR title "Update to Rel-17 version (MCC)." The technical procedure itself, the PMIPv6 LMA Initiated Update Notification procedure where the UPA message is used, remains based on IETF RFC 7077 for the MAG to acknowledge the LMA's Update Notification.
- Update to Rel-17 version (MCC) TS 29.275
In Release 18, the updates to the UPA function involved aligning the specification text to its Rel-18 version, as indicated by the Change Request titled "Update to Rel-18 version (MCC)." The core technical procedures for the PMIPv6 LMA Initiated Update Notification, where the UPA message is used by the MAG to acknowledge the LMA's Update Notification (UPN), remained based on the existing IETF RFC 7077 framework.
- Update to Rel-18 version (MCC) TS 29.275
In Release 19, the update to the UPA (Update Notification Acknowledgment) function was specifically an update to the Rel-19 version, as indicated by the Change Request. This maintenance change aligns the UPA procedure, which is part of the Proxy Mobile IPv6 LMA Initiated Update Notification process based on IETF RFC 7077, with the overall Release 19 specification version.
- Update to Rel-19 version (MCC) TS 29.275
Explore further
Broader topics and technologies where UPA plays a role.
Defining Specifications
3GPP specifications that define or reference UPA, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 29.275 vj00 | PMIPv6 Mobility & Tunnelling Protocols Stage 3 | Rel-19 |