Cisco Cisco ASR 5000

 

The LINKMGR, GBMGR and the MMEMGR select an IMSIMGR instance that needs to be contacted for session 
setup. Each subscriber session in the Session Manager maintains the IMSIMGR instance number that “hosts” the 
mapping for this IMSI. This information is required while communicating during audit and session recovery scenarios. 

When a single IMSI manager instance is present, there is only one centralized entry point for new calls into the system. 
Network overload protection is configured using the command “network-overload-protection”, new call acceptance 
rates are configured and controlled using this command. Once the configured rate is reached the new calls are dropped. 
When there are multiple IMSI manager instances, the configured new call acceptance rate is distributed equally across 
all IMSI Manager instances to throttle new calls. 

The IMSI manager manages target (NRI and count) based offloading. Though number of IMSI Manager instances is 
increased, only the first IMSI Manager instance is allowed to perform the target based offloading. It keeps track of the 
total offloaded subscribers for every Target-NRI from all Session Managers and notifies all the Session Managers on 
attaining Target-count for that Target-NRI. 

Several race handling scenarios like ISRAU-Attach collision scenario, Inter-MME TAU attach (FGUTI) on attach 
(IMSI) collision scenario and so on can occur, specific measures have been taken to ensure these race handling 
scenarios are handled correctly in a multiple IMSI Manager instance scenario.  

The control plane messaging throughput on the ASR5500 platform is increased, therefore Performance degradation or 
congestion is not observed during multiple IMSI Manager instance recovery after a crash or an unplanned card 
migration. Also mechanisms are devised to ensure there is no impact on Session Manager recovery and Session 
Manager Thresholding.  

The Monitor subscriber next-call option is used to trace the next incoming call into the system. With multiple IMSI 
Manager instances, the Session Controller now sends the next-call details to IMSI manager instance 1. So the next 
incoming call through IMSI manager instance “1” is monitored. 

The IMSI managers are updated with information on critical parameters that lead to congestion control. The IMSI 
managers have to inform the congestion status to all Link Managers and Gb Managers. In order to avoid multiple IMSI 
managers sending information to all Link Managers and Gb Managers, only the first IMSI Manager instance informs the 
congestion status to all Link Managers and Gb Managers. Also only the first IMSI Manager instance sends the traps 
indicating congestion status; this reduces the number of traps to be sent.  

From this release onwards, the Diameter Proxy Server queries the IMSI Manager instances to obtain 
IMSI/IMEI/MSISDN to Session manager instance mapping information.  

Many SGSN and MME features are based on the assumption that there is only one IMSI Manager and there is only one 
centralized entry point to the system, this assumption now no longer holds good with multiple IMSI manager instances. 
Workarounds have been arrived at to ensure there are no changes observed during such scenarios. Examples of such 
scenarios are listed below: 



 

MME per service session limit: The per MME service session limits are enforced by each IMSI manager 

instance. The per service session limit is configured by the command 

bind s1-mme max-subscribers 

.