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).
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:
This section describes how to enable traffic offloading to the target SGSN.
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>
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.
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.
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:
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 }
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.
Use this configuration in order to offload traffic based on the target-count:
config
sgsn-global
target-offloading algorithm optimized-for-target-count
end
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.
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 <>
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
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:
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
Enter this command in order to revert the configuration back to the default offloading algorithm:
config
sgsn-global
default target-offloading algorithm
end
Consider these important notes about the information that is described in this document: