Cisco Cisco Packet Data Gateway (PDG) Notas De La Versión

 

Once the criterion to signal “stop charging” is met, S-GW will send Modify Bearer Request (MBReq) to P-GW. MBReq 
would be sent for the PDN to specify which packets will be dropped at S-GW. MBReq will have a new private 
extension IE to send “stop charging” and “start charging” indication to P-GW. 

When the MBReq with stop charging is received from a S-GW for a PDN, P-GW will stop charging for downlink 
packets but will continue sending the packets to S-GW. 

P-GW will resume sending downlink packets after receiving “stop charging” request when either of these conditions is 
met: 



 

When the S-GW (which had earlier sent “stop charging” in MBReq) sends “start charging” in MBReq. 



 

When the S-GW changes (which indicates that maybe UE has relocated to new S-GW). 

Provides flexibility to the operators to have different configuration for GTP-C and Lawful Intercept, based on the type 
of peer or the IP address of the peer 

Peer profile feature allows flexible profile based configuration to accommodate growing requirements of customizable 
parameters with default values and actions for peer nodes of S-GW. With this feature, configuration of GTP-C 
parameters and disabling/enabling of Lawful Intercept per MCC/MNC or IP address based on rules defined. 

A new framework of peer-profile and peer-map is introduced. Peer-profile configuration captures the GTP-C specific 
configuration and/or Lawful Intercept enable/disable configuration. GTP-C configuration covers GTP-C retransmission 
(maximum number of retries and retransmission timeout) and GTP echo configuration. Peer-map configuration matches 
the peer-profile to be applied to a particular criteria. Peer-map supports criteria like MCC/MNC (PLMN-ID) of the peer 
or IP-address of the peer. Peer-map can then be associated with S-GW service. 

Intent of this feature is to provide flexibility to operators to configure a profile which can be applied to a specific set of 
peers. For example, have a different retransmission timeout for foreign peers as compared to home peers. 

This procedure optimizes the amount of signaling involved on S11/S4 interface when P-GW failure is detected. 

P-GW Restart Notification Procedure is a standards-based procedure supported on S-GW to notify detection of P-GW 
failure to MME/S4-SGSN. P-GW failure detection will be done at S-GW when it detects that the P-GW has restarted 
(based on restart counter received from the restarted P-GW) or when it detects that P-GW has failed but not restarted 
(based on path failure detection). When an S-GW detects that a peer P-GW has restarted, it shall locally delete all PDN 
connection table data and bearer contexts associated with the failed P-GW and notify the MME via P-GW Restart 
Notification. S-GW will indicate in the echo request/response on S11/S4 interface that the P-GW Restart Notification 
procedure is supported. 

P-GW Restart Notification Procedure is an optional procedure and is invoked only if both the peers, MME/S4-SGSN 
and S-GW, support it. This procedure optimizes the amount of signaling involved on S11/S4 interface when P-GW 
failure is detected. In the absence of this procedure, S-GW will initiate the Delete procedure to clean up all the PDNs 
anchored at that failed P-GW, which can lead to flooding of GTP messages on S11/S4 if there are multiple PDNs using 
that S-GW and P-GW. 

This section identifies S-GW features modified in release 15.0. 

The following changes have been introduced for compliance with 3GPP TS 29.274 Release 10.