The ePDG service runs on a Cisco ASR 5500 (DPC1/DPC2) chassis running the StarOS operating system, VPC-DI, and Virtualized Packet Core (VPC) platforms with optional crypto accelerator card (coleto creek). The chassis can be configured with a variety of components to meet specific network deployment requirements. For additional information, see the installation guide for the chassis and/or contact your Cisco account representative.

Important

The ePDG Hardware Crypto Assist (Coleto Creek) feature on VPC-DI is fully qualified in release 21.6 and later releases.

The ePDG is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco account representative for detailed information on specific licensing requirements. For information on installing and verifying licenses, see "Managing License Keys" in the System Administration Guide.

This section provides a description of the network elements that work with the ePDG in the E-UTRAN/EPC network. For untrusted non-3GPP IP access, note that the network architecture assumes the access network elements do not perform any function other than delivering packets.

The following table provides descriptions of the logical network interfaces supported by the ePDG in the E-UTRAN/EPC network.

The following table lists the IPv4/IPv6 transport combinations for the ePDG which support for the deployment of transport combination.

Note that the PMIPv6 S2b IPv6 transport is qualified.

A value-added feature to enable VPN service provisioning for enterprise or MVNO customers. Enables each corporate customer to maintain its own AAA servers with its own unique configurable parameters and custom dictionaries. This feature provides support for up to 800 AAA server groups and 800 NAS IP addresses that can be provisioned within a single context or across the entire chassis. A total of 128 servers can be assigned to an individual server group. Up to 1,600 accounting, authentication, and/or mediation servers are supported per chassis.

To ensure optimal performance and reliability, health monitoring for the Coleto Creek Chip is now available. This feature allows for system recovery by rebooting the card in cases of continuous chip operation failures. Health monitoring can be managed via CLI commands, with the feature being disabled by default.

Configuring Health monitoring for Crypto Chip

The health-monitoring crypto-chip CLI command has been introduced to configure the failure threshold for health monitoring.

configure  
            health-monitoring crypto-chip  failure-threshold failure_threshold    
            no health-monitoring crypto-chip 
            end 

Note	The no option disables the Health Monitoring feature for the Crypto Chip.

Intel® AES New Instructions (Intel® AES NI) is an advanced set of encryption instructions designed to enhance the Advanced Encryption Standard (AES) algorithm. It accelerates data encryption for the Intel® Xeon® and Intel® Core™ processor families.

Important

The AES-NI Transform Encryption feature is exclusively supported on the VNF.

AES-NI Capability Support

ePDG is enhanced to support the IKEv2 and IPSec encryption using AES-NI capabilities. In ePDG the IPsec encryption and decryption are managed by IFTASK, a DPDK-based software component. While AES-NI capability is enabled by default, you have the option to disable it during initialization using the [ no ] require aes-ni capability CLI command.

Important

After you configure this command, you must save the configuration and then reload the chassis for the command to take effect. For information on saving the configuration file and reloading the chassis, refer to the System Administration Guide for your deployment.

AES-NI Transform Set Support

The ePDG is now optionally capable of exclusively allowing AES-NI accelerated IKEv2 and IPsec algorithms within its configuration. This feature allows operators or users to specify the correct AES-NI accelerated algorithm set. Use this [ no ] require aes-ni transform-set CLI command to implement this feature. By default, both AES-NI and non-AES-NI algorithms are permitted, maintaining backward compatibility. However, when this configuration is applied, ePDG will enforce the use of only AES-NI accelerated algorithms for IKEv2 and IPsec, and will display an error message if non-compliant algorithms are configured.

Important

After you configure this command, you must save the configuration and then reload the chassis for the command to take effect. For information on saving the configuration file and reloading the chassis, refer to the System Administration Guide for your deployment.

The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data since it can be formatted to be parsed by external, back-end processors.

The system can be configured to collect bulk statistics and send them to a collection server called a receiver. Bulk statistics are collected in a group. The individual statistics are grouped by schema. The following is a partial list of supported schema:

• ePDG: Provides statistics to support the ePDG.

• ePDG-APN: Provides statistics to support the ePDG APN level statistics

• System: Provides system-level statistics.

• Card: Provides card-level statistics.

• Port: Provides port-level statistics.

The system supports the configuration of up to four sets of receivers. Each set can have primary and secondary receivers. Each set can be configured to collect specific sets of statistics from the various schema. Bulk statistics can be periodically transferred, based on the transfer interval, using ftp/tftp/sftp mechanisms.

Bulk statistics are stored on the receivers in files. The format of the bulk statistic data files can be configured by the user. Users can specify the format of the file name, file headers, and/or footers to include information such as the date, system host name, system uptime, the IP address of the system generating the statistics (available for headers and footers only), and/or the time that the file was generated.

When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through XML parsing, archiving, and graphing.

The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and can send it to a northbound NMS or an alternate bulk statistics server for further processing.

Additionally, if archiving of the collected statistics is desired, the Bulk Statistics Server writes the files to an alternative directory on the server. A specific directory can be configured by the administrative user or the default directory can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web Element Manager server.

For more information on bulk statistics, see the System Administration Guide.

Rekeying of an IKEv2 Child SA (Security Association) occurs for an already established Child SA whose lifetime is about to exceed a maximum limit. The ePDG initiates rekeying to replace the existing Child SA. The ePDG-initiated rekeying is disabled by default. This is the recommended setting, although rekeying can be enabled using the Crypto Configuration Payload Mode commands.

The congestion control feature allows you to set policies and thresholds and specify how the system reacts when faced with a heavy load condition.

The congestion control feature monitors the system for conditions that could potentially degrade performance when the system is under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an impact on the system's ability to service subscriber sessions. Congestion control helps identify such conditions and invokes policies for addressing the situation.

Congestion control operation is based on configuring the following:

• Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled and establishes limits for defining the state of the system (congested or clear). These thresholds function in a way similar to operation thresholds that are configured for the system as described in the Thresholding Configuration Guide. The primary difference is that when congestion thresholds are reached, a service congestion policy and an SNMP trap, starCongestion, are generated. A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for the condition to be cleared. An SNMP trap, starCongestionClear, is then triggered.

• Port Utilization Thresholds: If you set a port utilization threshold, when the average utilization of all ports in the system reaches the specified threshold, congestion control is enabled.

• Port-specific Thresholds: If you set port-specific thresholds, when any individual port-specific threshold is reached, congestion control is enabled system-wide.

• Service Congestion Policies: Congestion policies are configurable for each service. These policies dictate how services respond when the system detects that a congestion condition threshold has been crossed. The ePDG supports congestion policies to either drop or reject new calls when congestion is detected in the system.

The congestion control overload disconnect feature can also be enabled for disconnecting passive calls during an overload situation. The ePDG selects passive calls based on the overload disconnect configuration options.

The following table lists the congestion-control threshold command options supported on the ePDG.

For more information on the congestion control command options discussed in the table above, and configuration instructions, see the System Administration Guide. For more information on the congestion-control threshold command, see the eHRPD/LTE Command Line Interface Reference section of CLI Reference Guide.

ePDG does supports mapping of SWm to SWu error codes so that device can identify whether its temporary failure or permanent and can accordingly try connecting to the ePDG.

The communication service providers (CSP) would like the ability to take different actions depending on the severity of the error received from the AAA (SWm interface). If there is a temporary congestion in the network, a retry is appropriate.

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.

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 ePDG supports DPD (Dead Peer Detection) protocol messages originating from the ePDG and the WLAN UEs. DPD is performed when no IKE/IPSec packets reach the ePDG within the configured DPD interval. DPD is configured in the crypto template in the ePDG service. The administrator can also disable DPD. However, the ePDG always responds to DPD availability checks initiated by the UE, regardless of the ePDG idle timer configuration.

The ePDG supports a default APN when APN information is not available from the WLAN UEs over the SWu interface.

When the APN information is received from the WLAN UEs, the information is sent towards the AAA server via DER (Diameter EAP Request) messages. When the APN information is absent, the AAA server provides the default APN to the ePDG in a DEA (Diameter EAP Answer) message.

The maximum attribute size in Diameter-EAP-Answer (DEA) message is 3400 bytes.

The support for certain deprecated algorithms has been removed from the IPSec/IKEv2 transform set.

The following algorithms are no longer supported:

• AES-GCM-128 with a 64-bit ICV

• AES-GCM-128 with a 96-bit ICV

These changes to algorithm support apply only to trusted builds (DH group5). The following security supplement certificate signing schemes are deprecated for trusted builds:

• MD2WithRSAEncryption

• MD4WithRSAEncryption

• MD5WithRSAEncryption

• RIPEMD128WithRSAEncryption

• RIPEMD160WithRSAEncryption

• RIPEMD256WithRSAEncryption

Command Changes

crypto template min-key-size

Use the following configuration to set minimum key size.

configure  
   context context_name  
      crypto template crypto_template_name ikev2-dynamic 
      authentication min-key-size min_key_size 
      [ default | no ] authentication min-key-size  
      end 

NOTES:

• authentication min-key-size min_key_size : Sets minimum certificate key size. min_key_size must be an integer between 255 and 8192.

• default : Sets default key size. Default is 255.

• no : Disables minimum key size validation feature.

crypto map min-key-size

Use the following configuration to set minimum key size.

configure  
   context context_name  
      crypto map crypto_map_name [ikev2-ipv4 | ikev2-ipv6 ] 
      authentication min-key-size min_key_size 
      [ default | no ] authentication min-key-size 
      end 

NOTES:

• authentication min-key-size min_key_size : Sets minimum certificate key size. min_key_size must be an integer between 255 and 8192.

• default : Sets default key size. Default is 255.

• no : Disables minimum key size validation feature.

The supported size of the certificates configured on DER/PEM and the private key in DER/PEM has been increased. Now certificates of larger sizes can be configured.

The new supported size of certificate configured in DER is 6144 bytes and PEM is 8192 bytes. The new supported size of private key in DER is 3072 bytes and PEM is 4096 bytes.

Diffie-Hellman (DH) operation can be optimized by reusing Private Key and KE Payload for multiple sessions for one second. This optimization is based on RFC 7296 (2.12. Reuse of Diffie-Hellman Exponentials) for reuse of DH keys.

The DH group key exponential is reused within one second for multiple sessions. This enhancement is controlled using the ikev2-ikesa dh-group CLI command.

For more information on ikev2-ikesa dh-group command, refer to the Command Line Interface Reference.

During IPSec tunnel establishment, the WLAN UEs can request an IP address for the DNS in the CP payload (CFG_REQUEST). The ePDG retrieves the request from the CFG_REQUEST attribute of the first IKE_AUTH message exchange and includes it in the PBU (Proxy-MIP Binding Update) message sent to the P-GW.

The ePDG sends the PBU message by framing the MIPv6 APCO VSE (Additional Protocol Configuration Options Vendor Specific Extension) with an IPv6 and/or IPv4 DNS request to the P-GW. Once the response is received from the P-GW with the list of IPv6 and/or IPv4 DNS addresses in the returned MIPv6 APCO VSE, the ePDG includes the final address(es) in the CP payload (CFG_REPLY) of the final IKE_AUTH Response message sent to the UE.

In case the Protocol used on S2b is GTPv2 then APCO is used in Create Session Request message for requesting the IPv4 or IPv6 DNS server address request and then P-GW communicates the DNS server addresses in the APCO IE in the Create Session Response Message, the ePDG includes the final address(es) in the CP payload (CFG_REPLY) of the final IKE_AUTH Response message sent to the UE.

Note that the ePDG includes a maximum of two IPv4 DNS addresses and/or a maximum of two IPv6 DNS addresses in the CP payload (CFG_REPLY).

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.

Functional Description

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 P-GW.

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-marking-value to enable copying of DSCP value from inner-gtp-ip packet header (S2b) to the outer-esp header (SWu).

DSCP marking is supported in different platforms like Cisco ASR 5500 and VPC-SI/VPC-DI.

The ePDG can assign DSCP levels to specific traffic patterns in order to ensure that the data packets can be delivered according to the precedence with which they are tagged. The DiffServ markings can be applied to the IP header of the every subscriber data packet transmitted over the SWu and the S2b[GTPv2] interface.

The specific traffic patterns are classified as per their associated QCI/ARP value on the GTP-tunnel. Data packets falling under the category of each of the traffic patterns are tagged with a DSCP marking.

For uplink traffic, i.e. traffic from ePDG to P-GW through GTP tunnel, DSCP markings can be configured using global qci-qos mapping configuration association in ePDG service. In this case, only outer IP header is used for routing the packet over GTP-u' interface. Hence TOS field of only outer IP header is changed, i.e. subscriber packet is not marked with DSCP value at ePDG.

ePDG service does have configuration for association of the global configured qci-qos mapping and further in global qci-qos mapping configuration its expected that encaps-header configuration for dscp marking shall be used for setting the TOS value in the outer IP header.

Following is the global configuration under qci-qos mapping:

qci num [ uplink { encaps-header { copy-inner | dscp-marking hex } | 802.1p-value num }]

The 802.1p marking shall be done on the uplink traffic per the qci-qos mapping global configuration corresponding to the map configured under ePDG service. This is similar configuration as described above for DSCP marking.

The 802.1p marking shall be done in the "user priority" bits of the "TAG" field in the 802.1q tagged frame.

The ePDG supports PDN type IPv4v6. The ePDG handles traffic originating from both IPv4 and IPv6 UE addresses based on configured traffic selectors. Here Dual stack is mentioned for subscriber traffic (inner IP packets).

The ePDG determines the PDN type based on the requested IP address versions sent from the UE in the CP payload (CFG_REQUEST) within the IKE_AUTH Request message. The ePDG sets the IPv6 Home Network Prefix option and IPv4 Home Address Request option parameters when sending the PBU (Proxy-MIP Binding Update) message to the P-GW, specifying the PDN type as IPv4v6. In case the protocol used on S2b is GTPv2 then the ePDG sets the PDN Type inside PAA (PDN Address Allocation) as IPv4v6 and sends the same in Create Session Request Message to the P-GW. The ePDG sends the addresses allocated by the P-GW in the PBA (Proxy-MIP Binding Acknowledgement) / Create Session Response message to the UE via the CP payload (CFG_REPLY) in the IKE_AUTH Response message.

Enables secure user and device level authentication with a 3GPP AAA server or via 3GPP2 AAA proxy and the authenticator in the ePDG.

The ePDG uses the Diameter-based SWm interface to authenticate subscriber traffic with the 3GPP AAA server. Following completion of the security procedures (IKEv2) between the UE and ePDG, the ePDG selects EAP-AKA as the method for authenticating the subscriber session. EAP-AKA uses symmetric cryptography and pre-shared keys to derive the security keys between the UE and EAP server. The ePDG represents the EAP authenticator and triggers the identity challenge-response signaling between the UE and back-end 3GPP AAA server. On successful verification of user credentials, the 3GPP AAA server obtains the Cipher Key and Integrity Key from the HSS. It uses these keys to derive the MSK (Master Session Key) that are returned on EAP-Success to the ePDG. The ePDG uses the MSK to derive the authentication parameters.

After the user credentials are verified by the 3GPP AAA and HSS, the ePDG returns the PDN address obtained from the P-GW (using PMIPv6/GTPv2) to the UE. In the connection establishment procedures, the PDN address is triggered based on subscription information conveyed over the SWm reference interface. Based on the subscription information and requested PDN-Type signaled by the UE, the ePDG informs the P-GW of the type of required address (IPv6 and/or IPv4 Home Address Option for dual IPv4/v6 PDNs).

The 3GPP standard provides a mechanism for the UICC (SIM based) devices connectivity to the EPC via non-3GPP access enabling them for voice and video services over WiFi. However lot of non-UICC devices such as iPads, Tablets, Laptops do not have defined 3GPP standard mechanism for connecting over WLAN to EPC via ePDG. These devices can use the same LTE subscription as for the UICC device do not have potential to utlize CSPs and monetize voice and video offering by extending the same to non-UICC devices.

EAP-AKA is the mechanism defined in 3GPP standards for authenticating and authorizing the mobile devices using AAA server. The non UICC devices cannot support EAP-AKA.

For non UICC devices as IMSI is not present the IMSI mentioned in below flows is vIMSI which can be alphanumeric type (limit to 24 chars) or decimal digit IMSI and in such case when alphanumeric vIMSI is used its expected that AAA server shall be providing decimal digit IMSI to ePDG for S2b interface as part of mobile-node-identifier AVP.

Below is the list of different authentication mechanisms which can be used with ePDG acting as EAP pass-through mode for the non-UICC device support:

• EAP-MSCHAPv2

  • Single phase

  • Use MSCHAPv2 inside EAP

  • Challenge/Response based mechanism

  • Reference - http://tools.ietf.org/id/draft-kamath-pppext-eap-mschapv2-01.txt and RFC 3079

• EAP-TTLS (using MS-CHAPv2)

  • EAP method encapsulating TLS session

  • Two phases

    • Handshake phase (server authentication and key generation)

    • Data Phase (client authentication)

  • Handshake phase provides secure channel for data phase

  • Use MSCHAPv2 for authenticating client/device

  • Reference - RFC 5281

• EAP-TLS

  • Single phase

  • EAP method encapsulating TLS session

  • Use certificates between UE and AAA server for mutual authentication

  • Reference - RFC 5216

EAP-MSCHAPv2 Authentication Mechanism Call Flow

In this authentication mechanism the ePDG shall be acting in EAP pass-through mode and the AAA server shall be authenticating the device using EAP-MSCHAPv2. The authentication mechanism does have advantage of less lengthy call flow and is standard way. Additionally the operator does not require having certificate based infrastructure. The disadvantage is that MSK is 64 bytes but with 32 byte key and remaining 32 bytes as zeros as opposed to EAP-AKA where we have 64 byte non zero MSK. So effectively weaker authentication mechanism key.The Following diagram shows the call flow for the EAP-MSCHAPv2 based authentication:

1. UE ePDG: IKEv2 SA_INIT UE (UICC based) sends IKE_SA_INIT Request (SA, KE, Ni, NAT-DETECTION Notify).

2. ePDG UE: IKEv2 SA_INIT RSP The ePDG responds with an IKE_SA_INIT Response (SA, KE, Nr payloads, NAT-Detection Notify).

3. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH_REQ (IDi, [CERTREQ], IDr, SA, CP (CFQ_REQUEST (INTERNAL_IP6_ADDRESS, [INTERNAL_IP6_DNS], [INTERNAL_IP6_PCSCF]), TSi, TSr)). The UE does not include AUTH payload to indicate that it will use the EAP-MSCHAPv2 method for authenticating itself to AAA. IDi contains the NAI in the form "A<IMSI> nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org". Per standards the prefix can be 0/1 indicating EAP-AKA/EAP-SIM now as we shall be indicating to AAA server that use different authentication method here EAP-MSCHAPv2 so can indicate using "A". ePDG shall be transparent to received prefix and shall send to AAA server so that operator is free to use any prefix except the defined ones.

4. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host,Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload, User-Name (NAI), RAT-Type (WLAN), MIP6-Feature-Vector, Visited-Network-Identifier) message to the 3GPP AAA Server. The EAP-Payload contains the UE identity encoded by ePDG.

5. AAA server ePDG: DEA The 3GPP AAA Server initiates the authentication challenge and responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload). The EAP-Payload contains the Challenge packet which is used to begin the EAP MS-CHAP-V2 protocol.

6. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (IDr, [CERT (X509 CERTIFICATE SIGNATURE)], EAP Payload) The IDr is the identity of the ePDG and if the UE requests for certificates then CERT is included. The EAP message received from the 3GPP AAA Server (EAP-Request/Challenge) is included in order to start the EAP procedure over IKEv2.

7. UE ePDG: IKEv2 AUTH_REQ The UE sends EAP message in IKE_AUTH Request (EAP) with user-name, MS-CHAP2- Response AVPs.The EAP message shall be of EAP-Type=EAP-MS-CHAP-V2(Response).

8. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type (AUTHORIZE_AUTHENTICATE), EAP-Payload) message to the 3GPP AAA Server. The EAP-Payload contains the message as sent by UE.

9. AAA server ePDG: DEA The 3GPP AAA Server on successful authentication responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload)

10. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload) The EAP payload contains the EAP-MSCHAPv2 message as received from the AAA server.

11. UE ePDG: IKEv2 AUTH_REQ The UE sends IKE_AUTH Request (EAP) with EAP-MSCHAPv2 "Success Response packet". UE successfully validates the EAP MS-CHAP-V2 Success Request packet sent by the AAA server, respond.

12. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload) message to the 3GPP AAA Server. The EAP-Payload contains the message as sent by UE.

13. AAA server ePDG: DEA The 3GPP AAA Server sends an EAP success (Session-Id, Auth-Application-Id: 16777264, Result-Code, Origin-Host, Origin-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload User-Name(0<IMSI>mnc<mnc val>.mcc<mcc val>.pub.3gppnetwork.org), EAP-Master-Session-Key, APN-Configuration (Context-Identifier, PDN-Type: IPv4v6, Service-Selection (apn name), MIP6-Agent-Info), Auth-Session-State: STATE_MAINTAINED, Origin-State-Id). At this point mutual authentication is done and device is authorized by AAA server. The MSK can be generated by AAA server using following logic however ePDG is transparent to MSK generation logic and till the devices and AAA server are in sync any other logic of MSK generation should also work. MSK = MasterReceiveKey + MasterSendKey + 32 bytes zeroes (padding) Note - Extensible Authentication Protocol Method for Microsoft CHAP derives two 16-byte keys, MasterSendKey and MasterReceiveKey (as specified in [RFC3079], section 3.3).

14. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload) The EAP payload contains the EAP-MSCHAPv2 message as received from the AAA server.

15. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH request (AUTH) The UE takes its own copy of the MSK as input to generate the AUTH parameter to authenticate the first IKE_SA_INIT message.

16. ePDG PGW: S2b Create Session Req ePDG sends Create Session Request (IMSI, [MSISDN],Serving Network, RAT Type (WLAN), Indication Flags, Sender F-TEID for C-plane, APN, Selection Mode, PAA, APN-AMBR, [APCO], Bearer Contexts(), [Recovery], [Private IE (P-CSCF)]). Selection Mode is set to "MS or network provided APN subscribed verified". The P-GW performs the necessary interactions with 3GPP-AAA, PCRF and OCS/OFCS. ePDG shall set the HO in Indication flags IE and also the preserved IP address as received from UE in PAA IE.

17. PGW ePDG: Create Session Resp The PGW allocates the requested IP address session and responds back to the ePDG with a Create Session Response (Cause, PGW S2b F-TEID, PAA, [APN-AMBR],APCO, Bearer Contexts Created (EPS Bearer ID, Cause, [TFT], S2b-U PGW F-TEID, Bearer Level QoS), [Recovery], [Private IE (P-CSCF)]) message.

18. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (AUTH, CP, SA, CFG_REPLY ([INTERNAL_IP4_ADDRESS], [INTERNAL_IP4_NETMASK], [INTERNAL_IP4_DNS], INTERNAL_IP6_ADDRESS, INTERNAL_IP6_SUBNET, INTERNAL_IP6_DNS, [P-CSCF]) TSi, TSr) At this stage the ePDG has completed the ipsec SA and tunnel setup and also GTP-U tunnel setup thus completing the data path. The IP address provided by PGW is communicated to UE.

19. ePDG UE: IPv6 RA The assumption is that the IP stack needs the RA to initialize the address.

EAP-TLS authentication mechanism Call Flow

In this mechanism it's assumed that the authenticator entity shall be AAA server supporting the certificate based authentication. The ePDG shall be acting in EAP pass-through mode thus communicating the EAP-TLS negotiation between device and AAA server. The AAA server once completing the authentication mechanism shall be sharing the MSK to ePDG for generating the AUTH parameters and completing the IKEv2 authentication. Following diagram shows the call flow for the EAP-TLS based authentication:

1. UE ePDG: IKEv2 SA_INIT UE (UICC based) sends IKE_SA_INIT Request (SA, KE, Ni, NAT-DETECTION Notify).

2. ePDG UE: IKEv2 SA_INIT RSP The ePDG responds with an IKE_SA_INIT Response (SA, KE, Nr payloads, NAT-Detection Notify).

3. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH_REQ (IDi, [CERTREQ], IDr, SA, CP (CFQ_REQUEST (INTERNAL_IP6_ADDRESS, [INTERNAL_IP6_DNS], [INTERNAL_IP6_PCSCF]), TSi, TSr)). The UE does not include AUTH payload to indicate that it will use the EAP-TLS method for authenticating itself to AAA. IDi contains the NAI in the form "A<IMSI> nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org". Per standards the prefix can be 0/1 indicating EAP-AKA/EAP-SIM now as we shall be indicating to AAA server that use different authentication method here EAP-TLS so can indicate using "A". ePDG shall be transparent to received prefix and shall send to AAA server so that operator is free to use any prefix except the defined ones.

4. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload, User-Name (NAI), RAT-Type(WLAN), MIP6-Feature-Vector, Visited-Network-Identifier) message to the3GPP AAA Server. The EAP-Payload contains the UE identity encoded by ePDG.

5. AAA server ePDG: DEA The 3GPP AAA Server initiates the authentication challenge and responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload). The EAP-Payload contains the EAP-TLS/Start, the Start 'S' bit is set with no data.

6. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (IDr, [CERT (X509 CERTIFICATE SIGNATURE)], EAP Payload) The IDr is the identity of the ePDG and if the UE requests for certificates then CERT is included. The EAP message received from the 3GPP AAA Server (EAP-Request/Start) is included in order to start the EAP procedure over IKEv2.

7. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH_REQ (EAP payload) containing the TLS client hello handshake message.

8. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload, User-Name (NAI), RAT-Type(WLAN), MIP6-Feature-Vector, Visited-Network-Identifier) message to the 3GPP AAA Server. The EAP-Payload contains the TLS client hello handshake message.

9. AAA server ePDG: DEA The 3GPP AAA Server initiates the authentication challenge and responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload). The AAA server will then respond with an EAP-Request packet with EAP-Type=EAP-TLS. The data field of this packet will encapsulate one or more TLS records. These will contain a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, certificate_request, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message.

10. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload) The EAP payload contains the TLS message as received from the AAA server.

11. UE ePDG: IKEv2 AUTH_REQ The UE sends EAP message in IKE_AUTH Request (EAP). The data field of this packet MUST encapsulate one or more TLS records containing a TLS client_key_exchange, change_cipher_spec, and finished messages.

12. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host,Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload) message to the 3GPP AAA Server. The EAP-Payload contains the message as sent by UE.

13. AAA server ePDG: DEA The 3GPP AAA Server on successful authentication responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload) where EAP-Payload does contain the TLS finished message.

14. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload) The EAP payload contains the TLS message as received from the AAA server.

15. UE ePDG: IKEv2 AUTH_REQ The UE sends EAP message in IKE_AUTH Request (EAP) with no data.

16. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type (AUTHORIZE_AUTHENTICATE), EAP-Payload) message to the 3GPP AAA Server. The EAP-Payload contains the message as sent by UE.

17. AAA server ePDG: DEA The 3GPP AAA Server sends an EAP success (Session-Id, Auth-Application-Id: 16777264, Result-Code, Origin-Host, Origin-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload User-Name(0<IMSI>mnc<mnc val>.mcc<mcc val>.pub.3gppnetwork.org), EAP-Master-Session-Key, APN-Configuration (Context-Identifier, PDN-Type: IPv4v6, Service-Selection (apn name), MIP6-Agent-Info), Auth-Session-State:STATE_MAINTAINED, Origin-State-Id). At this point device is authenticated and authorized by AAA server.

18. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload) The EAP payload contains the TLS message as received from the AAA server.

19. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH request (AUTH) The UE takes its own copy of the MSK as input to generate the AUTH parameter to authenticate the first IKE_SA_INITmessage.

20. ePDG PGW: S2b Create Session Req ePDG sends Create Session Request (IMSI, [MSISDN],Serving Network, RAT Type (WLAN), Indication Flags, Sender F-TEID for C-plane, APN, Selection Mode, PAA, APN-AMBR, [APCO], Bearer Contexts(), [Recovery], [Private IE (P-CSCF)]). Selection Mode is set to "MS or network provided APN subscribed verified". The PGW performs the necessary interactions with 3GPP-AAA, PCRF and OCS/OFCS. ePDG shall set the HO in Indication flags IE and also the preserved IP address as received from UE in PAA IE.

21. PGW ePDG: Create Session Resp The PGW allocates the requested IP address session and responds back to the ePDG with a Create Session Response (Cause, PGW S2b F-TEID, PAA, [APN-AMBR],APCO, Bearer Contexts Created (EPS Bearer ID, Cause, [TFT], S2b-U PGW F-TEID, Bearer Level QoS), [Recovery], [Private IE (P-CSCF)]) message.

22. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (AUTH, CP, SA, CFG_REPLY([INTERNAL_IP4_ADDRESS], [INTERNAL_IP4_NETMASK],[INTERNAL_IP4_DNS], INTERNAL_IP6_ADDRESS, INTERNAL_IP6_SUBNET, INTERNAL_IP6_DNS, [P-CSCF]) TSi, TSr) At this stage the ePDG has completed the ipsec SA and tunnel setup and also GTP-U tunnel setup thus completing the data path. The IP address provided by PGW is communicated to UE.

23. ePDG UE: IPv6 RA The assumption is that the IP stack needs the RA to initialize the address.

EAP-TTLS authentication mechanism Call Flow

The EAP-TTLS based approach is useful when there is no certificate based infrastructure present for the operator to configure certificate for each device. Unlike EAP-TLS it enables the device authentication without certificates using customized AVPs. Here we have defined MSCHAPv2 based authentication mechanism. Here the AAA server needs to provide the key similar to MSK to ePDG for validating/generating the AUTH payload during IKEv2 xchg. Following diagram shows the call flow for the EAP-TTLS based authentication:

1. UE ePDG: IKEv2 SA_INIT UE (UICC based) sends IKE_SA_INIT Request (SA, KE, Ni, NAT-DETECTION Notify).

2. ePDG UE: IKEv2 SA_INIT RSP The ePDG responds with an IKE_SA_INIT Response (SA, KE, Nr payloads, NAT-Detection Notify).

3. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH_REQ (IDi, [CERTREQ], IDr, SA, CP (CFQ_REQUEST (INTERNAL_IP6_ADDRESS, [INTERNAL_IP6_DNS], [INTERNAL_IP6_PCSCF]), TSi, TSr)). The UE does not include AUTH payload to indicate that it will use the EAP-TTLS method for authenticating itself to AAA. IDi contains the NAI in the form "A<IMSI> nai.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org". Per standards the prefix can be 0/1 indicating EAP-AKA/EAP-SIM now as we shall be indicating to AAA server that use different authentication method here EAP-TTLS so can indicate using "A". ePDG shall be transparent to received prefix and shall send to AAA server so that operator is free to use any prefix except the defined ones.

4. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload, User-Name (NAI), RAT-Type(WLAN), MIP6-Feature-Vector, Visited-Network-Identifier) message to the 3GPP AAA Server. The EAP-Payload contains the UE identity encoded by ePDG.

5. AAA server ePDG: DEA The 3GPP AAA Server initiates the authentication challenge and responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload). The EAP-Payload contains the EAP-TTLS/Start, the Start 'S' bit is set with no data.

6. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (IDr, [CERT (X509 CERTIFICATE SIGNATURE)], EAP Payload) The IDr is the identity of the ePDG and if the UE requests for certificates then CERT is included. The EAP message received from the 3GPP AAA Server (EAP-Request/Start) is included in order to start the EAP procedure over IKEv2.

7. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH_REQ (EAP payload) containing the TLS client hello handshake message.

8. ePDG AAA server: DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload, User-Name (NAI), RAT-Type(WLAN), MIP6-Feature-Vector, Visited-Network-Identifier) message to the 3GPP AAA Server. The EAP-Payload shall contain the TLS client hello handshake message.

9. AAA server ePDG: DEA The 3GPP AAA Server initiates the authentication challenge and responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload). The AAA server will then respond with an EAP-Request packet with EAP-Type=EAP-TTLS. The data field of this packet will encapsulate one or more TLS records. These will contain a TLS server_hello handshake message, possibly followed by TLS certificate, server_key_exchange, server_hello_done and/or finished handshake messages, and/or a TLS change_cipher_spec message.

10. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload) The EAP payload contains the TLS message as received from the AAA server.

11. UE ePDG: IKEv2 AUTH_REQ The UE sends EAP message in IKE_AUTH Request (EAP). The data field of this packet MUST encapsulate one or more TLS records containing a TLS client_key_exchange, change_cipher_spec, and finished messages.

12. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host,Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload) message to the3GPP AAA Server. The EAP-Payload contains the message as sent by UE.

13. AAA server ePDG: DEA The 3GPP AAA Server on successful authentication responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload) where EAP-Payload does contain the TLS finished message.

14. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload). The EAP payload contains the TLS message as received from the AAA server. This stage the first phase of TTLS is done completing the TLS handshake and AAA server is authenticated by device and keys are generated to secure subsequent message handling.

15. UE ePDG: IKEv2 AUTH_REQ The UE sends EAP message in IKE_AUTH Request (EAP) with user-name, MS-CHAP2- Response, MS-CHAP Challenge AVPs.

16. ePDG AAA server: DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host, Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload) message to the3GPP AAA Server. The EAP-Payload contains the message as sent by UE.

17. AAA server ePDG: DEA The 3GPP AAA Server on successful authentication responds with DEA (Session-Id, Base AVPs, Auth-Request-Type and EAP-Payload), Upon receipt of these AVPs from the UE, the AAA server MUST verify that the value of the MS-CHAP-Challenge AVP and the value of the Ident in the client's MS-CHAP2-Response AVP are equal to the values generated as challenge material. If either item does not match exactly, the AAA server MUST reject the UE. In success case, AAA encodes the MS-CHAP2-Success attribute.

18. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload). The EAP payload contains the EAP-TTLS message as received from the AAA server.

19. UE ePDG: IKEv2 AUTH_REQ The UE sends IKE_AUTH Request (EAP) with no data. Upon receipt of the MS-CHAP2-Success AVP, the UE is able to authenticate the AAA. If the authentication succeeds, the UE sends an EAP-TTLS packet to the TTLS server containing no data (that is, with a zero-length Data field). Upon receipt of the empty EAP-TTLS packet from the client, the TTLS server considers the MS-CHAP-V2 authentication to have succeeded.

20. ePDG AAA server :DER The ePDG sends the DER (Session-Id, Auth-Application-Id, Origin-Host,Origin-Realm, Destination-Host, Destination-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload) message to the 3GPP AAA Server. The EAP-Payload contains the message as sent by UE.

21. AAA server ePDG: DEA The 3GPP AAA Server sends an EAP success (Session-Id, Auth-Application-Id: 16777264, Result-Code, Origin-Host, Origin-Realm, Auth-Request-Type(AUTHORIZE_AUTHENTICATE), EAP-Payload User-Name(0<IMSI>mnc<mnc val>.mcc<mcc val>.pub.3gppnetwork.org), EAP-Master-Session-Key, APN-Configuration (Context-Identifier, PDN-Type: IPv4v6, Service-Selection (apn name), MIP6-Agent-Info), Auth-Session-State:STATE_MAINTAINED, Origin-State-Id). At this point mutual authentication is done and device is authorized by AAA server.

22. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (EAP Payload) The EAP payload contains the TLS message as received from the AAA server.

23. UE ePDG: IKEv2 AUTH_REQ UE sends IKE_AUTH request (AUTH) The UE takes its own copy of the MSK asinput to generate the AUTH parameter to authenticate the first IKE_SA_INITmessage.

24. ePDG PGW: S2b Create Session Req ePDG sends Create Session Request (IMSI, [MSISDN],Serving Network, RAT Type (WLAN), Indication Flags, Sender F-TEID for C-plane, APN, Selection Mode, PAA, APN-AMBR, [APCO], Bearer Contexts(), [Recovery], [Private IE (P-CSCF)]). Selection Mode is set to "MS or network provided APN subscribed verified". The PGW performs the necessary interactions with 3GPP-AAA, PCRF and OCS/OFCS. ePDG shall set the HO in Indication flags IE and also the preserved IP address as received from UE in PAA IE.

25. PGW ePDG: Create Session Resp The PGW allocates the requested IP address session and responds back to the ePDG with a Create Session Response (Cause, PGW S2b F-TEID, PAA, [APN-AMBR],APCO, Bearer Contexts Created (EPS Bearer ID, Cause, [TFT], S2b-U PGW F-TEID, Bearer Level QoS), [Recovery], [Private IE (P-CSCF)]) message.

26. ePDG UE: IKEv2 AUTH_RESP ePDG sends IKE_AUTH_RESP (AUTH, CP, SA, CFG_REPLY([INTERNAL_IP4_ADDRESS], [INTERNAL_IP4_NETMASK],[INTERNAL_IP4_DNS], INTERNAL_IP6_ADDRESS,INTERNAL_IP6_SUBNET, INTERNAL_IP6_DNS, [P-CSCF]) TSi, TSr) At this stage the ePDG has completed the ipsec SA and tunnel setup and also GTP-U tunnel setup thus completing the data path. The IP address provided by P-GW is communicated to UE.

27. ePDG UE: IPv6 RA The assumption is that the IP stack needs the RA to initialize the address.

ePDG supports emergency APN session to support VoWiFi calls. For areas where the LTE coverage is less or absent then the user will utilize the Wi-Fi to perform the emergency session via ePDG.

A new ePDG-APN bulkstats schema is added to capture the APN level ePDG service statistics.

Emergency APN Support Use Cases

ePDG and PGW services does work together in combo mode (both enabled on the same chassis) with common component resources like IPsec being utilized in best effort manner. Session recovery including card migration is supported for the combo mode

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.

The UEs accessing through ePDG can perform multiple reattach due to movement across/within WLAN Network and can also access multiple PDN at the same time. In these cases, the UE authentication is performed frequently with AAA-server involving HSS node interaction for EAP-AKA algorithm.

The operator providing the untrusted WLAN access solution through ePDG can enable fast-reauthentication in AAA-server and UE in order to perform faster authentication and reduce the load in HSS. This is because the fast-reauthentication uses the keys derived in the previous full-authentication. Also fast-reauthentication helps the operator to enable local-policy in UE node to authenticate itself to AAA server periodically for enhanced security.

Reattach with fast-reauth-id Call flow

Below call flow describes Reattach with fast-reauth-id.

1. Call-1 established for APN-1 and AAA-Server has provided fast-reauth-id during this authentication process. ePDG will store mapping between IMSI and fast-reauth-id.
2. UE starts Call-2 for fast-reauthentication by sending the IKE-SA-INIT message to ePDG. IKE-SA established between UE and ePDG with IKA_SA_INIT message exchange.
3. The UE sends the fast-reauth-id in NAI format(fast-reauth-idrealm) in the IDi payload and the APN-1 (in the IDr payload) in this first message of the IKE_AUTH phase, and begins negotiation of child security associations. The UE omits the AUTH parameter in order to indicate to the ePDG that it wants to use EAP over IKEv2. The UE includes the configuration payload (CFG_REQUEST) within the IKE_AUTH request message to give indication that it needs to reconfigure the IP address.
4. ePDG Identifies the previous session based on the received fast-reauth-id as it already created mapping. ePDG will handle this request as new session. This is because the presence of CP-Payload indicates that the call should be established till PGW without retaining the IP address(S2B interface). The ePDG sends the Diameter-EAP-Request message to the 3GPP AAA Server, containing the fast-reauth-id and APN.

   Important

   Please note that ePDG uses the new diameter-session-id here as it is creating a new session.

5. The 3GPP AAA Server shall validate the fast-reauthentication-id and initiates the fast re-authentication request.

   Important

   Please note that there is no communication with HSS/HLR at this stage since fast-reauthentication-id is used. This makes the procedure faster and reduce load in HSS.

6. The ePDG responds with its identity, a certificate, and sends the AUTH parameter to protect the previous message it sent to the UE (in the IKE_SA_INIT exchange). The EAP message received from the 3GPP AAA Server (EAP-Request/Fast-Reauthentication) is included in order to start the EAP procedure over IKEv2.
7. The UE checks the authentication parameters and responds to the fast-reauthentication. The only payload (apart from the header) in the IKEv2 message is the EAP message.
8. The ePDG forwards the EAP-Response/Fast-Reauthentication message to the 3GPP AAA Server.
9. The AAA checks, if the Fast-Reauthentication response is correct. When all checks are successful, the 3GPP AAA Server sends the final Diameter-EAP-Answer(with a result code indicating success) including the users IMSI, relevant service authorization information, an EAP success and the key material to the ePDG. This key material shall consist of the MSK generated during the fast-reauthentication process. AAA-Server shall include the SN-Fast-Reauth-Username AVP with the fast-reauthentication-id value given to UE in step 5. ePDG creates mapping between IMSI and Fast-reauthentication-ID at this point.
10. The EAP Success message is forwarded to the UE over IKEv2.
11. The UE shall take its own copy of the MSK as input to generate the AUTH parameter to authenticate the first IKE_SA_INIT message. The AUTH parameter is sent to the ePDG in IKE_AUTH message.
12. The ePDG checks the correctness of the AUTH received from the UE. At this point the UE is authenticated. In S2b interface, ePDG initiates GTPv2 signaling between ePDG and PDN GW for creating the default-bearer for APN by sending Create-Session-Request to PGW with UE/APN details and request for IP-address allocation.
13. PGW responds with the Create-Session-Response message containing the allocation IP address, QoS details for this default-bearer connection.
14. The ePDG calculates the AUTH parameter which authenticates the second IKE_SA_INIT message. The ePDG sends the assigned Remote IP address in the configuration payload (CFG_REPLY) in the IKE_AUTH_RESPONSE message to UE. Fast-reauthentication is completed and Call-2 is connected now.
15. ePDG initiates the IKE-SA INFO_DELETE message for Call-1 to UE to delete the IKE-SA as part of call deletion.
16. UE responds with IKE-SA INFO_DELETE to delete the IKE-SA.
17. Call-1 is disconnected at ePDG.

ePDG Offline charging Architecture

Offline charging is a process where charging information is collected concurrently with that resource usage. The charging information is then passed through a chain of logical charging functions. At the end of this process, CDR files are generated by the network, which are then transferred to the network operator's Billing Domain(BD). Charging information like amount of data transmitted in uplink and downlink direction are collected as part of ePDG-CDR are used to inter-operator settlements.

The ePDG Offline charging involves the following functionalists for WLAN 3GPP IP Access:

• Charging Trigger Function
• Charging Data Function
• Ga Reference Point

The Charging Trigger Function (CTF) which is an integrated component generates charging events and forwards them to the Charging Data Function (CDF). The CDF, in turn generates ePDG-CDRs which are then transferred to the CGF. Finally, the CGF create ePDG-CDR files and forwards them to the Billing Domain. The CTF and CDF are integrated in ePDG, however, the CGF may exist as a physically separate entity or integrated to ePDG. If the CGF is external to the ePDG, then the CDF forwards the CDRs to the CGF across the Ga interface (using GTPP protocol defined in TS 32.295). ePDG-CDR format is as defined in TS 32.298 v12.6.0.

ePDG Offline Charging

ePDG supports CDRs to bill the UEs for network resource usage as defined in 3GPP specification TS32.298.

Supported Triggers for ePDG-CDRs Charging Information Addition

The "List of Traffic Volumes" attribute of the ePDG-CDR consists of a set of containers, on encountering the following trigger conditions, the charging information will be added to the container:

Qos Change: A change in the QoS will result to open the "List of Traffic Data Volumes" container being closed and added to the CDR and a new bearer specific container is opened. Also when there is a Change in QoS, the trigger will be sent to accounting module for CDR information addition using the API "sessmgr_acct_api_event(handle, params)" with the params ---> qos_change set from the sessmgr.

Tariff time: On reaching the Tariff Time Change open "List of Traffic Data Volumes" containers is closed and added to the CDR. Tariff-time change is to add charging information to CDR during a particular tariff-time of day.

Record Closure: Open "List of Traffic Data Volumes" containers is closed and added to the ePDG-CDR.

Supported Triggers for ePDG-CDR closure

The following events trigger closure and sending of ePDG-CDR:

Time Limit: CDRs are generated after every x seconds where x is the configured time limit.

Max container Triggers: Maximum number of charging condition changes (QoS/tariff time change). CDRs are generated when the max bucket limit is reached. By default its 4.

Volume limit trigger: CDRs are generated whenever the uplink or downlink data volume for the session crosses the configured uplink, downlink or total limit.

Management Intervention: CDRs can be generated by management intervention such as clear command issued by the operator to cleanup a session.

Assumptions and Limitations

eDNS

The ePDG supports extended DNS client to handle DNS response larger than 512 bytes.

RFC 1035 limits the size of DNS responses over UDP to 512 bytes. If P-GW discovery is done via DNS, there is a chance of 512 byte limit is hit as there are multiple P-GWs supporting an APN consequently having multiple responses to the DNS query, resulting in truncation of the RRs.

Extended the DNS (RFC 2671) allows the client to advertise a bigger re-assemble buffer size to the DNS server so that the server can send a response bigger than 512 bytes. An interim solution to the truncation issue is to arrange the RRs hierarchically so that the limit is never hit.

DNS over TCP

By default DNS client communicates with the server over UDP port. The client can support eDNS, DNS responses up to 4 K Bytes in size from the server. If FQDN resolves too many RRs, the 4 KB limit could be exhausted.

Use the following approach to resolve this issue:

Use TCP port when the server needs to send bigger responses (up to 64 KB), this needs to be driven by the client. When the server indicates that it is not able to send all the answers to a query by setting the truncation bit in the response header. The client on seeing this would switch to TCP port and re-sends the same query. The client continues to use UDP port for new requests.

P-GW re-selection on session timeout

During dynamic P-GW node selection by ePDG, if the selected P-GW is unreachable, the ePDG will select the next P-GW entry from the P-GW candidate list returned during the S-NAPTR procedure to set up the PDN connection.

PGW re-selection on call attempt failure due to PGW reject

The ePDG service enables the WLAN UEs in the untrusted non-3GPP IP access network to connect to the E-UTRAN/EPC network via a secure IPSec interface.

The following section explains the basic ePDG call flows.

The UE and the ePDG exchange the first pair of messages, known as IKE_SA_INIT and RSP, in which the ePDG and UE negotiate cryptographic algorithms, exchange nonces and perform a Diffie_Hellman exchange.

The ePDG does supports VoLTE call marking when the dedicated bearer corresponding to the QCI configured as VoLTE is created.The VoLTE call does have special handling of allowing data during the ICSR pending standby state and during the ICSR audit phase (at new active) which helps in reducing the data outage for the VoLTE calls during planned ICSR switchover.

When sessions are created on the ePDG, there is period of 60 seconds (configurable, explained below) lag before the sessions are check-pointed to the standby chassis. If chassis failure occurs during this period, the sessions that were not check-pointed are lost. Also, in some ICSR switchovers, a large number sessions that were not check-pointed need to be flushed resulting in additional delay in the switchover. This causes significant issues for VoLTE service.

This is critical for IMS sessions. If an IMS session is not synchronized with the standby chassis and an ICSR switchover event occurs, the newly active chassis does not have any information of this session and the ePDG is out of sync with other network elements. This situation cannot be corrected until the UE registers again (max 2 hours) and VoLTE calls cannot be delivered to the UE. Therefore, it is critical to minimize the interval in which the session is not synchronized with the peer.

In maintenance mode it's required that ePDG should automatically delete the VoLTE calls when the VoLTE bearer gets teared down or subscriber becomes non-volte after deletion of all VoLTE bearers.

The "clear subs all non-volte" command allows you to clear non volte calls and "clear subs all non-volte auto-del" command is used to delete non-volte calls and mark the VoLTE calls for auto deletion when the VoLTE bearer is torn down. This helps in avoiding manual intervention from admin to cleanup calls again when VoLTE bearer is torn down and the call becomes non-VoLTE. Once the call is marked for auto-deletion it cannot be reverted.

Non VoLTE sessions data outage reduction

ePDG does allows the data for non-VoLTE calls during ICSR switchover to reduce the data-outage for non-VoLTE calls and is configuration controlled to either allow data traffic for both VoLTE and non-VoLTE calls or only VoLTE calls.

The ePDG supports IKEv2 (Internet Key Exchange version 2) and IPSec (IP Security) ESP (Encapsulating Security Payload) encryption as per RFCs 4303 and 5996. IKEv2 and IPSec encryption enables network domain security for all IP packet-switched networks in order to provide confidentiality, integrity, authentication, and anti-replay protection. These capabilities are ensured through use of cryptographic techniques.

The data path from the ePDG supports mixed inner IPv4 and IPv6 addresses in the same Child SA for ESP (Encapsulating Security Payload) encapsulation and decapsulation when the Any option is configured in the payload, regardless of the IP version of the outer protocol.

The IKEv2 Fragmentation feature enables IPSec to fragment large messages at IKEv2 and replace them with a series of smaller messages as defined in RFC 7383. This ensures that fragmentation does not occur at IP level and fragmented packets are not dropped.

For more information on this feature, refer the IKEv2 Fragmentation chapter in the IPSec Reference guide.

The IKEv2 Mobility and Multi-homing protocol (MOBIKE) is supported on ePDG/IPSec as defined in RFC 4555. MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPSec Security Associations (SA) to change. This enables peer hosts to change its point of network attachment and use different interfaces without removing the existing IPSec tunnel.

Note	MOBIKE feature is supported only on ASR5500 and Ultra Services platforms.

For more information on this feature, refer the IKEv2 Mobility and Multi-homing Protocol chapter in the IPSec Reference guide.

StarOS IKEv2 stack complies to RFC 4306 and is enhanced to comply with newer version of IKEV2 RFC 5996. As part of new version support below features are introduced:

If invalid IMEI was received from the UE in CFG payload of the first IKE_AUTH request, multiple SessMgr restart was observed. Graceful handling support is added to avoid SessMgr restart.

• The sess-disconnect-invalid-imei bulk statistic is added in the ePDG schema to indicate the total number of sessions disconnected due to Invalid IMEI received from the UE.

• The Invalid IMEI field is added to the output of the show epdg-service statistics command to indicate the total number of sessions disconnected due to Invalid IMEI received from the UE.

The ePDG supports inter-access handovers between two different interfaces, such as a handover between a 3GPP network and an untrusted non-3GPP IP access network, or between two untrusted non-3GPP IP access networks.

When a UE sends an IKE_AUTH Request message with a NULL IPv4/IPv6 address in the CP payload, the ePDG determines that the request is for an initial attach. When a message contains non-null IP address values, the ePDG determines that the request is for a handover attach. On the SWu interface, the UE populates the INTERNAL_IP4_ADDRESS and/or INTERNAL_IP6_ADDRESS parameter with the previously-assigned IP addresses to indicate that UE supports IP address preservation for handovers.

In case the protocol used on S2b is PMIPv6, per 3GPP TS 29.275, the ePDG indicates an inter-access handover in the S2b Handoff Indicator option of PBU (Proxy-MIP Binding Update) messages. Per RFC 5213, the ePDG indicates the RAT (Radio Access Technology) of untrusted non-3GPP access network in the Access Technology Type option.

In case the protocol used on S2b is GTPv2 then per 3GPP TS 29.274, the ePDG indicates an inter-access handover in the indication flags IE.

The ePDG supports Interchassis Session Recovery (ICSR) with fault detection and automatic switchover. The subscriber session details for all ePDG interfaces are replicated in standby. In case of a switchover, the new chassis processes all subsequent control and data traffic for the subscriber session.

Important

Interchassis Session Recovery is supported only on Cisco ASR 5500.

The SWu, SWm and S2b interface are not impacted by the switchovers.

ePDG release 18.0 supports upgrade/downgrade from release 18 (N) to 16 (N-2).

Important

For more information on ICSR, see the System Administration Guide.

The ePDG supports IKEv2 Cookie challenge payload, this feature helps protect against opening too many half opened IPSec sessions.

The IKEv2 Cookie feature when enabled will invoke a cookie challenge payload mechanism which ensures that only legitimate subscribers are initiating the IKEv2 tunnel request and not a spoofed attack. Note that this configuration is per ipsecmgr.

The Cookie Challenge mechanism is disabled by default, the number of half open connections over which cookie challenge gets activated is also configurable.

The IPSec Large feature boosts IPSec crypto performance by enabling the resource manager (RM) task to assign additional IPSec managers to packet processing cards that have sufficient processing capacity. The system can be configured to achieve a higher per SF scale by configuring the [no] require ipsec-large command. This configuration is effective during init time only, and system resources are adjusted accordingly for more number of ePDG sessions or IPSec tunnel establishments.

Important

When IPSec large and demux on MIO are configured together, enable the IPSec large feature (using the require ipsec-large command) before enabling the demux on MIO (using the require demux management-card command).

Important

After you configure this command, you must save the configuration and then reload the chassis for the command to take effect. For information on saving the configuration file and reloading the chassis, refer to the System Administration Guide for your deployment.

IPv6 addressing enables increased address efficiency and relieves pressures caused by the rapidly approaching IPv4 address exhaustion problem.

The ePDG offers the following IPv6 capabilities:

IPv6 transport is supported on the SWm Diameter AAA interface with the external 3GPP AAA server. Note that the ePDG supports IPv6 transport for the UE-ePDG tunnel endpoints on the SWu interface.

The ePDG provides router advertisement support for IPv6 and dual stack PDNs to allow the WLAN UEs to initialize the IPv6 protocol stack. The ePDG sends an unsolicited router advertisement to the UE for an IPv6 PDN connection after sending the final IKE_AUTH Response message. When the ePDG receives a Router Solicitation Request message from the UE, the ePDG intercepts the message and responds to it. This is needed for some UEs that perform address auto-configuration despite receiving the IP address information through the CP payload of the IKE_AUTH Response message.

When a UE attaches to a WiFi Access Point, the WiFi Access Point always assigns the UE an IPv4 Address. With the IPv6 Support on IPSec SWU Interface feature the UE provides an IPv4 or IPv6 address by the WiFi Access Point for initiating the IPsec connection to the ePDG over IPv4/IPv6 transport accordingly. For IPv6 transport the IPv6 UDP checksum is mandatory and is supported for IKEv2 establishment.

The ePDG now supports incoming IKEv2 requests from UE over an IPv6 transport as well. One epdg-service can now bound to one IPv4 and IPv6 address which acts as IPsec tunnel endpoint addresses. ePDG continues to support the inner IPv4, IPv6 and IPv4v6 traffic in both IPv4 and IPv6 outer IP SWu transport.

IPv6 NAT support is not standardized and there is no requirement to support the IPv6 NAT. If at all NAT related parameters are present in the crypto template during configuration , it should not have any impact on the tunnel setup and the data flow.

Lawful Intercept (LI) is needed to perform electronic surveillance on an individual (a target/subject) as authorized by a judicial or administrative order. There are two types of intercept information that can be reported, Intercept Related Information (IRI) and Content of Communication (CC). The LI can be provisioned on ePDG based on user's IP-Addr, MSISDN, IMSI, NAI or IMEI (IMEI from rel 21.1).

For more information on ePDG's support for LI, refer the LI Configuration Guide.

For PGW selection, ePDG uses PGW address provided by AAA or uses DNS resolution. With local PGW resolution support, PGW address can be configured locally. If the above two methods (static and dynamic) PGW selection fails, or if PGW address were available but not reachable, then only locally configured addresses are referred and used. Also, if there is no PGW address received from AAA or, if no DNS setup is present, then also locally configured PGW addresses are referred. This way the existing functionality of PGW selection is retained, and added an additional backup-mode with local PGW address configuration resolution.

A new CLI is introduced in ePDG Service Config mode where epdg-service is associated with "subscriber-map", which is also an indication that "Local PGW Resolution Support" is enabled for epdg-service. The local PGW resolution will take into effect only if the CLI is configured and none of the existing method of PGW resolution method results in session creation.

Below are the Local PGW Resolution Support scenarios:

• PGW address received from AAA, but unreachable

• PGW addresses received by DNS resolution, but all are unreachable

• DNS server is not reachable, or rejects the DNS query

• None of the PGW selection mechanisms(Static/Dynamic) are present, i.e. neither DNS resolution is configured, nor AAA sends any PGW address

In all of the above scenarios, if local PGW address is configured and ePDG-Service is associated with Subscriber-Map, then PGW address is selected based on weight. In this algorithm the sessions are created approximately in the same ratio of the weights configured with the PGW addresses. For example if the weights are 10, 20 and 30, then 1000 sessions will be distributed in ration 1:2:3 respectively. (same algorithm used as DNS resolution based PGW selection mechanism.)

Only first PGW is selected based on weight based selection algorithm and if the call does not gets established with this selected PGW, rest of the addresses are selected on Round Robin method starting from next available PGW configured rounding upto PGW address configured just before the PGW address selected based on weight. This way none of the addresses are repeated. For example if ten PGW address are configured, based on weight 7th one is selected as first address, and if it is unreachable then address at 8th index is selected, then 9th, 10th, 1st, 2nd and so on until address present at 6th index.

In a case where PGW resolution is enabled and the existing DNS/AAA server PGW resolution mechanism failed and there is no disconnect reason already set from previous mechanism, further the local PGW resolution failed due to configuration error then new disconnect reason shall be set "ePDG-local-pgw-resolution-failed" for identifying the case.

Also in the case of HO, even if the local PGW resolution is enabled and there is no or unreachable PGW address provided by AAA server, or PGW FQDN provided results in no or unreachable PGW address, then ePDG will not use local PGW resolution mechanism for establishing the call.

Local configuration as preferred PGW selection mechanism

The ePDG is further enhanced to support local configuration based PGW selection as the preferred method for PGW node selection.

The ePDG service should be configured indicating preferred method of PGW selection, whether local configuration or DNS/AAA server based PGW selection. Local Configuration based PGW selection as fallback mechanism is default configuration behavior.

This preferred PGW selection mechanism feature provides more control and flexibility to customer for routing/load balancing the sessions on desired PGW.

The feature shall be applicable only for initial attach and for Hand-Off calls ePDG shall use the PGW address provided by AAA server even if the feature is enabled as the PGW selected by local configuration may be different from one have the session on LTE.

The number of IPSec managers per card has been increased to 48 from 22 subject to availability of hardware resources such as vCPU and RAM. Customers can utilize more hardware resources to enhance capacity and performance.

The ePDG hosts a MAG (Mobile Access Gateway) function, which acts as a proxy mobility agent in the E-UTRAN/EPC network and uses Proxy Mobile IPv6 signaling to provide network-based mobility management on behalf of the UEs attached to the network. The P-GW also uses Proxy Mobile IPv6 signaling to host an LMA (Local Mobility Anchor) function to provide network-based mobility management. With this approach, the attached UEs are no longer involved in the exchange of signaling messages for mobility.

The MAG function on the ePDG and the LMA function on the P-GW maintain a single shared tunnel. To distinguish between individual subscriber sessions, separate GRE keys are allocated in the PBU (Proxy-MIP Binding Update) and PBA (Proxy-MIP Binding Acknowledgement) messages between the ePDG and the P-GW. If the Proxy Mobile IP signaling contains PCOs (Protocol Configuration Options), it can also be used to transfer P-CSCF or DNS addresses.

The S2b interface uses IPv6 for both control and data. During PDN connection establishment, the P-GW uses Proxy Mobile IPv6 signaling to allocate the IPv6 HNP (Home Network Prefix) to the ePDG, and the ePDG returns the HNP to the UE in an IPv6 router advertisement.

Note that the MAG function on the ePDG does not support multiple PDN connections for the same APN and UE combination. The ePDG establishes each subsequent connection from the same UE to the same APN via a new session and deletes the previous session before the new session gets established.

The multiple PDN feature enables the WLAN UEs to simultaneously establish multiple PDN connections towards the P-GW. Each PDN connection has a separate IKE tunnel established between the UE and the ePDG.

Note that the ePDG supports multiple PDN connections to different APNs only and multiple PDN connections from the same UE to the same APN are not allowed. The ePDG establishes each subsequent connection from the same UE to the same APN via a new session and deletes the previous session before the new session gets established. These new PDN connections use different IPSec/PMIPv6/GTPv2 tunnels.

To request a new session, the UE sends the APN information (in the IDr payload) along with the user identity (in the IDi payload) in this first IKE_AUTH Request message, and begins negotiation of Child SAs. The ePDG sends the new APN information in the Service Selection Mobility Option towards the P-GW, which treats each MN-ID+APN combination as a separate binding and allocates a new IP address/prefix for each new binding.

In case of S2b protocol being used as GTPv2 IMSI + APN is used for identifying the unique session.

During traffic selector negotiation, ePDG by default responds with wildcard IP address, even if the UE is requesting specific range in the TSr. The ePDG should allow to use specific sets of TSs to send traffic to specific sets of address ranges for specific client policies. The ePDG also should respect the range requested by UE and it should (according to the IKEv2 spec) be able to narrow down the UE's request.

All these 4 cases will be supported with the exception that at any point of time maximum of four traffic selector per protocol (combination of IPv4 and/or IPv6) will be supported in a single CHILD SA.

When narrowing is done, if there are several subsets are acceptable, GW will respond back with first 4 acceptable subsets and it will not support ADDITIONAL_TS_POSSIBLE notification.

The cores on the VPC-DI/VPC-SI platforms are used for crypto processing to limit the throughput while using software for encryption or decryption. The SA index will be used to distribute the sessions across all non-MCDMA cores in the system for crypto processing. The system's performance will proportionally improve with the number of non-MCDMA IFTASK cores available.

The following configuration is added to limit the number of cores to be used for crypto.

IFTASK_CRYPTO_CORES=<percentage>

By default, all non-MCDMA cores are used. The value is specified as a percentage of the maximum number of IFTASK cores in the system. This configuration is added in the /boot1/param.cfg file under the debug shell of each SF before reload.

ePDG is enhanced to support the non UICC devices connectivity to EPC via ePDG using certificate based UE authentication following authorization by AAA server.

ePDG already supports UICC devices connectivity using EAP-AKA based device authentication. However as non UICC devices cannot do EAP-AKA based authentication, alternate method of using certificates is used.

ePDG supports the X.509 certificate based authentication and also communicates with OCSP (Online Certificate Status Protocol) server for completing the authentication. Once the authentication is done ePDG communicates with AAA server for ensuring the authorization of the device.

As non UICC devices do not have IMSI, customized vIMSI in format similar to UICC IMSI uniquely identifying the non UICC device needs to be shared by the device. The device IMSI is shared as part of peer (device) certificate to ePDG. ePDG extracts serial number, issuing authority and OCSP responder address details from the certificate and communicates with OCSP responder. In case the OCSP responder detail is absent in the certificate the ePDG configuration is used for extracting the same. The OCSP client (ePDG) to the OCSP responder interaction will be over HTTP. A TCP socket connection will be established to the OCSP responder. OCSP responder communicates with the associated CA (certification authority) and gets the certificate revocation status which can be "good" or "revoked" or "unknown". The ePDG behavior in case of "unknown" is similar to "revoked". When the OCSP response reaches ePDG, it validates if the response is received from genuine entity and post validation checks the certificate status. If the certificate status is good then proceeds with device authorization.

ePDG expects the SUBJECT/CN field of UE certificate to contain the IMSI or NAI and detects that its NAI with presence of '' else its IMSI. This extracted CN fields is accordingly verified with the IDi payload received from UE in IKE_AUTH_REQ message. The certificate identity is more reliable and also the IKE_AUTH_REQ identity does have significance is AUTH payload verification hence this functionality of comparison is in place. ePDG sends the NAI identity as received in the IKE_AUTH_REQ message to the AAA server and once AAA server sends back the authorization success then ePDG does PGW selection and communicates with PGW over S2b interface to establish the call.

IPsec subsystem does comply with RFC 2560 and uses open SSL 0.9.7 for certificate based authentication, therefore ePDG inherently complies with same.

ePDG supports both UICC and non-UICC devices simultaneously for same ePDG service. ePDG service does have single crypto template association with the service IP address and hence IPsec subsystem is enhanced for supporting the multiple authentication methods per crypto template. ePDG identifies whether certificate based authentication needs to be used or not by the presence of AUTH payload. If the AUTH parameter is absent in initial IKE_AUTH_REQ message it indicates that EAP-AKA based authentication is to be used. If the AUTH payload is present and the CERT payload is also present it indicates certificate based mechanism is to be used.

OCSP communication is optional and if not configured then ePDG validates based on the configured CA certificates.

To connect to the IMS core network, the WLAN UEs perform P-CSCF discovery as part of session establishment. This feature supports P-CSCF attributes in CFG_REQUEST and CFG_REPLY messages as part of the CP payload in the IKE_AUTH Request and Response messages the ePDG sends and receives from the UEs. The P-CSCF attribute can be sent on SWu as private or with standard value.

The WLAN UEs request a P-CSCF address in IKE_AUTH messages to establish IMS PDN connections. The ePDG receives the P-CSCF attribute in the CP payload (CFG_REQUEST) of the first IKE_AUTH message exchange and includes a P-CSCF Request message in the PBU (Proxy-MIP Binding Update) message to the P-GW. The ePDG sends the PBU message by framing the MIPv6 PCO VSE (Protocol Configuration Options Vendor Specific Extension) within the P-CSCF Request message to the P-GW. Once the ePDG receives the response from the PGW with the list of P-CSCF addresses, the ePDG shall include the P-CSCF addresses in the CP payload (CFG_REPLY) of the final IKE_AUTH Response message sent to the UE.

In case protocol used on S2b is GTPV2 ePDG has flexibility to use either APCO IE or Private Extension IE based on ePDG configuration. Once the ePDG receives the response from the P-GW with the list of P-CSCF addresses in the APCO / Private Extension IE, the ePDG includes the P-CSCF addresses in the CP payload (CFG_REPLY) of the final IKE_AUTH Response message sent to the UE.

On SWu interface the ePDG is able to handle the private attribute value for the P-CSCF address and this private attribute value is configurable on ePDG. By default 16384 is used for P-CSCF IPv4 address and 16390 is used for the IPv6 P-CSCF address. The values 16384-32767 are for private use among mutually consenting parties.

The P-CSCF v4 and v6 are recently assigned values by IANA so ePDG shall be supporting those values as well in addition to the private configured value. ePDG should respond to UE with same attribute value as received in the request. Private values are maintained for the devices which are already in market as they may not comply to standard values.

UE should include P-CSCF_V4_ADDR attribute only once in IKE_AUTH request and no specific P-CSCF address is included because it is a request. ePDG is enhanced to support both IPv4 and IPv6 P-CSCF address handling together. ePDG also supports maximum of 3 IPv4 and 3 IPv6 P-CSCF addresses. The exceeding P-CSCF address will be ignored. In case of invalid P-CSCF address are received the P-CSCF address is ignored and have no impact on the call establishment.

On S2b interface the P-CSCF is enhanced to support both APCO IE and private Extension IE. ePDG continues to use existing "vendor-specific-attribute" configuration present under epdg-service to decide whether to use APCO IE or private extension IE. The feature scope shall be limited to GTPv2 and shall not cover PMIPv6 as most of the customers are showing interest in GTPv2 based deployment.

How Passing on UE tunnel Endpoint Address over SWm works

Mobile operators would like to be able to block VoWiFi calls from users while roaming. It is required that the tunnel end-point (WLC or AP) IP address to be passed on from ePDG. This is very important to the operator as it generates a huge amount of revenue from roaming calls and would like to minimize the revenue leakage from users making VoWiFi calls while roaming.

The provisioning of UE Tunnel Endpoint-IP (IKEv2 tunnel endpoint incase of NAT) to AAA server will help the operator in identifying the UE's location at AAA server. The operator uses this information to control the access or to decide the UE connections. For example, Operator can lookup the GeoIP database (GeoDB) against the UE tunnel endpoint IP to identify the country from where the UE is connecting from. Based on this information operator can allow the call or reject it(using auth-failure) according to the policy configured. Lets say the policy dictates that the VoWiFi calls are allowed only for UEs connecting from home country but not allowed while roaming outside the country, they can save the revenue leakage using this information.

The value will be sent in UE-Local-IP-Address AVP(IPv4/IPv6) in all the DER messages to AAA server in SWm interface. The AVP is sent as part of standard SWm dictionary (aaa-custom16). In case of AAA server rejects the call based on the tunnel endpoint IP, ePDG will send AUTHENTICATION_FAILED/24 as NOTIFY error message in IKEv2 message to communicate the same to UE.

This feature is supported for EAP based authentication mechanism and not for non UICC deployment using certificate based device authentication.

ePDG receives the IMEI information from the UE over SWu interface and communicates the same to AAA server over the SWm interface.

The IMEI information is communicated to ePDG from UE as part of the CFG_REQUEST payload of the IKE_AUTH_REQ message. A new private attribute is added for the UE to communicate the IMEI information to ePDG. Also ePDG encodes and sends the received IMEI as Terminal Information AVP on the SWm interface.

ePDG is configured to have the private attribute value as configurable for the IMEI which gives the operator the flexibility of choosing the private attribute value for its deployment.

Important

Refer User Equipment Identity in IKE_Auth Message feature for 3GPP defined passing on IMEI to the AAA server in the Diameter EAP Request (DER) message over the SWm interface.

Configuring Passing on IMEI to AAA for EIR Support on WiFi

Use the pgw-address command under the APN Profile Configuration Mode to define local P-GW addresses for load balancing.

configure 
    context context_name 
        crypto template template_name ikev2-vendor  
        configuration-payload private-attribute-type imei imei_value 
        end 

• Use the crypto template template_name command to disable the P-GW address(es) configured for an APN profile.

• Use the ikev2-vendor command to disable the P-GW address(es) configured for an APN profile.

• Use the configuration-payload command to configure mapping of the configuration payload attributes.

• Use the private-attribute-type command to define the private payload attribute.

• Use the imei imei_value command to define IMEI payload attribute value. This is an integer value from 16384 to 32767. The default value is 16391.

• When multiple P-GW addresses are configured, only the first P-GW will be selected based on the weight. The rest of the P-GW addresses are selected using the round-robin mechanism

ePDG supports PDN connection, session establishment and release, along with support for dedicated bearer creation, deletion and modification that is initiated by the P-GW.

During the initial attachment, the ePDG "default EPS QOS", and "APN-AMBR" values are populated in the create session request based on the values received from the SWm interface. If these values are missing in the messages received on the SWm interface, ePDG encodes the mandatory or conditional IE with the values set to zero.

When a new PDN connection is established, ePDG allocates and sends a default EPS bearer ID to the PDN gateway. After the initial attach, a default bearer is created for the session, and the IP address is allocated and communicated to the UE.

A GTP-C and GTP-U tunnel is successfully established between the ePDG and P-GW, and an IPSec tunnel is established between the UE and ePDG. Traffic is allowed to flow between these established tunnels.

ePDG handles the received "create bearer request" message and sends a "create bearer response" message for the dedicated bearer creation triggered from the P-GW.

After the dedicated bearer is created, a new GTP-U tunnel is established between ePDG and P-GW, and traffic mapping to the TFT of this bearer occurs. ePDG supports up to 16 packet filters per bearer.

ePDG also stores mapping information between the uplink packet filters received from the P-GW (For example; in the Create Bearer Request message), and the corresponding S2b bearer. ePDG matches these filters and decides if the uplink packets should be allowed or dropped.

ePDG receives the "delete bearer request" message and sends a "delete bearer response" message for the dedicated bearer deletion triggered by the P-GW.

ePDG clears the bearer path (GTP-U tunnel) corresponding to the EBI received. In the case of a linked EBI, the PDN connection and its associated bearers are deleted. The TFT mapping for the deleted bearer is also deleted.

ePDG handles the received "update bearer request" message and sends a "update bearer response" message for dedicated bearer modification triggered from the P-GW. ePDG updates the UL TFT mapping for the associated bearer using the "bearer context" information.

ePDG supports path failure detection for control plane by using Echo Request and Echo Response messages. A peer's IP address-specific counter is reset every time an Echo Response message is received from the peer's IP address. The counter is incremented when the T3-RESPONSE timer expires for an Echo Request message sent to the peer's IP address. The path is considered as down if the counter exceeds the value of N3-REQUESTS.

ePDG initiates the Echo requests once retransmission timeout occurs for the request sent to the P-GW. The retransmission for GTP messages is handled by running the retransmission timer (T3-RESPONSE) and for N3-REQUESTS timer, the message is retransmitted after the retransmission timer expires. After all the retransmissions are over, echo handling is initiated.

The GTPC configuration has the configuration command, no gtpc path-failure detection-policy <CR> using which on path failure detection, SNMP traps/alarms are generated notifying that P-GW has gone down, but the sessions are not deleted. The SNMP trap is sent only once per peer, and not for every session. When this command is not configured, path failure detection and the subsequent cleanup action is enabled by default.

Detection of path failure for user plane is supported using the Echo Request/ Echo Response messages. A path counter is reset every time an Echo Response is received and incremented when the T3-RESPONSE timer expires for any Echo Request message sent. The path is considered as down if the counter exceeds the value of N3-REQUESTS.

Note	By default, path failure detection is not configured for ePDG.

Session recovery provides seamless failover and reconstruction of subscriber session information in the event of a hardware or software fault within the system, preventing a fully connected user session from being disconnected. The ePDG supports session recovery for IPv4, IPv6, and IPv4/v6 sessions and ensures that data and control planes are re-established as they were before the recovery procedure.

Note that for the recovered sessions, the ePDG recreates counters only and not statistics.

Session recovery is also useful for in-service software patch upgrade activities. If session recovery is enabled during the software patch upgrade, it helps to preserve existing sessions on the active hardware during the upgrade process.

Important

For more information on session recovery support, see the System Administration Guide.

The ePDG can propagate the MAC (Media Access Control) address of each WiFi access point to the P-GW. The ePDG sends this information using the PMIP Location AVP (Attribute-Value Pair) in the User-Location-Info Vendor Specific Option of PBU (Proxy-MIP Binding Update) messages over the S2b interface. In case the protocol used on S2b is GTPv2 then this information is communicated using the Private Extension IE in Create Session Request message.

The WLAN UEs send the MAC address of each WiFi access point to the ePDG embedded in the NAI (Network Access Identifier). When the ePDG receives an NAI that includes a MAC address, the ePDG checks the MAC address and if the validation is successful, the ePDG removes the MAC address from the NAI before sending it to the AAA server in the User-Name AVP of DER (Diameter EAP Request) messages.

Note that the ePDG can be configured to allow IPSec connection establishment without the MAC address present. If the MAC address is not present and the ePDG is configured to check for the MAC address, the ePDG fails the IKE negotiation and returns Notify payload 24 (AUTHENTICATION_FAILED).

The P-GW selection function enables the ePDG to allocate a P-GW to provide PDN connectivity to the WLAN UEs in the untrusted non-3GPP IP access network. The P-GW selection function can employ either static or dynamic selection.

ePDG supports the static UE IP address communicated by AAA to ePDG over SWm interface (as Served-Party-IP-Address AVP in DEA) and ePDG communicates the same to PGW over S2b interface (as PAA IE of create session request GTP message and Home Network Prefix/IPv4 Home Address in PBU for PMIPv6 case).

This feature is applicable for both GTPv2 and PMIPv6 based implementation.

It shall be AAA server functionality to provide the static PGW IP address, when the UE IP address is provided statically so that same PGW is selected which have the static IP pool corresponding to UE address. ePDG will continue with call establishment and will not be validating the AAA provided PGW allocation type. It is the discretion of PGW to accept/reject call in case the requested static IP address is not available at the PGW.

During handoff calls the priority should be given to UE provided IP address over the ones statically provided by AAA server as the subscribed QoS profile at AAA may not be updated. When UE is offloaded from LTE the IP address provided in LTE to UE should be given priority in WiFi over the AAA provided values. WiFi to WiFi handoff is not a requirement so inter ePDG service handoff is not a valid use-case.

All the three PDN Types UE static IP address are supported including the IPv4, IPv6 and IPv4v6.

In case of mismatch in the PDN type between UE requested and the one provided by AAA server the call shall be released by ePDG with "invalid-pdn-type" as the disconnect reason.

The User Equipment (UE) must consistently receive IP address assignment during Wi-Fi to LTE handover or conversely.For dual stack UEs requesting both addresses, due to the operator's choice and network preferences, UE receives either IPv4 or IPv6. In subsequent handovers, the UE will request based on the previously assigned IP address type. To ensure the IP address alignment between LTE to Wi-Fi HO or conversely, ePDG sends IPV4_ONLY_NOTIFICATION or IPV6_ONLY_NOTIFICATION in the IKE CFG_REPLY payload based on the allocated IP address. This feature complies with 3GPP TS 24.302 Release 15.

The table below details the IPv4 and IPv6 notification alignment.

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outages. Typically, these conditions are temporary (high CPU utilization or packet collisions on a network, for example) and are quickly resolved. However, continuous or large numbers of these error conditions within a specific time interval may be indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so that immediate action can be taken to minimize and/or avoid system downtime.

The system supports threshold crossing alerts for certain key resources such as CPU, memory, etc. With this capability, the operator can configure a threshold on these resources whereby, should the resource depletion cross the configured threshold, an SNMP trap would be sent.

The following thresholding models are supported by the system:

Thresholding reports conditions using one of the following mechanisms:

Important

For more information about threshold crossing alerts, see the Thresholding Configuration Guide.

This chapter describes UE Local IP Address IE in the S2B Interface over GTPv2 feature, below are the links to main sections of the document:

The location of the UE initiating a VoWifi call via ePDG will be identified based on the UE local IP address reported on s2b interface. This location information can be used for multiple purposes like billing and lawful interception etc.

Below is the specifications of the "UE Local IP Address IE in the S2B Interface over GTPv2" feature:

How It Works

This section describes signaling flow during an ePDG session setup procedure.

The above figure shows the signaling flow during an ePDG session setup procedure:

1. The IKEv2 procedure starts with the IKE_INIT (step 2) message received at ePDG from UE. The SRC address and port of the IKE_INIT message is recorded at ePDG and NAT detection is done as defined in RFC 5996.
2. The IKE_INIT message triggers the IKEv2 tunnel setup and after the IKE_INIT_RESP in step 3, the UE sends IKE_AUTH message (step 4).
3. This IKE_AUTH_REQ from UE triggers the multi round authentication with AAA server on SWm interface.
4. ePDG sends IKE_AUTH_RESP in step 11 to complete the EAP authentication.
5. The next IKE_AUTH_REQ from UE triggers the session setup towards the PGW over s2b interface and ePDG should include the "UE Local IP Address" and "UE UDP Port" (only if NAT detected) AVPs in the Create Session Request message.

Important

UE Local IP Address IE in the S2B Interface over GTPv2" supports only for GTPv2 based s2b interface.

Detailed Description

External Interfaces

Note: Even though the 3GPP specification mentions the usage of the AVPs in the context of Fixed Broadband access network, they are being used for untrusted WiFi access in this case.

The figure below shows an ePDG session establishment flow. The table that follows the figure describes each step in the flow.

The figure below shows the message flow during a UE-initiated session disconnection. The table that follows the figure describes each step in the message flow.

The figure below shows the message flow during an ePDG-initiated session disconnection. The table that follows the figure describes each step in the message flow.

The figure below shows the message flow during a P-GW-initiated session disconnection. The table that follows the figure describes each step in the message flow.

The figure below shows the message flow If the UE looses connection to the ePDG and then reconnects using the same ePDG. The table that follows the figure describes each step in the message flow.

Table 17. WiFi-to-WiFi Re-Attach

Step	Description
1.	The UE is authenticated and a PDN connection is established. This scenario addresses a case where the UE has ungracefully disconnected from the network and is reattaching to the network again.
2.	The session is still active in the ePDG and P-GW along with AAA, PCRF and AAA.
3.	The step 2 through 12 are identical to the UE initial attach scenario defined in section 3.2.1. It is assumed that the UE will not populate the IP Addresses in the IKE Config Request.
4.	The ePDG shall be detecting the duplicate session and clearing the previous established session at its ends. Further ePDG shall be establishing new session on P-GW following below steps
15.	ePDG UE: IKE_AUTH - The ePDG sends IKE_AUTH (AUTH, CP, SA, CFG_REPLY ([INTERNAL_IP4_ADDRESS], [INTERNAL_IP4_NETMASK], [INTERNAL_IP4_DNS], INTERNAL_IP6_ADDRESS, INTERNAL_IP6_SUBNET, INTERNAL_IP6_DNS, P-CSCF) TSi, TSr). The ePDG calculates the AUTH parameter, which authenticates the second IKE_SA_INIT message. The ePDG sends the assigned IP address in the configuration payload (CFG_REPLY). The AUTH parameter is sent to the UE together with the configuration payload, security associations and the rest of the IKEv2 parameters and the IKEv2 negotiation terminates.
16.	ePDG P-GW: PBU (Proxy-MIP Binding Update) - The ePDG selects the P-GW based on DNS response from the APN-FQDN.The ePDG sends PBU (IMSI, [MSIDSN], Serving Network, RAT Type (WLAN), Indication Flags, Sender F-TEID for C-plane, APN, Selection Mode, PAA, APN-AMBR, Bearer Contexts), [Recovery], [Charging Characteristics], Private IE (P-CSCF). The F-TEID shall be set to zero so that P-GW shall handle the same as create-on-create case.
19.	P-GW ePDG: PBA (Proxy-MIP Binding Acknowledgement) - The P-GW terminates the previous session by handling it as create on create case and establishes a new session. The P-GW allocates the requested IP address session and responds back to the ePDG with a PBA (Cause, P-GW S2b Address C-plane, PAA, [Recovery], APN-AMBR, Additional Protocol Configuration Option (APCO) Bearer Contexts Created, Private IE (P-CSCF)) message.
21.	ePGD UE: Router Advertisement - The ePDG sends Router Advertisement to ensure IP Stack is fully initialized.

Description:

The UE is authenticated and a PDN connection is established. This scenario addresses a case where the UE has ungracefully disconnected from the network and is reattaching to the network again.

The session is still active in the ePDG and P-GW along with AAA, PCRF and AAA.

The step 2 through 12 are identical to the UE initial attach scenario defined in section 3.2.1. It is assumed that the UE will not populate the IP Addresses in the IKE Config Request.

The ePDG detects the duplicate session and clears the previous established session at its ends. Then the ePDG establishes a new session on the P-GW using the following steps:

When a VoLTE call is ongoing, the P-GW will install the bearers on the LTE network using piggyback procedure.

Note

This call flow is the similar as that for IMSI/GUTI-based EUTRAN Attach, except for the additional steps for session clean up on WiFi network and multiple dedicated bearers are set up if voice and video media bearers are present. The critical difference is that the Handover Indication bit shall be set in Create Session Request message.

The UE which was previously having a WiFi call attaches to the LTE.

In this call flow we use the IMS PDN with an ongoing VoLTE call with the associated dedicated bearers.

The UE detects suitable WiFi access point and connects to AP as per node selection.

The following two counters are available:

• tot--handoff-attempts: Total number of user equipment (UE) attempted LTE to WiFi Handoff. The counter gets incremented at the time of creating ePDG session post IKE_INIT completion, and if the handoff indicator is enabled based on the IKE_AUTH message received from UE.

• tot-success-handoff: Total number of successful LTE to WiFi handoff. UE requests IPv4 or IPv6 or both in CFG Req payload of first IKE_AUTH Req and AAA mandatorily provides PGW IP or FQDN.