Description
The User Reachability Request Parameter for SGSN (URPP-SGSN) is a detailed information element within the GPRS Tunnelling Protocol for the control plane (GTP-C), specified in 3GPP TS 29.272 (Evolved Packet System; Mobility Management Entity and Serving GPRS Support Node related interfaces). It is used in the communication between the Serving GPRS Support Node (SGSN) – which manages mobility and session for UEs in 2G (GERAN) and 3G (UTRAN) access – and the Gateway GPRS Support Node (GGSN) in GPRS/UMTS cores, or the Packet Data Network Gateway (PGW) in the Evolved Packet Core (EPC). Its primary function is to convey the SGSN's request regarding how it wishes to be informed about changes in the User Equipment's (UE) reachability status from the gateway's perspective.
Operationally, the URPP-SGSN is included in GTP-C messages like Create Session Request, Modify Bearer Request, or specific Context Request/Response messages. The parameter contains flags that specify the SGSN's preferences. A key flag is the 'Request for UE Reachability Notification'. When this flag is set, it instructs the GGSN/PGW to monitor for the UE transitioning from an unreachable state (e.g., due to power-off, out-of-coverage, or extended idle timers) back to a reachable state. If such a transition is detected by the gateway (often because it receives downlink data for a UE it had marked as unreachable), the GGSN/PGW will then send a Downlink Data Notification (DDN) message to the SGSN, even if it might not have done so otherwise. This triggers the SGSN to initiate paging procedures to locate and establish a connection with the UE.
This mechanism is a crucial part of network efficiency and power saving for UEs. Without URPP-SGSN, a GGSN/PGW might silently discard downlink data packets for a UE it believes is unreachable, or it might aggressively send DDN messages that lead to unnecessary paging and signaling load. By allowing the SGSN to explicitly request notifications only when needed, the network optimizes the trade-off between ensuring timely data delivery and conserving radio and core network signaling resources. The SGSN's decision to set the flag is based on its local policy, subscriber profile, and the nature of the activated Packet Data Protocol (PDP) context or PDN connection.
Purpose & Motivation
The URPP-SGSN parameter was introduced to address inefficiencies in downlink data handling and paging for mobile devices, particularly as networks evolved to support always-on IP connectivity and diverse data services. In early GPRS releases, the mechanisms for notifying the SGSN about pending downlink data were less refined, potentially leading to either missed data (if the gateway gave up too easily) or excessive, battery-draining paging (if the gateway was too aggressive). The problem was especially relevant for smartphones and M2M devices with intermittent connectivity or long sleep cycles.
URPP-SGSN solves this by putting control in the hands of the SGSN, which has more direct knowledge of the UE's radio state and mobility patterns. It allows the SGSN to tailor the gateway's behavior on a per-session basis. For example, for a background synchronization service, the SGSN might not request reachability notifications, accepting that data can be delayed. In contrast, for a real-time messaging service, it would request notifications to ensure prompt delivery. This granular control optimizes network resource usage (reducing unnecessary paging signaling) and improves the user experience by ensuring timely delivery for important data flows while allowing less critical flows to be handled in a more network- and battery-efficient manner. Its specification in TS 29.272, starting from Release 9, was part of the broader EPC standardization that refined the interactions between the SGSN (for legacy access) and the new PGW entity.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (10 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-9, normative work from Rel-15.
In Release 15, clarifications were introduced for the UE Reachability monitoring event over the S6a/S6d interfaces, specifying the procedures for the MME and SGSN. This included defining the behavior of the MME/SGSN upon reception of a DIAMETER_UNABLE_TO_COMPLY error for a Notification-Request (NOR) command. Additionally, corrections and clarifications were made regarding the handling of the subscribed eDRX parameter and the S6a Notification-Request command for non-IP APNs.
- Clarification of S6a/Notification-Request command for non-IP APNs TS 29.272CR0718
- Correction on subscribed eDRX parameter value TS 29.272CR0743
- Clarification of UE Reachability monitoring event over S6a/S6d TS 29.272CR0740
- Behavior of MME/SGSN upon reception of DIAMETER_UNABLE_TO_COMPLY for NOR TS 29.272CR0784
- Access Restriction to NR as Secondary RAT for SGSN TS 29.272CR0794
In Release 16, the URPP-SGSN function was enhanced to support a combined MME/SGSN node, allowing it to operate over both the S6a and S6d interfaces using a single Diameter identity. This update also introduced the ability for the SGSN to interwork with 5G systems, as indicated by the CR title for SGSN interworking. Furthermore, the specification clarified procedures for the SGSN to register for SMS services when sending an Update Location Request.
In Release 18, the enhancement for URPP-SGSN introduced a new "Reachability Cause" parameter for immediate reports. This addition provides the SGSN with a specific reason for requesting user reachability information when interacting with the HSS over the S6d interface. The update refines the procedures for subscriber data management by allowing more granular control over reachability requests initiated by the SGSN.
- Reachability Cause in immediate reports TS 29.272CR0844
In Release 19, the URPP-SGSN function was enhanced to allow the SGSN to explicitly indicate its capability and preference for SMS registration via the S6d interface. This was achieved by introducing the "SMS Register Request" information element within the Update Location Request procedure, enabling the SGSN to inform the HSS if it needs to be registered, prefers not to be registered, or has no preference for SMS. This formalized the registration mechanism for "SMS in SGSN," aligning it with the existing capability for the MME on the S6a interface.
- MME/SGSN registration for SMS TS 29.272CR0886
Explore further
Broader topics and technologies where URPP-SGSN plays a role.
Defining Specifications
3GPP specifications that define or reference URPP-SGSN, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TS 29.272 vj40 | Diameter Interfaces for MME/SGSN | Rel-19 |