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
