Cisco Cisco Packet Data Gateway (PDG) Veröffentlichungshinweis

 

▄  Cisco ASR 5x00 Release Change Reference 

A LIPA (Local IP Access) PDN is a PDN Connection for local IP access for a UE connected to a HeNB. The LIPA 
architecture includes a Local Gateway (LGW) acting as an S-GW GTPv2 peer. The LGW is collocated with HeNB in 
the operator network behaves as a PGW from SGW perspective. Once the default bearer for the LIPA PDN is 
established, then data flows directly to the LGW and from there into the local network without traversing the core 
network of the network operator. 

In order to support millions of LIPA GTPC peers, S-GW memory management has been enhanced with regards to 
GTPv2 procedures and as well as to support the maintenance of statistics per peer node. 

Establishment of LIPA PDN follows a normal call flow similar to that of a normal PDN as per 23.401; the specification 
does not distinguish between a LGW and a PGW call. As a result, the S-GW supports a new configuration option to 
detect a LIPA peer. As a fallback mechanism, heuristic detection of LIPA peer based on data flow characteristics of a 
LIPA call is also supported. 

Whenever a peer is detected as a LIPA peer, the S-GW will disable GTPC echo mechanism towards that particular peer 
and stop maintaining some statistics for that peer. 

A configuration option in APN profile explicitly indicates that all the PDN’s for that APN are LIPA PDN’s, so all 
GTPC peers on S5 for that APN are treated as LGW, and thus no any detection algorithm is applied to detect LGW. 

This feature helps exchange capabilities of two communicating GTP nodes, and uses the new feature based on whether 
it is supported by the other node. 

This feature allows S-GW to exchange its capabilities (MABR, P-GW Restart Notification, NTSR) with the peer entities 
through ECHO messages. By this, if both the peer nodes support some common features, then they can make use of new 
messages to communicate with each other. 

With new “node features” IE support in ECHO request/response message, each node can send its supported features 
(MABR, P-GW Restart Notification, NTSR). This way, S-GW can learn the peer node’s supported features. S-GW’s 
supported features can be configured by having some configuration at the service level. 

If S-GW wants to use new message, such as P-GW Restart Notification, then S-GW should check if the peer node 
supports this new feature or not. If the peer does not support it, then S-GW should fall back to old behavior. 

If S-GW receives a new message from the peer node, and if S-GW does not support this new message, then S-GW 
should ignore it. If S-GW supports the particular feature, then it should handle the new message as per the specification. 

Overcharging Protection helps in avoiding charging the subscribers for dropped downlink packets while the UE is in 
idle mode. In some countries, it is a regulatory requirement to avoid such overcharging, so it becomes a mandatory 
feature for operators in such countries. Overall, this feature helps ensure subscriber are not overcharged while the 
subscriber is in idle mode. 

  Use of Overcharging Protection in S-GW requires that a valid license key be installed. Contact your 

Cisco account representative for information on how to obtain a license. 

P-GW will never be aware of UE state (idle or connected mode). Charging for downlink data is applicable at P-GW, 
even when UE is in idle mode. Downlink data for UE may be dropped at S-GW when UE is in idle mode due to buffer 
overflow or delay in paging. Thus, P-GW will charge the subscriber for the dropped packets, which isn’t desired. To 
address this problem, with Overcharging Protection feature enabled, S-GW will inform P-GW to stop or resume 
charging based on packets dropped at S-GW and transition of UE from idle to active state.