Cisco Cisco ASR 5000

Page of 640
SGSN Serving Radio Network Subsystem Relocation   
▀  How it Works 
 
▄  SGSN Administration Guide, StarOS Release 18 
   
Step
 
Description
 
The SGSN sends a Relocation Request message to the new RNC. At this point, radio access bearers have been established. 
The new RNC sends a Relocation Request Acknowledgement message to the SGSN. 
The SGSN sends a Relocation Command to the old RNC and the UE is detached from the old RNC and attached to the new 
RNC. 
The old SRNC may, according to the QoS profile, begin the forwarding of data for the RABs to be subject for data 
forwarding. 
Before sending the Relocation Commit the uplink and downlink data transfer in the source, the SRNC shall be suspended 
for RABs, which require a delivery order. The source RNC starts the data-forwarding timer. When the old SRNC is ready, 
the old SRNC triggers the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to 
the new RNC over the Iur interface. 
The new RNC sends a RAN Mobility Information message. This message contains UE information elements and CN 
information elements. 
When the new SRNC receives the RAN Mobility Information Confirm message, i.e. the new SRNC—ID + S-RNTI are 
successfully exchanged with the MS by the radio protocols, the target SRNC initiates the Relocation Complete procedure 
by sending the Relocation Commit message to the new SGSN. 
10 
The new RNC sends a Relocation Detect message to the SGSN. 
11 
The SGSN sends a Relocation Complete message to the new RNC. 
12 
If Direct Tunnel was established during intra-SGSN SRNS relocation, the SGSN sends Update PDP Context Request 
messages to the GGSN. 
13 
If Direct Tunnel was established during intra-SGSN SRNS relocation, the SGSN sends Update PDP Context Response 
messages to the GGSN. 
14 
The SGSN sends an Iu Release Command to the old RNC. 
15 
The old RNC releases the Iu connection and sends a Release Complete message to the SGSN. 
16 
After the MS has finished the RNTI reallocation procedure, and if the new Routing Area Identification is different from the 
old one, the MS initiates the Routing Area Update procedure. 
 
SRNS Relocation on the S4-SGSN 
On the S4-SGSN, the SRNS relocation feature is triggered by subscribers (MS/UE) moving between an eNodeB and an 
RNC or between two RNCs.  
If the originating and destination nodes are connected to the same S4-SGSN but are in different routing areas, the 
behavior triggers an intra-SGSN Routing Area Update (RAU).  
If the nodes are connected to different S4-SGSNs, the relocation is followed by an inter-SGSN RAU. This RAU occurs 
over a RANAP direct transfer. As a result, it does not trigger Context Request/Context Response/Context Ack 
procedures with the old SGSN/MME. These procedures are otherwise performed during a normal SGSN RAU. 
The GTPv2 protocol is used for SRNS relocation between two RNCs and between an eNodeB and an RNC.  
In addition to supporting Inter-SGSN SRNS relocation across the Gn interface, the S4-SGSN supports SRNS relocation 
for the following scenarios across the S3 (S4-SGSN to MME) and S16 (S4-SGSN to S4-SGSN) interfaces: 
 
Inter-SGSN SRNS relocation over the S16 interface