Offload SGSN Subscribers with Target-NRI and Target-Count in the SGSN Pool for an ASR 5000 Series

Introduction

This document describes how to offload traffic from one Serving General Packet Radio Service (GPRS) Support Node (SGSN) to Another SGSN in the same pool with the use of a target-Network Resource Identifier (NRI).

Background Information

In order for the Cisco 500 Series Aggregation Services Router (ASR500) SGSN to offload subscribers, it assigns a Non Broadcasting-Routing Area Identifier (NB-RAI), stamps a target-NRI in the Packet Temporary Mobile Subscriber Identifier (P-TMSI), and reduces the periodic routing area update timer during the Attach/Routing Area Update (RAU) accept messages. The offload CLI command is enhanced with the target-NRI and the number of subscribers in order to offload with that target-NRI. Once the target-based offloading CLI command is issued, the SGSN begins to offload the subscribers. It does not stop the offload process until a disable CLI command is issued, or when the target-count is reached.

Here is some important information to consider about the offload process:

• The SGSN does not have control over the offload rate; it depends on the Attach/RAU requests from the subscribers. The Attach/RAU requests can occur for current or new subscribers, and the current subscribers can be in either the Idle/Connected or Standby/Ready state.
• Because the Attach/RAU requests are not controlled by the SGSN, the SGSN cannot commit rate/counts per Session Manager (SESSMGR).

Offload Subscribers in Target SGSN

This section describes how to enable traffic offloading to the target SGSN.

Basic Configuration Required

Here is the basic configuration that is required in order to offload subscribers:

a) iups-service iups_svc
      	# plmn id mcc <XXX> mnc <XXX> network-sharing common-plmn mcc <XXX> mnc <XXX>

b) sgsn-global , imsi-range definition
#imsi-range mcc <XXX> mnc <XXX> operator-policy <oppolicy> (or)
#imsi-range mcc <XXX> mnc <XXX> PLMNID <common-plmn> operator-policy <oppolicy>

c) associate cc-profile to this op-policy and hook up the peer sgsn address static
   mapping.

# sgsn-address rac <xxx> lac <xxx> nri <> prefer local address ipv4 <XXX.XXX.XXX.XXX>

Note: Perform additional configuration changes as needed in order to allow RAU to work in offload cases.

You must configure an op-policy without a Public Land Mobile Network (PLMN) definition or common PLMN definition in the International Mobile Subscriber Identity (IMSI)-range. In order for the Cisco SGSN to handle the Packet Temporary Mobile Subscriber Identity (PTMSI)-based uplinks, it requires an op-policy without a PLMN or common PLMN definition (the common PLMN is the PLMN that was used for the network sharing configuration in the IUPS service).

a) One without PLMN

#imsi-range mcc xxx mnc xxx operator-policy <>
#operator-policy name <>
associate call-control-profile <>
#exit
#call-control-profile <>
authenticate rau
sgsn-address rac <xxx> lac <xxx> nri <x> prefer local address ipv4 <xxx.xxx.xxx.xxx>   
#exit

b) Define imsi-range with common-plmn as the one same which is in iups-service.

#imsi-range mcc <XXX> mnc <XXX> PLMNID <common-plmn> operator-policy <oppolicy>
#operator-policy name <oppolicy>
associate call-control-profile <ccprofile>
#exit
#call-control-profile ccprofile
authenticate rau
sgsn-address rac <XXX> lac <XXX> nri  <X> prefer local address ipv4< XXX.XXX.XXX.XXX>  
#exit

Any one of these IMSI-range definitions can be used in order to allow RAU in offloading cases to work.

Technical Justification and Explanation

In a network shared environment, if traffic must be offloaded, then the CC-profile that is selected for the offloaded subscriber must have entries for the local-lookup.

Either the CC-profile with an IMSI-range (Mobile Country Code (MCC)/Mobile Network Code (MNC) of the NB-RAI for the offloaded SGSNs) and the common PLMN as the PLMID will be selected, or the IMSI-range (MCC/MNC of the NB-RAI for the offloaded SGSNs) of these entries for the lookup.

Typically, there will not be an IMSI in the uplink, so you must get the MNC/MCC from the old RAI in the GPRS Mobility Management (GMM) message. The PLMN will be the common PLMN, which is the shared PLMN in the network and is temporary. After this op-policy is chosen, the SGSN chooses to run a Domain Name Server (DNS) query or pick a local address from the static mapping in the CC-profile.

Once the query is resolved, the SGSN sends the SGSN Context Request to the peer source-SGSN. The SGSN_CTX_RESP has an IMSI from the peer SGSN, and then the new op-policy is selected based on that IMSI information. For example, if the IMSI is 123456xxxxx and the current broadcasted PLMN is XXX-XXX, then this is the result: imsi-range mcc <XXX> mnc <XXX> plmnid <XXXXXX> operator-policy <>.

When network sharing is used in an offloading environment, the SGSN must pick a temporary policy in order to resolve the peer SGSN IP address. This can be achieved as mentioned previously; after the IMSI is fetched from the peer/source SGSN, then the SGSN again chooses an op-policy based on the IMSI MNC/MCC.

Signal Transfer Point Link Congestion Prevention

In the case of Signal Transfer Point (STP) congestion, attach a throttling action on the SGSN in order to reduce the transactions per second. Add this command in the source and target SGSN before the traffic is offloaded, which helps the throttle re-attach rate:

network-overload-protection sgsn-new-connections-per-second 2000 action
 reject-with-cause congestion queue-size 5000 wait-time 5

The data is provided per-link, and the link-set should be between the STP and the HLR. In this example, you can assume that:

• There are a maximum of 1,600 transactions per second in the link-set.
• There are four links in that link-set.
• During the time of the congestion, the SGSN sent 2,550 Transactions Per Second (TPS) towards the STP.
• In normal conditions, the SGSN sends about 400 transactions per second in the busy hour. (This is an aggregated number.)
• In the event of the congestion, the Call Event Per Second (CEPS) events reached 1,700.

Analysis

Network overload protection is an IMSIMGR feature that typically handles the procedures, such as the IMSI attach and foreign PTMSI uplink (which can be PTMSI attach or Inter SGSN RAU). Each procedure consumes three transactions per second on the GR link, when you consider the request response in one TPS. The Send Authentication Information (SAI) will take on TPS, and the Update GPRS Location (UGL) will take two TPS. Overall, one message that is handled at the IMSIMGR will have three TPS on the GR interface. When you consider the peak hour TPS on the link, which is 400 per second, it means that approximately 150 new connections per second are processed by the IMSIMGR.

For a maximum of 1,600 transactions per second in the link-set, the IMSIMGR handles approximately 533 (1600/3) new_conn_sec, so you must have a new_connections value within the range (150530). You should leave room between the maximum and minimum values. Cisco recommends that you configure 350 transactions for the new_connections value with this command.

You can configure a reject action with a cause code of congestion, so that the Attach requests are rejected with a GMM cause code 22=Congestion and the UE knows the exact network state.

Here is an example:

#network-overload-protection sgsn-new-connections-per-second new_connections<350>
 action { drop | reject with cause { congestion | network failure }

Offloading Algorithm for Target Count

The offloading SGSN uses the target-NRI and target-count from the target-based offloading CLI command. These values are updated to the IMSIMGR and eventually to the SESSMGR, as per the IMSIMGR and SESSMGR interaction. The IMSIMGR is the central entity that governs the progress of the offloading, as it is a single proclet. The SESSMGRs are distributed processing entities. Since there are many SESSMGRs and the subscribers are distributed in the SESSMGRs, the offloading occurs parallel on all SESSMGRs.

The IMSIMGR passes the target-NRI and target-count per target NRI to each SESSMGR. Each SESSMGR piggybacks the currently offloaded subscribers per target-NRI in all interactions with the IMSIMGR. A new message is also introduced, which is sent when a particular number or a timer-value expires or if there is no other message to piggyback the currently offloaded subscribers. The IMSIMGR keeps track of the total offloaded subscribers from all SESSMGRs and notifies all SESSMGRs upon attainment of the target-count for that target-NRI.

Global Configuration for Offloading Based on Target-Count

Use this configuration in order to offload traffic based on the target-count:

config
sgsn-global
target-offloading algorithm optimized-for-target-count
end

Offloading Phase 1

This section describes how to apply the initial offloading phase a few  hours before the maintenance window. This phase instructs the SGSN to offload any subscribers that send either an Attach request or an RAU request message.

Note: Repeat this command if the subscriber count increases again on the SGSN.

Here is an example that can be used in order to offload the source SGSN (NRI 5) to the target SGSN (NRI-3):

Context gn_ctx
sgsn offload sgsn-service sgsn_svc connecting t3312-timeout 4 target-nri
 3 target-count 600000

Enter this command in order to check the number of subscribers that are offloaded to the target SGSN:

show sgsn-pool statistics sgsn-service sgsn_svc target-offloaded-to-peer target-nri <>

Note: The t3312-timeout is a periodic RAU timeout, as per Technical Specification (TS) 23.236.

In the Packet Switch (PS) domain, a new RAU is triggered when the periodic RAU timer is set to a sufficiently low value (the recommended value is four seconds) in the Accept message. The UE will send a new RAU shortly after, and the Radio Access Network (RAN) node then routes to a new SGSN based on the target-NRI that is embedded in the P-TMSI.

Enter this command in order to confirm whether the previous command is in effect:

show sgsn-service name sgsn_svc
Sgsn NRI Value : 5, Offloading - connecting(On), activating(Off)
Sgsn Offload-T3312 Timeout : 4

Note: The Phase 2 procedure is not used for this offloading scenario because Phase 2 is used only for NULL NRI. The offloading that is described in this document is based on the target-NRI, so Phase 2 is not valid.

Offloading Phase 3

This section describes some additional commands that are used in order to offload the rest of the subscribers less than 100,000.

Enter the show subscribers summary command during the wait time. Ensure that the number of subscribers decreases and is not more than 100,000.

Show sub summary idle-time greater-than <time>

Dependent upon the number of subscribers in the idle state, for more than 3,600 seconds, the customers must decide whether to clear the subscribers from the idle time that is 3,600 seconds or more.

# context local

#clear subscribers idle-time greater-than 3600 -noconfirm
Wait for 10-15 minutes then continue.

#clear subscribers idle-time greater-than 1800 -noconfirm
Wait for 10-15 minutes then continue

# clear subscribers idle-time greater-than 900 -noconfirm
wait for 10-15 minutes then continue

If the subscriber count is still over 100,000, then one of these actions might be required:

• Clear the subscribers on a per-Access Point Name (APN) basis.
• Clear the subscribers on a per-APN/Packet Services Card (PSC) basis.
• Clear the subscribers on a per-session manager instance.

Stop Offloading and Remove STP Congestion Protection Command

In order to remove the network overload protection and return the system to the default settings, enter this command:

config
default network-overload-protection
end

In order to stop the offloading procedure, enter this command:

Context gn_ctx
sgsn offload sgsn-service sgsn_svc connecting stop

In order to confirm whether the offloading has stopped, enter this command:

show sgsn-service name sgsn_svc

Note: Ensure that the Offloading - connecting appears as Off and that the activating appears as Off in the output of this command.

Enter this command in order to revert the configuration back to the default offloading algorithm:

config
sgsn-global
default target-offloading algorithm
end

Important Notes

Consider these important notes about the information that is described in this document:

• All of the subscribers will be offloaded from the source SGSN based on the target-count so that all of the SESSMGRs are equally divided with offloaded subs.
• The periodic RAU timer is set to four seconds and the PTMSI is embedded with the target-NRI that is returned with the PTMSI in the source SGSN.
• The MS will perform the periodic RAU with the target-NRI that is embedded, and the Radio Network Controller (RNC) will route the calls to the target SGSN based on the NRI.
• The common PLMN configuration with the shared PLMN helps to resolve the SGSN address statically and send an SGSN_CTXT_REQ to the source SGSN.
• Once this process is complete, the subscriber is successfully offloaded.