Cisco Cisco Packet Data Interworking Function (PDIF)

 

In compliance with RFC 5996 2.21.2 ePDG sends AUTHENTICATION_FAILED/24 as Notify Error message type in 
IKE_AUTH_RESP message on SWu interface for all the SWm interface error codes. 

The ePDG needs mapping of SWm to SWu error codes for communicating different error codes to device, enabling 
device to identify whether its temporary failure or permanent and can accordingly try connecting to the ePDG. 

The ePDG continues to release the call while notifying the UE about the SWm error, however the UE based on error 
code shall take decision when to try connecting again. 

For the mapping ePDG uses Notify Error Message type between 31 to 8191 from the range reserved for IANA or from 
the private range 8192 to 16383. 

ePDG supports QCI based bearer duration information display at more granular leval to enable customers to Monitor 
VoWiFi dedicated bearers. 

For more information on show subscriber statistics and for show session duration commands refer CLI Reference 
Guide.  

To establish ePDG call once the PGW sends the create session response message to ePDG the call setup is complete at 
PGW and Downlink traffic may come. However on ePDG processing of create session response and setting up of IPsec 
tunnel may take small duration, so it is required that before bearer establishment and IPsec tunnel establishment is 
completed ePDG should have capability to buffer the data. In case of handover especially when the LTE bearer is torn 
down after sending create session response the downlink traffic shall be sent over the WLAN so this becomes even 
more important to buffer data on ePDG avoiding any traffic loss. 

3GPP standards section 8.6.2 "Handover from 3GPP access to untrusted Non-3GPP IP Access with GTP on S2b" 
indicates that traffic can come from PGW to ePDG before even the session setup is done at ePDG (during the 
processing of create session response at ePDG).  

The ESP IP header of the downlink packet in SWu interface sent out of ePDG has the TOS value copied from the inner 
IP payload of the ESP packet. But as per the customer requirement the TOS value should be taken from the 
configuration or GTPU IP header received on S2B side. 

 

The ePDG marks the DSCP value in the ESP IP header while sending out in the SWu interface(both IPv4 and IPv6) 
based on the following order of priority: 

1.  DSCP Configuration per QCI 



 

Use command 

qci num downlink encaps-header dscp-marking dscp-marking-value

 to 

configure marking of specific DSCP in downlink direction per QCI. 

2.  From GTPU header received from PGW.  

Download DSCP marking feature is backward compatible, where the Inner-GTP IP packet(S2B) DSCP value should be 
copied to the outer ESP IP packet(SWu). Use command 

qci num downlink encaps-header copy-inner dscp-

 to enable copying of DSCP value from inner-gtp-ip packet header(S2B) to the outer-esp header(SWu)