Description
SRNS Relocation is a fundamental mobility procedure in UTRAN (UMTS Terrestrial Radio Access Network) that transfers the role of the Serving Radio Network Subsystem (SRNS) from one Radio Network Subsystem (RNS) to another. In a UMTS network, the RNS that owns the Iu interface connection towards the Core Network (CN) for a given UE is called the Serving RNS (SRNS). The SRNS is responsible for terminating the Radio Resource Control (RRC) connection, managing radio resources, and acting as the anchor point for the UE's connection to the CN. When a UE moves such that a different RNS would be better positioned to serve it, the SRNS role must be relocated to that target RNS, which then becomes the new SRNS. The procedure is defined and referenced in 3GPP TS 21.905 (Vocabulary for 3GPP Specifications), where it is described as 'the change of Iu instance and transfer of the SRNS role to another RNS.'
The procedure involves several distinct phases. First, a relocation decision is made, typically by the SRNC (Serving RNC) based on measurement reports from the UE indicating that a drift RNC (DRNC) offers better radio conditions. The SRNC then initiates the relocation by sending a Relocation Required message to the CN (either the MSC for CS domain or SGSN for PS domain). The CN coordinates with the target RNC through a Relocation Request message, and the target RNC prepares the necessary radio resources. Once the target RNC is ready, it responds with a Relocation Request Acknowledge, and the CN instructs the source RNC to execute the relocation via a Relocation Command. The source RNC then sends a Relocation Commit to the target RNC, and the UE is instructed to perform the necessary reconfiguration to communicate with the new SRNC.
A key architectural aspect of SRNS Relocation is the distinction between the control plane and user plane handling. During relocation, the Iu interface instance is moved from the source RNC to the target RNC. This means that the RRC connection, the Iu signalling connection, and the associated user plane bearers must all be re-established or transferred. Depending on the type of relocation (UE involved or UE not involved), the process may require the UE to participate in the reconfiguration. The relocation can be intra-SGSN/intra-MSC (where the CN anchor remains the same) or inter-SGSN/inter-MSC (where the CN anchor also changes), with the latter being more complex as it involves additional CN signalling.
SRNS Relocation also encompasses the concept of 'SRNS Relocation with Iur' and 'without Iur.' When an Iur interface exists between the SRNC and DRNC, the relocation can be prepared more efficiently because the two RNCs can communicate directly. Without Iur, all coordination must go through the CN, adding latency and signalling overhead. The procedure supports both hard relocation (where the old radio link is released before the new one is established) and soft relocation (where both links exist temporarily), though soft relocation is more common in CDMA-based systems.
From a network performance perspective, SRNS Relocation is critical for maintaining service continuity during mobility. It ensures that the UE's connection to the CN is preserved while the radio access anchor point changes. The procedure must be fast enough to avoid noticeable service interruption, and it must be reliable to prevent dropped calls or data sessions. It also interacts with other mobility procedures such as soft handover, cell update, and URA update. In later releases, SRNS Relocation concepts were adapted for inter-RAT mobility (e.g., UMTS to LTE) and for the evolution towards flattened architectures, though the fundamental principle of transferring the serving anchor role remains relevant in modern networks.
Purpose & Motivation
SRNS Relocation exists to solve the problem of maintaining a stable connection between a mobile UE and the Core Network while the UE moves across the coverage areas of different Radio Network Subsystems. In early UMTS deployments, each RNC could potentially connect to the CN, but only one RNC could act as the serving anchor for a given UE at any time. Without a mechanism to transfer this role, a UE moving away from its serving RNC would either lose its connection or require a complete re-establishment of its CN connection, causing service interruption and excessive signalling.
The procedure was motivated by the need for seamless mobility in UMTS networks, particularly for real-time services like voice calls and video telephony where interruptions are unacceptable. It allows the network to optimise the radio path by moving the serving anchor closer to the UE's current location, reducing backhaul requirements and improving radio efficiency. It also enables load balancing across RNCs and supports scenarios where the original serving RNC becomes congested or fails.
Historically, SRNS Relocation was introduced as part of the UMTS architecture in 3GPP Release 99 and refined in Release 4 and beyond. It addressed the limitations of earlier GSM/GPRS mobility mechanisms, which were designed for circuit-switched voice and simple packet data and did not support the concept of a serving RAN anchor with a direct Iu interface. The procedure has evolved to support more complex scenarios, including inter-SGSN relocation, relocation with Iur, and relocation for high-speed packet access (HSPA) services, ensuring that UMTS networks could deliver the quality of service expected by mobile users.
What changed in its specifications
The latest release-to-release comparison of specifications that define SRNS Relocation. Each summary describes the whole specification, not only this term.
Rel-18 brings only minor changes to TS 21.905: 0 clauses changed, with no change attributed to a release feature.
Full comparison in TR 21.905 →Release Timeline
Evolution Across Releases
An overview written from the defining specifications, not a verified change history. For the exact text, open the specifications listed below.
Defining Specifications
3GPP specifications that define or reference SRNS Relocation, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj20 | 3GPP Terminology and Definitions | Rel-19 read |