Cisco Cisco Packet Data Interworking Function (PDIF)
GGSN Changes in Release 17
GGSN Changes in Release 17.0 ▀
Release Change Reference, StarOS Release 17 ▄
195
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.
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.
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.
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.
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.
CSCuo95634 - P-CSCF Info (PCO IE) for Secondary Context/ Update PDP Rsp
Feature Changes
P-CSCF Info for Secondary Context/ Update PDP Rsp
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.
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.
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.
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.