Cisco Cisco ASR 5000

 

VLR pools are configured in the Gs Service, which supports the Gs interface configuration for communication with 
VLRs and MSCs. 

A pool area is a geographical area within which an MS/UE can roam without the need to change the serving CN node. 
A pool area is served by one or more CN nodes in parallel. All the cells, controlled by an RNC or a BSC belong to the 
same one (or more) pool area(s). 

VLR hash is used when a pool of VLRs is serving a particular LAC (or list of LACs). The selection of VLR from this 
pool is based on the IMSI digits. From the IMSI, the SGSN derives a hash value (V) using the algorithm: [(IMSI div 10) 
modulo 1000]. Every hash value (V) from the range 0 to 999 corresponds to a single MSC/VLR node. Typically many 
values of (V) may point to the same MSC/VLR node. 

The crashlog is unique to each of the management cards, so if a crash occurs when card the “8” is active it will be 
logged on card “8”. A subsequent switchover would no longer display the crash in the log. To retrieve this crash, a 
switch back over to card “8” has to be done. The crash event log and dumps are unique to active and standby 
management cards, so if a crash occurs on an active card then the crash event log and related dumps will be stored on an 
active card only. This crash information is not available on the standby card. Whenever the cards switchover due to a 
crash in the active card, and crash information is no longer displayed on the card which takes over. Crash information 
can be retrieved only from the current active card. To retrieve the crash list of the other card a switchover is required 
again. To avoid this switchover and to obtain the crash information from the standby card, synchronization between two 
management cards and maintaining latest crash information is required. 

 The arriving crash event will be sent over to the standby SMC/MMIO and saved in the standby’s crashlog file in the 
similar manner. Minicore, NPU or kernel dumps on flash of active SMC/MMIO needs to be synchronized to standby 
SMC/MMIO using the ‘rsync’ command. When a crashlog entry or the whole list is deleted through the CLI command, 
it should be erased on both active and standby SMCs/MMIOs. There is no impact on memory. All the crash related 
synchronization activity will be done by the evlogd of standby SMC/MIO card, as the standby evlogd is less loaded and 
the standby card has enough room for synchronization activity. Therefore the performance of the system will not be 
affected. 

This feature is developed to suppress the CDRs with zero byte data count, so that the OCG node is not overloaded with 
a flood of CDRs. The CDRs can be categorized as follows: 



 

Final-cdrs: These CDRs are generated at the end of a context. 



 

Internal-trigger-cdrs: These CDRs are generated due to internal triggers such as volume limit, time limit, tariff 

change or user generated interims through the CLI commands. 



 

External-trigger-cdrs: These CDRs are generated due to external triggers such as QoS Change, RAT change and 

so on. All triggers which are not considered as final-cdrs or internal-trigger-cdrs are considered as external-
trigger-cdrs. 

The customers can select the CDRs they want to suppress. A new CLI command 

is developed to 

enable this feature. This feature is disabled by default to ensure backward compatibility. For more information see, 
Command Line Interface Reference and Statistics and Counters Reference.