Cisco Cisco IOS Software Release 12.3(2)XF Données agrégées

 

 

© 2005 Cisco Systems, Inc. All rights reserved. 

Important notices, privacy statements, and trademarks of Cisco Systems, Inc. can be found on cisco.com. 

Page 2 of 8 

 
 

The following features are supported in GGSN 5.2 in terms of backward compatibility: 

GTP session redundancy (GTP-SR) enhances GGSN availability and is supported using dual chassis. GTP-SR provides Packet Data Protocol (PDP) 

context stateful failover between two MWAM cards across two Cisco 7600 Series or two Cisco Catalyst 6500 Series chassis. 

One-to-one session redundancy in Cisco GGSN Release 5.2 is based on Active-Standby redundancy. In Active-Standby redundancy mode, one 

node is active and handles all user traffic. The second node is standing by, ready to take over in case of failover. Cisco GGSN does not handle 

any user traffic in standby mode. 

The following types of PDP contexts will not be redundant, and will require re-establishment of the PDP context on the standby node. 

•

 

Point-to-Point Protocol (PPP) PDP type. 

•

 

PPP regeneration/Layer 2 Tunneling Protocol (L2TP) access. 

•

 

IP Multimedia Subsystem (IMS) support (no support for the Go interface). 

•

 

Network-initiated PDP. 

•

 

GTP-SR for a single-chassis solution. This will be supported with supervisor engine failover when stateful switchover/nonstop forwarding 

(SSO/NSF) is supported. 

•

 

Command-line interface (CLI) redundancy for GTP-SR. Here, it is necessary to manually (or with a network management system [NMS]) make 

sure there is near-identical configuration on the active and standby nodes. 

•

 

In-Service Software Upgrade (ISSU). 

•

 

MIBs. Dynamic counters and statistics will not be synced; they will appear reset when a switchover happens. 

•

 

Protection of the call detail records (CDRs) in the memory of the active GGSN prior to switchover. User-data-related charging information for 

PDP is not planned to be synced; the unsent CDRs that are in the active GGSN’s memory before the switchover will be lost. Configuring nodes 
to close and send the closed CDRs to Charging Gateway Function (CGF) will minimize this loss. 

Cisco GGSN Release 5.2 is fully compliant with the Third-Generation Partnership Project (3GPP) releases 98, 99, and 4, and also with Release 5 

in terms of charging change requests. 

•

 

Local/tertiary charging gateway support—This supports a third charging gateway in addition to the two (primary and secondary) charging 

gateways that Cisco GGSN already supports. The third charging gateway can be deployed locally so that if the access to the primary and 
secondary charging gateways (which are remote) fails, the GGSN can act as backup and send the CDRs to the local (third) charging gateway 
until one or both of the remote charging gateways become operational. Then, the GGSN switches back to the primary or secondary gateway. 

•

 

Time-based triggers—Cisco GGSN Release 5.2 supports time-based triggers for generation of GGSN-CDRs [G-CDRs], in addition to the volume-

based triggers that are already supported by Cisco GGSN. These can be enabled per GGSN, access point name (APN), or PDP context. 

•

 

Enabling charging per APN—Cisco GGSN Release 5.2 allows enabling and disabling the generation of CDRs per APN. 

•

 

Configurable RADIUS attribute for backward compatibility—Cisco GGSN Release 5.2 allows configuration of the RADIUS attributes for the 

Mobile Station International ISDN Number (MSISDN) and the account session ID for a user to be able to support backward compatibility with 
Wireless Application Protocol (WAP).