ePDG SolutionDescription

Evolved Packet Data
Gateway (ePDG)
SolutionDescription
Commercial In Confidence
Date: Jul. 19, 2014
Published
For more information on Mavenir Systems, visit our Web site:
http://www.mavenir.com/
Every reasonable effort has been made to ensure the information and procedures detailed in this
document are complete and accurate at the time of printing. However, information contained in this
document is subject to change without notice.
© 2014 Mavenir Systems Inc.
II
Evolved Packet Data Gateway (ePDG) SolutionDescription
Contents
Abbreviations & Glossary ........................................................................................................................ 1
1 Overview .......................................................................................................................................... 3
2 Platform ............................................................................................................................................ 5
2.1 ePDG Platform Overview ........................................................................................................ 5
2.2 Software Architecture .............................................................................................................. 5
2.3 Deployment Models ................................................................................................................ 7
2.3.1 ATCA .................................................................................................................................... 7
2.3.2 ePDG in the Cloud (Virtualized) .......................................................................................... 8
2.4 Scaling ..................................................................................................................................... 9
2.5 OAMP .................................................................................................................................... 10
3 Feature Functionality ..................................................................................................................... 12
3.1 IP Security ............................................................................................................................. 12
3.1.1 Untrusted Non-3GPP Access............................................................................................ 12
3.1.2 Security between UE and ePDG ....................................................................................... 13
3.2 Interfaces............................................................................................................................... 18
3.2.1 SWu................................................................................................................................... 18
3.2.2 SWm .................................................................................................................................. 18
3.2.3 S2b .................................................................................................................................... 25
3.2.4 GTPv2-C ........................................................................................................................... 26
3.2.5 Create Session Request ................................................................................................... 27
3.2.6 Create Session Response ................................................................................................ 30
3.2.7 Delete Session Request .................................................................................................... 32
3.2.8 Delete Session Response ................................................................................................. 32
3.2.9 Modify Bearer Request ..................................................................................................... 33
3.2.10 Modify Bearer Response .................................................................................................... 33
3.2.10 Modify Bearer Command .............................................................................................. 33
3.2.11 Modify Bearer Failure Indication ................................................................................... 33
3.2.12 Trace Session Activation ............................................................................................... 33
3.2.13 Trace Session Deactivation .......................................................................................... 34
3.2.14 Create Bearer Request ................................................................................................. 34
3.2.15 Create Bearer Response .............................................................................................. 35
3.2.16 Update Bearer Request ................................................................................................ 36
3.2.17 Update Bearer Response .............................................................................................. 36
3.2.18 Delete Bearer Request .................................................................................................. 37
3.2.19 Delete Bearer Response ............................................................................................... 37
3.2.20 Delete PDN Connection Set Request ........................................................................... 38
3.2.21 Delete PDN Connection Set Response ........................................................................ 38
3.2.22 GTPv1-U ....................................................................................................................... 38
3.3 MOBIKE - IKEv2 Mobility and Multihoming Protocol ............................................................ 39
3.4 IMSI Filtering and Blacklisting ............................................................................................... 41
3.5 PGW Selection ...................................................................................................................... 41
3.6 Multiple PDN Support ............................................................................................................ 43
3.7 MAPCON – Multi Access PDN Connectivity ......................................................................... 43
3.8 IPFOM – IP Flow Mobility...................................................................................................... 44
3.9 DSCP Marking....................................................................................................................... 46
3.10 P-CSCF Discovery ................................................................................................................ 47
3.11 Multiple Identity Support ........................................................................................................ 47
3.12 Multiple Authentication and Fast Re-authentication Support ................................................ 48
4 Performance Monitoring and KPI ................................................................................................... 51
4.1 EMS ....................................................................................................................................... 51
4.2 EMS Client Portal .................................................................................................................. 52
4.3 IPsec Tunnel Events ............................................................................................................. 52
4.4 AAA Server Group Events .................................................................................................... 53
© 2014 Mavenir Systems Date: Jul. 19, 2014 i

Published
5 Performance Management ............................................................................................................ 55
5.1 Functional Performance Counters ........................................................................................ 55
5.1.1 ePDG ................................................................................................................................. 55
5.2 IKE SA Events ....................................................................................................................... 56
5.3 Protocol Performance Counters ............................................................................................ 61
5.3.1 SWm Diameter .................................................................................................................. 61
5.3.2 GTPv2-C-ePDG ................................................................................................................ 62
5.3.3 DHCP ................................................................................................................................ 65
5.3.4 DNS ................................................................................................................................... 66
5.3.5 IKE ..................................................................................................................................... 67
5.4 Platform Performance Counters............................................................................................ 70
5.4.1 Common Header Information ............................................................................................ 70
5.4.2 Signaling Performance Counters ...................................................................................... 70
5.4.3 System Performance Counters ......................................................................................... 72
6 Call Flows ...................................................................................................................................... 78
6.1 Untrusted Wi-Fi Attach over S2b GTPv2 .............................................................................. 78
6.2 UE Initiated Detach ............................................................................................................... 78
6.3 HSS Initiated Detach ............................................................................................................. 79
6.4 PGW Initiated Detach ............................................................................................................ 79
6.5 Handover From Wifi To EUTRAN ......................................................................................... 79
6.6 Handover from EUTRAN to WiFi .......................................................................................... 80
6.7 Dead Peer Detection ............................................................................................................. 81
6.8 IKE Rekeying......................................................................................................................... 81
6.9 Handover to EUTRAN with voice .......................................................................................... 82
6.10 Handover to WiFi with voice .................................................................................................. 83
6.11 HSS Initiated update of user profile ...................................................................................... 83
7 References ..................................................................................................................................... 83
7.1 3GPP ..................................................................................................................................... 83
7.2 IETF....................................................................................................................................... 84
ii
Evolved Packet Data Gateway (ePDG) SolutionDescription
Abbreviations & Glossary

Abbreviation/Term Definition
3GPP 3rd Generation Partnership Project

A-BGF Access Border Gateway Function
ACL Access Control List
A-SBC Access- Session Border Controller
ATCA Advanced Telecommunications Computing Architecture
ATCF Access Transfer Control Function, used in SR VCC implementation
ATGW Access Transfer Gateway
B2BUA Back 2 Back User Agent
BGCF Breakout Gateway Control Function
CDR Charging Data Record
CP Control Plane ( handles signaling and applications)
CS Circuit Switched
DDoS Distributed Denial of Service
DMZ De-militarized Zone, operator's perimeter network
DoS Denial of Service
DPI Deep Packet Inspection
DSCP Differentiated Services Code Point, used in IP header to classify packet
type
DTLS Datagram Transport Layer Security
EATF Emergency Access Transfer Function, used in SR VCC implementation
E-CSCF Emergency-Call Session Control Function
ETSI European Telecommunications Standards Institute
Gm 3GPP defined interface between SIP User Equipment (UE) and P-CSCF
GW Gateway
H.264 Video codec used for video compression
HTTP Hypertext Transfer Protocol
IBCF Interconnection Border Control Function
I-BGF Interconnection Border Gateway Function
ICE Interactive Connectivity Establishment
Ici 3GPP Reference point between IBCF and other IBCF from different
network
ICS IMS Centralized Services
IM Instant Message
IMS IP Multimedia Subsystem
IMS-AKA IMS Authentication and Key Agreement
IMS-ALG IMS Application Level Gateway
IPSec IP Security
IR.64 GSMA, IMS Service Centralization and Continuity Guidelines
IR.92 GSMA, IMS profile for Voice and SMS
IR.94 GSMA, IMS profile for Conversational Video
I-SBC Interconnect-Session Border Controller
Izi 3GPP Reference point between TrGW and another TrGW from different
network
© 2012 Mavenir Systems Date: Jul. 19, 2014 1
Published
LEA Law Enforcement Agency
LI Lawful Intercept
LRF Location Retrieval Function
MP Media Plane ( handles media related processing)
MSRP Message Session Relay Protocol , used for IM Chat session, session mode
IMs etc.
Mw 3GPP defined interface used to exchange messages between CSCFs
Mx 3GPP defined interface between BFCF/CSCF and IBCF
NAPT Network Address Port Translation
NAT Network Address Translation
NEBS Network Equipment Building System
NNI Network-Network Interface
OAMP Operations, Administration, Maintenance and Provisioning
OAuth Open protocol for authentication, defined by IETF RFC 5849
P-CSCF Proxy-Call Session Control Function
PKI Public Key Infrastructure
PS Packet Switched
PSAP Public Safety Answering Point
RCS Rich Communication Services
REGEX Regular Expressions, operations used for pattern matching on strings of
text
Rf 3GPP defined interface from a network element towards the Charging
Collection/Data Function
RTP Real-Time Transport Protocol
SBC Session Border Controller
SDP Session Description Protocol
SIP Session Initiation Protocol
SRTP Secure RTP
SR-VCC Single Radio-Voice Call Continuity
SSL Secure Socket Layer
STUN Session Traversal Utilities for NAT
TCP Transmission Control Protocol
TLS Transport Layer Security
TOS Type of Service, a field used in IP header to classify packet type for service
differentiation
TrGW Translation Gateway
TS Technical Specification
UAG Unified Access Gateway
UNI User-Network Interface
VLAN Virtual Local Area Network
VP8 Video compression format developed by Google Inc. supported on popular
web browsers
VPLMN Visited Public Land Mobile Network
WebRTC Web Real Time Communications
2
1 Overview
Due to tremendous surge in smart phones and other tablet devices leading to unpredictable
data usage growth rates, operators are trying to achieve fixed-mobile convergence and
manage subscriber’s demand for ubiquitous service access. It is predicted that by 2018
smart devices will contribute to 96% of mobile data traffic. This has led to various on-
net/off-net strategies to increase service reach and manage traffic load. While the obvious
choice seems to be improving the existing EPC core and access with improved network
architecture to enable band width usage growth, it is not a cost efficient and scalable
solution. One of the most significant approaches is offloading traffic over other access
technologies like Wi-Fi, Femto- or Small-cells that are connected to the EPC via untrusted
3rd party access networks such as DSL, Cable, FTTH, etc. Wi-Fi of all is uniquely positioned
to handle the data surge and throughput requirements on the mobile networks. WLAN is an
obvious choice for its ubiquitous presence, wide user adaptability, its integration with smart
devices, unified protocols worldwide and the associated costs involved in deploying
additional access points. As operators deploy VoLTE and Vo-Wi-Fi, ePDG bridges the gap
between the two by helping operators leverage their investments further. ePDG helps
operators offload the macro RANs by exploiting the unlicensed spectrum (Wi-Fi) while
providing a seamless user experience between the two access technologies.
With Mavenir’s leadership in Voice over LTE (VoLTE) and Voice over Wi-Fi (VoWi-Fi) space,
the ePDG provides seamless connectivity between the two accesses and selectively offloads
different traffic flows to each access providing best of breed user experience. Built on top of
the flagship mOne® convergence software platform, Mavenir’s ePDG enables flexible
deployment options based on operator needs. It can be deployed on a server based
platform (RMS 220), or an ATCA based or it can be deployed in cloud based infrastructure.
To enable low cost of ownership and flexibility of COTS hardware, Mavenir solution is also
available as a fully virtualized NFV-compliant carrier-grade product with scalability and
reliability at the top of the feature list. With full scale session resiliency, admission control
and four 9’s reliability ePDG provides plenty of configurable options for the operator to
override default behavior.
Mavenir’s solution further differentiates itself with an innovative collocation of ePDG along
with PGW and SBC. This enable true seamless handoffs between LTE and Wi-Fi while making
it transparent to the UE similar to PS-CS handoff. This removes the dependency on the user
equipment to support IP preservation procedures like MOBIKE. Most importantly it allows
the IMS layer to be aware of the transition and continue to invoke access related
procedures which is not possible with standalone ePDG. With support for both sim based
and sim-less devices through IKEv2, EAP-AKA , EAP-TLS and complete IPSEC functionality
Mavenir’s solution provides complete suite of security protocols. Mavenir’s converged
access solution (ePDG+PGW+SBC) is future proof and provides significant Capex and Opex
savings by reducing complexity and latency due to multiple hops.
3
HSS
SWx
S6a
PCRF
Gxc Rx
Gx
Ope rator's IP
SGi Services
3GPP Serving PDN (e.g. IMS, PSS
Access Gateway Gateway etc.)
S5
S6b
S2b
SWm
S2a ePDG 3GPP AAA
Server
HPLMN SWn
Non -3GPP Gxa

Networks SWu
Trusted Untrusted
Non -3GPP IP Non -3GPP IP
Access Access SWa
STa
UE
Figure 1 Overall Architecture
4
2 Platform
2.1 ePDG Platform Overview
The ePDG is based on proven mOne® Convergence platform software architecture.
The ePDG is pure software solution based on Mavenir’s patented and proven mOne®
Convergence Platform. The solution is designed to be highly scalable, robust and fault
tolerant. The ePDG solution has no underlying hardware dependency allowing it to be
deployed in a virtualized cloud environment. The ePDG platform is architected to provide
enormous flexibility in terms of deployment models, supported applications and scaling. The
flexible scaling allows the ePDG to be dimensioned to make the most use of the underlying
resource in a cost effective, efficient manner. The unpredictable nature of the traffic,
demands that the ePDG be flexible enough to accommodate such scaling requirements. The
modular and flexible mOne® software architecture allows the ePDG to provide such flexibility.
2.2 Software Architecture

The ePDG platform can be deployed with either integrated or distributed architecture. The
distributed architecture enables the virtualization of the ePDG, where the ePDG control plane
is hosted in a virtualized environment while the media and security planes are deployed at
5
the network edge. The distributed or decomposed architecture allows for performance
optimization and inherently more efficient independent scaling of components. The control
plane (CP) handles the signaling and related processing while user plane (UP) is responsible
for the data and media handling and processing. The security plane which is an overlay on
both control plane and media plane handles all the security related processing including
tunnel terminations, signaling and media encryption and decryption. The security plane also
handles most other security features of the ePDG.
Figure 2: Distributed Architecture
The mOne® software architecture is based on a modular design with clearly defined functions
spread across base and application layers. The ePDG solution consists of the following
software modules independently-hosted for easy scaling and as shown in Figure 3.
 Resource Manager: The Resource Manager (FE) module is responsible for external
packet processing, IPSec Tunnel terminations, handling SRTP and
encryption/decryption in media relay. Resource Manager modules are deployed in
1+1 active/standby redundant pairs. It is possible to deploy an additional pair of FE
cards depending on the scaling requirement, especially if the solution is used for very
large scale deployment.
 Session Control: Session Control (SC) hosts the control plane (CP) which handles
all signaling related processing as well as hosts the applications deployed on the
ePDG, for example P-CSCF, IBCF etc.
Session Control modules are deployed in 2N redundant mode, meaning they are
deployed as N number of 1+1 active/standby pairs
 Media Processor: The media processor module is handles all media related
processing and hosts RTP and SRTP stack. It handles jitter buffers, packet
reordering, packet time processing.
Media processor modules are deployed on N+ 1 redundant pairs.
 Admin Manager: Administration Module hosts the complete mOne Element
Management System (EMS). It is responsible for OAMP functions including
configuration management, system health monitoring and reporting, generating
alarms & events and providing performance counters. The admin module is also
responsible for CDR generation and processing (if local CDRs re used).
The Admin Manager is deployed in 1+1 redundant pair.
6
Figure 3: mOne Software Modules
2.3 Deployment Models

The ePDG product is offered in the following three configurations that can scale according to
operator’s need:
1) mOne® ATCA 13U-based blade system
2) Fully Virtualized system based on COTS.
3) Server based on RMS-220
2.3.1 ATCA
The ATCA solution is offered on Mavenir’s mOne® Convergence Platform which is an ATCA-
based system. The mOne® platform is carrier grade, highly scalable and resilient. Please
refer the mOne Convergence Platform Description document for more details. Mavenir’s
mOne platform provides a high degree of scalability within a single equipment rack. An mOne
platform deployment can consist of one or two 14 slot ATCA shelves within an equipment
frame. Following modules are hosted on the blades as described:
 Resource Manager: Resource Manager modules are deployed in 1+1 active/standby
redundant pairs. It is possible to deploy an additional pair of FE cards, depending on
the scaling requirement.
 Session Control: Session Control modules are deployed in 2N redundant mode,
meaning that they are deployed as N number of 1+1 active/standby pairs
 Media Processor: Media processor modules are deployed on N+ 1 redundant blade.
 The Admin Manager is deployed in 1+1 redundant blade configuration.
 Switching Engine: The SE provides full non-blocking connectivity between the
various modules deployed on various cards in a single ATCA chassis. The SE
provides completely separate switches and control processors for the Fabric and
Base networks, which meets the rigorous security requirements of carrier
environments.
The Switching Engine is deployed in 1+1 redundant blade configuration.
7
Figure: mOne® ATCA Platform
2.3.2 ePDG in the Cloud (Virtualized)

The ePDG is a software-based solution and the architecture is based on the mOne®
Convergence Platform. The mOne Convergence platform is also offered as a virtualized
solution. The solution is based on a modular design with clearly defined functions across base
and application layers. These modules are described in the ATCA-based solution description
in the above section. All of these modules can be deployed in a virtualized environment (note:
the switching module is not a function of the virtualized solution).
Figure 4 ePDG in NFV Infrastructure
The ePDG solution, when offered in a distributed architecture (separate signaling, media &
security planes), allows for virtualized solution deployment. In this deployment model, the
modular software functions are distributed, meaning each of these modules is handled in
separate virtual machines. Scaling is achieved using an integrated virtualized load balancer.
The scaling model uses a mix of N+1 and 1:1 active/standby redundant resource pools.
Resource pools are simply a pool of virtualized modules. Further reliability can be achieved
by ensuring active/standby functions spread across separate underlying physical machines
8
that host the virtual machines. The media resource pool is expected to run on its own
hardware or VM which is deployed at the network edge. The distributed control and media
plane ePDG architecture will allow the operator to deploy the control plane in the core network
cloud and the media/security plane at the edge if required. Besides the usual virtualization
benefits including operational simplicity and cost savings, the ePDG virtualized solution offers
two important benefits:
1) Automated Elastic Scaling: The virtualized solution is inherently scalable and elastic.
The independently scalable components make the solution efficient. The solution can be
configured differently as per the need of the call model. More capacity can be added as
required and only those components will be deployed which run out of capacity. The
mCloud virtualization solution offers automatic elasticity where it continuously monitors
the capacity of various modules and adds (instantiates) new modules automatically as
required.
2) EPC in the Cloud: The virtualized solution offers a key benefit where the operator can
push all the application intelligence towards a centralized cloud and deploy various media
planes at various locations as per the topology, geo-redundancy and capacity
requirements. This allows the operator to deploy a multi-site multi-national solution and
have it controlled from a centralized location.
2.4 Scaling
The ATCA chassis system comes with 14 blades of which 6 blades are used for admin,
Resource Manager and switching functions as shown in the following figure.
The solution can scale using the rest of the blades. Depending on the operator need and the
call model, operators can deploy the session control (control plane) and media processing
blades using the remaining 8 slots.
9
Figure 5: Software module configuration
It is possible to scale the solution into another 14 slot chassis if needed. When the second
chassis is added, the scalability of the solution will depend on the call model. The available
slots on the second chassis can be used to host more CP and MP cards as required by the
call model. Alternatively the second chassis can be deployed as an independent system to
add more capacity.
If second chassis is used, the N+ 1 redundant cards can be deployment in either chassis.
Figure 6: Scaling on ATCA-based system
2.5 OAMP
The ePDG is complemented with an intuitive, flexible management system that makes the
OAMP simple and effective. The network configuration, policy management, routing and
translation framework is at the core of the provisioning system. Mavenir’s integrated Element
Management System (EMS) system provides this easy-to-use GUI for all element
management functions. The EMS allows for controlling and managing the following essential
functions:
10
 Quick View, overall configuration and health
 Fault Management
 System and Application Configuration
 Performance
 Administration
The ePDG offers a variety of counters, alarms, logs and events to monitor the health and
performance of the system. Detail CDRs are provided to capture the session-related data for
each signaling and related media sessions. Other tools like detailed logs, call trace and user
profile query are also provided.
Alarms: The solution supports SNMP v3 and provides an Alarm and Event monitoring
solution in compliance with ITU-T X.733 and 734. An alarm indicates when there are fault
types generated within the solution that require attention. An Event depicts state changes
associated with components and other administrative events. The alarms and events are
consolidated in the EMS.
Counters: The traffic monitoring manager hosted on EMS is responsible for collection of
operational counters created by application software as well as within the system itself;
counter types created include individual and group counters. Traffic monitoring manager
creates statistical files for performance management purposes, and can report them
externally to 3rd party OSS via SFTP.
11
3 Feature Functionality
3.1 IP Security
SW
u
Five security feature groups are defined. Each of these feature groups accomplishes certain
security objectives:
 Network access security (I): the set of security features that provide users with
secure access to services while terminated at 3GPP EPC. Radio Access protection is a
non-3GPP access specific and outside the scope of the present document.
 Network domain security (II): the set of security features that enable nodes to
securely exchange signaling data, and protect against attacks on the wireline
network.
 Non-3GPP domain security (III): the set of security features are a non-3GPP access
specific and outside the scope of the present document.
 Application domain security (IV): the set of security features that enable
applications in the user and in the provider domain to securely exchange messages.
 User domain security (V): the set of security features that secure access to the
mobile station. If the terminal does not support 3GPP access capabilities, 3GPP does
not specify how user domain security is achieved
3.1.1 Untrusted Non-3GPP Access
Designating a Non-3GPP network as trusted or untrusted is left solely to the home operator.
Depending on the security groups (defined above) that are provided by the non-3gpp access
12
if they are not considered sufficiently secure then it is termed as untrusted non-3gpp access.
But the security group criteria may not be the only reason a particular access is designated
as secure or unsecure. ePDG fits into the untrusted non 3GPP access architecture. For
untrusted access, UE and the ePDG shall perform mutual authentication (IKEv2) during the
IPsec tunnel establishment between the UE and the ePDG (SWu reference point). In
addition, before the IPsec tunnel establishment between the UE and the ePDG can be
performed, the UE needs to obtain IP connectivity across the access network, which may
require an access authentication, which is independent of the EAP-AKA authentication run
in conjunction with the IPsec tunnel establishment. This additional access authentication
and key agreement is not required for the security of the Evolved Packet Core. However, it
may be required for the security of the untrusted non-3GPP access network.
3.1.2 Security between UE and ePDG
The UE and the ePDG shall use IKEv2, as specified in RFC 5996 [30], in order to establish
IPsec security associations. EAP-AKA, as specified in RFC 4187 [7], within IKEv2, as specified
in RFC 5996 [30], shall be used to authenticate UEs.
The tunnel end point in the network is the ePDG. As part of the tunnel establishment
attempt the use of a certain APN is requested. When a new attempt for tunnel
establishment is performed by the UE the UE shall use IKEv2 as specified in RFC 5996 [30].
The authentication of the UE in its role as IKEv2 initiator terminates in the 3GPP AAA Server.
The UE shall send EAP messages over IKEv2 to the ePDG. The ePDG shall extract the EAP
messages received from the UE over IKEv2, and send them to the 3GPP AAA Server. The UE
shall use the Configuration Payload of IKEv2 to obtain the Remote IP address.
The following illustration is of generic IKE message flow with AAA based authentication
using EAP methods. On AAA based subscriber authentication, ePDG supports authentication
methods: EAP-TLS and EAP-AKA
13
EAP-AKA
3GPP
UE ePDG
AAA-Serv
HSS / HLR
1. IKE_SA_INIT
[Headers, Sec. associations, D-H values, Nonces]
2. IKE_AUTH Request
3. Authentication & Authorization Req [EAP-
[Header, User ID, Configuration Payload(EAP-Resp/Identity), User ID, APN info]
Pyload, Sec. associations,
Traffic selectors, APN info] 4. User profile and AVs retrieval if needed
(i.e. if not available in the AAA)
Check user’s subsription whether tunnel is allowed
5. A&A-Answer [EAP-Request/AKA-Challenge]
6. IKE_AUTH Response
[Header, ePDG ID, Certificate, AUTH, EAP-Request/AKA-Challenge]
6.a UE runs AKA
algorithms, verifies AUTN,
generates RES and MSK
7. IKE_AUTH Request
[Header, EAP-Request/AKA-Challenge]
8. A&A-Request [EAP-Response/AKA-Challenge]
8a. 3GPP AAA Se rver verifies

If AT_RES = XRES
9. AA-Answer [EAP-Success, key material, IMSI]
10. AUTH payload is computed

using the keying material (MSK)
[Header, EAP-Success]
12. IKE_AUTH Request [AUTH]
13. Check AUTH correctness
14. Calculate AUTH

[Header, AUTH, Configuration Payload, Sec. Associations, Traffic Selectors]
1. The UE and the ePDG exchange the first pair of messages, known as IKE_SA_INIT, in
which the ePDG and UE negotiate cryptographic algorithms, exchange nonce and
perform a Diffie_Hellman exchange.
2. The UE sends the user identity (in the IDi payload) and the APN information (in the IDr
payload) in this first message of the IKE_AUTH phase, and begins negotiation of child
security associations. The UE shall send the configuration payload (CFG_REQUEST)
14
within the IKE_AUTH request message to obtain an IPv4 and/or IPV6 home IP Address
and/or a Home Agent Address.
3. The ePDG sends the Authentication and Authorization Request message to the 3GPP
AAA Server, containing the user identity and APN. The UE shall use the NAI, the 3GPP
AAA server shall identify based on the realm part of the NAI that combined
authentication and authorization is being performed for tunnel establishment with an
ePDG which allows only EAP-AKA.
4. The 3GPP AAA Server shall fetch the user profile and authentication vectors from
HSS/HLR (if these parameters are not available in the 3GPP AAA Server). The 3GPP
AAA Server shall lookup the IMSI of the authenticated user based on the received user
identity (root NAI or pseudonym) and include the EAP-AKA as requested
authentication method in the request sent to the HSS. The HSS shall then generate
authentication vectors and send them back to the 3GPP AAA server.
The 3GPP AAA Server checks in user's subscription if he/she is authorized for non-
3GPP access.
For example, for EAP AKA authentication: If the IMSI is 234150999999999 (MCC = 234, MNC = 15), the root NAI then
takes the form 0234150999999999@wlan.mnc015.mcc234.3gppnetwork.org and EAP SIM authentication
1234150999999999@wlan.mnc015.mcc234.3gppnetwork.org
5. The 3GPP AAA Server initiates the authentication challenge. The user identity is not
requested again.
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/AKA-Challenge) is included
in order to start the EAP procedure over IKEv2.
7. The UE checks the authentication parameters and responds to the authentication
challenge. The only payload (apart from the header) in the IKEv2 message is the EAP
message.
8. The ePDG forwards the EAP-Response/AKA-Challenge message to the 3GPP AAA
Server.
8.a The AAA checks, if the authentication response is correct.
9. When all checks are successful, the 3GPP AAA Server sends the final Authentication
and Authorization Answer (with a result code indicating success) including the 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 authentication
process. When the SWm and SWd interfaces between ePDG and 3GPP AAA Server are
implemented using Diameter, the MSK shall be encapsulated in the EAP-Master-
Session-Key-AVP, as defined in RFC 4072.
10. The MSK shall be used by the ePDG to generate the AUTH parameters in order to
authenticate the IKE_SA_INIT phase messages. These two first messages had not been
authenticated before as there was no key material available yet. According to RFC
5996, the shared secret generated in an EAP exchange (the MSK), when used over
IKEv2, shall be used to generated the AUTH parameters.
11. The EAP Success/Failure message is forwarded to the UE over IKEv2.
12. 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.
13. The ePDG checks the correctness of the AUTH received from the UE. At this point the
UE is authenticated. In case S2b is used, PMIP signalling between ePDG and PDN GW
can now start, as specified in TS 23.402 [5]. The ePDG continues with the next step in
15
the procedure described here only after successful completion of the PMIP binding
update procedure.
14. The ePDG calculates the AUTH parameter which authenticates the second
IKE_SA_INIT message. The ePDG shall send the assigned Remote IP address in the
configuration payload (CFG_REPLY).
15 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.
EAP-TLS
Mavenir ePDG allows both SIM and SIM-less UEs to connect to wireless service provider
network over Wi-Fi. This connection between UE and service provider network is established
over public internet. Hence it requires mutual authentication and authorization. The UE first
point of contact in the service provider network is ePDG. The ePDG Service Access Point (SAP)
is pre-published to the UE. In order to perform mutual authentication and user service
authorization, ePDG makes use of certificate chain validation and EAP-TLS based AAA
authentication. For successfully verified users, a secure IPsec tunnel is established from UE to
the edge of ePDG. This tunnel between UE and ePDG then serve as carrier of further service
exchanges between UE and ePDG. For IMS voice and rich messaging services, UE traffic is
routed within ePDG (such as P-CSCF, IMS-ALG/AGW). And internet services traffic is directly
routed out of ePDG towards the application servers within the provider network.
The following is an example illustration depicting non-cellular UE to ePDG interaction.
Private
Public Internet Private network
WiFi Network
Wifi APN ePDG

192.168.1.10 192.168.1.1 65.10.10.10 70.1.1.1 200.1.1.1/24
IP Header Public IP Header Public

Src: 192.168.1.10 Src: 65.10.10.10
Dest: 70.1.1.1 Dest: 70.1.1.1
ESP header ESP header
IP Header Private
Integrity Protected
Integrity Protected
Src: 200.1.1.10
Encrypted
IP Payload Priv IP PayloadPriv IP PayloadPriv Dest: 200.2.1.1

Encrypted
IP Payload
ESP Trailer ESP Trailer
ESP Auth ESP Auth
1 2 3 4
Figure 7: Example travel path of ESP packet for non-cellular access
16
UE UAG AAA
I1
IKE SA_INIT
I2c
IKE_SA_INIT Response with COOKIE
I1c
IKE SA_INIT (with COOKIE)
I2
IKE_SA_INIT Response
I3 IKE_AUTH Request
[EAP Response Identity, SA, TS] A1
A2
I4 IKE_AUTH Response
[EAP Payload]
I5 IKE_AUTH Request
EAP Response [TLS client_hello] A3
A4
[EAP Payload]
I7 IKE_AUTH Request
EAP Response [TLS finished] A5
A6
[EAP Payload]
I9 IKE_AUTH Request
EAP Response A7
A8
[EAP Success, SAs, Traffic Selectors]
After authentication IPSec tunnel is established between UE and ePDG. UE packages the
service packet inside another IP packet. The outer packet is sourced from the UE’s private IP
address within WiFi network and is destined to ePDG Security Gateway (ePDG) service
address.
For illustration purposes, WiFi Access Point, NATs the outer address in IP header. It is now
replaced with WiFi AP’s internet IP address. The packet arrives at ePDG and
integrity/confidentiality functions are performed on the ESP. The packaged IP packet is now
ready to be routed to any service within the provider network.
Below is summary of all supported security options on ePDG.

Protocol Type Supported Options
Internet Key IKEv2 Encryption  DES-CBC

Exchange version  3DES-CBC
2  AES-CBC-128
 AES-CBC-256
17
IKEv2 Pseudo Random  PRF-HMAC-SHA1
Function (PRF)  PRF-HMAC-MD5
 PRF_AES128_CBC
IKEv2 Integrity  AUTH_HMAC_SHA1_96
 AUTH_HMAC_SHA2_256
 AUTH_HMAC_MD5_96
 AUTH_AES_XCBC_96
IKEv2 Diffie-Hellman Group  Group 1 (768-bit)
 Group 2 (1024-bit)
 Group 5 (1536-bit)
 Group 14 (2048-bit)
IPSec IPSec Encapsulating  ENCR_3DES
Security Payload  ENCR_AES128_CBC
Encryption  ENCR_AES256_CBC
IPSec Integrity  NULL
 HMAC-SHA1-96
 HMAC-MD5-96
 AES-XCBC-96
3.2 Interfaces
3.2.1 SWu
This is the reference point between the UE and the ePDG and supports handling of IPSec
tunnels. The functionality of SWu includes UE-initiated tunnel establishment, user data
packet transmission within the IPSec tunnel and tear down of the tunnel and support for
fast update of IPSec tunnels during handover between two untrusted non-3GPP IP accesses.
SWu is based on IKEv2 and MOBIKE. IKEv2 is detailed in section 4.1 and MOBIKE is under 4.3
3.2.2 SWm
The SWm reference point is defined between the ePDG and the 3GPP AAA Server or
between the ePDG and the 3GPP AAA Proxy. The definition of the reference point and its
functionality is given in 3GPP TS 23.402 and the detailed messaging is in 29.273.
The SWm reference point shall be used to authenticate and authorize the UE.
The SWm reference point is also used to transport NBM (Network Based Mobility) related
mobility parameters in a case the UE attaches to the EPC via the S2b. As detailed in section
4.1 EAP-AKA and EAP-TLS are supported on SWm interface.
18
UE (EAP Peer) AAA
EAP Methods EAP Methods
EAP Message Exchange

EAP EAP EAP
DIAMETER
Supplicant ePDG
IKEv2
(EAP Authenticator)
DIAMETER Server
Message format
Below is summary of messages supported on SWm interface based on 3GPP TS 29.273
Command Remarks
1 Diameter-EAP-Request (DER) SWm Authentication & Authorization procedure
2 Diameter-EAP-Answer (DEA) SWm Authentication & Authorization procedure
3 Session-Termination-Request ePDG initiated Session Termination
(STR)
4 Session-Termination-Answer ePDG initiated Session Termination
(STA)
5 Abort-Session-Request (ASR) 3GPP AAA Initiated Session Termination
6 Abort-Session-Answer (ASA) 3GPP AAA Initiated Session Termination
3.2.2.1.1 Authentication and Authorization Request
The authentication and authorization procedure shall be used between the ePDG and 3GPP AAA
Server/Proxy. When a PDN connection is activated by the UE an IKEv2 exchange shall be initiated. It
shall be invoked by the ePDG, on receipt from the UE of a "tunnel establishment request" message.
This shall take the form of forwarding an IKEv2 exchange with the purpose of authenticating in order
to set up an IKE Security Association (SA) between the UE and the ePDG.
During the Access Authentication and Authorization procedure the ePDG may provide information
on its PMIPv6 or GTPv2 capabilities to the 3GPP AAA Server. The 3GPP AAA Server may perform IP
mobility mode selection between NBM or HBM. The 3GPP AAA Server may provide to the ePDG an
indication if either NBM or local IP address assignment shall be used. If NBM shall be used, the ePDG
then decides the S2b protocol variant to use.
Upon a successful authorization, when NBM is used, the 3GPP AAA server shall return NBM related
information back to the ePDG. This information may include the assigned PDN GW, UE IPv6 HNP
and/or UE IPv4-HoA.
The PDN Gateway identity is a FQDN and/or IP address of the PDN GW. If a FQDN is provided, the
ePDG shall derive it to IP address according to the selected mobility management protocol.
19
If DSMIPv6 is used, a single IKE SA is used for all PDN connections of the user. If PMIPv6 or GTPv2 is
used, a separate IKE SA is created for each PDN connection of the user
Each new additional IKE SA shall be handled in a different Diameter session. In such cases, the IP
mobility mode selected during the first authentication and authorization procedure is valid for all
PDN connections of the user, therefore, dynamic IP mobility mode selection is not executed during
the further procedures. The ePDG may select the same or different S2b protocol variant(s) towards
different PDN GWs when NBM has been selected.
The SWm reference point shall perform authentication and authorization based on the reuse of the
DER/DEA command set defined in Diameter EAP application, IETF RFC 4072 .
Command Remarks
1 Diameter-EAP-Request (DER) SWm Authentication & Authorization procedure
2 Diameter-EAP-Answer (DEA) SWm Authentication & Authorization procedure
3 Session-Termination-Request (STR) ePDG initiated Session Termination
4 Session-Termination-Answer (STA) ePDG initiated Session Termination
5 Abort-Session-Request (ASR) 3GPP AAA Initiated Session Termination
6 Abort-Session-Answer (ASA) 3GPP AAA Initiated Session Termination
Information Mapping to Cat. Description
element name Diameter AVP
User Identity User-Name M This information element shall contain the identity of the user. The
identity shall be represented in NAI form as specified in IETF RFC
4282 [15] and shall be formatted as defined in 3GPP TS 23.003 [14].
EAP payload EAP-Payload M This information element shall contain the encapsulated EAP
payload used for the UE - 3GPP AAA Server mutual authentication
Authentication Auth- M This information element shall indicate whether authentication only
Request Type Request- or authentication and authorization are required. It shall have the
Type value of AUTHORIZE_AUTHENTICATE.
APN Service- C This information element shall contain the Network Identifier part of
Selection the APN for which the UE is requesting authorization. This AVP shall
be present when the ePDG has received an APN from the UE in the
IKEv2 signalling.
Visited Visited- C This information element shall contain the identifier that allows the
Network Network- home network to identify the Visited Network.
Identifier (See Identifier This AVP shall be present if the ePDG is not in the UE's home
9.2.3.1.2) network i.e. the UE is roaming.
Access Type RAT-Type C This information element shall be present if the access type is known
by the ePDG. If present, it shall contain the non-3GPP access
network access technology type that is serving the UE.
Mobility MIP6- O This AVP shall be present, if the handling of any of the flags listed
features Feature- here requires dynamic (i.e. per user) handling for the VPLMN-
Vector HPLMN relation of the ePDG and 3GPP AAA Server. If present, the
AVP shall contain the mobility features supported by the ePDG.
Flags that are not relevant in the actual relation shall be set to zero.
If dynamic IP mobility mode selection is used, the
PMIP6_SUPPORTED flag and/or the GTPv2_SUPPORTED flag
shall be set by the ePDG if PMIPv6 and/or GTPv2 are supported.
PMIP6_SUPPORTED flag is defined in IETF RFC 5779 [2].
The MIP6_INTEGRATED flag shall be used to indicate to the 3GPP
AAA server that the ePDG supports IKEv2 based Home Agent
address discovery.
Supported Supported- O If present, this information element shall contain the list of features
Features Features supported by the origin host for the lifetime of the Diameter session.
(See 3GPP
TS 29.229
[24])
20
EAP payload EAP-Payload O If present, this information element shall contain the encapsulated EAP
payload used for UE - 3GPP AAA Server mutual authentication
Master- EAP-Master- C This IE shall contain keying material for protecting the communication
Session-Key Session-Key between the user and the ePDG. It shall be present when Result Code is set
to DIAMETER_SUCCESS.
Result code Result-Code / M This IE shall contain the result of the operation.
Experimental- The Result-Code AVP shall be used for errors defined in the Diameter Base
Result-Code Protocol or as per in NASREQ.
3GPP AAA Redirect-Host C This information element shall be sent if the Result-Code value is set to
Server Name DIAMETER_REDIRECT_INDICATION. When the user has previously been
authenticated by another 3GPP AAA Server, it shall contain the Diameter
identity of the 3GPP AAA Server currently serving the user. The node
receiving this IE shall behave as defined in the Diameter Base Protocol
(IETF RFC 3588 [7]). The command shall contain zero or more occurrences
of this information element. When choosing a destination for the redirected
message from multiple Redirect-Host AVPs, the receiver shall send the
Diameter request to the first 3GPP AAA Server in the ordered list received in
the Diameter response. If no successful response to the Diameter request is
received, the receiver shall send the Diameter request to the next 3GPP
AAA Server in the ordered list. This procedure shall be repeated until a
successful response is received from a 3GPP AAA Server.
Mobility MIP6-Feature- O This AVP shall be present if it was received in the authentication and
Capabilities Vector authorization request and the authentication and authorization succeeded/ It
shall contain the authorized mobility features. Flags that are not relevant in
the actual relation shall be set to zero.
The PMIP6_SUPPORTED flag and/or the GTPv2_SUPPORTED flag shall
be set to indicate that NBM (PMIPv6 or GTPv2) is to be used. The
ASSIGN_LOCAL_IP flag shall be set to indicate that a local IP address is to
be assigned.
The MIP6_INTEGRATED flag shall be set if a Home Agent address is
provided for IKEv2 based Home Agent address discovery. In the latter case
HA information for IKEv2 discovery is provided via the APN-Configuration
AVP.
APN-OI APN-OI- C This AVP shall indicate the domain name to replace the APN-OI in the non-
replacement Replacement roaming case or in the home routed roaming case when constructing the
PDN GW FQDN upon which it needs to perform a DNS resolution. See
3GPP TS 23.003 [3]. It shall only be included if NBM is used and the Result-
Code AVP is set to DIAMETER_SUCCESS.
APN and PGW APN- C This information element shall only be sent if the Result-Code AVP is set to
Data Configuration DIAMETER_SUCCESS.
The APN-Configuration is a grouped AVP, defined in 3GPP TS 29.272 [29].
When NBM is used, the following information elements per APN may be
included:
- APN
- APN-AMBR
- Authorized 3GPP QoS Profile
- User home IP Address (if static IPv4 and/or IPv6 is allocated to the UE's
subscribed APN)
- Allowed PDN types
- PDN GW identity (if the PDN connection was active in case of HO, or if
there is a static PDN GW allocated to the UE's subscribed APN)
- PDN GW allocation type
- VPLMN Dynamic Address Allowed
- Visited Network Identifier
When local IP address assignment is used, this AVP shall only be present if
IKEv2 based Home Agent discovery is used and
- if the PDN connection was active in case of HO, or
- if there is static PDN GW allocated to the UE's subscribed APN, or
In these cases, the following information elements shall be included:
- HA-APN
- PDN GW identity
21
Trace Trace-Info C This AVP shall be included if the subscriber and equipment trace has been
information activated for the user in the HSS and signalling based activation is used to
download the trace activation from the HSS to the ePDG.
Only the Trace-Data AVP shall be included to the Trace-Info AVP and
shall contain the following AVPs:
- Trace-Reference
- Trace-Depth
- Trace-Event-List
- Trace-Collection-Entity
The following AVPs may also be included in the Trace-Data AVP:
- Trace-Interface-List: if this AVP is not present, trace report generation is
requested for all interfaces listed in 3GPP TS 32.422 [32]
- Trace-NE-Type-List, with the only allowed value being "PDN GW (3)". If
this AVP is not included, trace activation in PDN GW is required.
MSISDN Subscription-ID C This AVP shall contain the MSISDN of the UE and shall be sent only if it is
available.
Session time Session- C If the authorization succeeded, then this IE shall contain the time this
Timeout authorization is valid for.
Permanent Mobile-Node- C This information element shall be present if NBM is used. It shall contain an
User Identity Identifier AAA/HSS assigned identity (i.e. IMSI in EPC root NAI format as defined in
3GPP TS 23.003 [14]) to be used by the MAG in subsequent PBUs as the
MN-ID identifying the user in the EPS network.
Serving GW MIP6-Agent- O This AVP shall be used only in chained S2b-S8 cases and it shall be sent
Address Info only if the Result-Code AVP is set to DIAMETER_SUCCESS.
UE Charging 3GPP- O This information element contains the type of charging method to be applied
Data Charging- to the user (see 3GPP TS 29.061 [31]).
Characteristics
Supported Supported- O If present, this information element shall contain the list of features
Features Features supported by the origin host for the lifetime of the Diameter session.
(See 3GPP TS
29.229 [24])
Table 7.1.2.1.1/2: Authentication and Authorization Answer
3.2.2.1.2 Authorization Procedures.

This procedure shall be used between the ePDG and 3GPP AAA Server and Proxy. It shall be invoked by the
ePDG, upon receipt of a valid Re-Authorization Request message from the 3GPP AAA Server.
This procedure shall be used by the ePDG to update the previously provided authorization parameters. This
may happen due to a modification of the subscriber profile in the HSS (for example, removal of a specific APN
associated with the subscriber, or change of the identity of a dynamically allocated PDN GW.This procedure is
mapped to the Diameter command codes AA-Request (AAR) and AA-Answer (AAA) specified in RFC 4005 .
Information element contents for these messages are shown in tables below. The ePDG knows if NBM is used
or if a local IP address is assigned based on the flags in the MIP6-Feature-Vector received during the initial
authentication and authorization procedure or based on preconfigured information. If the PMIP6_SUPPORTED
and/or the GTPv2_SUPPORTED flag are set in the MIP6-Feature-Vector received from the 3GPP AAA Server,
the ePDG knows that NBM is used

Permanent User-Name M This information element shall contain the identity of the user. The identity
User Identity shall be represented in NAI form as specified in IETF RFC 4282 [15] and
shall be formatted as defined in 3GPP TS 23.003 [14].
Request Type Auth-Request- M This information element shall contain the type of request. It shall have the
Type value AUTHORIZE_ONLY.
Table 7.1.2.2.1/1: SWm Authorization Request
22
User Identity shall be represented in NAI form as specified in IETF RFC 4282 [15], and
shall be formatted as defined in 3GPP TS 23.003 [14.]
Request Type Auth-Request- M It shall contain the value AUTHORIZE_ONLY. See IETF RFC 4072 [5].
Type
Registration Result-Code/ M This IE shall contain the result of the operation.
Result Experimental The Result-Code AVP shall be used for errors defined in the Diameter Base
Result Code Protocol or as per in NASREQ.
UE IPv4 Home PMIP6-IPv4- O If the authorization succeeded, and the user has an IPv4-HoA statically
Address Home-Address defined as part of his profile data, then this IE may be present. It shall
contain the IPv4-HoA allocated and assigned to the UE.
APN and PGW APN- C This information element shall only be sent if the Result-Code AVP is set to
Data Configuration DIAMETER_SUCCESS.
APN-Configuration is a grouped AVP, defined in 3GPP TS 29.272 [29].
When NBM is used, the following information elements per APN may be
included:
- APN
- APN-AMBR
- Authorized 3GPP QoS profile
- Statically allocated User IP Address (IPv4 and/or IPv6)
- Allowed PDN types
- PDN GW identity
- PDN GW allocation type
- VPLMN Dynamic Address Allowed
- Visited Network Identifier
When local IP address assignment is used, this AVP shall only be present if
IKEv2 based Home Agent discovery is used and
- if the PDN connection was active in case of HO, or
- if there is static PDN GW allocated to the UE's subscribed APN.
In these cases, the following information elements shall be included:
- HA-APN
- PDN GW identity
Trace Trace-Info C This AVP shall be included if the subscriber and equipment trace has been
information activated for the user in the HSS and signalling based activation is used to
download the trace activation from the HSS to the ePDG.
Only the Trace-Data AVP shall be included if trace activation is requested.

Only the Trace-Reference AVP shall be included if trace deactivation is
requested.
If the Trace-Data AVP is included, it shall contain the following AVPs:

- Trace-Reference
- Trace-Depth
- Trace-Event-List
- Trace-Collection-Entity
The following AVPs may also be included in the Trace-Data AVP:
- Trace-Interface-List: if this AVP is not present, trace report generation is
requested for all interfaces listed in 3GPP TS 32.422 [32]
- Trace-NE-Type-List, with the only allowed value being "PDN GW (3)". If
this AVP is not included, trace activation in PDN GW is required.
MSISDN Subscription-ID C This AVP shall contain the MSISDN of the UE and shall be sent only if it is
available.
UE Charging 3GPP- O If present, this information element shall contain the type of charging method
Data Charging- to be applied to the user (see 3GPP TS 29.061 [31]).
Characteristics
Session time Session- C If the authorization succeeded, then this IE shall contain the time this
Timeout authorization is valid for.
Table 7.1.2.2.1/2: SWm Authorization Answer
3.2.2.1.3 ePDG Initiated Session Termination Procedures
The SWm reference point allows the ePDG to inform the 3GPP AAA Server/Proxy about the termination of an
IKE_SA between UE and ePDG, and that therefore the mobility session established on the ePDG for all
associated PDN connections are to be removed.
23
The SWm Session Termination Request procedure shall be initiated by the ePDG to the 3GPP AAA Server which
shall remove associated non-3GPP Access information. The AAA Server shall then return the SWm Session
Termination Answer containing the result of the operation. These procedures are based on the reuse of
Diameter Base IETF RFC 3588 STR and STA commands
Table 7.1.2.3.1/1: SWm Session Termination Request

Element name Diameter AVP
Termination Termination- M This information element shall contain the reason for the disconnection.
Cause Cause
Table 7.1.2.3.1/2: SWm Session Termination Answer

Result Result-Code M This IE shall contain the result of the operation.
3.2.2.1.4 AAA Server Initiated Session Termination Procedures
The SWm reference point shall allow the 3GPP AAA Server to request the termination of an IKE_SA between
UE and ePDG, and therefore the termination of all mobility session established for all associated PDN
connections.
If the user has several accesses (IKE_SA) active at an ePDG, a separate Session Termination procedure shall be
initiated for each of them.
The procedure shall be initiated by the 3GPP AAA Server. This procedure is based on the reuse of NASREQ IETF
RFC 4005 ASR, ASA, STR and STA commands.
Table 7.1.2.4.1/1: SWm Abort Session Request

Auth-Session- Auth-Session- O If present, this information element indicates to the ePDG whether the 3GPP
State State AAA Server requires an STR message.
Table 7.1.2.4.1/2: SWm Abort Session Answer

Result Result-Code M This IE shall contain the result of the operation.
Table 7.1.2.4.1/3: SWm Session Termination Request

Termination- Termination- M This information element shall contain the reason why the
Cause Cause session was terminated. It shall be set to
"DIAMETER_ADMINISTRATIVE" to indicate that the
session was terminated in response to an ASR message.
Table 7.1.2.4.1/4: SWm Session Termination Answer

Result-Code Result-Code M This IE shall contain the result of the operation.
24
3.2.3 S2b
The S2b is the interface between ePDG and the PDN GW Function. The standard S2b interface can
be based upon PMIPv6 or GTP. For ePDG only GTP based S2b is supported.
The following illustration depicts control plane and user plane protocol stack for S2b.
IPv4/IPv6 IPv4/IPv6
GTP-C GTP-C
GTP-U GTP-U
IKEv2 IKEv2 UDP UDP

UDP UDP
IPv4/IPv6 IPv4/IPv6 IPv4/IPv6 IPv4/IPv6 IPSEC IPv4/IPv6

IPSEC IPv4/IPv6
IPv4/IPv6 IPv4/IPv6
L2/L1 L2/L1 L2/L1 L2/L1
L2/L1 L2/L1 L2/L1 L2/L1
S2b S2b
UE ePDG PGW-C
UE ePDG PGW-U
Control Plane User Plane
Figure 8: S2b Interface with ePDG and PGW
The following illustration depicts the relationship between IPSec tunnel on SWu and GTPu tunnels on
S2b with uplink and downlink filters. This behavior remains true for S2b interface between standalone
ePDG and P-GW. However with ePDG offering of co-hosted function, interaction between ePDG and
P-GW is highly optimized.
Figure 9: Two Unicast S2b bearers - GTP based S2b (Source: 3GPP 23.402 Rel
11)
On the S2b interface, a bearer uniquely identifies traffic flows that receive a common QoS treatment
between the ePDG and the PDN GW.
- All traffic mapped to the same bearer receive the same bearer level packet forwarding
treatment.
25
- The ePDG stores the uplink bearer traffic flow template (UL TFT) it receives from the
PGW (e.g. in the Create Bearer Request message) and does not forward them to the
WLAN UE.
- The ePDG routes uplink packets to the different bearers based on the uplink packet
filters in the TFTs assigned to the bearers in the PDN connection, similarly as what is
done by UE for uplink traffic under 3GPP access.
o If no match is found, the uplink data packet shall be sent via the bearer that does
not have any uplink packet filter assigned.
o If all bearers (including the default bearer for that PDN) have been assigned an
uplink packet filter, the ePDG shall discard the uplink data packet.
- The PGW uses the DL TFT for mapping traffic to a bearer in the downlink direction,
like done on GTP-based S5/S8.
- The ePDG releases the IPsec tunnel when the last active GTP tunnel of the associated
PDN connection to the PGW is released.
The ePDG function terminates IPsec tunnel on SWu interface. For each packet arriving on the SWu,
the ePDG, after applying the decryption keys, retrieves the inner IP Packet. This IP Packet is then
transmitted to P-GW through GTP-U tunnel. This requires additional GTP-U encapsulation of a
routable IP packet. On P-GW side, GTP-U header is stripped and local Policy is applied before routing
packet over SGi.
3.2.4 GTPv2-C
The basic GTPv2-C implementation compliant to path management, error handling as specified 3GPP
TS 29.274. Below is a summary of messages supported on S2b.
26
Message Initiator Triggered
Create Session request X
Create Session Response X
Delete Session Request X
Delete Session Response X
Echo Request X
Echo Response X
Modify Bearer Request X
Modify Bearer Response X
Modify Bearer Command X
Modify Bearer Failure Indication X
Trace Session Activation X
Trace Session Deactivation X
Create Bearer Request X X
Create Bearer Response X
Update Bearer Request X X
Update Bearer Response X
Delete Bearer Request X X
Delete Bearer Response X
Delete PDN Connection Set Request X
Delete PDN Connection Set X
Response
3.2.5 Create Session Request

The message is sent by the ePDG to the PGW as part of UE initiated initial attach or PDN connectivity
procedures in E-UTRAN.
Roaming Scenarios
PDN AAA HSS/

UE ePDG GW vPCRF Proxy hPCRF AAA
1. IKEv2 Authentication and Tunnel Setup

1. Authentication and Authorization
2. Create Session Request

3. IP-CAN Session Establishment
Procedure
4. Update PDN GW Address
5. Create Session Response
GTP Tunnel(s)
6. IPSec Tunnel Setup
Completion
7.IKEv2 (IP Address Configuration)
8. IPSec and GTP Tunnels

IPSec GTP Tunnel(s)
Figure 10: UE initial attach over non-3GPP access (Source: 3GPP TR 23.834)
ePDG supports following IEs in the Create Session Request message.

27
Information Element Presenc Description
e
IMSI C Included for all cases except emergency sessions
MSISDN C ePDG includes this IE, if MSISDN for UE is available
Serving Network C Identifier of serving network. Stored by the ePDG
RAT Type C The ePDG S2b profile will define the RAT type to specify
Indication Flags C ePDG supports following flags –

- Dual address bearer
Sender F-TEID for Control M

Plane
APN M Name of the APN.
Selection Mode C Selection Mode shall be set to “MS or network provided

APN, subscribed verified”
PDN Type C Indicates either IPv4, IPv6 or IPv4v6.

Determined UE request or Local policy
PDN Address Allocation (PAA) C The ePDG may receive a static IP address (i.e. a static IPv4
address and/or a static IPv6 prefix) from HSS/AAA during
IKEv2 tunnel establishment procedure. Then the ePDG
should forward the static IP address to the PDN GW.
If static IP address is not used, the IPv4 address shall be set
to 0.0.0.0, and/or the IPv6 Prefix Length and IPv6 prefix
and Interface Identifier shall all be set to zero
Types: IPv4, IPv6 or IPv4v6
APN-AMBR C Aggregate maximum bit rate assigned to the user for the
APN.
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.
Protocol Configuration Option C Protocol option are built based upon UE request during the
(PCO) IKEv2 exchange.
Bits 1-3 of Octet 5 shall be ‘000’ to indicate IP PDN.
28
e
The additional parameters list contains a list of special
parameters, each one in a separate container. The
type of the parameter carried in a container is
identified by a specific container identifier. Following
container identifiers are of interest to ePDG:
UE to Network direction:
-0001H (P-CSCF IPv6 Address Request);
-0002H (IM CN Subsystem Signalling Flag);
-0003H (DNS Server IPv6 Address Request);
-000BH (IPv4 address allocation via DHCPv4);
-000CH (P-CSCF IPv4 Address Request);
-000DH (DNS Server IPv4 Address Request);
When the container identifier indicates any of the

above mentioned values, the container identifier
contents field is empty and the length of container
identifier contents indicates a length equal to zero.
If the container identifier contents field is not empty, it
will be ignored by P-GW.
Bearer Contexts to be created M Indicates the bearers to be created. One bearer shall be
included for an E-UTRAN Initial Attach and UE requested
PDN Connectivity.
C This IE shall be included on the S4/S11 interface if an SGW
trace is activated, and/or on the S5/S8 and S S2a/2b
Trace Information
interfaces if a PGW trace is activated. See 3GPP TS 32.422
[18].
Recovery C Included if peer is being contacted for the first time

ePDG LDN O ePDG’s name. Included if ePDG contacting ePDG for the
first time. Stored by the ePDG in EPS bearer context
ePDG-FQ-CSID C This IE indicates support of partial failure restoration

procedures by the ePDG. Stored by the ePDG in the local
context
APCO O If multiple authentications are supported by the ePDG, the

ePDG shall include this IE on the S2b interface.
ePDG IP Address O It shall contain the ePDG IP address which is used as IKEv2
tunnel endpoint with the UE.
29
Bearer Context to be created within Create Session Request (all other IEs apart the ones that are
shown below within Bearer Context shall be ignored by the ePDG)
Octet 1 Bearer Context IE Type = 93 (decimal)

Octets 2 and 3 Length = n
Octet 4 Spare and Instance fields
Information P Condition / Comment IE Type
elements
EPS Bearer ID M EBI
S2b-U ePDG F- C This IE shall be included on the S2b interface for an F-TEID
TEID Attach with GTP on S2b, a UE initiated Connectivity
to Additional PDN with GTP on S2b and a Handover
to Untrusted Non-3GPP IP Access with GTP on S2b.
NOTE: For local PGW function ePDG shall apply

special handling described below.
Bearer Level QoS M Bearer QoS
3.2.6 Create Session Response

This message is sent by the PGW (local or external) to the ePDG in response to the Create Session
Request.
30
e
Cause M Indicates if the request was accepted or a
failure condition
PGW S5/S8/S2b F-TEID M Indicates the TEID allocated by the PGW.
PDN Address Allocation (PAA) C The PDN type field in the PAA is set to IPv4,
or IPv6 or IPv4v6 by the ePDG as the case
may be. If the DHCPv4 is used for IPv4
address allocation based upon UE’s request,
the IPv4 address field shall be set to 0.0.0.0
APN-AMBR C If the received value in CSR is modified by the
PGW using either Gx procedures or local
configuration
Bearer Contexts Created C Bearer contexts that are created w.r.t what was
requested in Create Session Request if the
request was successful
Recovery C Sent by PGW if contacting the ePDG for the
first time.
PGW LDN C Included if PGW contacting the ePDG for the
first time.
PCO C If the UE requested for P-CSCF IPv4 or IPv6
address then one address from the locally
configured list shall be provided to the UE.
If the UE requested DNS server IPv4 or IPv6

address then the DNS server address
configured in the APN shall be returned
If the UE requested DHCP server address then

the same as configured in the APN shall be
returned
PGW-FQ-CSID C Included if support for partial failure
restoration is enabled on the ePDG
Bearer Context Created within Create Session Response
Octets 1 Bearer Context IE Type = 93 (decimal)

Octets 4 Spare and Instance fields
elements
EPS Bearer ID M EBI
Cause M This IE shall indicate if the bearer handling was Cause
successful, and if not, it gives information on the
reason.
S2b-U PGW F- C This IE shall be included on the S2b interface during F-TEID
TEID the Attach with GTP on S2b, UE initiated
Connectivity to Additional PDN with GTP on S2b,
and Handover to Untrusted Non-3GPP IP Access
with GTP on S2b.
Note: For local ePDG function, ePDG shall make use

of fast path optimization to remove GTP-U.
Bearer Level QoS C This IE shall be included if the received QoS Bearer QoS
parameters have been modified with locally
configured values or by PCRF as the case may be.
31
3.2.7 Delete Session Request
This message is sent by the ePDG to PGW in as part of initial attach and UE requested PDN
disconnection.
Roaming Scenarios
PDN AAA HSS/

UE ePDG vPCRF hPCRF
GW Proxy AAA
1. IKEv2 tunnel
release trigger
2. Delete Session Request

3. Update PDN GW Address
4. PCEF-Initiated IP-CAN Session

Termination Procedure
5. Delete Session Response
6. Non-3GPP specific
resource release procedure
Figure 11: UE/ePDG initiated detach procedure (Source: 3GPP TR 23.834)
Linked bearer id is the only IE that is applicable in the delete session request message.

e
Linked EPS Bearer ID (LBI) C This IE is included to indicate the default
bearer associated with the PDN being
disconnected
3.2.8 Delete Session Response

This message is sent by the PGW to ePDG in in response to Delete Session Request.
Information Element Presence Description

Cause M Indicates if the session deletion is successful or
a failure
Recovery C Included if contacting the SGW/ePDG for the
first time (e.g after the restart)
32
3.2.9 Modify Bearer Request
The Modify Bearer Request message is sent on the on the S2b interface by the ePDG to the
PGW as part of the UE initiated IPsec tunnel update procedure
3.2.10 Modify Bearer Response

The message is sent by the PGW to the ePDG in response to the Modify Bearer Request
3.2.10 Modify Bearer Command

This message is sent by the ePDG to the ePDG as part of the HSS Initiated Subscribed QoS
Modification procedure.

APN-AMBR M Aggregate max bit rate of the user in the APN.
Bearer Contexts M Contains bearer information for modification.
It contains the default bearer Id and bearer
QoS.
Bearer Context within Modify Bearer Command

elements
EPS Bearer ID M This IE shall contain the default bearer ID. EBI
Bearer Level QoS C Mandatory if other parameters than the APN-AMBR Bearer QoS
have been changed
C This IE shall also be included when QCI and ARP
O have not been changed and if the SQCI flag is set to
1 in the Context Response message.
3.2.11 Modify Bearer Failure Indication

This message is sent in response to Modify Bearer Command by the PGW to the ePDG as part of
failure of HSS Initiated Subscribed QoS Modification procedure. This indicates that the EPS bearer
hasn’t been updated

Cause M Indicates successful outcome or the cause for
failure
Recovery C Sent if the peer is being contacted for the first
time
3.2.12 Trace Session Activation

The Trace Session Activation message shall be sent on S2b by ePDG to PGW when session trace is
activated for a particular IMSI for a UE that is attached and active or attached and idle.
33
IMSI C ePDG OAM shall provide the IMSI for which
tracing is required
Trace Information M
Trace Information is coded as depicted below. For details on trace information see 3GPP TS 32.422.
Bits
Octets 8 7 6 5 4 3 2 1
1 Type = 96(decimal)
2 to 3 Length = n
4 Spare Instance
5 MCC digit 2 MCC digit 1
6 MNC digit 3 MCC digit 3
7 MNC digit 2 MNC digit 1
8 to10 Trace ID
11 to 19 Triggering Events
20 to 21 List of NE Types
22 Session Trace Depth
23 to 34 List of Interfaces
35 to (n+4) IP Address of Trace Collection Entity
Figure 12: Trace Information IE TS 32.422
The above IE must be filled as specified by operator through ePDG OAM in compliance with section 5
of 3GPP TS 32.422
3.2.13 Trace Session Deactivation

The Trace Session Deactivation message shall be sent on S2b by ePDG to PGW when session trace
is deactivated for a particular IMSI for a UE that is attached and active or attached and idle.

Trace Reference M
3.2.14 Create Bearer Request

This message is sent from PGW to ePDG as part of the Dedicated bearer activation over G2b.

e
Linked Bearer Identity (LBI) M Indicates the default EPS bearer associated
with the PDN connection
Bearer Contexts M Contains bearer information including
dedicated EPS bearer Id and bearer level QoS
PGW-FQ-CSID C Included if partial failure restoration on ePDG

is enabled
34
Bearer Context within Create Bearer Request
Octets 1 Bearer Context IE Type = 93 (decimal)

Octets 4 Spare and Instance fields
elements
EPS Bearer ID M This IE shall be set to 0. EBI
TFT M This IE contains uplink packet filters to be sent to the Bearer TFT
UE
S2b-U PGW F- C This IE shall be sent on the S2b interface F-TEID
TEID
Bearer Level QoS M As received from PCRF or as configured locally on Bearer QoS
the ePDG
3.2.15 Create Bearer Response
This message is sent by the ePDG to the PGW in response to Create Bearer Request.
Cause M Indicates if the bearer creation is successful or

a failure
Bearer Contexts C Contains bearer information that was created
Recovery C Included if the SGW is contacting the ePDG

for the first time (e.g. after the restart)
ePDG-FQ-CSID C This IE shall be included by the ePDG on the

S2b interface according to the requirements in
3GPP TS 23.007
35
3.2.16 Update Bearer Request
The message is sent by the PGW to the ePDG as part of
- bearer modification procedure with updated QoS
- HSS Initiated Subscribed QoS Modification
- PGW Initiated Bearer Modification without Bearer QoS Update
- Update of P-CSCF list

e
APN-AMBR M Aggregate max bit rate for the user in the APN,
if modified from last reported value
Protocol Configuration Options C PCO shall be included if there is corresponding

(PCO) updated information (e.g updated list of P-
CSCF address)
Bearer Contexts M Contains bearer information for modification.

If no bearer QoS update is requested then only
one IE of this type is present.
PGW-FQ-CSID C Included if partial failure restoration support on

ePDG is enabled
Bearer Context within Update Bearer Request

elements
EPS Bearer ID M Bearers that could not be deleted EBI
TFT C Included if TFT change is needed Bearer TFT
Bearer Level QoS C This IE shall be included if QoS modification is Bearer QoS
requested
3.2.17 Update Bearer Response

This message is sent by the ePDG to PGW in in response to Update Bearer Request.
Cause M Indicates if the bearer creation is successful or

a failure
Bearer Contexts M This IE contains contexts related to bearers for

which QoS/TFT modification was requested.
Several IEs with this type and instance values
shall be included as necessary to represent a
list of Bearers
Protocol Configuration Options C

(PCO)
Recovery C
36
ePDG-FQ-CSID C Included if ePDG support partial failure

restoration. Stored by the ePDG
Bearer Context within Update Bearer Response

elements
EPS Bearer ID M Bearers that were requested to be updated EBI
Cause M Indicate the success or failure of bearer update Cause
3.2.18 Delete Bearer Request

The request is sent by the PGW to the ePDG to deactivate certain dedicated bearers or all the
bearers of a PDN connection. The message shall also be sent on the S2b interface by the PGW to the
ePDG as part of PGW Initiated Bearer Resource Allocation Deactivation procedure with GTP on S2b

e
Linked EPS Bearer ID (LBI) C Indicates the default bearer of the PDN
connection and it is included when all bearers
need to be deleted
EPS Bearer IDs C Indicates the dedicated bearer.
PGW-FQ-CSID C Included if partial failure restoration support on

ePDG is enabled
Cause C Included in case of handover from 3GPP to

non 3GPP access and vice versa
Bearer Context within Delete Bearer Request

elements
EPS Bearer ID M Bearers that could not be deleted EBI
Cause M The reason of the unsuccessful handling of the Cause
bearer.
3.2.19 Delete Bearer Response

The request is sent by the SGW/ePDG to ePDG in response to Delete Bearer Request.

Cause M Indicates successful outcome or the cause
for failure.
37
Recovery C Sent if the peer is being contacted for the
first time
3.2.20 Delete PDN Connection Set Request
The request is sent by the PGW to the ePDG in connection with the restoration procedures specified in
3GPP TS 23.007.

e
PGW-FQ-CSID C Included when ePDG reports a partial fault in
line with TS 23.007
3.2.21 Delete PDN Connection Set Response

The request is sent by the ePDG to the PGW in connection with the restoration procedures specified in
3GPP TS 23.007. TEID of 0 shall be used in the message.

e
Cause M Indicates successful outcome or a failure.
A value of "Request Accepted" indicates the
receiving node was capable of storing a CSID
value for each PDN connection for the type of
node (ePDG) in the Delete PDN Connection
Set Request and has marked, or will mark
immediately, the PDN connections for deletion
3.2.22 GTPv1-U
GTP-U Tunnels are used to carry encapsulated T-PDUs and signaling messages between a given
pair of GTP-U Tunnel Endpoints. The Tunnel Endpoint ID (TEID) which is present in the GTP header
shall indicate which tunnel a particular T-PDU belongs to. In this manner, packets are multiplexed and
de-multiplexed by GTP-U between a given pair of Tunnel Endpoints. The TEID value to be used in the
TEID field is signaled to the peer GTP-U entity using GTPv2-C. TEID is also used for multiplexing or
de-multiplexing data between GTP-U endpoints
The inner IP packet in a GTPv1-U packet (T-PDU) is either
- An IP packet sent to the UE in the downlink direction over one or more tunnels from the
external PDN identified by the APN.
- An IP packet sent by a UE in the uplink direction over one or more tunnels to the external
PDN
Echo Request and Path management

The ePDG shall initiate Echo request on its own periodically and shall be able to respond to Echo
requests received from the peer
38
Echo Response
The ePDG shall send Echo response to PGW with a Recovery IE containing the local restart counter.
Error Indication
The ePDG supports receiving and sending Error Indication message.
The TEID and GTP-U peer Address together uniquely identify the related EPS
bearer in the ePDG.
Information element Presence requirement

Tunnel Endpoint Identifier Data I Mandatory
GTP-U Peer Address Mandatory
3.3 MOBIKE - IKEv2 Mobility and Multihoming Protocol

For a seamless handover between two untrusted non 3GPPP accesses, the RFC 4555 defines
extensions to IKEv2 that enable an efficient management of IKE and IPsec Security Associations
when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over
time. The MOBIKE updates only the outer transport IP address of the Security association. The ePDG
side addresses and traffic selectors used inside remains the same. This enables to keep mobility
transparent to the applications. The MOBIKE requires the initiator to detect the mobility event and
take action.
39
Untrusted non-3GPP Untrusted non-3GPP
UE Access #1 Access #2 ePDG P-GW
IKE SA Establishment
IP1 (IKE_AUTH with MOBIKE_SUPPORTED) IPePDG
GTP-u Tunnel
IP1 IPsec Tunnel
Mobility Event Detected.

Layer-2 Disassociation
Layer-2 association with non-3GPP Access Point #2
IP Layer
Reconfiguration
IP3 INFORMATIONAL Request/Response (UPDATE_SA_ADDRESSES) IPePDG

Return
Routability
Check
IP3 INFORMATIONAL Request/Response (COOKIE2) IPePDG
GTP-u Tunnel
IP3 IPsec Tunnel
Figure 13: MOBIKE Supported UE handover between two non-3GPP Access

points
A brief description of the steps involved in MOBIKE assisted UE mobility on non-3GPP access.
1. In the UE initiated IKE SA, UE must indicate support for MOBIKE in IKE_AUTH message. And
responder (ePDG) shall indicated MOBIKE_SUPPORTED if configured to do so.
a. In addition to MOBIKE_SUPPORTED, UE may inform ePDG about additional IP
address it may or may not have by indicating ADDITIONAL_IP*_ADDRESSES (* can be
4 or 6) or NO_ADDITIONAL_ADDRESSES respectively.
b. The IKE and IPsec SAs are established between IP1 and IPePDG.
2. The UE shall detect the event of disconnection from non-3GPP Access Point #1.
3. And eventually UE shall attach to another non-3GPP Access Point #2. The Access Point #2
shall issue a new transport IP address to the UE.
Note: For deployment the interval between disconnection from AP#1 and re-connection to
AP#2 has to be under the IPsec tunnel inactivity timeout. In case where IPsec tunnel inactivity
is kicked in on ePDG, it will delete the security association. And UE will end up establishing
new IKE/IPsec SA.
4. The UE will then send INFORMATIONAL exchange request with UPDATE_SA_ADDRESSES
Notify payload using new IP address (IP2).
5. The ePDG shall respond to the INFORMATIONAL exchange request with Notify payload
including NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP.
40
6. The ePDG shall immediately initiate return routability check by issuing INFORMATIONAL with
COOKIE2 in Notify payload.
7. In order to complete the routability check, the UE must respond to the INFORMATIONAL
request by copying the COOKIE2 in response.
8. On completion of routability check, ePDG shall start using IP2 instead of IP1 for the UE.
3.4 IMSI Filtering and Blacklisting
During the IKEv2 Security Association establishment, the UE provides its identity in the IDi payload of
the IKE_AUTH message. It is possible that attacker generate valid SA_INIT message with cookie and a
subsequent IKE_AUTH with invalid Idi to overload IKE service and AAA. The operator network can
easily be protected against such attacks by filtering our invalid identities. The UE identity must be in
NAI format of username@realm. The username field contains IMSI preceded by “1” or “0”
depending upon EAP-SIM or EAP-AKA is used for the authentication (assuming full authentication is
used).
The ePDG shall check for presence of IDi payload in the first IKE_AUTH message from UE.
 If IDi payload is absent, ePDG shall reject the IKE session with notify message type
AUTHENTICATION_FAILED
 The ID type within IDi must match the operator specified “IdentityType” in the IKEv2
Service Profile. Otherwise terminate session with notify message type
AUTHENTICATION_FAILED in IKE_AUTH response.
 The ePDG shall terminate IKE Session with AUTHENTICATION_FAILED, if identity

does not match the specified ID type. For example: Identity of type
ID_RFC822_ADDR must be RFC822 compliant.
 The ePDG shall apply IMSI filtering only for ID type of ID_RFC822_ADDR.
 The ePDG shall not apply IMSI filtering if selected AUTH method for ePDG service is
anything other than EAP-AKA/EAP-AKA` or EAP-SIM.
 If IMSI filtering is enabled, the ePDG shall first perform “Fast Re-auth” Prefix check.
 If IMSI filtering is enabled and the username prefix does not match the “Fast Re-
auth” prefix, the following must be checked (in case of failure send IKE_AUTH
response with AUTHENTICATION_FAILED)
i. The username must be numeric digits.
ii. The username must be 15 digits or 16 digits long.
iii. The username must start with numeric ‘0’ or ‘1’.
iv. The MCC and MNC in the username must match one of the configured IMSI
filter pairs and also match the MCC/MNC in the realm part.
Operator can also provision IMSIs that need to be blacklisted so that access is denied on ePDG.
3.5 PGW Selection
The PDN Gateway selection function on ePDG interacts with the 3GPP AAA Server or 3GPP AAA
Proxy and uses subscriber information provided by the HSS to the 3GPP AAA Server. During the
41
initial authorization, PDN Gateway selection information for each of the subscribed PDNs is returned
to the ePDG or the Trusted Non-3GPP Access Network. The PDN Gateway selection information
includes:
- The PDN GW identity, which is a logical name (FQDN) or IP address and an APN; or
- An APN and an indication whether the allocation of a PDN GW from the visited PLMN is
allowed or a PDN GW from the home PLMN shall be allocated.
In the case that a UE already has assigned PDN Gateway(s), the PDN GW identity for each of the
already allocated PDN Gateway(s), as well as information that identifies the PLMN in which the PDN
GW is located, are returned by the 3GPP AAA Server or Proxy during the authorization step. This
eliminates the need to repeat PDN Gateway selection for the PDNs the UE is already connected with.
For the PDNs the UE is already connected with transfer of PDN GW information takes place as
defined below:
If a UE attaches to a non-3GPP access and it already has assigned PDN Gateway(s) due to a previous
attach in a 3GPP access, the HSS provides the PDN GW identity, as well as information that identifies
the PLMN in which the PDN GW is located, for each of the already allocated PDN Gateway(s) with
the corresponding PDN information to the 3GPP AAA server over the SWx reference point.
The HSS receives the PDN GW identity for each of the selected PDN GWs and the corresponding PDN
information for a given UE, from both the 3GPP AAA Server and also from the MME/S4-SGSN,
depending on the currently in-use access. The HSS is responsible for the storage of the selected PDN
GW
DNS resolution for PGW address is achieved via static or dynamic configuration and this is
configurable on ePDG by the operator.
- Static
Under static mode, the PGW is already know the ePDG via ePDG configuration.
- Dynamic
For Dynamic mode, ePDG determines the P-GW for a given APN via the DNS.
UE ePDG DNS Proxy DNS
1) APN
2) APN FQDN to DNS Proxy

3) DNS Query
4) DNS Query Response

5) ‘S’ Records with service params
6) DNS SRV Query (with replacement string)

7) DNS Query
8) DNS Response
9) Hostname List
10) A/AAAA Query

11) DNS Query
12) DNS Query Response
13) PDN GW Address
Figure 14: Dynamic PGW Selection by ePDG
The ePDG P-GW Dynamic selection will involve following steps:
42
o Using the APN provided by UE, ePDG shall send a S-NAPTR query to the DNS Proxy.
The APN-FQDN will be the Application-Unique String of format
 <APN-NI>.apn.epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org
o DNS will respond with NAPTR resource records. This may include multiple NAPTR
resource records with ‘S’ flag for SRV records with the same or different service
parameters.
o ePDG shall select the replacement string (APN) that matches the service parameter
‘x-3gpp-pgw:x-s2b-gtp’. ePDG shall then perform SRV query for each of the selected
replacement strings.
o DNS provides the SRV response to the ePDG with the target strings.
o ePDG shall perform an A/AAAA query with the selected P-GW FQDN to receive the P-
GW IP address.
o Note: For more details refer to 3GPP TS 29.303 Rel11
The ePDG supports weight based load balancing of P-GW. For weight based load balancing, ePDG
shall maintain list of P-GW hostnames returned in DNS response for a given APN.
o In the NAPTR response, if there are multiple entries with same priority then the
session distribution shall be as per the weight parameter. ePDG shall use the weight
parameter to for proportionate distribution of the traffic. That is, higher the weight
higher is the probability of selection for traffic.
# host -t NAPTR example.com

example.com NAPTR 10 100 "S" "SIP+D2U" "" _sip._udp.example.com.
example.com NAPTR 20 100 "S" "SIP+D2T" "" _sip._tcp.example.com.
example.com NAPTR 30 100 "S" "E2U+email" "!^.*$!mailto:info@example.com!i"
_sip._tcp.example.com.
If the selected P-GW does not respond ePDG shall move to next P-GW form the list. ePDG supports
extended DNS RFC 2671 in order to handle DNS responses greater than 512 bytes and also support
DNS over TCP.
3.6 Multiple PDN Support
The multiple PDN feature allows the UEs to simultaneously establish multiple PDN connections
towards the P-GW. Each PDN connection results in a separate IKE and IPsec security association
between the UE and the ePDG. The ePDG shall allow establishment of simultaneous PDN
connections to different APNs. IPv4, IPv6 and IPv4v6 are the supported PDN connection types. ePDG
shall not allow multiple PDN connections from the same UE to the same APN. For example, UE shall
not be able to establish two IPv4 PDN connections to same APN. However UE shall be able to
establish separate IPv4 and IPv6 PDN to same APN. For UEs with existing PDN connection in a given
APN, any subsequent connection attempt by that UE to the same PDN and APN shall result in
deletion of the previous session before the new session gets established.
3.7 MAPCON – Multi Access PDN Connectivity

As described in 4.6 where UE has multiple PDN connection to different APNs in same access (Wi-Fi),
for MAPCON, the UE shall try to simultaneously connect to different APNs through different access
43
networks if the home network supports such simultaneous connectivity. The UE determines that the
network supports such simultaneous connectivity over multiple accesses if the UE is provisioned
with or has received per-APN inter-system routing policies from the home network through the
ANDSF node.
*ANDSF is out of scope as in not part of ePDG. Information below is just for understanding
The ANDSF contains data management and control functionality necessary to provide network
discovery and selection assistance data as per operators' policy. The ANDSF shall respond to UE
requests for access network discovery information (pull mode operation) and may be able to initiate
data transfer to the UE (push mode operation), based on network triggers or as a result of previous
communication with the UE.
ANDSF provides different policies
 Inter System Mobility Policy - The Inter-System Mobility Policy (ISMP) is a set of
operator-defined rules that affect the inter-system mobility decisions taken by the
UE. The UE uses the inter-system mobility policy when it can route IP traffic only
over a single radio access interface at a given time
 Inter System Routing Policy - The Inter-System Routing Policy (ISRP) is a set of
operator-defined rules that determine how the UE should route IP traffic across
multiple radio access interfaces. The ANDSF may provide a list of ISRP rules to the UE
independently of the UE capability to route IP traffic simultaneously over multiple
radio access interfaces. The UE uses the ISRP rules when it can route IP traffic
simultaneously over multiple radio access interfaces
 Inter APN Routing Policy - The Inter-APN Routing Policy (IARP) is a set of operator-
defined rules that determine which traffic should be routed across different PDN
connections and which traffic should be non-seamlessly offloaded to WLAN .These
rules can be provisioned by the H-ANDSF only. If the UE receives IARP rules from the
V-ANDSF, the UE shall ignore them. An Inter-APN routing capable UE selects an
existing IP interface to route IP flows based on the received / provisioned IARP rules
and user preferences. This IP interface is either associated with a specific APN or is
used for non-seamless WLAN offload (NSWO).
 WLAN Selection Policy - The WLAN Selection Policy (WLANSP) is a set of operator-
defined rules that determine how the UE selects and reselects a WLAN access
network. The UE may be provisioned with WLANSP rules from multiple PLMNs.
The information provided by ANDSF may also be statically pre-configured by the operator on the UE. The
information provided to the UE by the ANDSF take precedence over the corresponding information pre-
configured by the operator on the UE.
3.8 IPFOM – IP Flow Mobility
IPFOM is the mechanism allowing UE to simultaneously connect to 3GPP access and WLAN and
exchange different IP flows belonging to the same PDN connection through different accesses. The
mechanism also enables seamless IP flow mobility, with IP flows belonging to the same or different
applications being moved seamlessly between a 3GPP access and WLAN. This allows the operator to
indicate how the IP flows are routed through the available access systems and to selectively offload
some traffic (e.g. best effort traffic) to WLAN while using UTRAN or E-UTRAN for other traffic (e.g.
traffic with specific QoS requirements). This is usually referred to as WLAN offload. The UE attaches
separately to 3GPP access and wifi access before triggering IFOM.
44
Trusted GERAN Roaming Scenario
-
non-3GPP IP UTRAN/
PDN GW/ AAA vPCRF HSS/ hPCRF
Access/PDG/ EUTRAN
HA Proxy AAA
UE ePDG
1. WLAN link establishment and IP address assignment
2. HA discovery, DSMIPv6 bootstrapping and Home Link Detection
3. Binding Update
4. IP-CAN session modification request
5. IP-CAN session modification response

6. Binding Acknowledgement
7. GW control session and QoS rules provision procedure
8. 3GPP resource release
The signaling flow above shows the particular case where the UE is first connected to a 3GPP access
and then it requests addition of a WLAN access.
1. The UE discovers a WLAN and connects to it and configures an IPv4 address and/or an IPv6
address/prefix.
2. The UE performs HA discovery, DSMIPv6 bootstrapping and DSMIPv6 home link detection
procedure unless already performed in the 3GPP access.
3. The UE sends a DSMIPv6 Binding Update (HoA, CoA, Lifetime, BID, FID, flow description)
message to the HA over the WLAN access. The UE may include the requested routing rules via
the FID mobility option with both the routing filters and the BID (which includes the routing
address) as specified in IETF RFC 5555, IETF RFC 5648 and RFC 6089. The UE can include more
than one routing rule by including multiple FID mobility options in the Binding Update. The
DSMIPv6 Binding Update also contains an indication which indicates that the home link (3GPP
access) is still connected and also the BID mobility options which identify that one binding is
associated with the home address (3GPP access) and the other with the Care-of-Address from
45
the WLAN access. The UE also indicates in the Binding Update which is the default binding
where the HA should route packets not matching any FID as specified in RFC 6089.
4. In case the HA function is located in the PDN GW and dynamic PCC is deployed, the PDN GW
sends an IP-CAN session modification request to the PCRF. In this request, the PDN GW
provides the updated routing rules to the PCRF. The PCRF stores the mapping between each
SDF and its routing address.
5. If the HA function is located in the PDN GW, based on the successful establishment of
resources at the BBERF, the PCRF sends an acknowledgement to the PDN GW, including
updated PCC rules if appropriate.
6. The HA creates a DSMIPv6 binding, installs the IP flow routing rules and sends a Binding
Acknowledgment (Lifetime, HoA, CoA, BID, FID) as specified in RFC 5555 , RFC 5648 and
RFC 6089 , to indicate which routing rules requested by the UE are accepted.
The PDN GW may send message 6 before receiving the reply from PCRF in message 5.
7. Based on the IP-CAN session modification request (if step 4 was performed), the PCRF ensures
that the relevant QoS rules for the SDFs are installed in the target BBERF. This is done by a GW
control session and QoS rules provision procedure as specified in TS 23.203 .
8. In case the HA function is located in the PDN GW, appropriate 3GPP resource release
procedures are executed for the resources associated with the flows that were moved away
from the 3GPP source access. This procedure may be triggered by the PCRF via a GW control
session and QoS rules provision procedure if PMIPv6 is used on S5 and it may be triggered by
the PDN GW in case GTP is used on S5.
3.9 DSCP Marking

The Class of Service (CoS) makes use of Priority Code Point (PCP) field in the Ethernet frame of VLAN
tagged frames.
Figure 15: User Priority field in the 802.1Q VLAN Tag
The ePDG supports CoS marking of uplink traffic as per QCI to QoS mapping defined in Table 6.1.7 of
23.203 Release 11.
Following is the QCI to QoS mapping defined the 3GPP TS 23.203 V11
46
Figure 16: 3GPP TS 23.203 V11 Table 6.1.7
The eight different class of services are listed below:
PCP Priority Acronym Traffic Types

1 0 (lowest) BK Background
0 1 BE Best Effort
2 2 EE Excellent Effort
3 3 CA Critical Applications
4 4 VI Video, < 100 ms latency and jitter
5 5 VO Voice, < 10 ms latency and jitter
6 6 IC Internetwork Control
7 7 (highest) NC Network Control
The ePDG supports DSCP marking of IP header of the data traffic over the SWu and S2b interface.
For uplink traffic on S2b, DSCP marking shall be performed as per QCI-to-QoS mapping table.
This TOS field marking shall only be of the outer IP header and not the subscriber data.
3.10 P-CSCF Discovery

For P-CSCF reporting to UE, ePDG shall make use of IETF draft “3GPP IMS Option for IKEv2
draft-gundavelli-ipsecme-3gpp-ims-options-02” (http://tools.ietf.org/html/draft-gundavelli-ipsecme-
3gpp-ims-options-02)
This draft adds two new configuration attributes for requesting and transporting IPv4/IPv6 P-CSCF
address. ePDG supports configuration attribute P-CSCF_IP4_ADDRESS and P-CSCF_IP6_ADDRESS.
The ePDG supports UE requesting P-CSCF_IP4_ADDRESS or P-CSCF_IP6_ADDRESS in initial IKE_AUTH.
In such scenario, ePDG shall provide P-CSCF_IP4_ADDRESS and/or P-CSCF_IP6_ADDRESS in final
IKE_AUTH response.
3.11 Multiple Identity Support
47
For operators requiring ePDG to support multi PLMNS, configuration requires a separate certificate
per FQDN. To enable this Mavenir ePDG supports fetching multiple FQDN and multiple certificates.
3.12 Multiple Authentication and Fast Re-authentication

Support
IKEv2 [IKEv2] supports several mechanisms for parties involved in the IKE_SA (IKE security
association). These include signatures with public-key certificates, shared secrets, and Extensible
Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these
mechanisms to authenticate itself. However, there are scenarios where making the authorization
decision in IKEv2 (whether to allow access or not) requires using several of these methods.
For instance, it may be necessary to authenticate both the host (machine) requesting access, and the
user currently using the host. These two authentications would use two separate sets of credentials
(such as certificates and associated private keys) and might even use different authentication
mechanisms. If both peers support this extension, either of them can announce that it wishes to
have a second authentication by including an ANOTHER_AUTH_FOLLOWS notification in any
IKE_AUTH message that contains an AUTH payload. This indicates that the peer sending the
ANOTHER_AUTH_FOLLOWS wishes to authenticate another set of credentials to the other peer. The
next IKE_AUTH message sent by this peer will contain a second identity payload (IDi or IDr) and
starts another authentication exchange. The IKE_AUTH phase is considered successful only if all the
individual authentication exchanges complete successfully.
ePDG provides a configurable (on/off) support for Multiple Authentication as described in RFC 4739.
When support is enabled ePDG communicates the support in the Notify payload of SA_INIT
Response. On reception of another initiator identity (IDi) payload from UE, ePDG shall initiate further
procedure based on authentication mode required by P-GW/external AAA. Two authentication
modes required to be supported are: PAP and CHAP
48
External
UE ePDG P-GW
AAA
IKE SA_INIT
SA_INIT
[…, MULTIPLE_AUTH_SUPPORTED]
IKE_AUTH request
(…, MULTIPLE_AUTH_SUPPORTED)
UE Authentication by ePDG/3GPP AAA
IKE_AUTH Request
(…, ANOTHER_AUTH_FOLLOWS)
IKE_AUTH Response
[AUTH]
IKE_AUTH Request
[IDi]
IKE_AUTH Response
[EAP-GTC Request,...]
IKE_AUTH Request
[EAP-GTC Response, ...] Create Session Request
[APCO,...] Access-Request
[User-name, User-Password]
Create Session Response Access Accept

IKE_AUTH Response [APCO,...]
[EAP-Success,...]
IKE_AUTH Request
IKE_AUTH Response
IPsec ESP
Figure 17: Multiple Authentication Support for PAP over S2b
. UE initiates another round of authentication by indicating

ANOTHER_AUTH_FOLLOWS in Notify payload
a. On reception of ANOTHER_AUTH_FOLLOWS from UE, ePDG shall start
collecting additional parameter before raising CSR to P-GW.
b. The UE must send new IDi payload with identity to be used for secondary
authentication.
c. For PAP authentication support, ePDG shall send EAP-GTC (Generic Token
Card) request to the UE. The EAP-GTC is as per RFC 2284.
d. On receiving EAP-GTC response from UE, ePDG shall include the user-name
and user-password in APCO IE of CSR.
e. PGW on reception of CSR with APCO will execute PAP authentication with
the external AAA.
f. On success, P-GW shall return Create Session Response with APCO. On any
failure response, ePDG shall teardown the IKE SA with
AUTHENTICATION_FAILED error code.
For PAP Authentication Mode, following steps must be performed
49
External
UE ePDG P-GW
AAA
IKE SA_INIT
SA_INIT
[…, MULTIPLE_AUTH_SUPPORTED]
IKE_AUTH request
(…, MULTIPLE_AUTH_SUPPORTED)
UE Authentication by ePDG/3GPP AAA
IKE_AUTH Request
(…, ANOTHER_AUTH_FOLLOWS)
IKE_AUTH Response
[AUTH]
IKE_AUTH Request
[IDi]
IKE_AUTH Response
[EAP MD5-Challenge Request,...]
IKE_AUTH Request
[EAP MD5-Challenge Response, ...] Create Session Request
Access-Request
[APCO,...]
[User-name, CHAP-Password, CHAP-
Challenge]
Access Accept
Create Session Response
IKE_AUTH Response [APCO,...]
[EAP-Success,...]
IKE_AUTH Request
IKE_AUTH Response
IPsec ESP
Figure 18: Multiple Authentication Support for CHAP over S2b
g. UE initiates another round of authentication by indicating

ANOTHER_AUTH_FOLLOWS in Notify payload
h. On reception of ANOTHER_AUTH_FOLLOWS from UE, ePDG shall start
collecting additional parameter before raising CSR to P-GW.
i. The UE must send new IDi payload with identity to be used for secondary
authentication.
j. For CHAP authentication support, ePDG shall send EAP MD5 challenge
request to the UE. The EAP MD5 is as per RFC 2284.
k. On receiving EAP MD5 response with hash of user’s password, ePDG shall
include the user-name, CHAP-password and CHAP-challenge in APCO IE of
CSR.
l. PGW on reception of CSR with APCO will execute CHAP authentication with
the external AAA.
m. On success, P-GW shall return Create Session Response with APCO. On any
failure response, ePDG shall teardown the IKE SA with
AUTHENTICATION_FAILED error code.
50
4 Performance Monitoring and KPI
4.1 EMS
CLI (over SSH) UAG

Operator UAG
console
Management
Interface
EMS
DB
HTTP(S) Policy
Management
TRL
3rd Party OSS

UAG Management Syslog SNMP CDR
(SOAP/XML/SNMP)
Figure 19 EMS
The EMS has following capabilities:
1. Policy Build and Implement

2. Software update
3. Syslog
4. Alarm Management
5. TRL/CDRs
6. SNMP
7. Web Services
8. License Management
9. Real time session monitoring
51
4.2 EMS Client Portal
Figure 20 EMS GUI
The ePDG supports RADIUS related configuration under Administrative tab. The ePDG provides
option to change user privileges and properties later on under admin privilege. The ePDG user login
and authentication is enhanced to support RADIUS based remote authentication. With the new
authentication process ePDG OAM login and access can be controlled and managed centrally.
4.3 IPsec Tunnel Events

The UAG shall generate the following events for IPsec tunnel traffic
EID_MAX_IPSEC_CAPACITY_REACHED
Event ID EID_MAX_IPSEC_CAPACITY_REACHED
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Repair Action Need more IKE_SA capacity
Probable Cause Maximum IPSec Capacity of <Number of SAs> reached on IKE-SAP
<IKE-SAP-ID> of node type <IKE-SAP node type>
Specific Problem May result from sudden flood or low provisioned capacity
EID_MAX_IPSEC_CAPACITY_REACHED_CLEARED
Event ID EID_MAX_IPSEC_CAPACITY_REACHED_CLEARED
Type TYPE_COMMU
52
Severity CLEAR
Trap Indicator YES
Repair Action None
Probable Cause TRAFFIC DROPPED WITHIN THRESHOLD LIMITS
Specific Problem None
EID_ESP_TUNNEL_BANDWIDTH_VIOLATION
Event ID EID_ESP_TUNNEL_BANDWIDTH_VIOLATION
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Repair Action Verify the specified user activity.
Probable Cause TRAFFIC IN DIRECTION < SourceIP, Port> to <DestinationIP, Port>
using <PROTOCOL> violated the bandwidth policy
Specific Problem May result from sudden flood or an bandwidth attack
EID_ESP_TUNNEL_BANDWIDTH_VIOLATION_CLEARED
Event ID EID_ESP_TUNNEL_BANDWIDTH_VIOLATION_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None
Probable Cause TRAFFIC DROPPED WITHIN THRESHOLD LIMITS
4.4 AAA Server Group Events

The UAG shall generate the following events for AAA Servers
EID_AAA_UNREACHABLE
Event ID EID_AAA_UNREACHABLE
Type TYPE_COMMU
Severity MAJOR
53
Trap Indicator YES
Repair Action Specified AAA Server is down
Probable Cause In AAA Server Group <AAA Server Group ID> <Primary/Secondary>
server < IP ADDRESS: Port> is DOWN
Specific Problem AAA Server Outage
EID_AAA_UNREACHABLE_CLEARED
Event ID EID_AAA_UNREACHABLE_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None
Probable Cause In AAA Server Group <AAA Server Group ID> <Primary/Secondary>
server < IP ADDRESS: Port> is UP
54
5 Performance Management
5.1 Functional Performance Counters
5.1.1 ePDG
The UAG-ePDG supports following KPIs in this group (note the field “APN” which is used
to classify the counters per APN):
Index Field Name Description Object Time

Aggr. Aggr.
5 APN Name of the APN
6 EPDG_PDN_CONN_REQ Number of PDN connection requests Sum Sum
received
7 EPDG_PDN_CONN_REQ_SU Number of successful PDN connection Sum Sum
CC requests
8 EPDG_PDN_CONN_REQ_FAI Number of failed PDN connection Sum Sum
L requests
11 PGW_DEDICATED_BEARER_ Number of attempted dedicated Sum Sum
REQ bearer activations initiated by PGW
12 EPDG_DEDICATED_BEARER Number of successful dedicated bearer Sum Sum
_SUCC activations initiated by PGW
13 EPDG_DEDICATED_BEARER Number of unsuccessful dedicated Sum Sum

_FAIL bearer activations initiated by PGW
14 EPDG_PDN_CONN_TERM_R Number of PDN connection Sum Sum

EQ termination requests received
15 EPDG_PDN_CONN_TERM_S Number of successful PDN connection Sum Sum
UCC termination requests send by ePDG
16 EPDG_PDN_CONN_TERM_F Number of unsuccessful PDN Sum Sum
AIL connection termination requests
20 EPDG_DEDICATED_BEARER Number of dedicated bearer Sum Sum
_TERM_REQ termination requests sent by ePDG
_TERM_SUCC terminations

_TERM_FAIL bearer terminations

_TERM_ATT termination requests received by
ePDG.
_TERM_ATT_SUCC terminations

_TERM_ATT_FAIL bearer terminations
55
Aggr. Aggr.
_MOD_QOS_ATT modification requests sent by PGW
with QoS update (Transmission of
"Update Bearer REQUEST"
message From PDN-GW with
“Bearer Level QoS” IE)
_MOD_QOS_ATT_SUCC modification with QoS update received
by ePDG
_MOD_QOS_ATT_FAIL bearer modification with QoS update
attempted by PGW
_MOD_ATT modification requests sent by PGW
without QoS update (Transmission of
"Update Bearer REQUEST"
message From PDN-GW without
“Bearer Level QoS” IE)
_MOD_ATT_SUCC modification without QoS update
attempted by PGW
_MOD_ATT_FAIL bearer modification without QoS
update attempted by PGW
5.2 IKE SA Events

The UAG shall generate the following events for IKE traffic
EID_MAX_SA_CAPACITY_REACHED
Event ID EID_MAX_SA_CAPACITY_REACHED
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Repair Action Need more IKE_SA capacity
Probable Cause Maximum SA Capacity of <Number of SAs> reached on IKE-SAP <IKE-
SAP-ID> of node type <IKE-SAP node type>
Specific Problem May result from sudden flood or low provisioned capacity
EID_MAX_SA_CAPACITY_REACHED_CLEARED
Event ID EID_MAX_SA_CAPACITY_REACHED_CLEARED
Type TYPE_COMMU
56
Severity CLEAR
Trap Indicator YES
Repair Action None
Probable Cause TRAFFIC DROPPED WITHIN THRESHOLD LIMITS on IKE-SAP <IKE-
SAP-ID>
EID_HIGH_IKE_SA_INIT_WITHOUT_COOKIE_RATE
Event ID EID_HIGH_IKE_SA_INIT_WITHOUT_COOKIE_RATE
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Probable Cause IKEv2 SA_INIT MESSAGE RATE TO IKE-SAP <DestinationIP, Port> is
high at <specify the message rate>
EID_HIGH_IKE_SA_INIT_RATE_CLEARED
Event ID EID_HIGH_IKE_SA_INIT_WITHOUT_COOKIE_RATE_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None
SAP-ID>
EID_HIGH_IKE_SA_INIT_WITH_COOKIE_RATE
Event ID EID_HIGH_IKE_SA_INIT_WITH_COOKIE_RATE
57
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Probable Cause IKEv2 SA_INIT MESSAGE RATE TO IKE-SAP <DestinationIP, Port> is
EID_HIGH_IKE_SA_INIT_RATE_CLEARED
Event ID EID_HIGH_IKE_SA_INIT_WITH_COOKIE_RATE_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None
SAP-ID>
EID_HIGH_IKE_AUTH_RATE
Event ID EID_HIGH_IKE_AUTH_RATE
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Probable Cause IKEv2 IKE_AUTH MESSAGE RATE TO IKE-SAP <DestinationIP, Port>
is high at <specify the message rate>
EID_HIGH_IKE_AUTH_RATE_CLEARED
Event ID EID_HIGH_IKE_AUTH_RATE_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None
58
SAP-ID>
EID_HIGH_IKE_INFORMATIONAL_RATE
Event ID EID_HIGH_IKE_INFORMATIONAL_RATE
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Probable Cause IKEv2 IKE_INFO MESSAGE RATE TO IKE-SAP <DestinationIP, Port> is
EID_HIGH_IKE_INFORMATIONAL_RATE_CLEARED
Event ID EID_HIGH_IKE_INFORMATIONAL_RATE_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None

SAP-ID>
EID_HIGH_CREATE_CHILD_SA_RATE
Event ID EID_HIGH_CREATE_CHILD_SA_RATE
Type TYPE_COMMU
Severity MAJOR
Trap Indicator YES
Probable Cause IKEv2 CREATE_CHILD_SA MESSAGE RATE TO IKE-SAP
<DestinationIP, Port> is high at <specify the message rate>
59
EID_HIGH_CREATE_CHILD_SA_RATE_CLEARED
Event ID EID_HIGH_CREATE_CHILD_SA_RATE_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None
SAP-ID>
EID_UAG_CERTIFICATE_EXPIRING
Event ID EID_UAG_CERTIFICATE_EXPIRING
Type TYPE_COMMU
Severity CRITICAL
Trap Indicator YES
Repair Action Provided updated certificate
Probable Cause Current UAG certificate will expire on <Date>
Specific Problem This alarm shall be raised within 30 days of expiration of certificate
EID_UAG_CERTIFICATE_EXPIRING_CLEARED
Event ID EID_UAG_CERTIFICATE_EXPIRING_CLEARED
Type TYPE_COMMU
Severity CLEAR
Trap Indicator YES
Repair Action None
Probable Cause New certificate with expiration date of <date> provided
60
5.3 Protocol Performance Counters
5.3.1 SWm Diameter
The UAG supports the following counters in this performance group with the details
mentioned below
Group Name: SWm_DIAMETER
This Performance Group captures measurement related to Diameter related transactions at the
protocol level. The Diameter transactions measured is between the UAG and the PCRF (Rx
Interface).
Index Field Name Description

5 Peer A string identifying the diameter peer (in this case it will be
AAA Server Address)
6 DIAM_SND_DER Number of DER Requests sent to a given AAA
7 DIAM_RCV_DEA Number of DEA Responses received from a given AAA
8 DIAM_SND_STR Number of STR Requests sent to a given AAA
9 DIAM_RCV_STA Number of STA Responses received from a given AAA
10 DIAM_RCV_STA_RC_2001 STA responses received with Result-
Code=DIAMETER_SUCCESS
Code=DIAMETER_TOO_BUSY
Code=DIAMETER_LOOP_DETECTED
Code=DIAMETER_REDIRECT_INDICATION
Code=DIAMETER_OUT_OF_SPACE
15 DIAM_RCV_STA_RC_ 4xxx STA responses received with 4xxx category Result-Code.
Excludes other RC which have explicit counter defined.
16 DIAM_RCV_STA_ERC_4xxx STA responses received with 4xxx category Experimental-
Result-Code. Excludes other ERC which have explicit
counter defined.
17 DIAM_RCV_STA_RC_5002 STA responses received with Result-Code=
DIAMETER_UNKNOWN_SESSION_ID
Code=DIAMETER_INVALID_AVP_VALUE
Code=DIAMETER_MISSING_AVP
Code=DIAMETER_UNABLE_TO_COMPLY
Code=DIAMETER_INVALID_BIT_IN_HEADER
61
22 DIAM_RCV_STA_RC_5xxx STA responses received with 5xxx category Result-Code.
23 DIAM_RCV_STA_ERC_5xxx STA responses received with 5xxx category Experimental-
Result-Code. Excludes other RC which have explicit
counter defined.
24 DIAM_RCV_ASR ASR Requests received
25 DIAM_SND_ASA_RC_2001 ASA responses sent with Result-
Code=DIAMETER_SUCCESS
Code=DIAMETER_TOO_BUSY
Code=DIAMETER_LOOP_DETECTED
Code=DIAMETER_OUT_OF_SPACE
29 DIAM_SND_ASA_RC_4xxx ASA responses sent with 4xxx category Result-Code.
30 DIAM_SND_ASA_ERC_4xxx ASA responses sent with 4xxx category Experimental-
Result-Code. Excludes other ERC which have explicit
counter defined.
31 DIAM_SND_ASA_RC_5002 ASA responses sent with Result-Code=
DIAMETER_UNKNOWN_SESSION_ID
Code=DIAMETER_INVALID_AVP_VALUE
Code=DIAMETER_MISSING_AVP
Code=DIAMETER_UNABLE_TO_COMPLY
Code=DIAMETER_INVALID_BIT_IN_HEADER
36 DIAM_SND_ASA_RC_5xxx ASA responses sent with 5xxx category Result-Code.
37 DIAM_SND_ASA_ERC_5xxx ASA responses sent with 5xxx category Experimental-
Result-Code. Excludes other RC which have explicit
counter defined.
5.3.2 GTPv2-C-ePDG
The UAG supports following KPIs in this group:

Aggr. Aggr.
6 EPDG_CSR_SND Number of Create Session Requests Sum Sum
send
62
Aggr. Aggr.
7 EPDG_CSR_RSP_RCV_SUCC Number of successful Create Session Sum Sum
response received with Cause
"Request accepted"
8 EPDG_CSR_RSP_RCV_78 Number of unsuccessful Create Session Sum Sum
response received with Cause ‘Missing
or Unknown APN’
‘Preferred PDN type not supported’
response received with Cause ‘All
dynamic addresses are occupied’
response received with Cause ‘APN
Congestion’
‘Multiple PDN connections for a
given APN not allowed’
13 EPDG_CSR_RSP_RCV_OTHER Number of unsuccessful Create Session Sum Sum
response received with Cause other
than those mentioned above
14 EPDG_DSR_SND Number of Delete Session Requests Sum Sum
sent
15 EPDG_DSR_RSP_RCV_SUCC Number of successful Delete Session Sum Sum
"Request accepted"
16 EPDG_DSR_RSP_RCV_64 Number of unsuccessful Delete Session Sum Sum
response received with Cause ‘Context
Not Found’
17 EPDG_DSR_RSP_RCV_OTHER Number of unsuccessful Delete Session Sum Sum
‘Preferred PDN type not supported’
18 EPDG_MBC_SND Number of Modify Bearer Command Sum Sum
messages send
19 EPDG_MBC_FAIL_IND_RCV Number of Modify Bearer Failure Sum Sum
Indication received
22 EPDG_MBR_SND Number of Modify Bearer Requests Sum Sum
sent
23 EPDG_MBR_RSP_RCV_SUCC Number of successful Modify Bearer Sum Sum
"Request accepted" or “Request
accepted partially”
24 EPDG_MBR_RSP_RCV_64 Number of unsuccessful Modify Bearer Sum Sum
response received with Cause ‘Context
Not Found’
63
Aggr. Aggr.
25 EPDG_MBR_RSP_RCV_OTHER Number of unsuccessful Modify Bearer Sum Sum
26 EPDG_CBR_RCV Number of Create Bearer Requests Sum Sum
received
27 EPDG_CBR_RSP_ SND_SUCC Number of successful Create Bearer Sum Sum
response sent with Cause "Request
accepted" or “Request accepted
partially”
28 EPDG_CBR_RSP_SND_64 Number of unsuccessful Create Bearer Sum Sum
response sent with Cause ‘Context Not
Found’
response sent with Cause ‘Denied in
RAT’
response sent with Cause ‘UE not
Responding’
response sent with Cause ‘UE Refuses’
32 EPDG_CBR_RSP_SND_OTHER Number of unsuccessful Create Bearer Sum Sum
response sent with Cause other than
those mentioned above
33 EPDG_UBR_RCV Number of Update Bearer Requests Sum Sum
received by ePDG
34 EPDG_UBR_RSP_SND_SUCC Number of successful Update Bearer Sum Sum
response send with Cause "Request
accepted" or “Request accepted
partially”
35 EPDG_UBR_RSP_SND_64 Number of unsuccessful Update Bearer Sum Sum
response sent with Cause ‘Context Not
Found’
response sent with Cause ‘Denied in
RAT’
response sent with Cause ‘UE not
Responding’
response sent with Cause ‘UE Refuses’
39 EPDG_UBR_RSP_SND_OTHER Number of unsuccessful Update Bearer Sum Sum
response sent with Cause other than
those mentioned above
51 EPDG_DPCS_SND Number of Delete PDN Connection Set Sum Sum
requests sent
52 EPDG_DPCS_RSP_RCV Number of Delete PDN Connection Set Sum Sum
response received with Cause ‘Request
Accepted’
64
Aggr. Aggr.
53 EPDG_DPCS_RSP_RCV_72 Number of Delete PDN Connection Set Sum Sum
response received with Cause ‘System
Failure’
54 EPDG_DPCS_RSP_RCV_OTHER Number of Delete PDN Connection Set Sum Sum
5.3.3 DHCP
The UAG supports the following header information in this KPI group

1 STARTTIME The time when the collection interval began in YYYYMMDDHHMM format.
2 STOPTIME The time when the collection interval ended in YYYYMMDDHHMM format.
3 NodeID A unique string identifying the mOne node, taken from the ‘name’ field in
the mOne ‘platform’ configuration table.
4 CardID The Protection Group identifier, unique for a given NodeID.
5 PeerID DHCP server address
The UAG supports following KPIs in this group (DHCP message types are determined from
Option code 53, refer RFC 2132)

Aggr. Aggr.
6 PGW_DHCP_DISCOVER_RCVD Number of DHCP Discover messages Sum Sum
received
7 PGW_DHCP_OFFER_SND Number of DHCP Offer messages sent Sum Sum
8 PGW_DHCP_REQEUST_RCVD Number of DHCP Request messages Sum Sum
received
9 PGW_DHCP_ACK_SND Number of DHCP Ack messages sent Sum Sum
10 PGW_DHCP_NACK_SND Number of DHCP Nack messages sent Sum Sum
11 PGW_DHCP_DECLINE_RCVD Number of DHCP Decline messages Sum Sum
received
12 PGW_DHCP_RELEASE_RCVD Number of DHCP Release messages Sum Sum
received
13 PGW_DHCP_INFORM_RCVD Number of DHCP Inform messages Sum Sum
received
14 PGW_DHCP_DISCOVER_SND Number of DHCP Discover messages Sum Sum
sent
15 PGW_DHCP_OFFER_RCVD Number of DHCP Offer messages Sum Sum
received
16 PGW_DHCP_REQEUST_SND Number of DHCP Request messages Sum Sum
sent
65
Aggr. Aggr.
17 PGW_DHCP_ACK_RCVD Number of DHCP Ack messages Sum Sum
received
18 PGW_DHCP_NACK_RCVD Number of DHCP Nack messages Sum Sum
received
19 PGW_DHCP_DECLINE_SND Number of DHCP Decline messages Sum Sum
sent
20 PGW_DHCP_RELEASE_SND Number of DHCP Release messages Sum Sum
sent
21 PGW_DHCP_INFORM_SND Number of DHCP Inform messages Sum Sum
sent
5.3.4 DNS
These protocol counters shall be maintained by UAG.
mentioned below
Group Name: UAG_DNS
This performance group captures measurements of transactions related to DNS traffic at UAG SBC.
This group supports the following Peer field which identifies whether the UAG is serving the session
originator or terminator.

5 Peer A string identifying the following:
 Functional module – “A-SBC” or “I-SBC”; and
 Peer DNS node address
“A-SBC/I-SBC_DNSSRV_<IP address>”
The performance counter details for all the counters defined under this group are defined below:
Trigger This counter is incremented on receiving or sending the request or response

corresponding to the counter.
Type Aggregate
Level DNSRESOLVER
Usage The counters defined in this group are used to measure the DNS traffic between the
SBC and the DNS server.
The following table lists the performance counters in this group. The counters are described in
subsequent sections.

6 DNS_SND_NAPTR_QUE Number of “NAPTR” Query sent
RY
66
7 DNS_SND_NAPTR_QUE Number of NAPTR RETRY sent
RY_RETRY
8 DNS_RCV_NAPTR_SUC Number of Successful “NAPTR” Query Response received.
CESS
9 DNS_RCV_NAPTR_FAIL Number of failed “NAPTR” Query Response received
URE
10 DNS_NAPTR_QUERY_TI Number of failed “NAPTR” Query Timeouts.
MEOUT
11 DNS_SND_SRV_QUERY Number of “SRV” Query sent.
12 DNS_SND_SRV_QUERY_ Number of SRV RETRY sent.
RETRY
13 DNS_ RCV_ Number of Successful “SRV” Query Response received.
SRV_SUCCESS
14 DNS_ RCV_ Number of failed “SRV” Query Response received.
SRV_FAILURE
15 DNS_SRV_QUERY_TIME Number of failed “SRV” Query Timeouts.
OUT
16 DNS_SND_A_QUERY Number of “A” Query sent.
17 DNS_SND_A_QUERY_RE Number of A RETRY sent.
TRY
18 DNS_ RCV_ A Number of Successful “A” Query Response received.
_SUCCESS
19 DNS_ RCV_ A _FAILURE Number of failed “AAAA” Query Response received.
20 DNS_ Number of failed “AAAA” Query Timeouts.
A_QUERY_TIMEOUT
5.3.5 IKE
mentioned below
Group Name: IKE
Group Number: 305
This Performance Group captures measurement related to current status of an IKE-SAP.
This group includes the following Peer header field:

5 ServiceID <IKE-SAP-ID> This is SAP level counter. The SA Connection counters
must be maintained for each IKE-SAP.

67
Type Aggregate
Level IKE-SAP
Usage The counters defined in this group are used to measure the IKEv2 Traffic on IKE-
SAP

6 IKEV2_RESP_INITIAL- UAG-SEG in responder mode: Initial SA_INIT request
SA_INIT_REQ_RECVD received
7 IKEV2_RESP_SA_INIT_WITH_ UAG-SEG in responder mode: Response to initial
COOKIE_RESP_SENT SA_INIT request sent with COOKIE
8 IKEV2_RESP_SA_INIT_WITH_ UAG-SEG in responder mode: Received SA_INIT
COOKIE_REQ_RECVD request with COOKIE
9 IKEV2_RESP_INITIAL- UAG-SEG in responder mode: Response sent to
SA_INIT_RESP_SENT SA_INIT request with COOKIE
10 IKEV2_RESP_IKE_AUTH_RE UAG-SEG in responder mode: IKE_AUTH request
Q_RECVD received
11 IKEV2_RESP_IKE_AUTH_RE UAG-SEG in responder mode: IKE_AUTH response
SP_SENT sent
12 IKEV2_RESP_CREATE_CHIL CREATE_CHILD_SA Request received
D_SA_REQ_RECVD
13 IKEV2_RESP_CREATE_CHIL CREATE_CHILD_SA Response Sent
D_SA_RESP_SENT
14 IKEV2_RESP_CREATE_CHIL CREATE_CHILD_SA Request Sent
D_SA_REQ_SENT
15 IKEV2_RESP_CREATE_CHIL CREATE_CHILD_SA Response received
D_SA_RESP_RECVD
16 IKEV2_INFO_EXCHANGE_RE INFORMATIONAL_EXCHANGE Request received
Q_RECVD
17 IKEV2_INFO_EXCHANGE_RE INFORMATIONAL_EXCHANGE Response sent
SP_SENT
18 IKEV2_INFO_EXCHANGE_RE INFORMATIONAL_EXCHANGE Request sent
Q_SENT
19 IKEV2_INFO_EXCHANGE_RE INFORMATIONAL_EXCHANGE Response received
SP_RECVD
20 IKEV2_INIT_INITIAL- UAG-SEG in initiator mode: Initial SA_INIT request sent
SA_INIT_REQ_SENT
21 IKEV2_INIT_SA_INIT_WITH_C UAG-SEG in initiator mode: Response to initial
OOKIE_RESP_RECVD SA_INIT request with COOKIE received
68
22 IKEV2_INIT_SA_INIT_WITH_C UAG-SEG in initiator mode: Sent SA_INIT request with
OOKIE_REQ_SENT COOKIE
23 IKEV2_INIT_INITIAL- UAG-SEG in initiator mode: Response received to
SA_INIT_RESP_RECVD SA_INIT request with COOKIE
24 IKEV2_INIT_IKE_AUTH_REQ_ UAG-SEG in initiator mode: IKE_AUTH request sent
SENT
25 IKEV2_INIT_IKE_AUTH_RESP UAG-SEG in initiator mode: IKE_AUTH response
_ RECVD received
26 IKEV2_FAILED_REASON_UN SA Setup failure reason as per NOTIFY payload:
SUPPORT_CRITICAL_PAYLO UNSUPPORT_CRITICAL_PAYLOAD
AD
27 IKEV2_FAILED_REASON_INV SA Setup failure reason as per NOTIFY payload:
ALID_IKE_SPI INVALID_IKE_SPI
ALID_MAJOR_VERSION INVALID_MAJOR_VERSION
ALID_SYNTAX INVALID_SYNTAX
ALID_MESSAGE_ID INVALID_MESSAGE_ID
ALID_SPI INVALID_SPI
32 IKEV2_FAILED_REASON_NO SA Setup failure reason as per NOTIFY payload:
_PROPOSAL_CHOSEN NO_PROPOSAL_CHOSEN
ALID_KE_PAYLOAD INVALID_KE_PAYLOAD
34 IKEV2_FAILED_REASON_AU SA Setup failure reason as per NOTIFY payload:
THENTICATION_FAILED AUTHENTICATION_FAILED
35 IKEV2_FAILED_REASON_SIN SA Setup failure reason as per NOTIFY payload:
GLE_PAIR_REQUIRED SINGLE_PAIR_REQUIRED
36 IKEV2_FAILED_REASON_NO SA Setup failure reason as per NOTIFY payload:
_ADDITIONAL_SAS NO_ADDITIONAL_SAS
37 IKEV2_FAILED_REASON_INT SA Setup failure reason as per NOTIFY payload:
ERNAL_ADDRESS_FAILURE INTERNAL_ADDRESS_FAILURE
38 IKEV2_FAILED_REASON_FAI SA Setup failure reason as per NOTIFY payload:
LED_CP_REQUIRED FAILED_CP_REQUIRED
39 IKEV2_FAILED_REASON_TS_ SA Setup failure reason as per NOTIFY payload:
UNACCEPTABLE TS_UNACCEPTABLE
ALID_SELECTORS INVALID_SELECTORS
41 IKEV2_FAILED_REASON_TE SA Setup failure reason as per NOTIFY payload:
MPORARY_FAILURE TEMPORARY_FAILURE
42 IKEV2_FAILED_REASON_CHI SA Setup failure reason as per NOTIFY payload:
LD_SA_NOT_FOUND CHILD_SA_NOT_FOUND
69
5.4 Platform Performance Counters
5.4.1 Common Header Information
The UAG supports the following common header information in all performance groups

1 STARTTIME The time when the collection interval began in YYYYMMDDHHMM
format.
2 STOPTIME The time when the collection interval ended in YYYYMMDDHHMM
format.
3 NodeID A unique string identifying the mOne node, taken from the ‘name’
field in the mOne ‘platform’ configuration table.
4 CardID The Protection Group identifier, unique for a given NodeID.
5.4.2 Signaling Performance Counters
ePDG
mentioned below
Group Name: ePDG
Group Number:
This Performance Group captures measurement related to current status of an IKE-SAP.

5 ServiceID <IKE-SAP-ID> This is SAP level counter. The SA Connection counters
must be maintained for each IKE-SAP.

Type Aggregate
Level IKE-SAP
Usage The counters defined in this group are used to measure the ePDG service
performance.
70
6. Total Mature IKE SA Count of currently active IKE Security Associations
7. Total Half Open IKE SA Count of half open connections
8. Total Auth Phase IKE SA Count of currently active SA in authentication phase.

That is received first IKE_AUTH and yet to mature.
9. Total ESP Tunnels Count of currently active IPsec ESP Tunnels
10. Total PDN Connections Count of currently active PDN connections
11. Total IPv4 PDN connections Count of currently active IPv4 PDN connections
13. Total IPv4v6 PDN connections Count of currently active IPv4v6 PDN connections
14. Active IKE Rekeying Count of active IKE SA undergoing IKE rekeying
15. Active IPsec Rekeying Count of active IKE SA undergoing ESP rekeying
16.
17.
18.
ePDG-APN
mentioned below
Group Name: ePDG-APN
Group Number:
This Performance Group captures measurement related to current status of an ePDG over per APN.

5 Peer <APN > This is APN level counter.

Type Aggregate
Level APN
Usage The counters defined in this group are used to measure the ePDG service
performance.
71
19. Total Mature IKE SA Count of currently active IKE Security Associations
20. Total Half Open IKE SA Count of half open connections
21. Total Auth Phase IKE SA Count of currently active SA in authentication phase.
That is received first IKE_AUTH and yet to mature.
22. Total ESP Tunnels Count of currently active IPsec ESP Tunnels
23. Total PDN Connections Count of currently active PDN connections
26. Total IPv4v6 PDN connections Count of currently active IPv4v6 PDN connections
27. Active IKE Rekeying Count of active IKE SA undergoing IKE rekeying
28. Active IPsec Rekeying Count of active IKE SA undergoing ESP rekeying
29.
30.
31.
5.4.3 System Performance Counters

The UAG supports new counters defined in this section in addition to the ones defined in FRS 673
and 703. All the groups defined in FRS 673 and 703 are applicable for R4.0.
Data Path Performance
The UAG-U supports the following counters in this performance group with the details
mentioned below
Group Name: UAGU_DATA_PATH_PERF

5 Peer A string identifying the level, set to <SYSTEM_ID, REALM_ID or
NETWORK_INTERFACE_ID>
A string identifying the following
- Level – “SYSTEM” or “REALM” or “NETINTF”
- Identifier – Identifier of the system/realm/network interface
“SYSTEM/REALM/NETINTF_<Identifier>”
These statistics at maintained at System level, realm level and physical network interface level.
This data path performance statistics consist of packet transport statistics.
72
6 UAGU_DP_TOTAL_PACKETS_TX Total transmitted packet count
7 UAGU_DP_CURRENT_PACKET_TX_ Current packet transmission rate (in packets per
RATE second)
8 UAGU_DP_PEAK_PACKET_TX_RATE Peak packet transmission rate (in packets per
second) seen so far.
9 UAGU_DP_MEAN_PACKET_TX_RAT Mean packet transmission rate (in packets per
E second)
10 UAGU_DP_TOTAL_PACKETS_RX Total received packet count
11 UAGU_DP_CURRENT_PACKET_RX_ Current packet reception rate (in packets per second)
RATE
12 UAGU_DP_PEAK_PACKET_RX_RATE Peak packet reception rate (in packets per second)
seen so far.
13 UAGU_DP_MEAN_PACKET_RX_RAT Mean packet reception rate (in packets per second)
E
14 UAGU_DP_TOTAL_PACKET_DISCAR Total number of packets discarded
DED
15 UAGU_DP_PACKET_DISCARD_RATE Packet discard rate in packets per second.
The UAG-U shall capture total discarded packets counter as part of the same performance
group.
These counters shall be maintained at System level, realm level and physical network interface level.
16 1UAGU_DP_DISCARD_REASON_L2_T Layer-2: Ethernet type has to be
5YPE_ERROR from supported list, otherwise packet
shall be discarded
17 1UAGU_DP_DISCARD_REASON_UNS ARP: Unsupported operation field
6UPPORTED_ARP_OPR in ARP
18 UAGU_DP_DISCARD_REASON_INVA Layer-3: Incorrect Layer-3 packet
LID_PACKET_LEN length
19 UAGU_DP_DISCARD_REASON_INVA Layer-3: IP Header length is
LID_IP_HEADER_LEN invalid
20 UAGU_DP_DISCARD_REASON_INVA Layer-3: Unsupported IP version
LID_IP_VERSION
21 UAGU_DP_DISCARD_REASON_INVA Layer-3: System has no service
LID_TRANSPORT for that transport. For e.g. a UDP
packet on TCP port
22 UAGU_DP_DISCARD_REASON_INVA Layer-3: IP Checksum error
LID_IP_CHECKSUM
23 UAGU_DP_DISCARD_REASON_INVA Layer-3: Unexpected source or
LID_IP_ADDRESS destination IP address
24 UAGU_DP_DISCARD_REASON_UNS Layer-3: Requested protocol type
UPPORTED_PROTOCOL in not supported
25 UAGU_DP_DISCARD_REASON_BLA Layer-3: Source IP Address/port
CKLISTED_SOURCE is blacklisted
26 UAGU_DP_DISCARD_REASON_INVA Layer-4: System has no service
LID_PORT_NUMBER on that port.
27 UAGU_DP_DISCARD_REASON_INVA Layer-4: Checksum is invalid
LID_L4_CHECKSUM
28 UAGU_DP_DISCARD_REASON_INVA Layer-4: Length related error for
LID_L4_PACKET_LEN UDP or TCP
29 UAGU_DP_DISCARD_REASON_INVA Layer-4: URG pointer related
LID_TCP_URG_PTR error in TCP
73
30 UAGU_DP_DISCARD_REASON_INVA Layer-4: TCP Timestamp error
LID_TCP_TIMESTAMP
31 UAGU_DP_DISCARD_REASON_INVA Any VRRP packet specific error
LID_VRRP
32 UAGU_DP_DISCARD_REASON_RAT Packet discarded as a result of
E_LIMITING operator defined rate limiting policy
enforcement
The UAG-U shall maintain packet discard counters protocol wise.

These counters shall be maintained at System level, realm level and physical network interface level.

33 1UAGU_DP_DISCARD_PROTO_ARP Discarded packet was a ARP
6 packet
34 UAGU_DP_DISCARD_PROTO_ICMP Discarded packet was an ICMP
packet.
35 UAGU_DP_DISCARD_PROTO_OTHE Discarded packet was not from
RS any of the above listed protocols.
The UAG-U shall capture IPv4 ICMP volume statistics at system level, network interface and
realm level.

36 1UAGU_DP_TOTAL_ICMP_RECVD Total ICMP messages received
5
37 1UAGU_DP_ICMP_ECHO_REPLY Total number of ICMP – Echo Reply
6 messages received
38 UAGU_DP_ICMP_DEST_UNREAC Total number of ICMP – Destination
HABLE Unreachable messages received
39 UAGU_DP_ICMP_SOURCE_QUEN Total number of ICMP – Source
CH Quench messages received
40 UAGU_DP_ICMP_REDIRECT_MES Total number of ICMP – Redirect
SAGE messages received
41 UAGU_DP_ICMP_ECHO_REQUES Total number of ICMP – Echo
T Request messages received
42 UAGU_DP_ICMP_ROUTER_ADVE Total number of ICMP – Router
RT Advertisement received
43 UAGU_DP_ICMP_ROUTER_SOLIC Total number of ICMP – Router
ITATION Solicitation received
44 UAGU_DP_ICMP_TTL_EXCEEDED Total number of ICMP – TTL
Exceeded received
45 UAGU_DP_ICMP_TIMESTAMP Total number of ICMP – Timestamp
received
46 UAGU_DP_ICMP_TRACEROUTE Total number of ICMP – Traceroute
received
47 UAGU_DP_ICMP_OTHERS Total number of ICMP – not covered
by the above received
74
IPsec Performance
mentioned below
Group Name: IPSECPERF
Group Number: 407
5 Peer A string identifying the level, set to <SYSTEM_ID, REALM_ID or

NETWORK_INTERFACE_ID>
A string identifying the following
- Level – “SYSTEM” or “REALM” or “NETINTF”
- Identifier – Identifier of the system/realm/network interface
“SYSTEM/REALM/NETINTF_<Identifier>”
The UAG shall capture following IPsec (transport and tunnel mode) specific counters at
system level and at realm level:

6 1DP_IPSEC_TOTAL_TUNNEL Total IPSec ESP setup in tunnel mode
5
7 1DP_IPSEC_ACTIVE_TUNNEL Active IPSec ESP setup in tunnel mode
6
8 DP_IPSEC_PEAK_TUNNEL Peak concurrent IPSec ESP tunnels
9 DP_IPSEC_TOTAL_TRANSPORT Total transport mode IPSec
10 DP_IPSEC_ACTIVE_TRANSPORT Active transport mode IPSec ESP
11 DP_IPSEC_PEAK_TRANSPORT Peak concurrent transport mode IPSec ESPs
12 DP_IPSEC_SETUP_RATE_TUNNE Current IPSec Tunnel setup rate (tunnels per
L second)
13 DP_IPSEC_PEAK_SETUP_RATE_T Peak IPSec tunnel setup rate (tunnels per
UNNEL second)
14 DP_IPSEC_SETUP_RATE_TRANS Current Transport mode IPSec ESP setup rate
PORT (tunnels per second)
15 DP_IPSEC_PEAK_SETUP_RATE_T Peak Transport mode IPSec ESP setup rate
RANSPORT (tunnels per second)
16 DP_IPSEC_REL_RATE_TUNNEL Current IPSec Tunnel teardown rate (tunnels
per second)
17 DP_IPSEC_PEAK_REL_RATE_TU Peak IPSec tunnel teardown rate (tunnels per
NNEL second)
18 DP_IPSEC_REL_RATE_TRANSPO Current Transport mode IPSec ESP teardown
RT rate (tunnels per second)
19 DP_IPSEC_PEAK_REL_RATE_TRA Peak Transport mode IPSec ESP teardown
NSPORT rate (tunnels per second)
75
20 DP_IPSEC_TUNNEL_INACTIVITY_ Current IPSec Tunnel inactivity timeout rate
TIMEOUT_RATE (tunnels per second)
21 DP_IPSEC_TUNNEL_INACTIVITY_ Peak IPSec tunnel inactivity timeout rate
TIMEOUT_PEAK_RATE (tunnels per second)
22 DP_IPSEC_ERR_REPLAY IPSEC ESP with Replay Error
23 DP_IPSEC_AUTH_FAILURE IPSEC ESP failed authentication
24 DP_IPSEC_DECRYPT_FAILURE IPSEC ESP failed decryption
25 DP_IPSEC_BAD_HEADER IPSec ESP with Bad Header
26 DP_IPSEC_BAD_TRAILER IPSec ESP with Bad trailer
Peak System Transactions

mentioned below
Group Name: PEAKSYSTRANS
Group Number: 400
The UAG supports the following additional counters for R4.0.
Trigger As described above.
Type Data
Level DIAMETER
Usage The counters defined in this group are used to measure the peak transaction rates.
The following table lists the performance counters in this group.

6 DER_MIN The minimum number of DER transactions between the
UAG and AAA.
7 DER_MAX The maximum number of DER transactions between the
UAG and AAA.
8 DER_AVG The average number of DER transactions between the
UAG and AAA.
9 DEA_MIN The minimum number of STR transactions between the
UAG and AAA.
10 DEA_MAX The maximum number of STR transactions between the
UAG and AAA.
11 DEA_AVG The average number of STR transactions between the UAG
and AAA.
12 STR_MIN The minimum number of STR transactions between the
UAG and AAA.
13 STR_MAX The maximum number of STR transactions between the
UAG and AAA.
76
14 STR_AVG The average number of STR transactions between the UAG
and AAA.
15 STA_MIN The minimum number of STA transactions between the
UAG and AAA.
16 STA_MAX The maximum number of STA transactions between the
UAG and AAA.
17 STA_AVG The average number of STA transactions between the UAG
and AAA.
18 ASR_MIN The minimum number of ASR transactions between the
UAG and AAA.
19 ASR_MAX The maximum number of ASR transactions between the
UAG and AAA.
20 ASR_AVG The average number of ASR transactions between the
UAG and AAA.
21 ASA_MIN The minimum number of ASA transactions between the
UAG and AAA.
22 ASA_MAX The maximum number of ASA transactions between the
UAG and AAA.
23 ASA_AVG The average number of ASA transactions between the UAG
and PCRF.
77
6 Call Flows
6.1 Untrusted Wi-Fi Attach over S2b GTPv2
Untrusted Non3GPP Access Attach/Registration over GTP S2b
UE DRA AAA HSS DNS-G PGW PCRF

ePDG
1. Attach to WiFi AP
and ePDG selection
2. IKEv2 SA_INIT
3. IKEv2 SA_INIT RESP
4. IKE_AUTH Request
5. DER Diameter EAP Request
6. MAR - Multimedia AuthReq
7. MAA - Multimedia AuthResp [Vectors]

8. DEA Diameter EAP Response
10. UE runs AKA,

generates RES and MSK
11. IKE_AUTH Request 12. DER Diameter EAP

Request
13. AAA Server verifies RES
14. SAR Server Assignment Req
15. SAA Server Assignment Resp

16. DEA Diameter EAP Resp
18. IKE_AUTH Request [AUTH] 19. PGw Address query
20. PGw Address Resp
21. Create Session Request
22. AAR
23. SAR Server Assignment Req

[PGw identity, APN]
24. SAA Server Assignment Resp
25. AAA
26. Credit Control Request
27. Credit Control Answer


[AUTH, CFG Payload]
IPSec Tunnel GTP Tunnel
6.2 UE Initiated Detach

Untrusted Non3GPP Access UE initiated detach over GTP S2b
PG PCRF
UE ePDG DRA AAA HSS DNS-G W
1. IKEv2 tunnel
release trigger 2. Delete Session
Request
3. Session termination request (STR)
Remove S6b
session
6. Session termination answer (STA) 7. Credit Control

Request
8. Credit Control
Answer
9. Delete Session
Response
10. STR 4. SAR
12. Non – 3GP 11. STA 5. SAA

specific resource
release procedure
78
6.3 HSS Initiated Detach
Untrusted Non3GPP Access HSS/AAA initiated detach over GTP S2b
UE ePDG DRA AAA HSS DNS-G PGW PCRF
Subscription
Registration Termination withdrawn
Request (RTR)
Find the
Session
Abort Session
Request (ASR)
Abort Session
Answer (ASA)
RTA
Delete Session Request
Session termination request (STR)
Remove S6b
session
Session termination answer (STA)

Credit Control Request
Delete Session Credit Control Answer

Response
Session termination
request (STR)
Remove SWm
Session termination session
answer (STA)
6.4 PGW Initiated Detach

Untrusted Non3GPP Access PGW initiated detach over GTP S2b
PG PCRF
UE ePDG DRA AAA HSS DNS-G W
Delete Bearer Request

IKEv2 info Delete Req
Remove S6b
session
CCR -T
CCA - T
Delete Bearer Response
IKEv2 info Delete Res
STR SAR
SAA
STA
6.5 Handover From Wifi To EUTRAN
79
Handover to E-UTRAN from Untrusted Non3GPP Access over GTP S2b
PG
UE ePDG MME AAA HSS SGW W
UE discovers
3GPP access
system and
Attach
initiate HO
Request
Authentication and Security
Location Update Request

Location Update Answer
Create Session request
EnodeB Create Session Response
Attach Accept/ initial context setup request

RRC reconfig
RRC reconfig
Complete
Direct Initial context setup response
Trasfer
Attach Complete
Modify Bearer Request
Modify bearer Request
Modify bearer Response
Modify Bearer Response
Radio Access Bearer GTP Tunnel

Remove S6b
session
SAR
SAA
6.6 Handover from EUTRAN to WiFi
Handover from E-UTRAN to Untrusted Non3GPP Access over GTP S2b
UE E-UTRAN ePDG PGW

MME AAA HSS SGW
Radio Access Bearer / S1 Bearer GTP Tunnel
UE discovers untrusted
Non-3GPP access and
initiate HO
IKEv2 SA_INIT
IKEv2 SA_INIT RESP
IKE_AUTH Request
DER Diameter EAP Request
MAR - Multimedia AuthReq
MAA - Multimedia AuthResp [Vectors]

DEA Diameter EAP Resp
IKE_AUTH Response
UE runs AKA, generates
RES and MSK
IKE_AUTH Request
SAR Server Assignment Req
SAA Server Assignment Resp
DEA Diameter EAP Res
IKE_AUTH Response [EAP Success]
IKE_AUTH Request [AUTH]

Create Session Request
AAR
[PGw identity, APN]
AAA
IKE_AUTH Response Create Session Response

[AUTH, CFG Payload]
3GPP EPS Bearer Release
80
6.7 Dead Peer Detection
Untrusted Non3GPP Access Dead Peer DEtection
UE AAA HSS PGW PCRF

ePDG
ePDG starts timer for DPD
UL Data ePDG reset DPD timer
IKE Info req DPD timer expires without any data
IKE info Resp ePDG reset DPD timer
IKE Info req DPD timer expires without any data
Delete Session Request

SAR
SAA
Credit Control Request
Delete Session Response Credit Control Answer
UL Data UE returns and try to use already delete tunel
IKEv2 info Delete
IKEv2 info Delete response
6.8 IKE Rekeying

REKEYING IKE-SA & IPSEC-SA
UE PGW
ePDG
SA Lifetime expired
Create CHILD SA REQ Rekeying
Create CHILD SA RSP Rekeying
SA Lifetime expired
Create CHILD SA REQ Rekeying
Create CHILD SA RSP Rekeying

81
6.9 Handover to EUTRAN with voice
Handover to E-UTRAN from Untrusted Non3GPP Access over GTP S2b with voice
PG
UE ePDG MME AAA HSS SGW W
UE discovers
3GPP access
system and
Attach
initiate HO
Request
Authentication and Security
Location Update Request

Location Update Answer
EnodeB
Attach Accept/ initial context setup request
RRC reconfig
RRC reconfig
Complete
Direct Initial context setup response
Trasfer
Attach Complete
Modify Bearer Request
Modify bearer Request
Modify bearer Response
Modify Bearer Response
Radio Access Bearer GTP Tunnel
Create Bearer request Create Bearer request
Create Bearer response Create Bearer response

Remove S6b
session

SAR
SAA
82
6.10 Handover to WiFi with voice
Handover from E-UTRAN to Untrusted Non3GPP Access over GTP S2b with Voice
UE E-UTRAN ePDG PGW

MME AAA HSS SGW
Radio Access Bearer / S1 Bearer GTP Tunnel
UE discovers untrusted
Non-3GPP access and
initiate HO
IKEv2 SA_INIT
IKEv2 SA_INIT RESP
IKE_AUTH Request
MAR - Multimedia AuthReq
MAA - Multimedia AuthResp [Vectors]

DEA Diameter EAP Resp
IKE_AUTH Response
UE runs AKA, generates
RES and MSK
IKE_AUTH Request
DEA Diameter EAP Res

IKE_AUTH Response [EAP Success]
IKE_AUTH Request [AUTH]

Create Session Request
AAR

[PGw identity, APN]
AAA
IKE_AUTH Response Create Session Response

[AUTH, CFG Payload]
GTP Tunnel
IPSec Tunnel
Create Bearer Request
Create Bearer Request
Create Bearer Response
Create Bearer Response
3GPP EPS Bearer Release
6.11 HSS Initiated update of user profile

HSS initiated Update of User Profile
ePDG AAA HSS
Push Profile Request
RAR
RAA
Push profile Answer
AAR
AAA
7 References
7.1 3GPP
1. 3GPP TS 23.402: Architecture enhancements for non-3GPP accesses;
http://www.3gpp.org/ftp/Specs/html-info/23402.htm
83
2. 3GPP TS 33.402: Security aspects of non-3GPP accesses;
3. 3GPP TS 23.861: Network based IP flow mobility; http://www.3gpp.org/ftp/Specs/html-

info/23861.htm
4. 3GPP TS 24.312: Access Network Discovery and Selection Function (ANDSF) Management
Object (MO); http://www.3gpp.org/ftp/Specs/html-info/24312.htm
5. 3GPP TR 23.852: Study on S2a Mobility based on GTP & WLAN access to EPC;
6. 3GPP 23.853: Operator Policies for IP Interface Selection (OPIIS);

7. 3GPP 23.855: Data Identification in Access Network Discovery and Selection Function
(ANDSF) (DIDA); http://www.3gpp.org/ftp/Specs/html-info/23855.htm
8. 3GPP TS 23.261: IP Flow Mobility (IFOM) and seamless WLAN offload;

9. 3GPP TS 24.302: Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks http://www.3gpp.org/DynaReport/24302.htm
10. 3GPP TS 29.274: 3GPP Evolved Packet System (EPS); Evolved General Packet Radio
Service (GPRS) Tunneling Protocol for Control plane (GTPv2-C)
http://www.3gpp.org/DynaReport/29274.htm
11. 3GPP TS 23.003: Numbering, addressing and identification

12. 3GPP TS 29.303 Domain Name System Procedures
7.2 IETF
[1] RFC 5996: Internet Key Exchange Protocol Version 2 (IKEv2)
[2] RFC 4718: IKEv2 Clarification and Implementation Guidelines
[3] RFC 3706: A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
[4] RFC 4941: Privacy Extensions for Stateless Address Auto configuration in IPv6
[5] RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile
[6] RFC 3948: UDP Encapsulation of IPsec ESP Packets
[7] RFC 4301: Security Architecture for the Internet Protocol
[8] RFC 4303: IP Encapsulating Security Payload (ESP)
[9] RFC 4304: Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation
(DOI) for Internet Security Association and Key Management Protocol
[10] RFC 4739: Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2)
Protocol
[11] IETF RFC 4555 (June 2006): "IKEv2 Mobility and Multihoming Protocol (MOBIKE)".
[12] RFC 5448: Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA’ – EAP-AKA Prime)
84

ePDG SolutionDescription

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ePDG SolutionDescription

Uploaded by

Copyright:

Available Formats

Evolved Packet Data

© 2014 Mavenir Systems Inc.

© 2014 Mavenir Systems Date: Jul. 19, 2014 i

Abbreviations & Glossary

3GPP 3rd Generation Partnership Project

Non -3GPP Gxa

Figure 1 Overall Architecture

2.2 Software Architecture

Figure 2: Distributed Architecture

2.3 Deployment Models

1) mOne® ATCA 13U-based blade system

2) Fully Virtualized system based on COTS.

3) Server based on RMS-220

2.3.2 ePDG in the Cloud (Virtualized)

Figure 4 ePDG in NFV Infrastructure

Figure 6: Scaling on ATCA-based system

3.1.1 Untrusted Non-3GPP Access

3.1.2 Security between UE and ePDG

8a. 3GPP AAA Se rver verifies

9. AA-Answer [EAP-Success, key material, IMSI]

10. AUTH payload is computed

13. Check AUTH correctness

14. Calculate AUTH

15. IKE_AUTH Response

The following is an example illustration depicting non-cellular UE to ePDG interaction.

Wifi APN ePDG

IP Header Public IP Header Public

ESP header ESP header

IP Payload Priv IP PayloadPriv IP PayloadPriv Dest: 200.2.1.1

ESP Trailer ESP Trailer

ESP Auth ESP Auth

Figure 7: Example travel path of ESP packet for non-cellular access

Below is summary of all supported security options on ePDG.

Internet Key IKEv2 Encryption  DES-CBC

EAP Methods EAP Methods

EAP Message Exchange

Below is summary of messages supported on SWm interface based on 3GPP TS 29.273

3.2.2.1.1 Authentication and Authorization Request

3.2.2.1.2 Authorization Procedures.

Information Mapping to Cat. Description

Only the Trace-Data AVP shall be included if trace activation is requested.

If the Trace-Data AVP is included, it shall contain the following AVPs:

3.2.2.1.3 ePDG Initiated Session Termination Procedures

Information Mapping to Cat. Description

Table 7.1.2.3.1/2: SWm Session Termination Answer

Information Mapping to Cat. Description

3.2.2.1.4 AAA Server Initiated Session Termination Procedures

Information Mapping to Cat. Description

Table 7.1.2.4.1/2: SWm Abort Session Answer

Information Mapping to Cat. Description

Table 7.1.2.4.1/3: SWm Session Termination Request

Information Mapping to Cat. Description

Table 7.1.2.4.1/4: SWm Session Termination Answer

Information Mapping to Cat. Description

IKEv2 IKEv2 UDP UDP

IPv4/IPv6 IPv4/IPv6 IPv4/IPv6 IPv4/IPv6 IPSEC IPv4/IPv6

Control Plane User Plane

Figure 8: S2b Interface with ePDG and PGW

3.2.5 Create Session Request

PDN AAA HSS/

1. IKEv2 Authentication and Tunnel Setup

2. Create Session Request

7.IKEv2 (IP Address Configuration)