для Cisco Cisco Packet Data Gateway (PDG)

 

Addition of some new RADIUS attributes has been done via some new CLIs. 

Previous Behavior:  Previously, as per the configuration guide, the attribute is mentioned as supported, but it was never 
sent as part of any RADIUS messages because the attribute was never supported in the first place. It was defined in 
starent.attr file only for encoding/decoding purposes. 

New Behavior:  Now, support has been provided for the NAS-Port-Id AVP in Access-request and Accounting-Start 
messages for both GGSN and PGW calls. Even then, the attribute is not sent by default, if any customer wants to send 
the attribute, the same should be explicitly enabled using "radius attribute" config. 

Customer Impact:  If the customer does not have GGSN session licence, there would not be any impact, as the CLI 
would not be visible and the AVP will not be sent in the messages. 

Existing customers with GGSN session license who use starent dictionary or a custom dictionary which encompasses 
starent dictionary will not face any impact. If they need the AVP to be present in their RADIUS messages, they can do 
so by using the "radius attribute" CLI. The CLI will be displayed in verbose mode. 

GGSN Support for PCSCF Discovery refers to maintaining Parity between PGW and GGSN implementations as far as 
P-CSCF discovery is concerned. But there is an inherent difference between the message exchanges for the two 
services. 



 

The Create Bearer Request is Network driven for PGW against Create PDP Req (secondary context) which is 

Access side driven for GGSN. Thus the Create PDP Req(secondary context) can request for P-CSCF Address 
information which the Create Bearer Req (PGW) cannot. 



 

Similarly the Update Bearer Request is Network driven for PGW against Update PDP Req which is Access side 

driven for GGSN. P-CSCF Address information can be requested via Update PDP Req. 

Previous Behavior:  Following Test cases arise as a result: 



 

Verify GGSN behavior when Secondary PDP request from access side carries P-CSCF address request but the 

primary CPCQ did not 



 

Verify GGSN behavior when the Update PDP context from the access side carries P-CSCF request whereas 

CPCQ did not 



 

Check GGSN behavior when secondary pdp context requests for P-CSCF address of ipv6 type and primary was 

established with v4 CSCF address 



 

Check GGSN behavior when secondary pdp context requests for P-CSCF address of ipv4 type and primary also 

was established with v4 CSCF address 

New Behavior:  The P-CSCF discovery would be initiated ONLY as part of Initial Attach (PGW) and Create PDP 
Context (Primary) for GGSN. Subsequently, as part of Create PDP Context (Secondary) and Update PDP procedure, the 
P-CSCF Address information, if requested, would be returned as part of the corresponding Response procedure(PCO 
IE), provided the P-CSCF Address Information is ALREADY Discovered. In other words, a new P-CSCF discovery 
would NOT be triggered upon receiving P-CSCF Address request as part of Secondary context creation or Update PDP 
request. The existing discovered information would be returned appropriately.