cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

SGSN offloading procedure

1448
Views
3
Helpful
2
Comments

 

 

Introduction

Goal

To offload subscribers from one SGSN to the other peer SGSN in the pool.

Primary purpose

There are situations where a network operator will wish to remove load from one CN node in an orderly manner (e.g. to perform scheduled maintenance, or, to perform load re-distribution to avoid overload) with minimal impact to end users and/or additional load on other entities. The re-distribution procedure does not require any new functionality in the terminal, that is, all terminals can be moved.

NOTE: During the offload and the upgrade procedure, please monitor the peripheral network elements encompassing and not limited to : STP, PCRF, GGSN/SPGW, MO, RNC.

 

 As Per 3GPP Standard


Re-distribution of UEs is initiated via an O&M command in the CN node, which needs to be off-loaded.


1st phase
 In a first phase (a couple of Periodic LU/RAU periods long), UEs doing LU/RAU or Attach are moved to other CN nodes in the pool. When the CN node receives the Location Update, Routing Area Update or Attach request, it returns a new TMSI/P-TMSI with a null-NRI, and a non-broadcast LAI/RAI in the accept message.
 In the PS domain, a new Routing Area Update is triggered by setting the periodic routing area update timer to a sufficiently low value (recommended value is 4 seconds) in the accept message. The UE will shortly after send a new Routing Area Update that the RAN node then will route to a new SGSN due to the presence of a null-NRI.


2nd Phase
In a second phase (PS domain specific), the SGSN requests all UEs trying to set up PDP Contexts to detach & reattach. When they reattach, the SGSN moves them as in the first phase described above.


3rd Phase

A third phase includes scanning through remaining UEs and initiating a move of them to other CN nodes. In the PS domain UEs are requested to detach and reattach, which will cause them to be moved. In case of CS domain a new TMSI is allocated to these UEs using the TMSI re-allocation procedure (with null-NRI and non-broadcast LAI) so that a Location Update is triggered when the ongoing CM transaction ends, which will cause them to be moved.
UEs being moved from one CN node are stopped from registering to the same CN node again by an O&M command in BSCs and RNCs connected to the pool. UEs moving into a pool area may also be stopped from registering into a CN node being off-loaded in the same manner.
In network configurations using MOCN network sharing, re-distribution is always done between CN nodes within the same CN Operator. This is ensured by each CN Operator using his own unique null-NRI. The RAN node is preconfigured with the null-NRIs for the different CN Operators, and it uses the null-NRI to select a CN node within the same CN Operator.
A CN node should ensure that move operations does not overload the network. BSCs and RNCs shall be able to handle situations where several CN nodes are off-loaded simultaneously.

 

CLI used in Cisco SGSN

 

Start SGSN offloading procedure for 1st phase

context gnctx
sgsn offload sgsn-service <> connecting


Check status of offloading
show sgsn-service name <>


5.2 Start SGSN offloading procedure for 2nd phase
context <>
sgsn offload sgsn-service <> activating
Check status of offloading
show sgsn-service name <>

5.3 Start SGSN offloading procedure for 3rd phase
***Start executing this phase only if big traffic degradation is present and only after Customer approval**
clear subs all
yes

 

Backoff procedure

1.To Stop-offloading for Phase 1

Context gn_ctx

sgsn offload sgsn-service sgsn_svc connecting stop

          

2. To Stop-offloading for phase 2

Context gn_ctx

sgsn offload sgsn-service sgsn_svc activating stop

 

***Note:- Confirm if the offloading stopped by applying the following command.***

             show sgsn-service name <>

                   (ensure result: Offloading - connecting(Off), activating(Off)

 

Related Information

 

Comments
Cisco Employee

Hi Krishna, thanks a lot for your great job for this brilliant document, it's just in time since I'm preparing a SGSN node upgrade project. Here I want to ask you one more question, what's the suggestion for the duration of phase 1 and phase 2 offload, given the online 3G sessions are around 500K?

Thanks,

Tiger

Cisco Employee

My suggestion would be too gradually removed the Subs one by one. 

CreatePlease to create content