15 0 eWAG Admin

Cisco ASR 5000 Enhanced Wireless Access
Gateway Administration Guide

Version 15.0
Last Updated November 30, 2013
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY
OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED
WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED
WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain
version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL
FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE
PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR
ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at
www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship
between Cisco and any other company.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phon e numbers. Any examples, command display
output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in
illustrative content is unintentional and coincidental.
Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide
© 2013 Cisco Systems, Inc. All rights reserved.

CONTENTS
About this Guide ............................................................................................... vii

Conventions Used .................................................................................................................................. viii
Contacting Customer Support ..................................................................................................................ix
Additional Information ............................................................................................................................... x
Enhanced Wireless Access Gateway Overview ............................................ 11
Introduction ............................................................................................................................................. 12
Platform Requirements ........................................................................................................................... 13
License Requirements ............................................................................................................................ 14
RADIUS-based Enhanced Wireless Access Gateway Overview ................. 15
Product Overview ................................................................................................................................... 16
Network Deployments and Network Interfaces .................................................................................. 17
Network Deployments .................................................................................................................... 17
Network Interfaces ......................................................................................................................... 18
Feature Description ................................................................................................................................ 19
R-eWAG-WLC/Wi-Fi AAA Interface ................................................................................................... 19
Control and Data Interfaces ........................................................................................................... 20
R-eWAG-GGSN Gn' Interface............................................................................................................ 20
IP Address Allocation ..................................................................................................................... 21
Network Layer Service Access Point Identifier Allocation ............................................................. 21
Routing Area Identification Encoding ............................................................................................. 21
Differentiated Services Code Point Marking ...................................................................................... 21
Access Point Name Selection ............................................................................................................ 22
Quality of Service Profile Selection .................................................................................................... 23
GGSN Selection ................................................................................................................................. 23
GGSN Failover Case.......................................................................................................................... 23
Network Address Translation and Application Level Gateway Support ............................................. 23
Virtual APN Support ........................................................................................................................... 24
Offline Charging Support .................................................................................................................... 24
Triggers for Charging Information Addition and CDR Closure ...................................................... 25
Billing Record Transfer .................................................................................................................. 25
UE Identity and Location Information Support ................................................................................... 25
UE Identity Information Support ..................................................................................................... 25
UE Location Information Support ................................................................................................... 26
Lawful Intercept Support .................................................................................................................... 26
Bulk Statistics Support ....................................................................................................................... 26
Threshold Crossing Alerts Support .................................................................................................... 27
Congestion Control Support ............................................................................................................... 28
Redundancy Support.......................................................................................................................... 29
How it Works .......................................................................................................................................... 30
Session Setup .................................................................................................................................... 30
Session Setup using Accounting-Interim ....................................................................................... 33
Session Replacement ........................................................................................................................ 36
Session Setup Failure ........................................................................................................................ 37
Mandatory AVP Missing / No Resource ........................................................................................ 38
Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄
iii
▀ Contents
GTP Tunnel Setup Failure ............................................................................................................. 38

Session Update .................................................................................................................................. 39
WLC-initiated Accounting Interim ................................................................................................... 40
GGSN-initiated Update PDP Context ............................................................................................ 40
Session Teardown .............................................................................................................................. 41
UE Detach - Accounting Stop ........................................................................................................ 41
GGSN-initiated DPC ...................................................................................................................... 42
eWAG Timeouts/Admin Disconnect ............................................................................................... 43
Dependencies and Limitations................................................................................................................ 44
eWAG + GGSN Combo Deployments ............................................................................................... 44
Virtual APN Configuration in R-eWAG + GGSN Combo Deployments ......................................... 44
eWAG + TTG Combo Deployments ................................................................................................... 45
SGTP Service Configuration in R-eWAG + TTG Combo Deployments ........................................ 45
eWAG + TTG + GGSN Combo Deployments .................................................................................... 46
Mobility Setup Considerations ............................................................................................................ 46
3G-eWAG-TTG Mobility using Proxy-MIP at GGSN ...................................................................... 46
RADIUS-based Enhanced Wireless Access Gateway Configuration .......... 47
Before You Begin .................................................................................................................................... 48
R-eWAG Configuration ........................................................................................................................... 49
Creating and Configuring the R-eWAG Service ................................................................................. 49
Creating the R-eWAG Service ....................................................................................................... 49
Configuring the R-eWAG Service .................................................................................................. 50
Configuring the APN ........................................................................................................................... 53
Configuring the SGTP Service ........................................................................................................... 54
Configuring NAT/ALG Support ........................................................................................................... 55
Configuring ECS Rulebase with Firewall-and-NAT Policy ............................................................. 55
Configuring APN with Firewall-and-NAT Policy ............................................................................. 55
Configuring Routing Rules and NAT ALG ...................................................................................... 55
Additional Configurations ................................................................................................................... 58
Configuring Access Lists ................................................................................................................ 58
Configuring Bulk Statistics ............................................................................................................. 58
Configuring Congestion Control ..................................................................................................... 59
Configuring Offline Charging for R-eWAG ..................................................................................... 60
Configuring Session Recovery ....................................................................................................... 61
R-eWAG Administration.......................................................................................................................... 63
Logging Support ................................................................................................................................. 63
Protocol Monitoring Support ............................................................................................................... 63
Monitor Protocol ............................................................................................................................. 63
Monitor Subscriber ......................................................................................................................... 64
Gathering R-eWAG-related Statistics and Information ...................................................................... 64
DHCP-based Enhanced Wireless Access Gateway Overview ..................... 67
Product Overview ................................................................................................................................... 68
Deployment Models ............................................................................................................................ 69
3G-SSID ............................................................................................................................................. 69
Association Process ........................................................................................................................... 70
802.1x EAP-SIM/AKA Authentication Process ................................................................................... 70
IP Address Allocation Process ........................................................................................................... 70
Data Traffic between WLAN and 3G Network .................................................................................... 71
D-eWAG as First-Hop Router to WLAN Network ............................................................................... 71
D-eWAG as Default Gateway ............................................................................................................. 71
APN Selection .................................................................................................................................... 71
D-eWAG Service in the ASR5000 Chassis ........................................................................................ 72
WLC - D-eWAG Interface ................................................................................................................... 72
▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide
iv
Contents ▀
Control Plane ................................................................................................................................. 72

D-eWAG - AAA Interface ................................................................................................................... 74
RADIUS CoA/DM Support ............................................................................................................. 74
RADIUS Accounting Support ......................................................................................................... 75
D-eWAG - GGSN (Gn') ...................................................................................................................... 75
GGSN Selection ............................................................................................................................. 75
GTP Messages .............................................................................................................................. 75
NSAPI Allocation ............................................................................................................................ 77
UE Identity and Location Information Support ............................................................................... 77
Data-Plane ......................................................................................................................................... 78
Uplink Data Path ............................................................................................................................ 78
Downlink Data Path ....................................................................................................................... 78
Overlapping IP Address Support ........................................................................................................ 78
Local Traffic Breakout ........................................................................................................................ 79
APN Selection ................................................................................................................................ 79
Controlling Local Traffic Breakout .................................................................................................. 80
NAT In-line Service Support .......................................................................................................... 80
Data Path Flow .............................................................................................................................. 81
Data Path Changes ........................................................................................................................ 81
Recovery Support .......................................................................................................................... 82
Accounting Support ........................................................................................................................ 82
Differentiated Services Code Point Marking ...................................................................................... 82
Bulk Statistics Support ....................................................................................................................... 83
Threshold Crossing Alerts Support .................................................................................................... 84
Congestion Control Support ............................................................................................................... 85
Redundancy Support.......................................................................................................................... 86
Charging ............................................................................................................................................. 87
Offline Charging ................................................................................................................................. 87
Triggers for Charging Information Addition and CDR Closure ...................................................... 87
Billing Record Transfer .................................................................................................................. 88
Lawful Intercept Support .................................................................................................................... 88
D-eWAG + R-eWAG Combo Deployment ......................................................................................... 88
How it Works .......................................................................................................................................... 89
Session Setup .................................................................................................................................... 89
Session Teardown.............................................................................................................................. 92
Session Teardown - AAA Initiated ................................................................................................. 92
Session Teardown - GGSN Initiated .............................................................................................. 93
Session Teardown - UE Initiated ................................................................................................... 93
Session Teardown - WLC Initiated ................................................................................................ 94
Session Update .................................................................................................................................. 94
Session Update - AAA Initiated ..................................................................................................... 95
Session Update - GGSN Initiated .................................................................................................. 95
Session Update - WLC Initiated ..................................................................................................... 96
Dependencies and Limitations ............................................................................................................... 97
Deployment Models............................................................................................................................ 97
Requirements in WLC ........................................................................................................................ 98
Requirements at GGSN ..................................................................................................................... 98
DHCP-based Enhanced Wireless Access Gateway Configuration ............. 99
Before You Begin ................................................................................................................................. 100
D-eWAG Configuration ......................................................................................................................... 101
Creating and Configuring the D-eWAG Service ............................................................................... 101
Creating the D-eWAG Service ..................................................................................................... 101
v
▀ Contents
Configuring the D-eWAG Service ................................................................................................ 102

Configuring DHCP Service ............................................................................................................... 103
Configuring the Subscriber Template ............................................................................................... 104
Configuring the SGTP Service ......................................................................................................... 104
Configuring NAT for Local Traffic Breakout Support ........................................................................ 105
Additional Configurations ................................................................................................................. 106
Configuring Bulk Statistics ........................................................................................................... 106
Configuring Congestion Control ................................................................................................... 107
Configuring Session Recovery ..................................................................................................... 108
Configuring Offline Charging for D-eWAG ................................................................................... 108
D-eWAG Administration........................................................................................................................ 110
Logging Support ............................................................................................................................... 110
Protocol Monitoring Support ............................................................................................................. 110
Monitor Protocol ........................................................................................................................... 110
Monitor Subscriber ....................................................................................................................... 111
Gathering D-eWAG-related Statistics and Information .................................................................... 111
RADIUS-based Enhanced Wireless Access Gateway AAA AVP Support 115
DHCP-based Enhanced Wireless Access Gateway AAA AVP Support .... 117
AAA AVP Support in Accounting Messages......................................................................................... 118
AAA AVP Support in Authentication Messages.................................................................................... 121
vi
About this Guide
This document pertains to the features and functionality that run on and/or that are related to the Cisco® ASR 5000
Chassis.
vii
About this Guide
▀ Conventions Used
Conventions Used
The following tables describe the conventions used throughout this documentation.
Icon Notice Type Description

Information Note Provides information about important features or instructions.
Caution Alerts you of potential damage to a program, device, or system.
Warning Alerts you of potential personal injury or fatality. May also alert you of potential electrical hazards.
Typeface Conventions Description

Text represented as a screen This typeface represents displays that appear on your terminal screen, for example:
display Login:
Text represented as commands This typeface represents commands that you enter, for example:
show ip access-list
This document always gives the full form of a command in lowercase letters. Commands
are not case sensitive.
Text represented as a command This typeface represents a variable that is part of a command, for example:
variable show card slot_number
slot_number is a variable representing the desired chassis slot number.
Text represented as menu or sub- This typeface represents menus and sub-menus that you access within a software
menu names application, for example:
Click the File menu, then click New
viii
About this Guide
Contacting Customer Support ▀
Contacting Customer Support

Use the information in this section to contact customer support.
Refer to the support area of http://www.cisco.com for up-to-date product documentation or to submit a service request.
A valid username and password are required to access this site. Please contact your Cisco sales or service representative
for additional information.
ix
About this Guide
▀ Additional Information
Additional Information
Refer to the following guides for supplemental information about the system:
 Cisco ASR 5000 Installation Guide
 Cisco ASR 5000 System Administration Guide
 Cisco ASR 5x00 Command Line Interface Reference
 Cisco ASR 5x00 Thresholding Configuration Guide
 Cisco ASR 5x00 SNMP MIB Reference
 Web Element Manager Installation and Administration Guide
 Cisco ASR 5x00 AAA Interface Administration and Reference
 Cisco ASR 5x00 GTPP Interface Administration and Reference
 Cisco ASR 5x00 Release Change Reference
 Cisco ASR 5x00 Statistics and Counters Reference
 Release notes that accompany updates and upgrades to the StarOS for your service and platform
x
Chapter 1
Enhanced Wireless Access Gateway Overview
This chapter provides an overview of the Enhanced Wireless Access Gateway (eWAG).
The following topics are covered in this chapter:
 Introduction
 Platform Requirements
 License Requirements
11
▀ Introduction
Introduction
Providing a consistent subscriber experience and supporting the ever exploding demand for bandwidth to provide data
services in 3G/4G networks is quickly becoming a big challenge for mobile operators. Widely prevalent Wireless Local
Area Network (WLAN) at public hotspots, private corporate networks, and so on have been viewed as providing a
viable alternative to 3G/4G radio and providing a solution to the overloading of radio networks by providing an
offloading solution. These Interworking WLAN (I-WLAN) provide subscriber access to 3G/4G networks making
services offered by operators universally available.
However, due to the inherent un-trusted nature of WLANs, the I-WLAN solution has been designed keeping security
aspects in view and so is based on IPSec. The IPSec-based solution requires a client to be installed on the UE. At this
point in the evolution of subscriber access from WLANs, the UE client has been a major stumbling block in the
deployment of I-WLANs.
On the other hand, trusted Wi-Fi networks provide a unique opportunity in converting WLANs into seamless extensions
of 3G/4G mobile networks, enabling improved subscriber experience, especially indoors which often suffers poor
cellular coverage, as subscribers are able to reach their 3G/4G services via both mobile and Wi-Fi accesses.
The Cisco® eWAG enables Wi-Fi integration into 3G mobile packet core (MPC), allowing clientless UE attached to
trusted Wireless Local Area Networks (WLANs) seamlessly access 3G services. In this case, the UE does not require a
client, it has no dependencies on the Wi-Fi architecture, and does not realize that it is connecting to a 3G network (3G
access is integrated with the normal UE-WLAN attach procedure).
The Cisco® eWAG can be configured in the following modes:
 RADIUS-based eWAG — This solution is based on RADIUS accounting messages generated by the WLAN
network. Here the UE attaches to the WLAN network after authentication and acquires an IP address, and then
the Accounting-Start message generated for the UE session from WLAN network is received at eWAG to
create the corresponding 3G session with the GGSN. This means that the 3G network operator will provide the
3G IP address and the UE has already obtained a Wi-Fi IP address during WLAN attachment procedure. So the
mobility between change of access is not possible as the UE changes its location.
For more information on R-eWAG, refer to the RADIUS-based Enhanced Wireless Access Gateway Overview
chapter.
 DHCP-based eWAG — This solution is based on the DHCP protocol and uses the IP address allocated by the
GGSN node for the UE attaching to the WLAN network. The IP address is maintained across the access. There
is no separate IP address space like 3G IP address and Wi-Fi IP address. D-eWAG achieves this by acting as
DHCP-Server to the Wi-Fi network and allocating the IP address to the WLAN UE directly when it tries to
attach to the WLAN network.
For more information on D-eWAG, refer to the DHCP-based Enhanced Wireless Access Gateway Overview
chapter.
12
Platform Requirements ▀
Platform Requirements
The eWAG service is supported on Cisco® ASR 5000 Series chassis running StarOS. The chassis can be configured
with a variety of components to meet specific network deployment requirements. For additional information, refer to the
Installation Guide for the chassis and/or contact your Cisco account representative.
13
▀ License Requirements
License Requirements
The eWAG is a licensed Cisco product. Separate session and feature licenses may be required. Contact your Cisco
account representative for detailed information on specific licensing requirements. For information on installing and
verifying licenses, refer to the Managing License Keys section of the Software Management Operations chapter in the
System Administration Guide.
14
Chapter 2
RADIUS-based Enhanced Wireless Access Gateway
Overview
This chapter provides an overview of the RADIUS-based Enhanced Wireless Access Gateway (R-eWAG).
 Product Overview
 Feature Description
 How it Works
 Dependencies and Limitations
15
RADIUS-based Enhanced Wireless Access Gateway Overview
▀ Product Overview
Product Overview
The Cisco® eWAG enables Wi-Fi integration into 3G mobile packet core (MPC), allowing clientless UE attached to
trusted Wireless Local Area Networks (WLANs) seamlessly access 3G services. In this case, the UE does not require a
client, it has no dependencies on the Wi-Fi architecture, and does not realize that it is connecting to a 3G network (3G
access is integrated with the normal UE-WLAN attach procedure).
Important: The eWAG enables 3GPP MPC access only from trusted Wi-Fi networks—802.1x for authentication
and Wi-Fi encryption is required.
The eWAG enables Wi-Fi sessions to be anchored on GGSN of the existing 3G networks via the Gn’ interface. On the
data plane, the eWAG accepts Layer 3 Wi-Fi packets, encapsulates them into GTP tunnels and sends them to the
GGSN. In the downlink direction, the eWAG de-capsulates the packets and sends them to the Wi-Fi network.
The unique advantages of the eWAG include:
 The Cisco® ASR5000 chassis on which the eWAG is deployed is a high capacity chassis that can support
millions of subscribers on a single chassis. Therefore, a single chassis is likely to support large session/capacity
requirements for several years to come.
 The Wi-Fi core does not need any enhancement apart from the Wi-Fi AAA, which must act as a RADIUS
accounting client towards the eWAG, with all data traffic routed to eWAG as the default nexthop.
 This solution enables optimal use of existing MPC infrastructure—PCRF, OCS, Billing, and so on. Billing and
other 3G/MPC services such as deep packet inspection (DPI) are available to subscribers attached to Wi-Fi via
the GGSN. Apart from the basic IP services, eWAG enables enhanced services such as offload, video
optimization, and on-deck services to the Wi-Fi UE. It also enables policy and charging for the Wi-Fi network,
and enables service providers to provide seamless service experience for subscribers in Wi-Fi network
regardless of their access type.
16
Product Overview ▀
Figure 1. eWAG-based MPC access from WLAN
Network Deployments and Network Interfaces

This section describes deployment options and network interfaces supported by the R-eWAG.
Network Deployments
The R-eWAG can be deployed in any of the following ways:
 Stand-alone R-eWAG deployment on an ASR 5000 chassis.
 Combo R-eWAG + GGSN deployment on the same ASR 5000 chassis.
Important: In this release, the following deployment options are not fully qualified and are not supported, these
are available only for lab testing purposes.
 Combo R-eWAG + TTG deployment on the same ASR 5000 chassis.

 Combo R-eWAG + TTG + GGSN deployment on the same ASR 5000 chassis.
17
Important: For information on dependencies and limitations of these deployment options see the Dependencies
and Limitations section.
Network Interfaces
The Gn’ reference point is located between the R-eWAG and the GGSN supporting GTPv1 and GTPv0 protocols. R-
eWAG supports GTP Path messages towards GGSN. Here, the R-eWAG acts as an SGSN and initiates the PDP Context
Creation procedure. For every UE, the R-eWAG creates one GTP tunnel with the GGSN. The UE’s APN and IMSI are
forwarded to the GGSN in the Create PDP Context Request message. This APN is either the subscribed APN from the
HLR for the connecting user, or the locally configured default APN at the R-eWAG.
18
Feature Description ▀
Feature Description
This section presents general description of features supported by the R-eWAG.
 RADIUS AAA Support
 Differentiated Services Code Point Marking
 Access Point Name Selection
 Quality of Service Profile Selection
 GGSN Selection
 GGSN Failover Case
 Network Address Translation and Application Level Gateway Support
 Virtual APN Support
 Offline Charging Support
 UE Identity and Location Information Support
 Lawful Intercept Support
 Bulk Statistics Support
 Threshold Crossing Alerts Support
 Congestion Control Support
 Redundancy Support
R-eWAG-WLC/Wi-Fi AAA Interface

The R-eWAG provisions a RADIUS server, as defined in RFC 2865, which enables the R-eWAG to act as a RADIUS
accounting server supporting receiving and responding to RADIUS accounting messages as defined in RFC 2866.
For the list of RADIUS attributes supported by R-eWAG, refer to the RADIUS-based Enhanced Wireless Access
Gateway AAA AVP Support appendix.
The R-eWAG provisions configuring one or more RADIUS clients (with corresponding authentication keys) to create a
trusted set of AAA. The R-eWAG discards RADIUS messages from any device that is not in the RADIUS client list.
The R-eWAG authenticates each RADIUS message using a configured authentication key. The R-eWAG creates a new
PDP context (for a subscriber session) upon receiving a valid RADIUS Accounting Start Request.
No 3GPP interface has been defined between WLAN and MPC. Therefore, RADIUS messages generated by core Wi-Fi
network (for example, from WLAN AAA client (WLC or ISG)) are used to provide WLAN session information (Wi-Fi
IP address of UE) to MPC and set up access side association. For this, RADIUS accounting messages
(Start/Interim/Stop) are used.
Many attributes required by MPC (IMSI, MSISDN, APN, Charging-Characteristics, and others) are not inherent in
WLAN access interactions. So, these have to be populated by a WLAN network entity after obtaining it from the MPC.
This enrichment is done by the Wi-Fi AAA. The Wi-Fi AAA interacts with the MPC AAA to obtain these attributes
when UE authentication (EAP over 802.1x) is initiated during initial WLAN attach. Wi-Fi AAA caches these attributes.
After successful authentication and session establishment, WLAN AAA-client (WLC or ISG) generates Accounting-
Start message. This message is proxied by Wi-Fi AAA, enriched with MPC-related attributes, and sent to R-eWAG.
19
▀ Feature Description
Here, Wi-Fi AAA acts as the RADIUS accounting client and R-eWAG as the RADIUS accounting server. R-eWAG
extracts the necessary attributes required to create the GTP tunnel to GGSN. R-eWAG resolves the APN to get the
GGSN address to which to create the GTP tunnel. In this release, the PDP context will be created with a dynamic IP
address. On successful creation of the GTP tunnel, R-eWAG creates the association between the GGSN-assigned IP
address and the Wi-Fi IP address.
All IP data packets generated by the UE in the WLAN are directed to the R-eWAG. The R-eWAG NATs the outer
source IP address (Wi-Fi IP address) with the GGSN-assigned IP address (MPC IP address) and forwards it to the
GGSN via the GTP tunnel. The application servers in the PDN identify the UE by the GGSN-assigned IP address.
In the downlink direction, the R-eWAG NATs the outer destination address (MPC IP address) to the Wi-Fi IP address
so that it is correctly routed to the UE in the WLAN.
Control and Data Interfaces

eWAG supports the following control and data interfaces:
 WLC/Wi-Fi AAA – R-eWAG:
 Control Plane: The following RADIUS messages are supported on this interface:
 Accounting Start
 Accounting Interim
 Accounting Stop
 Disconnect Request
 Data Plane: There is direct IP connectivity between WLC and R-eWAG. R-eWAG receives the original
IP packets generated by UE in WLAN. There could be other network elements (routers) between
WLC and R-eWAG, which can provide Layer 2 or Layer 3 tunneling to route the WLAN-generated
packets across the public network.
Important: In this release, R-eWAG does not support Tunneling (IP over GRE).
ICMP Processing: ICMP packets in the downlink direction are remapped and sent to the UE.
 eWAG – GGSN (Gn’):
 PDP Activation Messages: The following messages are supported over the Gn’ reference point:
 Create PDP Context Request / Response
 Update PDP Context Request / Response: R-eWAG-initiated Update PDP Context scenario is
supported as explained in the Session Update Call Flow section.
 Delete PDP Context Request / Response
 Error Indication
 Version Not Supported
 GTP Payload Forwarding
 GTP Echo
R-eWAG-GGSN Gn' Interface
20
IP Address Allocation
When a UE attaches to the WLAN network it obtains an IP address from the WLAN network (Wi-Fi IP address). Also,
when the R-eWAG creates PDP context with the GGSN, the GGSN assigns a remote MPC IP address to the UE. In the
Create PDP Context Request message the end-subscriber-address IE will be empty (indicating dynamic address
assignment by the GGSN), which makes the GGSN assign and return an IP address in the response message.
eWAG performs NAT between the Wi-Fi IP address and the MPC IP address during data transmission.
Network Layer Service Access Point Identifier Allocation

The R-eWAG allocates Network Layer Service Access Point Identifier (NSAPI) values before sending the Create PDP
Context Request message to the GGSN. Although the R-eWAG acts like an SGSN in terms of GTP tunnel
establishment, it also manages NSAPI allocation as WLAN UE's proxy for the purpose of leaving the Gn’-based R-
eWAG transparent to the WLAN UE.
Important: In this release, the R-eWAG always assigns the NSAPI value 15. For simultaneous GPRS and
WLAN connection with the same GGSN, if the UE uses NSAPI 15 for GPRS PDP context then context replacement
will occur at the GGSN.
Routing Area Identification Encoding

The Routing Area Identification (RAI) is encoded using PLMN-ID in “3GPP-SGSN-MCC-MNC”, if received in
Accounting-Start/Interim. Otherwise, the RAI is encoded using the MCC MNC or PLMN ID configured at the R-
eWAG.
Differentiated Services Code Point Marking

Differentiated Services Code Point (DSCP) levels can be assigned to specific traffic patterns in order to ensure that data
packets are delivered according to the precedence with which they are tagged. The DiffServ markings are applied to the
IP header for every subscriber data packet transmitted in the downlink and/or uplink direction. The four traffic patterns
have the following order of precedence:
1. Background (lowest)
2. Interactive
3. Streaming
4. Conversational (highest)
In addition, for class type Interactive, further categorization is done in combination with traffic handling priority and
allocation-retention priority. Data packets falling under the category of each of the traffic patterns are tagged with a
DSCP marking. Each traffic class is mapped to QCI value according to mapping mentioned in TS 23.203. Therefore,
DSCP values must be configured for different QCI values. The following table lists mapping for traffic class to QCI.
Table 1. Traffic Class to QCI Mapping
GPRS QoS Class Identifier Value UMTS QoS Parameters

Traffic Class THP Signalling Indication Source Statistics Descriptor
21

1 Conversational N/A N/A speech
2 Conversational N/A N/A unknown
3 Streaming N/A N/A speech
4 Streaming N/A N/A unknown
5 Interactive 1 Yes N/A
6 Interactive 1 No N/A
9 Background N/A N/A N/A
For the downlink path, DSCP markings can be configured to control the DSCP markings for downlink packets. IP
header of the packet is updated with the value in TOS field. Note that there is no tunnel at access side in R-eWAG,
hence TOS field in subscriber IP packet is marked with DSCP value directly.
For uplink traffic—traffic from R-eWAG to GGSN through GTP tunnel—DSCP markings can be configured. In this
case, only outer IP header is used to routing the packet over Gn’ interface. Hence, TOS field of only outer IP header is
changed, that is subscriber packet is not marked with DSCP value at R-eWAG.
DSCP marking can be configured with a “pass through” option, which when configured uses the marking received on
the ingress to mark packets on egress.
Access Point Name Selection

eWAG selects Access Point Name (APN) in the following manner:
 If the “Called-Station-ID” AVP is populated in the Accounting-Start Request received and the corresponding
APN is configured at R-eWAG, this APN is selected and call is accepted.
 If the “Called-Station-ID” AVP is populated in the Accounting-Start Request received and the corresponding
APN is not configured at R-eWAG, the call is dropped.
 If “Called-Station-ID” AVP is not populated in the Accounting-Start Request received, it is checked if the
default APN name is configured in the profile in service configuration. If that default APN is configured in R-
eWAG, the call is accepted.
 If the “Called-Station-ID” AVP is not populated in the Accounting-Start request received, it is checked if the
default APN name is configured in the profile in service configuration. If that default APN is not configured,
the call is dropped.
Important: Note that in all cases only the NI part (as in the APN definition) needs to be specified as APN name
in R-eWAG.
22
Quality of Service Profile Selection

If the “3GPP-GPRS-Negotiated-QoS-Profile” AVP is not supplied in Accounting-Start Request message, a default
Quality of Service (QoS) profile is used. This value is hardcoded to maximum values in the QoS profile as defined in TS
24.008.
GGSN Selection
In this release, R-eWAG assumes the presence of Operator Identifier (OI) in “mncXXX.mccYYY.gprs” format in APN
received in the “Called-Station-ID” AVP. However, no validation of the presence of OI is made. The “Called-Station-
Id” AVP content is sent to DNS for GGSN IP address resolution without any modification. The same is applicable if the
“Called-Station-Id” AVP is not present and the default APN configuration in the R-eWAG service is used. Note that in
both these cases only the Network Identifier (NI) part has to be configured as APN at R-eWAG.
GGSN Failover Case

In case the DNS server returns more than one GGSN address for the given APN, and if Create PDP Context Request to
GGSN fails due to the GGSN being unreachable, then the next GGSN address from the list of addresses will be tried.
The next GGSN address will also be tried in case the GGSN rejects Create PDP Context Request due to any of the
following reasons:
 No resources available
 All dynamic PDP addresses are occupied
 No memory available
 Missing or unknown APN
 System failure
 Unknown PDP address or PDP type
 All decode errors at peer, such as “Mandatory IE incorrect”, “Mandatory IE missing”, “Optional IE incorrect”,
and “Invalid message format”
The next GGSN will be tried until either the address list is exhausted or PDP context activation succeeds. Note that the
R-eWAG is concerned with only the first five reasons from the above list to retry the next GGSN.
The maximum limit for the number of GGSN addresses that can be retried is 31.
R-eWAG also has the ability to locally select a GGSN. This would be used in case a DNS server is unavailable or
unreachable. The GGSN IP addresses can be configured under the R-eWAG service in the CLI.
Network Address Translation and Application Level Gateway Support

For the interworking between trusted WLANs and 3G MPC, the R-eWAG uses Network Address Translation (NAT) in-
line service support to map Wi-Fi IP addresses to MPC IP addresses and vice versa.
A UE connected to Wi-Fi has IP address allocated from Wi-Fi. It will also have another IP address allocated from the
MPC. The translation involves remapping of the Wi-Fi IP address to the MPC IP address and vice versa in the IP header
as well as in the payload (Application Level Gateway (ALG)).
23
On successful creation of the GTP tunnel, the R-eWAG creates the association between the GGSN-assigned IP address
and the Wi-Fi IP address with static NAT support. The binding between the Wi-Fi IP address and GGSN IP address for
a subscriber is maintained by R-eWAG/NAT.
In the uplink direction, the R-eWAG accepts Layer 3 Wi-Fi packets, which are translated by NAT. The Source IP
address, which is the Wi-Fi IP address, is translated to the GGSN-assigned IP address. The translated packet is then
encapsulated into GTP tunnel and forwarded to the GGSN.
In the downlink direction, the R-eWAG de-capsulates the GTP packets and translates the destination IP address, which
is the GGSN IP address, to the Wi-Fi IP address and then forwards the packets to the Wi-Fi network.
The R-eWAG + NAT/ALG supports the ability to apply the FTP, SIP, RTSP, PPTP, and H323 ALG on the subscriber's
IP flows.
Important: eWAG call requires NAT configuration. Without NAT, R-eWAG call will not setup. For NAT/ALG,
R-eWAG service configuration requires rulebase configuration with NAT ALG enabled, IN and OUT ACL in APN, and
Firewall-and-NAT policy specified in the APN or rulebase. For R-eWAG + GGSN combo deployments, virtual-APN
configuration is required to separate the rulebases required for R-eWAG (for NAT) and GGSN (for DPI, NAT, P2P, and
others).
Virtual APN Support

The Virtual APN feature allows operators to use a single APN to configure differentiated services. The APN that is
supplied by the R-eWAG is evaluated by the GGSN in conjunction with configurable parameters. Then the GGSN
selects an APN configuration based on the supplied APN and those configurable parameters.
Important: For R-eWAG + GGSN combo deployments, the virtual-APN configuration is required to ensure that
the rulebases required for R-eWAG (for NAT) and GGSN (for DPI, NAT, P2P, and others) work without any issues.
For more information on virtual-APN support in R-eWAG + GGSN combo deployments refer to the Dependencies and
Limitations section.
Offline Charging Support

Offline Charging is a process wherein charging information is collected concurrently with resource usage. The charging
information is then passed through a chain of logical charging functions, and the CDR files are generated by the
network, which are then transferred to the network operator's Billing Domain.
The CTF (an integrated component in each charging relevant NE) generates charging events and forwards them to the
CDF. The CDF, in turn generate S-CDRs, which are then transferred to the CGF. Finally, the CGF create S-CDR files
and forwards them to the Billing Domain. The CTF and CDF are integrated in the R-eWAG. However, the CGF may
exist as a physically separate entity or integrated to the R-eWAG. If the CGF is external to the R-eWAG, then the CDF
forwards the CDRs to the CGF across the Gz/Wz interface (using GTPP protocol).
In the ASR5000 chassis, R-eWAG is integrated with the CTF and CDF functions and it generates S-CDR based on the
triggered events and sends the same to the CGF over the Gz/Wz interface. Note that the S-CDR format is used by
SGSN, and is now used for R-eWAG as well.
The R-eWAG Offline charging involves the following functionalities for WLAN 3GPP IP Access:
 Charging Trigger Function
 Charging Data Function
24
 Gz/Wz Reference Point
Triggers for Charging Information Addition and CDR Closure

The R-eWAG uses the Charging Characteristics to determine whether to activate or deactivate CDR generation. The
Charging Characteristics are also used to set the coherent chargeable event conditions (for example, time/volume limits
that trigger CDR generation or information addition). Multiple Charging Characteristics “profiles” may be configured in
the R-eWAG to allow different sets of trigger values.
Triggers for S-CDR Closure

The following events trigger closure and sending of a partial S-CDR:
 Time Trigger (every x seconds configured using “interval x”)
 Volume Trigger (every x octets configured using “volume x” (up/down/total))
 On reaching maximum number of container limit
 Command gtpp interim now
An S-CDR is closed as the final record of a session for the following events:
 UE-initiated call termination
 Admin release at R-eWAG via clear sub all
 GGSN-initiated call termination
 Abnormal releases due to multiple software failures.
Triggers for S-CDR Charging Information Addition

The “List of Traffic Volumes” attribute of the S-CDR consists of a set of containers, which are added when specific
trigger conditions are met, and identify the volume count per PDP context, separated for uplink and downlink traffic, on
encountering that trigger condition.
Billing Record Transfer

The S-CDRs generated can either be stored on Hard Disk (GSS) or can be transferred to the CGF. Local storage is also
available. Gz/Wz is the offline charging interface (CDR-based) between the GSN and the CGF. The R-eWAG supports
both GSS and GTPP-based record transfer.
UE Identity and Location Information Support

The R-eWAG supports sending UE identity and location information to the GGSN, which the GGSN can use for Lawful
Intercept support.
UE Identity Information Support

The R-eWAG receives UE identity information from the Wi-Fi AAA in the optional “SN-WLAN-UE-Identifier” AVP
included in Accounting-Start/Accounting-Interim message from the WLC. The R-eWAG encodes the UE identity
information into IMEIsV IE of Create PDP Context. The UE identity information is composed of the UE's MAC
25
address in the “Calling-Station-Id” AVP’s format as per RFC 3580, that is the MAC address in ASCII format (upper
case only), with octet values separated by hyphens. For example, “00-10-A4-23-19-C0”.
Important: Note that R-eWAG's encoding of the UE MAC address into IMEIsV is not standards based. This is
because the IMEIsV definition only allows values in the range of 0–9. While the MAC address hex values range from
0–F. TBCD encoding used for encoding IMEIsV on GTP allows the range 0–F. Also, when the UE MAC address is
encoded into IMEIsV in TBCD format, MAC address is encoded in the initial six bytes of IMEIsV IE. The last two
bytes get padded with FFFE in TBCD encoding. The last nibble is encoded as 0xE since if the ASR5000 GGSN
encounters F in the last nibble it drops the last byte considering it a filler. As all the 16 ASCII -hex characters have to be
sent to Gx, Gy, and CDR interfaces, the R-eWAG instead encodes the last two bytes as FFFE.
The SN-WLAN-UE-Identifier UE MAC to IMEIsV encoding is CLI controlled. Only if the map ue-mac-to-imei
CLI command is enabled in the R-eWAG service, mapping will take place and IMEIsV will be sent to the GGSN.
Important: Note that the “SN-WLAN-UE-Identifier” AVP is available only in the “starent” RADIUS dictionary.
Therefore, UE Identity Information support is available only if R-eWAG uses the “starent” RADIUS dictionary, if not
R-eWAG will ignore the AVP.
UE Location Information Support

The R-eWAG receives the access point identity information from the Wi-Fi AAA in the optional “SN-WLAN-AP-
Identifier” AVP included in Accounting-Start message from the WLC. The R-eWAG encodes this access point identity
information into ULI IE of Create PDP Context. In Accounting-Interim, if a new AP identifier is provided it is sent to
the GGSN in ULI IE of Update PDP Context. The access point identity is composed of the Location Area Code Cell
Identity (LAC_CI) — that is, Location Area Code (LAC) and Cell Id (CI) separated by an underscore. For example, if
the access point is assigned LAC = 123 and CI = 56789, then SN-WLAN-AP-Identifier AVP will contain 123_56789.
Important: Note that the “SN-WLAN-AP-Identifier” AVP is available only in the “starent” RADIUS dictionary.
Therefore, UE Location Information support is available only if R-eWAG uses the “starent” RADIUS dictionary, if not
R-eWAG will ignore the AVP.
Lawful Intercept Support

The Lawful Intercept (LI) functionality provides network operators the ability to intercept control and data messages of
suspicious subscribers. The ASR5000 chassis provides a proprietary interface to third-party Mediation Function (MF) or
Delivery Function (DF), and supports LI for R-eWAG.
For more information on LI support, contact your accounts representative.
Bulk Statistics Support

The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to
them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data
since it can be formatted to be parsed by external, back-end processors.
When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.
26
The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a
receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema.
For the list of supported schema and information on how to configure them, refer to the Enhanced Wireless Access
Gateway Configuration chapter.
The system supports the configuration of up to four sets (primary/secondary) of receivers. Each set can be configured
with to collect specific sets of statistics from the various schema. Statistics can be pulled manually from the system or
sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.
The format of the bulk statistic data files can are configurable, operators can specify the format of the file name, file
headers, and/or footers to include information such as the date, system host name, system uptime, the IP address of the
system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.
When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through
XML parsing, archiving, and graphing.
The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information
in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and
can send it to a Northbound NMS or an alternate bulk statistics server for further processing.
Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative
directory on the server. A specific directory can be configured by the administrative subscriber or the default directory
can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web
Element Manager server.
Important: For more information on bulk statistic configuration, refer to the Configuring and Maintaining Bulk
Statistics chapter in the System Administration Guide.
Threshold Crossing Alerts Support

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage.
Typically, these conditions are temporary (i.e. high CPU utilization, or packet collisions on a network) and are quickly
resolved. However, continuous or large numbers of these error conditions within a specific time interval may be
indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so
that immediate action can be taken to minimize and/or avoid system downtime.
There are no R-eWAG- or IPSG-specific thresholds available. However, thresholds for generic total/active sessions, call
setup/failure, license-level, system resource utilization like port/CPU, and others work with R-eWAG. With this
capability, operators can configure threshold on these resources whereby, should resource depletion cross the configured
threshold, an SNMP Trap will be sent.
The following thresholding models are supported by the system:
 Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high
threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of
the polling interval.
 Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches
or exceeds the configured high threshold within the specified polling interval. The alert is generated then
generated and/or sent at the end of the polling interval.
Thresholding reports conditions using one of the following mechanisms:
 SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of
each of the monitored values.
27
Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get
displayed. SNMP traps are supported in both Alert and Alarm modes.
 Logs: The system provides a facility called threshold for which active and event logs can be generated. As with
other system facilities, logs are generated. Log messages pertaining to the condition of a monitored value are
generated with a severity level of WARNING.
Logs are supported in both the Alert and the Alarm models.
 Alarm System: High threshold alarms generated within the specified polling interval are considered
“outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding”
alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in
the Web Element Manager.
The Alarm System is used only in conjunction with the Alarm model.
Important: For more information on thresholds, refer to the Thresholding Configuration Guide.
Congestion Control Support

The Congestion Control feature enables to specify how the system reacts in a heavy load condition. Congestion control
operation is based on configuring congestion condition thresholds and service congestion policies.
Important: Overload Disconnect is not supported.
Congestion Control monitors the system for conditions that could potentially degrade performance when the system is
under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are
quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an
impact the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and invokes
policies for addressing the situation.
Congestion control operation is based on configuring the following:
 Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled
and establishes limits for defining the state of the system (congested or clear). These thresholds function in a
way similar to operation thresholds that are configured for the system as described in the Thresholding
Configuration Guide. The primary difference is that when congestion thresholds are reached, a service
congestion policy and an SNMP trap are generated.
A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for
the condition to be cleared. An SNMP trap is then triggered.
 Port Utilization Thresholds: Congestion thresholds for utilization of all ports in the system.
 Port-specific Thresholds: Congestion thresholds for individual ports.
 Service Congestion Policies: Congestion policies are configurable for each service. These policies
dictate how services respond when the system detects that a congestion condition threshold has been
crossed.
 License Utilization: Congestion thresholds for license utilization on the system.
 Maximum Sessions-per-Service Utilization: Congestion thresholds for maximum number of sessions
allowed per service.
28
Important: For more information on Congestion Control feature, refer to the Congestion Control chapter in the
Redundancy Support
Important: In this release, R-eWAG supports basic Session Recovery, ICSR is not supported.
Session Recovery feature provides a mechanism to recover failed Session Manager (SessMgr) task(s) without any call
loss. Recovery framework is same as used by other products. A minimum of four PSCs (three active and one standby) is
required in an ASR 5000 chassis to support the Session Recovery feature. This is because the DEMUX Manager and
VPN Manager tasks run on a PSC where no SessMgr runs when session recovery is enabled and one PSC is used as
standby PSC. The other two PSCs run SessMgr and AAAMgr tasks.
Session Recovery is a licensed feature and can be controlled from the CLI, that is enabled/disabled Session Recovery
across the whole chassis. When the CLI is used to configure the Session Recovery feature, Session Controller updates
each SessMgr task.
In the case of R-eWAG, the IPSG Manager, SGTPC Manager, and VPN Manager run on one PSC. SessMgr runs on one
separate PSC. AAAMgr runs on one separate PSC and on one standby PSC. Therefore, a minimum of four PSCs (three
active and one standby) are required.
For R-eWAG Session Recovery support, existing IPSG Session Recovery framework is reused for recovering access
side attributes common between IPSG and R-eWAG sessions. New fields are added in IPSG Session Recovery record to
recover attributes specific to R-eWAG session such as WLAN IP address, MPC IP address, R-eWAG GTP information,
and so on. R-eWAG GTP context information will be recovered similar to TTG since Gn' interface is used by both.
29
▀ How it Works
How it Works
This section presents call procedure flows for the following scenarios:
 Session Setup
 Session Setup using Accounting-Interim
 Session Replacement
 Session Setup Failure
 Mandatory AVP Missing No Resource
 GTP Tunnel Setup Failure
 Session Update
 WLC-initiated Accounting Interim
 GGSN-initiated Update PDP Context
 Session Teardown
 UE Detach - Accounting Stop
 GGSN-initiated DPC
 eWAG TimeoutsAdmin Disconnect
Session Setup
This section presents call flow for the session setup scenario.
30
How it Works ▀
Figure 2. Session Setup Call Flow
31
▀ How it Works
Table 2. Session Setup Call Flow Descriptions
Step Description
1 The UE attaches to the WLAN network using WLAN attach procedure by selecting SSID advertised for 3G access.
2 The UE provides its EAP-identity for authentication in 802.1x message.
3 The WLC forwards the UE EAP-identity to the Wi-Fi AAA server in RADIUS Access-Request message by encapsulating
the EAP message in it. This message also contains the WLAN UE’s MAC Address and the WLAN Radio Network
Identifier.
4 The Wi-Fi AAA server proxies the Access-Request message to the 3GPP AAA server.
5 The 3GPP AAA server identifies the subscriber as a candidate for authentication with EAP-SIM/AKA based on the
received identity. It interacts with the HLR to fetch the GSM/UMTS authentication vectors for EAP-SIM/AKA
authentication and other 3GPP-specific attributes like IMSI, MSISDN, APN, and Charging Characteristics from the
subscriber’s profile.
6 The 3GPP AAA server sends Access-Challenge-Request to the UE as part of EAP-SIM/AKA authentication procedure to
the Wi-Fi AAA Proxy server.
7 The Wi-Fi AAA proxies the Access-Challenge message back to the WLC.
8 The WLC sends the EAP-Challenge message to the UE over 802.1x.
9 Similar EAP message exchanges happen between the UE and 3GPP AAA as part of the authentication procedure.
10 After successful authentication, the 3GPP AAA sends an Access-Accept message with 3GPP-specific attributes like IMSI,
MSISDN, Charging-Characteristics, APN, and others.
11 The Wi-Fi AAA server caches these 3GPP attributes in Access-Accept message, which will be later used to enrich the
RADIUS accounting messages generated from WLC and sent to the R-eWAG.
12 The Wi-Fi AAA proxies the Access-Accept message to the WLC.
13 The WLC sends the EAP-Success message over 802.1x to the UE and completes the authentication procedure.
14 The UE gets an IP address allocated from the Wi-Fi domain using the DHCP exchanges as per the normal WLAN
procedure of allocating IP address.
Note that the DHCP server allocating this IP address to the UE is part of the Wi-Fi domain, and the IP address thus
allocated is hereon referred to as the Wi-Fi IP address.
15 After the IP address is allocated to the attaching UE, the WLC initiates RADIUS accounting for the UE session by sending
a RADIUS Accounting-Start message to the Wi-Fi AAA.
16 The Wi-Fi AAA sends the Accounting-Response message back to the WLC as acknowledgement.
17 The Wi-Fi AAA server enriches the Accounting-Start message received with 3GPP-specific attributes as mentioned in Step
11. This modification of Accounting-Start message later helps the R-eWAG in creating the PDP context with the GGSN,
which requires 3G attributes like IMSI, MSISDN, APN, and others.
18 The Wi-Fi AAA server sends the Accounting-Start message enriched with the 3GPP-specific attributes to the R-eWAG.
19 The R-eWAG creates a new session based on this Accounting-Start message. It assumes the default APN configured under
R-eWAG service if it is not available in the Accounting-Start message. It also assigns a default QoS value for the R-eWAG
session if not available in the Accounting-Start message.
20 The R-eWAG identifies the GGSN it needs to connect with using the same 3G procedure of identifying GGSN from
SGSN(/TTG) using DNS resolution. The R-eWAG then sends the Create PDP Context Request message to the GGSN to
create the GTP tunnel.
32
How it Works ▀
Step Description
21 The GGSN processes the Create PDP Context Request and allocates the MPC IP address in the Create PDP Context
Response message. It also negotiates the QoS to be used for this subscriber session and sends the same in Create PDP
Context Response message.
22 The R-eWAG processes the Create PDP Context Response message, and creates the binding between the Wi-Fi IP address
and the MPC IP address in the R-eWAG session.
23 The R-eWAG sends an Accounting-Response message to the Wi-Fi AAA server to acknowledge the Accounting-Start
message.
24 The UE initiates data transfer to the destination in APN network with Source IP set to its Wi-Fi IP address. This packet gets
routed to the R-eWAG from the WLAN network.
25 The R-eWAG performs NAT on this data packet (Layer 3 to Layer 7), from Wi-Fi IP address to MPC IP address.
26 The R-eWAG sends the NATd IP packet encapsulated over the GTP-U tunnel created with the GGSN.
27 The GGSN decapsulates the IP packet received over the GTP-U tunnel and sends it to the destination APN network. Note
that this IP packet contains the source IP address set to the MPC IP address.
28 The data packet received in the downlink direction from the APN network is processed by the GGSN. This downlink
packet contains the destination IP address set to the MPC IP address.
29 The GGSN encapsulates the IP packet over the GTP-U tunnel and sends it downlink to the R-eWAG.
30 The R-eWAG performs reverse-NAT on the downlink IP packet (received over the GTP-U tunnel from the GGSN) and
converts all MPC IP addresses to Wi-Fi IP addresses from Layer 3 to Layer 7.
31 The R-eWAG sends the plain IP packet downlink to the UE.
Session Setup using Accounting-Interim

The R-eWAG supports session creation based on the first Accounting-Interim message for scenarios where RADIUS
Accounting-Start message cannot be generated with IPv4 address assigned to the UE, but can send an Accounting-
Interim message when IPv4 address actually gets assigned.
The iPhone is one such example where by default it starts in IPv6 mode. As the R-eWAG does not support IPv6, session
creation based on IPv6 address-based Accounting-Start is not possible. Therefore, if the interim create-new-call
CLI configuration is enabled, R-eWAG creates the session based on the first accounting-interim. If this configuration is
not enabled and the Accounting-Interim is received at R-eWAG, it will be acknowledged when existing session is found
for this message, else it gets dropped.
Note that once the session is created at R-eWAG, the consecutive Accounting-Interim messages received by R-eWAG
will be treated in the same way as in the case of session-creation based on Accounting-Start. This means that any
accounting-interim message that consists of AVPs (apn, acct-session-id, and others) that do not match existing session
parameters will get dropped (and call not replaced). So, in the iPhone scenario, the new call with the accounting-interim
will be created only after the existing session gets cleared using administrative reasons, idle-timeout, and so on. Until
then, R-eWAG will drop Accounting-Interim with different AVP values.
This section presents call flow for session setup using accounting-interim scenario.
33
▀ How it Works
Figure 3. Session Setup using Accounting-Interim Call Flow
34
How it Works ▀
Table 3. Session Setup using Accounting-Interim Call Flow Descriptions
Step Description
1 The UE attaches to the WLAN network using WLAN technology attach procedure by selecting SSID advertised for 3G
access.
2 The UE provides its EAP-identity for authentication in 802.1x message.
3 The WLC forwards the UE EAP-identity to the Wi-Fi AAA server through RADIUS Access-Request message by
encapsulating the EAP message in it. This message also contains the WLAN UE MAC Address and the WLAN Radio
Network Identifier.
4 The Wi-Fi AAA server proxies the Access-Request message to the 3GPP AAA server.
5 The 3GPP AAA server identifies the subscriber as a candidate for authentication with EAP-SIM/AKA based on received
identity. It interacts with the HLR to fetch the GSM/UMTS authentication vectors for EAP-SIM/AKA authentication and
other 3GPP-specific attributes from the subscriber profile, including IMSI, MSISDN, APN, and Charging Characteristics.
6 The 3GPP AAA sends the Access-Challenge-Request to the UE as part of EAP-SIM/AKA authentication procedure to the
Wi-Fi AAA proxy server.
7 The Wi-Fi AAA proxies the Access-Challenge message back to the WLC.
8 The WLC sends the EAP-Challenge message to the UE over 802.1x.
9 Similar EAP message exchanges happen between the UE and 3GPP AAA as part of authentication procedure.
10 After successful authentication, the 3GPP AAA sends an Access-Accept message with 3GPP-specific attributes including
IMSI, MSISDN, Charging-Characterstics, APN, etc.
11 The Wi-Fi AAA server caches the 3GPP attributes in the Access-Accept message, which will be later used to enrich the
RADIUS accounting messages generated from WLC and sent to the R-eWAG.
12 The Wi-Fi AAA proxies the Access-Accept message to the WLC.
13 The WLC sends the EAP-Success message over 802.1x to the UE and completes the authentication procedure.
14 The UE gets an IP address allocated from the Wi-Fi domain using DHCP exchanges as per the normal WLAN procedure of
allocating the IP address.
Note that the DHCP server allocating this IP address to the UE is part of Wi-Fi domain and the IP address thus allocated is
hereon referred to as the Wi-Fi IP address.
15 After the IP address is allocated to the attaching UE, the WLC initiates RADIUS accounting for the UE session by sending
RADIUS Accounting-Start message to the Wi-Fi AAA.
16 The Wi-Fi AAA server sends back the Accounting-Response to the WLC as acknowledgement.
17 The Wi-Fi AAA server sends the Accounting-Interim message enriched with 3GPP-specific attributes to the R-eWAG.
And, the R-eWAG creates the session based on this message and establishes GTP tunnel with the GGSN.
18 The R-eWAG creates new session based on this Accounting-Interim message. It assumes the default APN configured in the
R-eWAG service if it is not available in the Accounting-Interim message. It also assigns a default QoS value for the R-
eWAG session if not available in the Accounting-Interim message.
19 The R-eWAG identifies the GGSN to connect to using the same 3G procedure of identifying GGSN from SGSN/TTG
using DNS resolution. The R-eWAG then sends the Create PDP Context Request message to the GGSN to create the GTP
tunnel.
35
▀ How it Works
Step Description
20 The GGSN processes the Create PDP Context Request and allocates the MPC IP address in the Create PDP Context
Response message. It also negotiates the QoS to be used for the subscriber session and sends the same in the Create PDP
Context Response message.
21 The R-eWAG processes the Create PDP Context Response message and creates the binding between the Wi-Fi IP address
and the MPC IP address in the R-eWAG session.
22 The R-eWAG sends the Accounting-Response message to the Wi-Fi AAA server to acknowledge the Accounting-Interim
message.
23 The UE initiates data transfer to the destination in APN network with Source IP set to its Wi-Fi IP address. This packet gets
routed to the R-eWAG from the WLAN network.
24 The R-eWAG performs NAT on this data packet (Layer 3 to Layer 7), from Wi-Fi IP address to MPC-IP address.
25 The R-eWAG sends the NATd IP packet encapsulated over the GTP-U tunnel created with the GGSN.
26 The GGSN decapsulates the IP packet received over the GTP-U tunnel, and sends it to the destination APN network. Note
that this IP packet contains the source IP address set to the MPC IP address.
27 The data packet received in the downlink direction from the APN network is processed by the GGSN. This downlink
packet contains the destination IP address set to the MPC IP address.
28 The GGSN encapsulates the IP packet over the GTP-U tunnel and sends it downlink to the R-eWAG.
29 The R-eWAG performs reverse-NAT on the downlink IP packet received over the GTP-U tunnel from the GGSN, and
converts all MPC IP addresses to Wi-Fi IP addresses from Layer 3 to Layer 7.
30 The R-eWAG sends the plain IP packet downlink to the UE.
Session Replacement
Session identification at R-eWAG is done using the following parameters:
 Username+MSISDN combination
 Wi-Fi IP address
If the R-eWAG cannot identify the session for the received Accounting-Start message using the above parameters, then
session replacement will happen if any one of the above parameters matches existing session as explained below:
1. Matching session found at R-eWAG with same Username+MSISDN combo but containing different Wi-Fi IP
address. This is the scenario where the subscriber lost connectivity with Wi-Fi and is trying to reconnect again
with a different IP address.
2. Matching session found at R-eWAG with same Wi-Fi IP address but containing different Username+MSISDN
combo. This is the scenario where the subscriber has disconnected from Wi-Fi network and released the IP
address but the Accounting-Stop sent from WLC is lost/not received by R-eWAG. So the session at R-eWAG
will be stale during this time and when new Accounting-Start message comes with the same Wi-Fi IP address
as the existing session it will get replaced as this Accounting-Start message is for new subscriber with different
Username+MSISDN combo.
Important: In case of session replacement, old call will be disconnected with the session
disconnect reason “IPSG-session-replacement”.
36
How it Works ▀
If R-eWAG finds a matching session using the session identification parameters then the older session is
replaced with the newer session on receipt of the Accounting-Start message under the following conditions:
• Matching session found at R-eWAG with same Username+MSISDN and Wi-Fi IP address received in
the new Accounting-Start message but containing different APN. This is the scenario where the same
subscriber is trying to connect through different APN.
the new Accounting-Start message but containing different Accounting-Session-ID. This is the
scenario where the same subscriber is trying to connect again after loosing the previous session for
some reason (for example, got detached from the WLAN, UE restart, and so on).
the new Accounting-Start message but containing different NAS-IP-Address. This is the scenario
where the same subscriber is trying to connect again due to loosing the previous session for some
reason (for example, got detached from the WLAN, UE restart, and so on) and when the subscriber is
trying to re-connect it is coming through different WLC/ISG.
the new Accounting-Start message but containing different Source IP address. This is the scenario
where the same subscriber is trying to re-connect due to loosing the previous session for some reason
(for example, getting detached from the WLAN, UE restart, and so on) and when the subscriber tries
to re-connect it is coming through different Wi-Fi AAA.
the new Accounting-Start message but containing different IMSI. This negative scenario should not
occur as MSISDN and IMSI will have one-to-one mapping. However, the session will be replaced if
this scenario does happen and IMSI is handled in similar way as all the other parameters explained
earlier.
Important: In this release, R-eWAG does not support overlapping IP addresses. The IP addresses for all UEs
spread across all WLANs are expected to be unique.
Note that at any time, only one APN is supported for a subscriber. This is because APN selection is tied with WLAN
attach. UE can be connected to only one WLAN (SSID) at a time. So, during session establishment with R-eWAG only
one APN can be supplied in Accounting-Start. If a new request comes with same Username+MSISDN but a different
APN, it would mean that the UE lost connection with the WLAN and then re-attached.
Also, note that the IMSI and MSISDN should have one-to-one relationship. So, R-eWAG uses only MSISDN for
session-identification. In case where different IMSI arrives for same MSISDN call, the older call gets replaced as
explained above.
Session Setup Failure

This section presents call flows for setup failure scenarios.
A call setup request via Accounting-Start can fail due to any of the following reasons:
 Mandatory AVP Missing No Resource
 GTP Tunnel Setup Failure
R-eWAG supports sending RADIUS DM with UE MAC-address when call setup fails due to auth failure, no resource,
missing or unknown APN, and other reasons.
37
▀ How it Works
Mandatory AVP Missing / No Resource

This section presents call flow for the Session Failure – Mandatory AVP Missing and No Resource scenarios. When
missing AVPs carrying username, IMSI, MSISDN, Wi-Fi IP address, NAS-IP address, and Accounting-Session-ID.
And, for resource issues, such as license limit reached.
Figure 4. Session Failure Call Flow – Mandatory AVP Missing / No Resource
GTP Tunnel Setup Failure

This section presents call flow for the Session Failure – GTP Tunnel Setup scenario.
38
How it Works ▀
Figure 5. Session Failure Call Flow – GTP Tunnel Setup Failure
Session Update
This section presents call flows for the following session update scenarios:
 WLC-initiated Accounting Interim
39
▀ How it Works
 GGSN-initiated Update PDP Context
WLC-initiated Accounting Interim

This section presents call flow for the session update – WLC-initiated Accounting Interim scenario.
Figure 6. Session Update Call Flow – WLC-initiated Accounting Interim
GGSN-initiated Update PDP Context

This section presents call flow for the session update – GGSN-initiated Update PDP Context scenario.
GGSN-initiated Update PDP Context Request for QoS update is processed at R-eWAG and the QoS associated with the
session is updated. Update PDP Context Request for update of any other parameter will be rejected by R-eWAG. GGSN
might initiate a DPC because of this.
Important: Note that R-eWAG internally uses R7-QoS regardless of which QoS is requested and negotiated.
When R-eWAG receives UPC from GGSN, it compares it with the QoS requested by AAA and QoS with smaller
version is selected for UPC response. In case of same version, QoS with small Max-bit-rate (MBR) is selected.
40
How it Works ▀
Important: The R-eWAG does not generate any CoA RADIUS Request to Wi-Fi AAA as the R-eWAG acts as a
RADIUS accounting server towards Wi-Fi AAA and not as an authorization server.
Figure 7. Session Update Call Flow – GGSN-initiated Update PDP Context
Session Teardown
This section presents call flows for the following session teardown scenarios:
 UE Detach - Accounting Stop
 GGSN-initiated DPC
 eWAG TimeoutsAdmin Disconnect
UE Detach - Accounting Stop

This section presents call flow for the UE Detach - Accounting Stop scenario.
41
▀ How it Works
Figure 8. Session Teardown Call Flow – UE Detach - Accounting Stop
GGSN-initiated DPC
This section presents call flow for the Session Teardown – GGSN-initiated scenario.
Figure 9. Session Teardown Call Flow – GGSN-initiated DPC
42
How it Works ▀
eWAG Timeouts/Admin Disconnect

This section presents call flow for the Session Teardown – R-eWAG Timeouts and Admin Disconnect scenarios.
Figure 10. Session Teardown Call Flow – R-eWAG Timeouts/Admin Disconnect
43
▀ Dependencies and Limitations
Dependencies and Limitations

This section lists limitations to the R-eWAG in this release.
 IPSG-Service Configuration Restriction: Only one IPSG service must be configured per context. Multiple IPSG
services must not be configured in the same context as the IPSG will not be able to differentiate between uplink
and downlink packets.
 Overlapping-IP Address Support: Overlapping IP addresses are not supported in this release. This means that
two UEs cannot have the same WLAN-assigned IP address and still be able to access 3G services via R-
eWAG.
 NAT In-line Service Restrictions:
 NAT drops ICMP packets received in invalid state due to stateful checks.
 NAT supports only translation of TCP/UDP/ICMP packets. GRE translation is supported for PPTP-
GRE flows. All unsupported protocol packets will be dropped both in the uplink and downlink
directions.
 In case NAT is disabled on R-eWAG, the packets will not have NAT applied. But because of the
presence of redirect ACLs, packets will still go through ECS processing.
 The R-eWAG call gets created upon receiving Accounting Start Request from Wi-Fi AAA. Before
creation of the GTP tunnel between the R-eWAG and GGSN, if any data packets are received from
the Wi-Fi UE, such packets will be dropped at R-eWAG.
 Static NAT is the only type of NAT that will be performed on R-eWAG. Regular NAT/Stateful
Firewall will be disabled on R-eWAG even if configured through the policy.
If Static NAT is disabled on R-eWAG, then R-eWAG call will not have any kind of NAT/Firewall
enabled (policy configuration will not be applied). The packets will simply be processed by ECS and
forwarded.
 In this release, only static NAT44 is supported on R-eWAG.
eWAG + GGSN Combo Deployments

This section lists dependencies and limitations for R-eWAG + GGSN combo deployments.
Virtual APN Configuration in R-eWAG + GGSN Combo Deployments

eWAG destination context is the context where the SGSN GPRS Tunneling Protocol (SGTP) service is configured.
However, in the ASR 5000 chassis the R-eWAG operates based on APN profile. This means that when the GGSN (used
for connecting to APN) is also configured on the same chassis, it will use the same APN profile used by the R-eWAG
(assuming that the subscriber is connecting through R-eWAG to reach that APN using the collocated GGSN). So, when
some APN-specific configuration is added, it will be referred by both R-eWAG and GGSN call lines as they both refer
to the same APN in the configuration due to co-location.
For example, if the local-policy/Gx enabled in the GGSN for that APN for the purpose of charging, then there will be an
ACL configured in that APN to redirect all data packet to the ECS in-line service. As, in the same chassis, the same
APN configuration is referred by R-eWAG node as well, the data packets reaching R-eWAG callline will also get
redirected to ECS for charging because of ACL configuration, which is intended only for GGSN.
In order to avoid this issue, in collocated scenarios when the APN configuration is shared between R-eWAG and
GGSN, virtual-APN support is enabled in the R-eWAG so that R-eWAG+GGSN residing in the same chassis can use
44
Dependencies and Limitations ▀
different set of APN configurations. R-eWAG will use the virtual-APN and GGSN will be using the real-APN
configuration in this case.
Note that in the ASR 5000 chassis the virtual-APN selection can be based on other criteria apart from access gateway
(AGW) address selection like MSISDN range, RAT type, and so on. R-eWAG uses only AGW address criteria, which
is the RADIUS accounting-client from which the initial Accounting-Start message is received.
This way, the real-APN can be configured with virtual-APN selection based on RADIUS-client for R-eWAG, clearly
separating out the APN configuration being used by colocated R-eWAG+GGSN. So, after enabling virtual-APN for R-
eWAG in colocated chassis as explained above, the configurations under virtual-APN are used only by R-eWAG
callline and the configurations under real-APN will be used only by the GGSN callline without affecting each other.
Important: Note that if the virtual-APN profile configuration is not available for the virtual-APN name specified
under the real-APN, the call will get dropped with unknown-APN as the reason.
Consider the R-eWAG+GGSN combo deployment with an SGSN connecting to the GGSN for 3G access. In this case,
if the SGSN service's IP address subnet is 111.2.3.4/24 and the RADIUS accounting-client that is sending Accounting-
Start message to the R-eWAG is also in the same subnet 111.2.3.4/24, the virtual-APN is configured under real-APN as
follows:
virtual-apn preference 1 apn ewag_corp1 access-gw-addr 111.2.3.4/24
In the above case, when the call is coming through 3G macro-access and landing in GGSN, the virtual-APN criteria
matches for the GGSN call line as the AGW address in this case is SGSN node, which matches the subnet. So, the
GGSN call line will start using virtual-APN profile. In the same way, when the call is coming through Wi-Fi access
through R-eWAG, then the virtual-APN criteria matches for the R-eWAG callline as the AGW address in this case is
RADIUS accounting-client which matches the subnet. So the R-eWAG call line will start using virtual-APN profile as
well. Also, if the R-eWAG service's IP address subnet matches with the RADIUS accounting-client IP address and there
is a virtual-APN configuration based on this subnet range as AGW address, then both R-eWAG and GGSN call lines
start using the virtual-APN profiles only ignoring real-APN. This is because AGW address for R-eWAG call is
RADIUS accounting-client and the AGW address for GGSN call is R-eWAG (GTP-peer) and both of them are in the
same subnet making the virtual-APN condition to be true for both call lines. It is important to be aware of above
possibilities to avoid any mis-configurations or undetermined behavior.
eWAG + TTG Combo Deployments
Important: In this release, the R-eWAG + TTG combo deployment option is not fully qualified and is not
supported, it is available only for lab / testing purposes.
This section lists dependencies and limitations for R-eWAG + TTG combo deployments.
SGTP Service Configuration in R-eWAG + TTG Combo Deployments

The R-eWAG and TTG both require SGTP service configuration, and in a combo deployment they can share the same
SGTP service. Note that R-eWAG always allocates NASPI value 15, while TTG allocates NSAPI starting from 5
(maximum 15).
In an R-eWAG + TTG combo deployment sharing the same SGTP service:
 If R-eWAG call is setup with GTPv1 and TTG call comes up with the same IMSI and NSAPI 15 on same the
SessMgr, only GTPv1 Create PDP Context will be sent by SGTP. If Create PDP Context response for GTPv1
45
is not received then SGTP will not start with GTPv0. The call will be rejected with disconnect reason “act-
rejected-by-ggsn”. The same is true if the TTG call is setup first and then the R-eWAG call comes up.
 If the R-eWAG call is setup with GTPv0 and new TTG call with same IMSI and NSAPI 15 comes up on the
same SessMgr, the TTG call will be dropped with the cause “no resource”. The same is true if the TTG call is
setup first and then the R-eWAG call comes up.
 If the R-eWAG call and the TTG call with the same IMSI and same NSAPI land on different SessMgr call setup
is not affected.
eWAG + TTG + GGSN Combo Deployments
Important: In this release, the R-eWAG + TTG + GGSN combo deployment option is not fully qualified and is
not supported, it is available only for lab / testing purposes.
This section lists dependencies and limitations for R-eWAG + TTG + GGSN combo deployments.
The R-eWAG + TTG + GGSN combo setup works on a single chassis. For considerations, refer to the eWAG + GGSN
Combo Deployments and eWAG + TTG Combo Deployments sections.
Mobility Setup Considerations
Important: In this release, R-eWAG Mobility Support is not fully qualified and is not supported, it is available
only for lab / testing purposes.
3G-eWAG-TTG Mobility using Proxy-MIP at GGSN

 Different FA service should be used for all TTG APN, R-eWAG APN, and 3G APN. If the FA service is the
same, if one call is already present at GGSN and new call comes up with same IMSI different NSAPI on same
FA service, then previous GGSN call gets the registration response and new call is disconnected with MIP
timeout.
 CLI ip context name … configuration under APN is used to define the FA service to be used. FA service
under ip context name will be used by the APN. Note that there can be only one FA service per context.
 The authentication imsi-auth username-strip-apn CLI configuration should be used under the APN
so that HA will identify session just based on IMSI, and APN part will be stripped from the user name. This
will ensure same IP allocation to same IMSI.
 Issue at GGSN if new call comes up on same SessMgr with same IMSI and NSAPI, context replacement will
happen at GGSN. Even though the two calls are with two different GGSNs.
 If new GGSN call comes up with same IMSI, the GTPCMgr will always setup the new call on the same SessMgr
where the call is previously present. If a new call comes up with the same IMSI and same NSAPI, the context
replacement will happen at GGSN.
46
Chapter 3
RADIUS-based Enhanced Wireless Access Gateway
Configuration
This chapter provides information on configuring the RADIUS-based Enhanced Wireless Access Gateway (R-eWAG)
service.
 Before You Begin
 R-eWAG Configuration
 R-eWAG Administration
47
RADIUS-based Enhanced Wireless Access Gateway Configuration
▀ Before You Begin
Before You Begin

Before you can configure the R-eWAG service:
1. Confirm that the chassis on which the R-eWAG software will be configured has been set up as described in the
2. Confirm that the Enhanced Charging Service (ECS) in-line service is configured as described in the Enhanced
Charging Service Administration Guide. Also, confirm that the required license is installed.
3. Confirm that the Network Address Translation in-line service is configured as described in the Network Address
Translation Administration Guide. Also, confirm that the required license is installed.
4. Confirm that the R-eWAG license is installed.
The R-eWAG is a licensed Cisco product. Separate session and feature licenses may be required. Contact your
Cisco account representative for information on licensing requirements.
For information on installing and verifying licenses, refer to the Managing License Keys section of the
Software Management Operations chapter in the System Administration Guide.
48
R-eWAG Configuration ▀
R-eWAG Configuration
This section describes how to configure the R-eWAG service.
1. Create and configure the R-eWAG service as described in the Creating and Configuring the R-eWAG Service
section.
Important: Note that the R-eWAG service is the IPSG service configured in R-eWAG mode.
There is no separate R-eWAG configuration mode.
2. Create and configure an APN for R-eWAG as described in the Configuring the APN section.
3. Create and configure an SGTP service for R-eWAG as described in the Configuring the SGTP Service section.
4. Configure the NAT in-line service for R-eWAG as described in the Configuring NATALG Support section.
5. Save your configuration to the flash memory, an external memory device, and/or a network location using the
Exec Mode command save configuration. For additional information on how to verify and save
configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important: Commands used in the configuration examples in this section provide base functionality to the extent
that the most common or likely commands and/or keyword options are presented. In many cases, other optional
commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete
information regarding all commands.
Creating and Configuring the R-eWAG Service

This section describes how to create and configure an R-eWAG service.
 Creating the R-eWAG Service
 Configuring the R-eWAG Service
Creating the R-eWAG Service

To create the R-eWAG service use the following configuration:
configure
context <context_name> [ -noconfirm ]
ipsg-service <ipsg_service_name> mode radius-server ewag [ -noconfirm ]
end
Notes:
 The ewag keyword enables the R-eWAG service (IPSG service in R-eWAG mode), and enters the IPSG
RADIUS Server Configuration Mode, which is common for the R-eWAG and IPSG services.
49
▀ R-eWAG Configuration
 You can configure a maximum of 64 eWAG/IPSG services in the system, one per context. Only one IPSG
service must be configured per context. Multiple eWAG services must not be configured in the same context as
they will not be able to differentiate between uplink and downlink packets.
Configuring the R-eWAG Service

This section describes how to configure the R-eWAG service for the following deployments:
 Configuring Stand-alone R-eWAG Deployment
 Configuring R-eWAG GGSN Combo Deployment
Configuring Stand-alone R-eWAG Deployment

For a stand-alone R-eWAG deployment use the following configuration:
configure
context <context_name>
ipsg-service <ipsg_service_name> mode radius-server ewag
#To associate an SGTP service:
associate sgtp-service <sgtp_service_name> [ context <sgtp_context_name> ]
#To bind the R-eWAG service to a logical AAA interface and configure the number of
subscriber sessions allowed:
bind address <ipv4/ipv6_address> [ max-subscribers <max_sessions> | port

<port_number> | source-context <source_context_name> ]
#To configure location-specific mobile network identifiers:
plmn id mcc <mcc_number> mnc <mnc_number>
#To enable APN profile for R-eWAG and optionally configure the default APN:
profile APN [ default-apn <default_apn_name> ]
#To configure QoS DSCP parameters:
ip { gnp-qos-dscp | qos-dscp } qci { { { 1 | 2 | 3 | 4 | 9 } | { 5 | 6 | 7 | 8 }

allocation-retention-priority { 1 | 2 | 3 } } { af11 | af12 | af13 | af21 | af22 | af23 |
af31 | af32 | af33 | af41 | af42 | af43 | be | ef | pt } } +
#To configure RADIUS dictionary:
radius dictionary <dictionary_name>
#To configure RADIUS accounting parameters:
radius accounting { client { <ipv4/ipv6_address> | <ipv4/ipv6_address/mask> } [

encrypted ] key <key> [ acct-onoff [ aaa-context <aaa_context_name> ] [ aaa-group
50
<aaa_server_group_name> ] [ clear-sessions ] + ] [ dictionary <dictionary_name> ] [

disconnect-message [ dest-port <destination_port_number> ] + | interim create-new-call }
#To enable mapping of UE MAC address to IMEIsV IE of GTP message in order to send it to
the GGSN:
map ue-mac-to-imei
#To configure timeout for R-eWAG session setup attempts:
setup-timeout <setup_timeout>
end
Notes:
 In the APN profile configuration, <default_apn_name> specifies the default APN to be used for the R-eWAG
service. It should be configured as NI+OI for proper DNS resolution. Also, note that R-eWAG does not
support subscriber profile.
 <dictionary_name> specifies the RADIUS dictionary to use for the R-eWAG service. For information on
which dictionary to use in your deployment, contact your Cisco account representative. The default dictionary
is starent-vsa1.
 In the RADIUS accounting parameter configurations, the disconnect-message option enables sending
RADIUS accounting messages to the configured RADIUS accounting client if the call goes down due to any
failure. If this option is not configured, the R-eWAG will not send Disconnect-Message in call failure
scenarios.
 In the binding configuration, the source-context option specifies the source context where RADIUS
accounting requests are received. This keyword should be configured if the source of the RADIUS requests is
in a different context than the R-eWAG service. If not configured, the system will default to the context in
which the R-eWAG service is configured.
 The map ue-mac-to-imei CLI command supports enabling/disabling UE MAC to IMEI mapping. When
enabled, the UE MAC received in “Calling-Station-Id” RADIUS attribute is mapped to IMEIsV and sent in
GTP CPC message towards the GGSN.
Configuring R-eWAG + GGSN Combo Deployment

To configure the R-eWAG service for an R-eWAG + GGSN combo deployment use the following configuration:
configure
ipsg-service <ipsg_service_name> mode radius-server ewag
#To bind the R-eWAG service to a logical AAA interface and configure the number of

<port_number> | source-context <source_context> ]
51
#To enable APN profile for R-eWAG and optionally configure the default APN:
profile APN [ default-apn <apn_name> ]


<aaa_server_group_name> ] [ clear-sessions ] + ] [ dictionary <dictionary> ] [
the GGSN:
map ue-mac-to-imei
#To configure timeout for R-eWAG session setup attempts:
end
Notes:
 In the APN profile configuration, <default_apn_name> specifies the default APN to be used for the R-eWAG
service. It should be configured as NI+OI for proper DNS resolution. Also, note that R-eWAG does not
support subscriber profile.
 <dictionary_name> specifies the RADIUS dictionary to use for the R-eWAG service. For information on
which dictionary to use in your deployment, contact your Cisco account representative. The default dictionary
is starent-vsa1.
 In the RADIUS accounting parameter configurations, the disconnect-message option enables the sending of
RADIUS accounting messages to the configured RADIUS accounting client when call goes down due to any
failure. Note that without this enabled, R-eWAG will not send Disconnect-Message in call failure scenarios.
in a different context than the R-eWAG service. If not configured, the system will default to the context in
which the R-eWAG service is configured.
52
 R-eWAG has the ability to locally select a GGSN. This would be used in case a DNS server is unavailable or
unreachable at the moment. For this purpose, use the gtp peer-ip-address <ipv4_address> CLI
command.
Configuring the APN

This section describes how to configure an APN for the R-eWAG service. The R-eWAG uses APN configuration to
specify certain attributes in the subscriber profile.
To create and configure an APN for R-eWAG use the following configuration:
configure
apn <apn_name>
#To configure the accounting mode:
accounting-mode none
#To specify the ACS rulebase:
active-charging rulebase <ecs_rulebase_name>
#To specify the IP access group:
ip access-group <access_list_name> in
ip access-group <access_list_name> out
#To specify the Firewall-and-NAT policy to use for NAT support:
fw-and-nat policy <fw_nat_policy_name>
#To configure alternative APN to be used by R-eWAG:
virtual-apn preference <preference> apn <virtual_apn_name> access-gw-address {

<radius_client_ipv4/ipv6_address> | <radius_client_ipv4/ipv6_address/mask> }
end
Notes:
 In the ASR 5000 chassis, virtual APN selection can be based on other criteria apart from Access Gateway
address (access-gw-address) selection, such as the MSISDN range, RAT type, and so on. However, only
the access gateway address criteria is applicable to the R-eWAG, which is the RADIUS accounting client from
which the initial Accounting-Start message is received.
Note that for stand-alone R-eWAG deployments virtual APN is not mandatory.
53
 For more information on virtual APN in R-eWAG + GGSN combo deployments, refer to the Enhanced Wireless
Access Gateway Overview chapter.
 In the IP access group configuration, the access list ( <access_list_name>) specified must be configured in
the destination context with ECS redirect ACL. See the Access List Configuration section.
 For R-eWAG, the Firewall-and-NAT policy for subscribers can be specified either in the APN template or in the
ECS rulebase. For selection, the policy specified in the APN configuration has higher priority than the one
specified in the ECS rulebase configuration.
Configuring the SGTP Service

To create and configure the SGTP service use the following configuration:
configure
sgtp-service <sgtp_service_name>
#To configure GTP-C parameters:
gtpc { bind address <ipv4_address> | dns-sgsn context <context_name> | echo-

interval <echo_interval_seconds> | echo-retransmission { exponential-backoff [ [ min-
timeout <min_retrans_timeout_seconds> ] [ smooth-factor <smooth_factor> ] + ] | timeout
<retrans_timeout_seconds> } | guard-interval <guard_interval_seconds> | ignore response-
port-validation | ip qos-dscp { af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 |
af33 | af41 | af42 | af43 | be | ef } | max-retransmissions <max_retransmissions> |
retransmission-timeout <retrans_timeout_seconds> | send { common flags | rab-context |
target-identification-preamble } }
#To configure GTP-U parameters:
gtpu { bind address <ipv4_address> | echo-interval <echo_interval_seconds> |

echo-retransmission { exponential-backoff [ [ min-timeout <min_retrans_timeout_seconds> ]
[ smooth-factor <smooth_factor> ] + ] | timeout <retrans_timeout_seconds> } | max-
retransmissions <max_retransmissions> | retransmission-timeout <retrans_timeout_seconds>
}
#To configure path failure detection policy:
path-failure detection-policy gtp { echo | non-echo } +
#To configure the restart counter change window to avoid service deactivations and
activations that could cause large bursts of network traffic if the restart counter
change messages from the GGSN are erroneous:
max-remote-restart-counter-change <variance>
end
Notes:
 The SGTP service must be associated in the R-eWAG service configuration.
54
Configuring NAT/ALG Support

This section explains NAT/ALG related configurations.
For R-eWAG, the Firewall-and-NAT policy for a subscriber can be specified either in the APN template or in the ECS
rulebase. For selection, the policy specified in the APN configuration has higher priority than the one specified in the
ECS rulebase configuration.
 Configuring ECS Rulebase with Firewall-and-NAT Policy
 Configuring APN with Firewall-and-NAT Policy
 Configuring Routing Rules and NAT ALG
Configuring ECS Rulebase with Firewall-and-NAT Policy

To specify the Firewall-and-NAT policy in an ECS rulebase use the following configuration:
configure
active-charging service <ecs_service_name>
rulebase <rulebase_name>
fw-and-nat default-policy <fw_nat_policy_name>
end
Configuring APN with Firewall-and-NAT Policy

To specify the Firewall-and-NAT policy to use in an APN use the following configuration:
configure
apn <apn_name>
fw-and-nat policy <fw_nat_policy_name>
end
Configuring Routing Rules and NAT ALG

The routing rules must be configured in the ECS service and the routing rule priorities must be configured in the ECS
rulebase for routing packets to the respective analyzers for performing NAT ALG processing.
configure
active-charging service <ecs_service_name>
#To configure routing ruledefs:
#FTP ALG:
55
ruledef <ftp_control_ruledef_name>
tcp either-port <operator> <value>
rule-application routing
exit
ruledef <ftp_data_ruledef_name>
exit
#SIP ALG:
ruledef <sip_ruledef_name>
udp either-port <operator> <value>
exit
#RTSP ALG:
ruledef <rtsp_ruledef_name>
exit
#PPTP ALG:
ruledef <pptp_ruledef_name>
exit
#TFTP ALG:
ruledef <tftp_ruledef_name>
exit
#H323 ALG:
56
ruledef <h323_ruledef_name>
exit
ruledef <h323_multi_ruledef_name>
exit
ruledef <h323_tcp_ruledef_name>
exit
#To configure the routing rule priorities in the rulebase:
rulebase <rulebase_name>
route priority <route_priority> ruledef <ftp_control_ruledef_name> analyzer ftp-

control
route priority <route_priority> ruledef <ftp_data_ruledef_name> analyzer ftp-

data
route priority <route_priority> ruledef <rtsp_ruledef_name> analyzer rtsp
route priority <route_priority> ruledef <pptp_ruledef_name> analyzer pptp
route priority <route_priority> ruledef <tftp_ruledef_name> analyzer tftp
route priority <route_priority> ruledef <sip_ruledef_name> analyzer sip advanced
route priority <route_priority> ruledef <h323_ruledef_name> analyzer h323
route priority <route_priority> ruledef <h323_multi_ruledef_name> analyzer h323
route priority <route_priority> ruledef <h323_tcp_ruledef_name> analyzer h323
exit
#To enable payload (Layer 7) translation of IP packets, in the ECS service:
firewall nat-alg ftp
firewall nat-alg pptp
firewall nat-alg rtsp
57
firewall nat-alg sip
firewall nat-alg h323
end
Notes:
 For more information on ECS ruledef and rulebase configurations, refer to the Enhanced Charging Service
Administration Guide.
Additional Configurations
This section covers the following configurations:
 Configuring Access Lists
 Configuring Bulk Statistics
 Configuring Congestion Control
 Configuring Offline Charging for R-eWAG
 Configuring Session Recovery
Configuring Access Lists

To create and configure an ACL to use in steering subscriber traffic through ECS, use the following configuration:
configure
ip access-list <access_list_name>
redirect css service <ecs_service_name> <keywords> <options>
end
Notes:
 <ecs_service_name> must be the name of the enhanced charging service; no CSS service has to be
configured.
Configuring Bulk Statistics

To configure bulk statics collection for R-eWAG service, use the following configuration:
configure
bulkstats mode
ipsg schema <schema_name> format <schema_format>
end
58
Notes:
 For detailed information on R-eWAG-related bulk statistics available in the IPSG schema, refer to the IPSG
Schema chapter of the Statistics and Counters Reference, and for those available in the System schema, refer to
the System Schema chapter of the Statistics and Counters Reference.
 Apart from the IPSG and System schema, as needed you can also configure variables available in the other
schema, including:
 APN: For Access Point Name (APN) related statistics
 Card: For card-level statistics
 Context: For context service related statistics
 ECS: For Enhanced Charging Service related statistics
 Port: For port-level statistics
 RADIUS: For per-RADIUS server statistics
 The following is a sample schema format for R-eWAG statistics:
“eWAG Schema: Test\n ----------------------\nVPN Name:%vpnname%,\nService
Name:%servname%,\n Session Statistics: \n Total Current Sessions
:%total_current_sessions%,\n Total Sessions Setup: %total_sessions_setup%,\n -----
-----------------\n”
Configuring Congestion Control

To enable Congestion Control, use the following configuration:
configure
#To enable Congestion Control:
congestion-control
#To configure Congestion Control policy:
congestion-control policy ipsg-service action { drop | none }
#To configure Congestion Control thresholds:
congestion-control threshold { { license-utilization | max-sessions-per-service-

utilization | message-queue-utilization | port-rx-utilization | port-specific {
<slot/port> | all { rx-utilization | tx-utilization } } | port-specific-rx-utilization |
port-specific-tx-utilization | port-tx-utilization | service-control-cpu-utilization |
system-cpu-utilization | system-memory-utilization | tolerance } [ critical ]
<percentage> | message-queue-wait-time [ critical ] <seconds> | { port-specific-rx-
utilization | port-specific-tx-utilization } [ critical ] }
end
Notes:
 Congestion policies are configurable for each service. These policies dictate how the services respond when the
system detects that a congestion condition threshold has been crossed. For more information on the Congestion
Control feature, refer to the Congestion Control chapter of the System Administration Guide.
59
 In the above configuration, the Congestion Control thresholds featured are at the system level and are not
specific to R-eWAG.
 R-eWAG supports only critical threshold values.
Verifying your Configuration

To verify your Congestion Control configuration, in the Exec Mode issue the following command:
show congestion-control configuration
The output of this command displays information including whether or not Congestion Control is enabled/disabled,
Congestion Control threshold parameter settings, Congestion Control policy, and more.
Configuring Offline Charging for R-eWAG

To configure Offline Charging for R-eWAG, use the following configuration:
configure
gtpp single-source
#To configure GTPP Group:
gtpp group <gttp_group_name>
#To configure charging agent:
gtpp charging-agent address <ip_address>
#To configure GTPP dictionary:
gtpp dictionary <gtpp_dictionary>
#To configure remote server address:
gtpp server <ip_address>
#To configure triggers:
gtpp trigger volume-limit
#To configure CDR attributes:
gtpp attribute local-record-sequence-number
gtpp attribute msisdn
gtpp attribute rat
exit
#To configure accounting policy:
60
policy accounting <accounting_policy>
cc profile <profile_bit_value> volume total <no_of_octets>
exit
#To configure accounting in IPSG service configuration:
ipsg-service <service_name> mode radius-server ewag
associate accounting-policy <accounting_policy_name>
accounting-context <ewag_accounting_context_name>
exit
#To configure APN mode:
apn <apn_name>
accounting-mode gtpp
gtpp group <gtpp_group_name> accounting-context <ewag_accounting_context_name>
end
Notes:
 For information on the GTPP dictionary to use contact your Cisco account representative.
 Optional APN-level configuration to override charging characteristics supplied in Acct-Start:
configure
apn <apn_name>
cc-ipsg { { home-subscriber-use-local | roaming-subscriber-use-

local | visiting-subscriber-use-local } + | all-subscriber-use-local
behavior <bits> profile <index> }
cc-home behavior bits profile <index>
cc-roaming behavior bits profile <index>
cc-visiting behavior bits profile <index>
end
Configuring Session Recovery

To enable Session Recovery use the following configuration:
configure
61
require session recovery
end
Notes:
 For more information on the Session Recovery feature, refer to the Session Recovery chapter of the System
 A valid feature key is required for this configuration. This command enables/disables the feature to try to
perform hitless session recovery for all session types supported by the software release. After enabling session
recovery through this configuration, make sure that session recovery status is “ready”.
62
R-eWAG Administration ▀
R-eWAG Administration
This section describes R-eWAG administrative procedures.
This section includes the following topics:
 Logging Support
 Protocol Monitoring Support
 Gathering R-eWAG-related Statistics and Information
Logging Support
To view IPSG-related logs, in the Exec Mode use the following command:
logging filter active facility { ipsg | ipsgmgr } level <severity_level> [ critical-info

| no-critical-info ]
To view SGTP-related logs, in the Exec Mode use the following command:
logging filter active facility { sgsn-gtpc | sgsn-gtpu | sgtpcmgr } level

<severity_level> [ critical-info | no-critical-info ]
To view SessMgr-related logs, in the Exec Mode use the following command.
SessMgr info level log having event ID 12077 displays the mapping between WLAN IP address and MPC IP address
along with subscriber information, including Username, IMSI, MSISDN, and APN.
logging filter active facility sessmgr level <severity_level> [ critical-info | no-

critical-info ]
Protocol Monitoring Support

The system provides protocol monitor and test utilities that can are useful when troubleshooting or verifying
configurations. The information generated by these utilities can in many cases either identify the root cause of a
software or network configuration issue or, at the very least, greatly reduce the number of possibilities.
For troubleshooting purposes, the system provides a powerful protocol monitoring utility. This tool can be used to
display protocol information for a particular subscriber session or for every session being processed.
For more information on Monitor Protocol and Monitor Subscriber, refer to the System Administration Guide.
Monitor Protocol
The system’s protocol monitor displays information for every session that is currently being processed. Depending on
the number of protocols monitored, and the number of sessions in progress, a significant amount of data is generated. It
is highly recommended that logging be enabled on your terminal client in order to capture all of the information that is
generated.
To view monitor protocol based logging information, in the Exec Mode use the following command:
63
▀ R-eWAG Administration
monitor protocol
For R-eWAG use the following filters:

 41 - IPSG RADIUS Signal: Must be used to view the RADIUS accounting messages on the control path for
IPSG session management.
 24 - GTPC
 26 - GTPU
Monitor Subscriber
The system’s protocol monitor can be used to display information for a specific subscriber session that is currently
being processed. Depending on the number of protocols monitored, and the number of sessions in progress, a significant
amount of data is generated. It is highly recommended that logging be enabled on your terminal client in order to
capture all of the information that is generated.
To view monitor subscriber based logging information, in the Exec Mode use the following command:
monitor subscriber
The following filters are available for monitor subscriber based logging in R-eWAG.
 By MSID/IMSI
 By IP Address
 By MSISDN
 Next-IPSG Call
 By Username
Gathering R-eWAG-related Statistics and Information

Table 4. R-eWAG Statistics and Information
eWAG-related statistics or information CLI command to use

To view concise R-eWAG service-level information. show ipsg service all
To view detailed R-eWAG service-level information. show ipsg service all verbose
To view R-eWAG service-level statistics, including session and show ipsg statistic
RADIUS message-level statistics.
To view R-eWAG session counter information. show ipsg sessions counters
To view R-eWAG subscriber information. show subscribers ipsg-only
To view detailed R-eWAG session information, for all sessions. show ipsg sessions full all
To view detailed subscriber information, for all subscribers. show subscribers full all
To view session progress information for in-progress calls. show session progress
To view IPSG Manager related information. show session subsystem facility ipsgmgr
64
R-eWAG Administration ▀
eWAG-related statistics or information CLI command to use

To view APN-related information. show apn name <apn_name>
To view APN-related statistics. show apn statistics
To view SNMP trap history. show snmp trap history | grep IPSG
To view SNMP trap statistics, for all services including R-eWAG show snmp trap statistics
and SGTP.
To view Congestion Control statistics for IPSG Manager. show congestion-control statistics ipsgmgr
To view Congestion Control configuration. show congestion-control configuration
To view NAT-related statistics. show active-charging firewall statistics
To view ECS session-level information. show active-charging sessions
To view detailed ECS session-level information. show active-charging sessions full
To view information for subscribers with NAT enabled. show subscribers nat required
To view information for ECS flows with NAT enabled. show active-charging flows full nat required
To view information for all ECS flows. show active-charging flows all
To view ECS statistics for specific analyzer. show active-charging analyzer statistics
name <analyzer_name>
To view ECS statistics for specific rulebase. show active-charging rulebase name
<rulebase_name>
To view detailed ECS subsystem-level information. show active-charging subsystem all
To view GTPP statistics. show gtpp statistics
65
Chapter 4
DHCP-based Enhanced Wireless Access Gateway
Overview
This chapter describes the DHCP-based Enhanced Wireless Access Gateway (D-eWAG) solution.
 Product Overview
 How it Works
 Dependencies and Limitations
67
DHCP-based Enhanced Wireless Access Gateway Overview
Product Overview
The D-eWAG solution described in this chapter is designed for centralized WLAN deployments, wherein Access Points
(APs) spread across geographical locations provide Wi-Fi access, and Wireless LAN Controllers (WLCs) located in a
central server farm control all the APs.
Figure 11. D-eWAG Deployment
The D-eWAG acts as first-hop L3 router to WLC with direct connectivity between them and is located in the central
server farm. With the use of Service Set Identification (SSID)-based WLAN access, subscribers can be authenticated
based on the SSID that they use in order to connect to the WLAN. The AP/WLC maintains a separate SSID for
providing 3G access. This enables the UE to select the correct SSID for obtaining 3G access through the Wi-Fi network.
The D-eWAG also acts as the AAA Proxy and the DHCP server to the UE attaching to the WLAN network. This helps
in processing all the control packets from the UE and maintaining the subscriber session to provide 3G access. While
acting as DHCP server, D-eWAG creates the PDP-Context with GGSN to obtain the IP address to be allocated to the
UE through DHCP-Response in the access side. Note that this interface with GGSN is similar to the TTG's Gn' interface
with GGSN in 3GPP.
When the UE wants to gain 3G access through the Wi-Fi network, the subscriber selects the 3G-SSID from the list of
advertised SSIDs.
The WLAN attach procedure occurs in three stages:
1. Association process
2. 802.1x EAP-SIM/AKA authentication process
3. IP address allocation process
These three steps are transparent to the subscriber accessing the Wi-Fi network and do not involve any subscriber
intervention. At the end of the WLAN attach procedure, the UE connects to the 3G network.
68
Deployment Models
The D-eWAG can be deployed in any of the following ways:
 Stand-alone D-eWAG deployment on an ASR 5000 chassis.
 Combo D-eWAG + GGSN deployment on the same ASR 5000 chassis.
Important: In this release, the following deployment option is not qualified and is not supported, it is available
only for lab testing purposes.
 Combo D-eWAG + R-eWAG deployment on the same ASR 5000 chassis.
Important: For assumptions and dependencies pertaining to the network models discussed in this section, refer
to the Dependencies and Limitations section.
Supported network deployment models:

 One SSID mapped to one VLAN mapped to one APN.
 Each SSID should always be mapped to a unique VLAN in this case, even if it is served using multiple
WLCs.
 Different VLAN used for all UE sessions connecting through different SSIDs and uplink packets can be
identified uniquely with {VLAN+Source IP} at D-eWAG.
 One SSID mapped to one VLAN mapped to multiple APN.
 Each SSID should always be mapped to a unique VLAN in this case, even if it is served using multiple
WLCs.
 Same VLAN used for all UE sessions and so the uplink packets cannot be identified uniquely with
{VLAN+Source IP} at D-eWAG as there can be overlapping IP addresses in this case.
 This type of deployment is needed to ensure that the multiple APNs being served do not contain
overlapping IP address space.
 One SSID mapped to multiple VLAN mapped to one APN.
 WLCs can be different with different VLAN for same SSID.
 WLC can be configured with AP-Group to use different VLAN.
 Set of VLANs serving one APN are different from set of VLANs serving another APN. Hence,
overlapping IP address is not an issue in this case as the session can be identified uniquely using
{VLAN+Source IP}.
3G-SSID
The SSID created in Wi-Fi network for 3G access through D-eWAG is referred to as 3G-SSID. The following options
(not restricted to) can be considered for 3G-SSID creation in Wi-Fi networks:
 Each SSID (or WLAN) represents particular APN network access of an operator. One SSID per APN case.
 Each SSID (or WLAN) represents particular operator itself. This is one SSID per operator scenario where multiple APN
served by that operator can be accessed through this SSID. This means that the different users connecting through this
69
SSID can be subscribed to different APN served by that operator. All the users can gain access to their subscribed APN
network as the 3GPP-AAA server will return the subscribed APN to D-eWAG and selects GGSN based on that.
Association Process
During the 802.11 Association process, the access points allocate resources for UE communication and synchronize
with the UE. This is as per the standard 802.11 process and D-eWAG is not involved in this process.
802.1x EAP-SIM/AKA Authentication Process

After the association process has completed:
 AP/WLC asks for UE identity by sending EAP-ID request through 802.1x authentication. Both EAP-AKA and EAP-SIM
authentication methods are supported in this model.
 UE sends its EAP-Identity in the form “IMSI@realm” in EAP-ID-Response message.
 This EAP-ID-Response message is sent to the AP/WLC where it creates the corresponding RADIUS Access-Request to
the AAA Server. Note that the AAA server for this 3G-SSID is D-eWAG. Thus, the Access-Request message is sent to
D-eWAG over the VLAN mapped to that 3G-SSID (3G-WLAN) from WLC.
 D-eWAG acting as AAA-Proxy uses this RADIUS Access-Request message and uses the same as First Sign of Life
(FSoL) for UE session creation and stores the UE's MAC address (Calling-Station-ID) to uniquely identify the session.
 D-eWAG selects the 3GPP-AAA server for UE authentication based on the realm part received in the user-identity
(inside RADIUS Access-Request) and proxies the Access-Request to that server. If the realm part is not available in the
EAP-Identity, then the locally configured default 3GPP-AAA server is selected. This way the normal EAP-SIM/AKA
authentication procedure will continue between UE and 3GPP-AAA server with D-eWAG acting as AAA-Proxy.
 At the end of the authentication procedure, D-eWAG caches all the 3GPP-specific parameters used for PDP-Context
Creation with GGSN (like MSISDN, APN, Charging-Char, etc.) from the Access-Accept message. The 3GPP-AAA
server sends all the 3G attributes in the Access-Accept message (similar to PDG/TTG in 3GPP).
IP Address Allocation Process

After successful authentication using 802.1x in WLAN, the UE initiates the DHCP signaling message to obtain the IP
address. The WLC should be configured as DHCP-Relay-Agent and the D-eWAG IP address should be configured as
the external DHCP-Server at WLC for 3G-SSID. The DHCP-Discover broadcast message from UE is processed by
WLC (DHCP relay) and sent as Unicast DHCP-Discover Request to D-eWAG (DHCP-Server) over the mapped VLAN.
This DHCP-Discover message contains the CHADDR field containing the UE's MAC address and helps in identifying
the correct session uniquely at D-eWAG. After the UE session is identified, D-eWAG initiates the PDP Context
Creation procedure with GGSN and obtain the IP address. Note that the 3G attribute used for the creation of PDP-
Context was already cached at D-eWAG during the authentication process. D-eWAG sends the DHCP-Offer message
with the IP address allocated by the GGSN set in the “Your-IP-Address” field. The subsequent DHCP-Request message
from the UE containing the GGSN-allocated IP address is acknowledged with the DHCP-Ack message by D-eWAG.
This way the UE gets the WLAN IP address directly from the 3G network and starts sending data traffic.
The following additional host configuration parameters should be provisioned for the UE during DHCP signaling since
the access is WLAN:
 Default gateway
 Subnet mask/prefix length
70
 DNS server address

 DHCP server address
After the WLAN attach procedure is completed as explained above, D-eWAG session for the UE becomes active and
ready for data transfer.
Note that if the WLC sends the Accounting-Start message to the D-eWAG (if it is configured as Accounting-Proxy at
WLC), it will proxy the Accounting-Start message to the 3GPP-AAA server and send the Accounting-Response
message back to the WLC.
Data Traffic between WLAN and 3G Network

As the D-eWAG acts as default-gateway for the UE, all uplink data packets are received by D-eWAG and sent to the
GGSN over GTP-U tunnel. When the downlink data packet is received from GGSN over the GTP-U tunnel, D-eWAG
throws the packet to WLC over the VLAN mapped for the UE session, and WLC delivers the packet to the UE.
D-eWAG as First-Hop Router to WLAN Network

The D-eWAG acts as the first-hop router to the WLAN network, which provides access to the 3G domain. This means
that D-eWAG has L2 connectivity with the Wireless LAN Controller (WLC) using VLANs and acts as first-hop router
to route traffic to the GGSN.
In a typical Wi-Fi network each SSID will have corresponding VLAN mapping at WLC node. Therefore, the network
setup should be in such a way that D-eWAG should also be the member of all VLANs as that of the WLC's VLAN
serving 3G-SSID. This ensures that all the traffic from UEs attaching to any 3G-SSID will reach the D-eWAG acting as
first-hop router through WLC.
Each VLAN interface at D-eWAG can be connected to one or more WLCs serving the same SSID, and each WLC acts
as RADIUS client and DHCP relay for that SSID. So, the RADIUS-client/DHCP-relay function at WLC will use the IP
address of VLAN interface mapped to that 3G-SSID, and D-eWAG is configured as corresponding RADIUS/DHCP
server.
D-eWAG as Default Gateway

D-eWAG operates as first-hop L3 router (default-gateway) for Wi-Fi clients (UE), it should be possible for all UEs to
send data traffic directly to the D-eWAG. This is achieved by sending the default-gateway DHCP option (or DHCP
ROUTER option-3) as described in the Requirements at GGSN section. Note that this default-gateway IP address should
be in the same subnet as that of IP address allocated by the GGSN.
Thus, when the UE wants to send traffic, it will first resolve the MAC address of the default-gateway using ARP-
Request. This ARP-Request gets forwarded by WLC over mapped VLAN and D-eWAG responds with ARP-
RESPONSE as it owns the IP address. This ensures that all the data packets from the UE reach D-eWAG.
When the default-gateway configuration is not available or does not match with subnet of the allocated IP address from
GGSN, the call will get dropped. This ensures that any consecutive DHCP packets from that UE get dropped at D-
eWAG.
APN Selection
APN for the D-eWAG session is selected in following way:
71
 APN for a particular session is returned by the 3GPP-AAA server during authentication. The APN can be sent
using the RADIUS “Service-Selection” AVP in Access-Accept message from the 3GPP-AAA server.
 If the APN is not supplied during authentication, the locally configured APN under the subscriber-template
configuration is applied to the D-eWAG session.
D-eWAG Service in the ASR5000 Chassis

D-eWAG’s service capabilities include:
 The D-eWAG service acts as an authentication-proxy during authentication of UE with 3GPP AAA. This is to
process authentication messages between the UE and 3GPP-AAA server and to obtain the 3G-specific
attributes required for PDP context creation with the GGSN.
 D-eWAG service acts as DHCP server terminating the DHCP-Relay messages from the AP/WLC. This is to
process the actual DHCP signaling during Wi-Fi attach procedure and return the IP address allocated by GGSN
(during PDP context creation) in DHCP message itself.
Important: Note that the DHCP service must be configured in DHCP-Server mode in the
same context as the D-eWAG service.
 D-eWAG acts as accounting-proxy to proxy the RADIUS accounting messages between WLC and 3GPP-AAA.
WLC - D-eWAG Interface

As discussed earlier, the interface between WLC and D-eWAG is based on VLAN. Note that there can be multiple
WLCs connecting to a single D-eWAG. In which case, each WLC should be part of at least one VLAN which is shared
by D-eWAG. This helps the control/data packets from 3G-SSID reach D-eWAG from WLC through that VLAN.
Control Plane
Following are the control signaling packets to be handled by D-eWAG during the WLAN attach procedure by UE in the
3G-SSID WLAN network:
 802.1x authentication
 DHCP IP assignment
 RADIUS accounting
Requirements for 802.1x Authentication

 Ingress EAP authentication messages are all encapsulated inside RADIUS messages.
 WLC configured with D-eWAG service IP address as the AAA authentication server for the 3G-SSID.
Characteristics of this control flow:
 D-eWAG acts as AAA-Proxy for the authentication happening between UE and 3GPP-AAA.
 D-eWAG selects the actual 3GPP-AAA server based on REALM part in the NAI received in “Username” AVP.
This is achieved using the Subscriber Template based operation of D-eWAG in the ASR5000 chassis.
 The first inbound RADIUS message (Access-Request) is the FSoL for D-eWAG to create a new D-eWAG
session.
72
 The UE MAC address present in the “Calling-Station-ID” AVP of Access-Request message is used to identify
the UE session at D-eWAG for subsequent RADIUS messages from the WLC.
 At the end of 802.1X authentication, the Access-Accept message from 3GPP-AAA server carries the 3G-specific
attributes of the authenticated user such as IMSI, MSISDN, and APN. This information is used by D-eWAG
for creating a GTP PDP context with the GGSN.
DHCP Requirements
 The WLC should act as DHCP-Relay and should be configured with D-eWAG service IP address as the “external dhcp-
server” for the 3G-SSIDs.
 D-eWAG processes all the DHCP messages sent to standard DHCP server UDP port 67.
 When DHCP-Discover message is received from the UE, DHCP server in the ASR5000 chassis goes into pending state to
wait until the signaling on the MNO side (GTP tunnel creation) is done to get an IP address for the UE.
 On the arrival of the Create PDP Context Response, which carries the assigned IP address c.c.c.c for the client, DHCP is
fully resumed to offer c.c.c.c back to the client.
 On the completion of DHCP signaling, the session on the DP is fully activated to tunnel the client's entire traffic to the
GGSN over GTP-U.
 In subsequent DHCP message exchanges over time (for example, DHCP Request and DHCP ACK), no further signaling
will happen on the MNO side. The DHCP-REQUEST on the D-eWAG needs to always turn around to compose a
corresponding response to reassign or renew this same address with an endless lease back to the client.
 Important: UE suggesting the IP address to DHCP server in DHCP-Discover or DHCP-Request messages is not
supported in this release.
 UE connecting through D-eWAG should include the “PARAMETER REQUEST LIST” DHCP option in DHCP-
Discover/Request to ask for subnet-mask, default-router, and DNS configuration parameters from DHCP Server (D-
eWAG) as DHCP-Inform message is not supported in this release.
 DHCP service should be configured in the same context as the D-eWAG service. This is because D-eWAG is using the
existing DHCP service in the ASR5000 chassis to act as DHCP-server in this model.
RADIUS Accounting
RADIUS accounting messages are exchanged in the WLC-D-eWAG interface as described here:
 WLC node can be configured with D-eWAG service IP address as the RADIUS accounting-server for the 3G-
SSID sessions.
 After the IP address is allocated to the WLAN UE using DHCP signaling, WLC will send the RADIUS
Accounting-Start/Interim/Stop messages for the UE session to D-eWAG.
 The accounting messages received are proxied to the 3GPP-AAA server (like authentication process) by D-
eWAG. Acct-Interim message are used for D-eWAG session updates like identifying AP change, and Acct-
Stop message are used to teardown the D-eWAG session as the corresponding session at WLC is down.
 Note that this accounting proxy is optional. WLC can have different AAA server configured for RADIUS
accounting.
 When D-eWAG receives a RADIUS accounting message from WLC, it is forwarded to the AAA server. In this
scenario, if the call goes down for any reason apart from Acct-Stop from WLC, D-eWAG creates Acct-Stop on
its own for this WLC-initiated accounting and sends it to the AAA server. This ensures that the AAA server
will know that the WLC-initiated accounting session needs to be stopped as the session has gone down.
73
However, if there is no accounting message received for that session from WLC then D-eWAG will not send
Acct-Stop on its own for WLC accounting session on call teardown.
D-eWAG - AAA Interface

By acting as AAA Proxy, D-eWAG will be proxying all the RADIUS authentication/accounting messages between
AP/WLC and the 3GPP AAA server. D-eWAG selects the actual 3GPP-AAA server based on REALM part in the NAI
received in “Username” AVP. D-eWAG operates based on the Subscriber Template in ASR5000 chassis and thus the
AAA server is selected.
RADIUS CoA/DM Support

RADIUS CoA
D-eWAG supports CoA messages from the AAA server to change data filters associated with a subscriber session as
well as QoS value, rulebase, and Firewall-NAT-policy.
The CoA request message from the AAA server must contain attributes to identify NAS and the subscriber session and
either filter rule, Firewall-NAT-policy or QoS or rulebase name.
If the system successfully executes a CoA request, a CoA-ACK message is sent back to the RADIUS server and the data
filter is applied to the subscriber session. Otherwise, a CoA-NAK message is sent with an error-cause attribute without
making any changes to the subscriber session.
Important: Note that D-eWAG does not forward the CoA request to WLC. WLC does not support CoA.
Important: Changing ACL/rulebase/Firewall-NAT-policy/QoS together in a single CoA is not supported. For

this, separate CoA requests can be sent through the AAA server requesting for one attribute change per request.
Filter-ID
The “Filter ID” AVP contains name of the data filter to apply to the subscriber session. The “filter-id” attribute
(attribute ID 11) contains the name of an Access Control List (ACL).
QoS
If CoA is received with QoS value the same is sent to GGSN in UPC Request and on receiving successful UPC
Response, CoA Ack is sent. Otherwise, CoA-Nack is sent.
Firewall Policy
CoA if received with Firewall policy name must be applied to the subscriber session. If the system does not support that
Firewall policy for the subscriber then CoA-NACK is sent.
Rulebase
CoA can have Rulebase AVP to specify new rulebase to apply to subscriber.
74
RADIUS Disconnect Message

RADIUS Disconnect Message (DM) is used to disconnect subscriber session in the system from a RADIUS server. The
DM Request message contains necessary attributes to identify the subscriber session.
If the system successfully disconnects the subscriber session, a DM-ACK message is sent back to the RADIUS server,
otherwise a DM-NAK message is sent with proper error reasons. If disconnect ACK is sent then as per normal
deallocation path D-eWAG sends disconnect request to WLC as well (if configured in the D-eWAG service
configuration).
Important: Disconnect Request sent by the D-eWAG to the WLC may not contain the same attribute list that it
received in Disconnect Request from 3GPP AAA.
RADIUS Accounting Support

D-eWAG supports RADIUS accounting. It uses subscriber template configuration to obtain accounting mode
information.
D-eWAG - GGSN (Gn')

The Gn' reference point is between the D-eWAG and the GGSN. Here the D-eWAG acts as an SGSN and initiates the
creation of a PDP context.
For every UE, the D-eWAG creates one GTP tunnel with the GGSN. The W-APN, IMSI, MSISDN, Charging
Characteristics, and QoS of the WLAN-UE are forwarded to GGSN in Create-PDP-Context-Request message.
GGSN Selection
The GGSN node is selected as per the 3GPP standard of resolving the IP address using DNS query.
This DNS query contains the DNS-APN string in the form “<apn-name>.mncXXX.mccYYY.gprs”. The APN name is
derived from either local-configuration or obtained from AAA server during Access-Accept message. MCC and MNC
values are derived in the following priority:
1. From the NAI sent by UE in Access-Request message in the form “[email protected]”.
2. Local configuration.
Configured using the plmn id mcc mcc mnc mnc CLI command under the D-eWAG service.
GTP Messages
The following messages are supported over the Gn' reference point:
 Create PDP Context Request/Response.
 Update PDP Context Request/Response:
 GGSN-initiated UPC handled for updating QoS.
GGSN-initiated UPC Request is accepted only for QoS Update case. QoS is updated for the D-eWAG
session and accept status is sent in UPC Response. UPC Requests with EUA Update, PCO Update,
APN Restriction Update, TFT Update, Direct Tunnel Update will be rejected by D-eWAG.
75
Note that only EUA Update rejection from D-eWAG will cause session teardown at GGSN and
subsequently D-eWAG session will be torn down through GGSN-initiated DPC. Also, note that EUA
Update is sent by GGSN in UPC Request only when GGSN had sent 0 IP address in EUA IE of the
CPC Response.
 D-eWAG-initiated UPC when new AP Location Information is received in the Accounting-interim
message for the session, and when COA with QoS update is received from 3GPP AAA.
UPC response handling scenarios:
 If GGSN responds with UPC failure with cause other than “non-existent”, there will be no
QoS update for the D-eWAG session. The session persists in this case.
 If GGSN responds with UPC failure with cause set to “non-existent”, the D-eWAG session
gets removed. Disconnect Message is sent to the WLC.
 If there is no UPC response from GGSN, GTP path failure is assumed and the D-eWAG
session is removed.
 Delete PDP Context Request/Response
 Error Indication
 Version Not Supported
 GTP Payload Forwarding
 GTP Echo
Important: As the WLC cannot send 3gpp-qos, UPC from D-eWAG to GGSN for QoS change from WLC does
not happen.
Dynamic IP Address Allocation

In this case, IP address for the UE connecting through WLAN is dynamically assigned by the GGSN. As explained
earlier, the UE initiates DHCP-Discover to obtain IP address after authentication. D-eWAG creates the PDP-Context in
response to this DHCP message. The End-user-address IE in the Create PDP Context Request message (indicating
dynamic address assignment by GGSN) is empty, which makes the GGSN allocate an IP address in the Response
message.
Static IP Allocation
Important: Static IP Allocation is not supported in this release. D-eWAG responds to DHCP static IP request
with DHCP NAK.
The UE can sometimes request for an IP address using the “requested ip address” (option 50) field in DHCP message.
The scenario could be that the UE was earlier attached to the 3G network using macro-cell and is now connecting
through WLAN. Thus, it will try to retain the IP address it was allocated during 3G access by requesting the same
through DHPC message. In this case, D-eWAG will also request for the same IP address to GGSN by filling it in the
“End-user-address” IE in CPC Request. If the GGSN is not able to allocate the requested IP address, then D-eWAG
drops the call and DHCP-Offer message is not sent back.
76
NSAPI Allocation
D-eWAG is responsible for allocating NSAPI values before sending the Create-PDP-Context-Request message to the
GGSN. Although the D-eWAG acts as an SGSN in terms of GTP tunnel establishment, it also manages NSAPI
allocation as WLAN UEs do not send NSAPI in this case. The default NSAPI allocated by D-eWAG is 15.
UE Identity and Location Information Support

The D-eWAG supports sending UE identity and location information to the GGSN, which the GGSN can use for
Lawful Intercept support.
RAI
The RAI IE in CPC Request sent to GGSN is encoded using the MCC MNC or PLMN ID configured at D-eWAG.
ULI
The User Location Information (ULI) IE in CPC Request sent to GGSN is encoded using the “Called-Station-ID” AVP
received in Authentication-Request message at D-eWAG. The “Called-Station-ID” AVP contains the Access Point
Identifier (AP Identifier), which is composed of the Location Area Code Cell Identity (LAC_CI) — that is, Location
Area Code (LAC) and Cell Id (CI) separated by an underscore. For example, if the access point is assigned LAC = 123
and CI = 56789, then the “Called-Station-ID” AVP will contain 123_56789. As per 3GPP TS 23.003, the LAC and CI
are each 2 bytes in length.
Note that the “Called-Station-ID” AVP is optional in RADIUS Auth/Accounting Requests. WLC supports different
format of “Called-Station-ID”. However, for ULI functionality to work, “Called-Station-ID” AVP should be received in
AP Identifier format. If Called-Station-ID is received in AP Identifier format then it is sent to GGSN in ULI IE of CPC
request.
The “User Location Information” IE is encoded in Cell Global Identifier (CGI) format to indicate WLAN AP location
information where the UE is currently located.
The “Geographic Location Type” field is used to convey what type of location information is present in the
“Geographic Location” field. To indicate Cell Global Identity format, it should be set to 0.
The “Geographic Location” field is used to convey the actual geographic information as indicated in the “Geographic
Location Type” field. The MCC MNC octets should be set to PLMN ID of the PLMN where D-eWAG is located. The
LAC and CI octets should be set to Called-Station-ID AP-Identifier LAC and CI components.
After the UE moves to a different access point, WLC sends a RADIUS Accounting Interim with the new Access Point
location in “Called-Station-ID” AVP. D-eWAG checks the older ULI and if it is different, it will send UPC Request
with ULI with the new Access Point location.
UE MAC to IMEI Mapping Support

The UE MAC to IMEI Mapping Support feature allows user identity information to be provided to the GGSN. This
support can be enabled/disabled from the CLI. When enabled, the UE MAC received in “Calling-Station-Id” RADIUS
attribute is mapped to IMEIsV and sent in GTP CPC message to the GGSN.
77
Data-Plane
Uplink Data Path

The uplink data packet from UE is sent by WLC to D-eWAG over the mapped VLAN for that UE session. D-eWAG
identifies the session for the received data-packet based on the source IP address. After the session is identified, the data
packet is placed over the GTP-U tunnel created with GGSN for this session. This ensures that the packet reaches the
appropriate APN network.
Downlink Data Path

D-eWAG uniquely identifies a session based on the GTP-U tunnel from GGSN and extracts the IP packet from GTP-U
tunnel. This IP packet contains the destination IP address set to the UE's IP address allocated during DHCP signaling
(and actually allocated by GGSN). D-eWAG sends the IP packet downstream to the WLC over the correct VLAN. D-
eWAG always uses the same VLAN over which the DHCP packets are received for this UE session in this case. The
WLC also takes care of delivering the IP packet to the UE over WLAN.
Overlapping IP Address Support
Important: In this release, Overlapping IP Address support is not fully qualified and is not supported, it is
available only for lab testing purposes.
If the IP address allocated by GGSN during the PDP Context Creation is expected to be unique for each UE session
(across the different APN/PLMN), then Overlapping IP Address support is not required. In that case, identification of
the session for the data-traffic at D-eWAG can be based only on the Source IP address.
To support Overlapping IP addresses, identification of data-traffic is done based on the {VLAN-ID, Source-IP-Address}
pair, which ensures that the overlapping IP addresses can exist across operators/APN.
Following table shows the overlapping IP address support in various possible deployment models of D-eWAG:
Table 5. Overlapping IP Address Support
Model Overlapping IP Support Notes

One SSID mapped to one Yes, the VLAN has to be a. Each SSID should always be mapped to unique VLAN in this
VLAN mapped to one always different for different case even if it is served using multiple WLCs.
APN. APN. b. Different VLAN used for all UE sessions connecting through
different SSIDs and uplink packets can be identified uniquely with
{vlan+src.ip} pair at D-eWAG.
One SSID mapped to one No a. Each SSID should always be mapped to a unique VLAN in this
VLAN mapped to multiple case, even if it is served using multiple WLCs.
APN. b. Same VLAN used for all UE sessions and uplink packets cannot
be identified uniquely with {vlan+src.ip} pair at D-eWAG.
One SSID mapped to Yes, the VLAN has to be a. WLCs can be different with different VLAN for same SSID.
multiple VLAN mapped to always different for different b. WLC can be configured with AP-Group to use different VLAN.
one APN. APN. c. Set of VLANs serving one APN are different from set of VLANs
serving another APN. This way overlapping-ip can be supported.
78
Local Traffic Breakout

The Local Traffic Breakout feature enables the D-eWAG to forward data that does not require 3G access directly to the
Internet. With Local Traffic Breakout support the traffic carried by UE will fall into one of the following categories:
 WLAN Direct IP Access: Carries part of the traffic that will go directly over the Internet. The Gn’ interface is
bypassed.
 WLAN 3GPP IP Access: Carries the 3G traffic that will go in the GTPU tunnel towards the MPC (GGSN).
D-eWAG acts as the AAA proxy as well as DHCP server to the UE attaching to the WLAN network. While acting as
DHCP server, D-eWAG creates the PDP context with the GGSN to obtain the IP address to be allocated to the UE
through DHCP-Response in the access-side. After the session is created, data is allowed to go through the MPC or
directly over the Internet.
Figure 12. D-eWAG with Local Traffic Breakout Deployment
Important: For Local Traffic Breakout support, D-eWAG requires Dynamic NAT functionality for which the
ECS and NAT in-line service licenses are required.
APN Selection
A single APN is used for both 3G access and direct IP access. If Local Traffic Breakout is enabled, WLAN subscribers
can simultaneously access 3G services and direct IP services.
A WLAN subscriber is always associated with a single IP address, there is no distinction between the Wi-Fi IP address
and PDP IP address.
Note that NAT is applied to direct IP traffic, the subscriber’s IP address is NATd and sent to the Internet. In the
downlink direction, the destination IP address is changed from the NATd IP address to the subscriber’s IP address and
then forwarded to the subscriber.
79
Controlling Local Traffic Breakout

D-eWAG enables Local Traffic Breakout (direct IP access) based on the availability of Firewall-and-NAT policy for the
subscriber. If NAT is enabled for the subscriber then Local Traffic Breakout is enabled.
NAT In-line Service Support

NAT in-line service is required for Local Traffic Breakout support. Local Traffic Breakout is applied to subscriber
traffic based on the L3/L4 characteristics—source IP address, source port number, destination IP address, destination
port number, and the protocol. One-to-one NAT is applied only for direct IP data while the rest of the 3G data is
bypassed by NAT. This can be configured with the help of target-based NAT support. If NAT is enabled, all subscriber
IP is NATd. Private IP check of subscriber IP is bypassed.
If NAT is not enabled then all the user data goes to the GGSN.
Important: For D-eWAG, irrespective of the NAT pool type, NAT IP address is allocated only on demand—
after the data requiring NAT comes in.
Enabling Firewall-and-NAT Policy

The Firewall-and-NAT policy can be enabled for a subscriber in one of the following ways:
 Subscriber Template
 RADIUS AVP
 ECS Rulebase
The Firewall-and-NAT policy can either be specified in the ECS rulebase, which can in turn be specified in the
Subscriber Template, or the policy can be specified directly in the Subscriber Template.
Subscriber configuration has higher priority compared to the ECS rulebase configuration. Therefore, if Firewall-and-
NAT policies are configured both in the Subscriber Template and in the ECS rulebase, the policy specified in the
Subscriber Template is applied for the subscriber.
Target-based NAT Configuration

A NAT Realm (NAT IP Pool from where the NAT IP can be assigned to a subscriber) can be selected based on the
L3/L4 characteristics of the flows / connections coming from the subscriber.
This association is done with the help of Access rules configurations in the rulebase. The administrator can configure
the realm names along with the Access rules in the Firewall-and-NAT policy. The matching criteria for these rules in
the rulebase can be based on the L3/L4 parameter. This allows the realms to be selected based on L3/L4 parameters of
the flow (target-based NAT). When packets matching a given ruledef r1 are received, NAT is done using the NAT IP
address allocated to the subscriber from the realm configured for the ruledef r1. In this way, the NAT realm/NAT IP
address to be used for subscriber flows is decided during rule match.
If no NAT realm name is found in the ruledef matching the packet, or if it is specified to bypass NAT, NAT will not be
applied on the subscriber flow. The traffic is routed within the private network.
Thus for NAT to be applied, a realm name must be configured in the matching ruledef. If NAT has to be bypassed, then
a NAT realm must not be configured in the ruledef.
80
Data Path Flow

In the uplink direction, irrespective of the data received at D-eWAG, D-eWAG will apply the ACS ruledef specified.
For 3G data, as per the ruledef configuration NAT will be bypassed. For direct IP data, NAT is applied to the
destination address. After the ACS is processed NAT status will decide whether the data should directly go over the
Internet or in the GTPU tunnel towards the GGSN.
In the downlink direction, MPC data received at the SGTP interface in GTPU tunnel goes directly towards the UE.
While the data from direct IP connection received at D-eWAG is NATd and sent to the UE.
Important: Note that NAT is applied only for the direct IP data based on the access rules defined.
Data Path Changes

When using WLAN direct IP access, a WLAN UE has to use its local IP address. As the WLAN local IP address and
the GGSN assigned IP address are same, NAT support is required for direct IP access. All the traffic between WLAN
UE and direct IP connection is NATd.
Uplink Data Path

All 3G service data is NAT bypassed while other direct IP data is NATd. After ECS and NAT processing is done, if
flagged, the data is sent directly over the Internet. Else, the data is sent to the GGSN over the GTPU tunnel.
Figure 13. Uplink Data Path
Downlink Data Path

Data from 3G services is received in GTPU tunnel while the NATd data from Internet is received directly. In the
downlink data path, after ECS processing is done the data is sent to the UE.
81
Figure 14. Downlink Data Path
Recovery Support
The NAT framework takes care of recovering the NAT status and NAT flow. For the Local Traffic Breakout counters,
new micro checkpoint is added, which is sent as part of clp stats for D-eWAG callline.
Accounting Support
Direct IP data is accounted separately.
The following RADIUS AVPs support direct IP counts:
 SN-LBO-Acct-IN-Pkts: Indicates number of packets sent by UE directly to the Internet
 SN-LBO-Acct-Out-Pkts: Indicates number of packets received by UE directly from the Internet.
 SN-LBO-Acct-IN-Octets: Indicates number of octets sent by UE directly to the Internet.
 SN-LBO-Acct-Out-Octets: Indicates number of octets received by UE directly from the Internet.
Note that whereas direct IP data is accounted separately, there is only a cumulative Total Uplink and Total Downlink
data count available for the UE. It is not possible to identify 3G data sent for the subscriber from accounting messages
or CDR.
Differentiated Services Code Point Marking

Differentiated Services Code Point (DSCP) levels can be assigned to specific traffic patterns in order to ensure that data
packets are delivered according to the precedence with which they are tagged. The DiffServ markings are applied to the
IP header of every subscriber data packet transmitted in the downlink and/or uplink direction based on negotiated QoS
at GGSN and local configuration in the IPSG service.
DSCP values must be configured for different QCI values. The following table presents the traffic class to QCI mapping
(based on 3GPP spec 23.203).
82
Table 6. Traffic Class to QCI Mapping

1 Conversational N/A N/A speech
2 Conversational N/A N/A unknown
3 Streaming N/A N/A speech
4 Streaming N/A N/A unknown
5 Interactive 1 Yes N/A
9 Background N/A N/A N/A
For the downlink path, DSCP markings can be configured to control the DSCP markings for downlink packets. IP
header of the packet is updated with value in the TOS field.
For uplink traffic—traffic from D-eWAG to GGSN through GTP tunnel—DSCP markings can be configured. In this
case, only outer IP header is used for routing the packet over Gn' interface. Hence, TOS field of only outer IP header is
changed, that is subscriber packet is not marked with DSCP value at D-eWAG.
DSCP marking can be configured with a “pass through option”, which when configured uses the marking received on
ingress to mark packets on egress.
Important: Note that Traffic Policing/Shaping is not supported in this release.
Bulk Statistics Support

The system's support for bulk statistics allows operators to choose to view not only statistics that are of importance to
them, but also to configure the format in which it is presented. This simplifies the post-processing of statistical data
since it can be formatted to be parsed by external, back-end processors.
When used in conjunction with the Web Element Manager, the data can be parsed, archived, and graphed.
The system can be configured to collect bulk statistics (performance data) and send them to a collection server (called a
receiver). Bulk statistics are statistics that are collected in a group. The individual statistics are grouped by schema.
For the list of supported schema and information on how to configure them, refer to the DHCP-based Enhanced
Wireless Access Gateway Configuration chapter.
The system supports the configuration of up to four sets (primary/secondary) of receivers. Each set can be configured
with to collect specific sets of statistics from the various schema. Statistics can be pulled manually from the system or
sent at configured intervals. The bulk statistics are stored on the receiver(s) in files.
The format of the bulk statistic data files can are configurable, operators can specify the format of the file name, file
headers, and/or footers to include information such as the date, system host name, system uptime, the IP address of the
system generating the statistics (available for only for headers and footers), and/or the time that the file was generated.
83
When the Web Element Manager is used as the receiver, it is capable of further processing the statistics data through
XML parsing, archiving, and graphing.
The Bulk Statistics Server component of the Web Element Manager parses collected statistics and stores the information
in the PostgreSQL database. If XML file generation and transfer is required, this element generates the XML output and
can send it to a Northbound NMS or an alternate bulk statistics server for further processing.
Additionally, if archiving of the collected statistics is desired, the Bulk Statistics server writes the files to an alternative
directory on the server. A specific directory can be configured by the administrative subscriber or the default directory
can be used. Regardless, the directory can be on a local file system or on an NFS-mounted file system on the Web
Element Manager server.
Important: For more information on bulk statistics configuration, refer to the Configuring and Maintaining Bulk
Statistics chapter in the System Administration Guide.
Threshold Crossing Alerts Support

Thresholding on the system is used to monitor the system for conditions that could potentially cause errors or outage.
Typically, these conditions are temporary (i.e. high CPU utilization, or packet collisions on a network) and are quickly
resolved. However, continuous or large numbers of these error conditions within a specific time interval may be
indicative of larger, more severe issues. The purpose of thresholding is to help identify potentially severe conditions so
that immediate action can be taken to minimize and/or avoid system downtime.
The ASR5000 chassis supports several threshold values of which the following are applicable to D-eWAG:
 Call setup:
 Number of calls setup
 Subscriber number:
 Total number
 Licensed session utilization
 Port utilization:
 High activity
 Transmit utilization
 Receive utilization
 PAC/PSC CPU resource availability:
 Percent utilization
 Available memory
 Load
 Memory usage
 Session throughput
 SPC/SMC CPU resource availability:
 Memory usage
 Percent utilization
 Packet processing:
84
 Number of packets filtered/dropped

 Number of packets forwarded to CPU
Note that the other thresholds are platform specific and so are applicable to D-eWAG as well.
The following thresholding models are supported by the system:
 Alert: A value is monitored and an alert condition occurs when the value reaches or exceeds the configured high
threshold within the specified polling interval. The alert is generated then generated and/or sent at the end of
the polling interval.
 Alarm: Both high and low threshold are defined for a value. An alarm condition occurs when the value reaches
or exceeds the configured high threshold within the specified polling interval. The alert is generated then
generated and/or sent at the end of the polling interval.
Thresholding reports conditions using one of the following mechanisms:
 SNMP traps: SNMP traps have been created that indicate the condition (high threshold crossing and/or clear) of
each of the monitored values.
Generation of specific traps can be enabled or disabled on the chassis. Ensuring that only important faults get
displayed. SNMP traps are supported in both Alert and Alarm modes.
 Logs: The system provides a facility called threshold for which active and event logs can be generated. As with
other system facilities, logs are generated. Log messages pertaining to the condition of a monitored value are
generated with a severity level of WARNING.
Logs are supported in both the Alert and the Alarm models.
 Alarm System: High threshold alarms generated within the specified polling interval are considered
“outstanding” until a the condition no longer exists or a condition clear alarm is generated. “Outstanding”
alarms are reported to the system's alarm subsystem and are viewable through the Alarm Management menu in
the Web Element Manager.
The Alarm System is used only in conjunction with the Alarm model.
Important: For more information on thresholds, refer to the Thresholding Configuration Guide.
Congestion Control Support
Important: In this release, Congestion Control support is not qualified and is not supported, it is available only
for lab testing purposes.
The Congestion Control feature enables to specify how the system reacts in a heavy load condition. Congestion control
operation is based on configuring congestion condition thresholds and service congestion policies.
Important: Overload Disconnect is not supported.
Congestion Control monitors the system for conditions that could potentially degrade performance when the system is
under heavy load. Typically, these conditions are temporary (for example, high CPU or memory utilization) and are
quickly resolved. However, continuous or large numbers of these conditions within a specific time interval may have an
impact on the system’s ability to service subscriber sessions. Congestion control helps identify such conditions and
invokes policies for addressing the situation.
85
Congestion control operation is based on configuring the following:

 Congestion Condition Thresholds: Thresholds dictate the conditions for which congestion control is enabled
and establishes limits for defining the state of the system (congested or clear). These thresholds function in a
way similar to operation thresholds that are configured for the system as described in the Thresholding
Configuration Guide. The primary difference is that when congestion thresholds are reached, a service
congestion policy and an SNMP trap are generated.
A threshold tolerance dictates the percentage under the configured threshold that must be reached in order for
the condition to be cleared. An SNMP trap is then triggered.
 Port Utilization Thresholds: Congestion thresholds for utilization of all ports in the system.
 Port-specific Thresholds: Congestion thresholds for individual ports.
 Service Congestion Policies: Congestion policies are configurable for each service. These policies
dictate how services respond when the system detects that a congestion condition threshold has been
crossed.
 License Utilization: Congestion thresholds for license utilization on the system.
 Maximum Sessions-per-Service Utilization: Congestion thresholds for maximum number of sessions
allowed per service.
Important: For more information on the Congestion Control feature, refer to the Congestion Control chapter in
the System Administration Guide.
Redundancy Support
Important: In this release, D-eWAG supports basic Session Recovery, ICSR is not supported.
Important: In this release Line Card Switchover is not supported.
Session Recovery feature provides a mechanism to recover failed Session Manager (SessMgr) task(s) without any call
loss. Recovery framework is same as used by other products. A minimum of four PSCs (three active and one standby) is
required in an ASR5000 chassis to support the Session Recovery feature. This is because the DEMUX Manager and
VPN Manager tasks run on a PSC where no SessMgr runs when session recovery is enabled and one PSC is used as
standby PSC. The other two PSCs run SessMgr and AAAMgr tasks.
Session Recovery is a licensed feature and can be controlled from the CLI, that is enabled/disabled Session Recovery
across the whole chassis. When the CLI is used to configure the Session Recovery feature, Session Controller updates
each SessMgr task.
In the case of D-eWAG, the IPSG Manager, SGTPC Manager, and VPN Manager run on one PSC. SessMgr runs on
one separate PSC. AAAMgr runs on one separate PSC and on one standby PSC. Therefore, a minimum of four PSCs
(three active and one standby) are required.
For D-eWAG Session Recovery support, apart from common access-side attributes (common between D-eWAG and R-
eWAG sessions), attributes specific to D-eWAG session such as Default-GW-IP address, UE-MAC, and so on are
supported. D-eWAG GTP context information is recovered similar to R-eWAG as Gn' interface is used by both.
86
Charging
User traffic towards mobile packet core is accounted by GGSN in collaboration with existing 3G Charging Gateway
Function. D-eWAG supports the following accounting for the user-traffic:
 RADIUS accounting
 GTPP accounting (CDR)
Offline Charging
In Offline Charging, charging information is collected concurrently with resource usage. The charging information is
then passed through a chain of logical charging functions, and the CDR files are generated by the network, which are
then transferred to the network operator's Billing Domain.
The CTF (an integrated component in each charging relevant NE) generates charging events and forwards them to the
CDF. The CDF, in turn generate S-CDRs, which are then transferred to the CGF. Finally, the CGF create S-CDR files
and forwards them to the Billing Domain. The CTF and CDF are integrated in the D-eWAG. However, the CGF may
exist as a physically separate entity or integrated to the D-eWAG. If the CGF is external to the D-eWAG, then the CDF
forwards the CDRs to the CGF across the Gz/Wz interface (using GTPP protocol).
In the ASR5000 chassis, D-eWAG is integrated with the CTF and CDF functions and it generates S-CDR based on the
triggered events and sends the same to the CGF over the Gz/Wz interface. Note that S-CDR is used by SGSN, and the
same format is used for D-eWAG.
The D-eWAG Offline charging involves the following functionalities for WLAN 3GPP IP Access:
 Charging Trigger Function
 Charging Data Function
 Gz/Wz Reference Point
Triggers for Charging Information Addition and CDR Closure

D-eWAG uses the Charging Characteristics to determine whether to activate or deactivate CDR generation. The
Charging Characteristics are also used to set the coherent chargeable event conditions (for example, time/volume limits
that trigger CDR generation or information addition). Multiple Charging Characteristics “profiles” may be configured in
the D-eWAG to allow different sets of trigger values.
Triggers for S-CDR Closure

The following events trigger closure and sending of a partial S-CDR:
 Time Trigger (every x seconds configured using “interval x”)
 Volume Trigger (every x octets configured using “volume x” (up/down/total))
 On reaching maximum number of container limit
 Command gtpp interim now
An S-CDR is closed as the final record of a session for the following events:
 UE-initiated call termination
 Admin release at D-eWAG via clear sub all
 GGSN-initiated call termination
87
 Abnormal releases due to multiple software failures.

 UE-initiated DHCP release
 AAA-initiated call disconnect
 WLC-initiated call termination
Triggers for S-CDR Charging Information Addition

The “List of Traffic Volumes” attribute of the S-CDR consists of a set of containers, which are added when specific
trigger conditions are met, and identify the volume count per PDP context, separated for uplink and downlink traffic, on
encountering that trigger condition.
Billing Record Transfer

The S-CDR generated can either be stored on Hard Disk (GSS) or can be transferred to the CGF. Local storage is also
available. Gz/Wz is the offline charging interface (CDR-based) between the GSN and the CGF. The D-eWAG supports
both GSS and GTPP-based record transfer.
Lawful Intercept Support

The Lawful Intercept (LI) functionality provides network operators the ability to intercept control and data messages of
suspicious subscribers. The ASR5000 chassis provides a proprietary interface to third-party Mediation Function (MF) or
Delivery Function (DF), and supports LI for D-eWAG.
For more information on LI support, contact your accounts representative.
D-eWAG + R-eWAG Combo Deployment
Important: In this release, the D-eWAG + R-eWAG combo deployment option is not qualified and is not
supported, it is available only for lab testing purposes.
The D-eWAG and R-eWAG services can be deployed on the same chassis. This is possible because R-eWAG operates
based on APN profile and D-eWAG operates based on subscriber-template. This clearly separates the user profile
selection process for these services without affecting each others configurations.
The only known restriction is that both these services cannot be configured in the same context. Also, note that the
context-replacement issue at GGSN due to same IMSI+NSAPI will not be the issue in R-eWAG + D-eWAG combo
setup as the UE can attach to only one WLAN at a time. Thus, it cannot connect through both R-eWAG and D-eWAG
at the same time.
Important: In this release, NAT policy must not be configured for D-eWAG. In D-eWAG + R-eWAG combo
deployments NAT is required for R-eWAG, it must be ensured that NAT policy is not configured for D-eWAG ECS
session.
88
How it Works ▀
How it Works
The following illustration shows network setup for the D-eWAG-based solution for MPC access.
Figure 15. D-eWAG Network Setup
This section presents call procedure flows for the following scenarios:
 Session Setup
 Session Teardown
 Session Teardown - AAA Initiated
 Session Teardown - GGSN Initiated
 Session Teardown - UE Initiated
 Session Teardown - WLC Initiated
 Session Update
 Session Update - AAA Initiated
 Session Update - GGSN Initiated
 Session Update - WLC Initiated
Session Setup
This section presents the call flow for session setup scenario.
89
▀ How it Works
Figure 16. D-eWAG Session Setup Call Flow
90
How it Works ▀
Figure 17. D-eWAG Session Setup Call Flow... continued
91
▀ How it Works
Figure 18. D-eWAG Session Setup Call Flow... continued
Session Teardown
This section presents call flows for session teardown scenarios.
 Session Teardown - AAA Initiated
 Session Teardown - GGSN Initiated
 Session Teardown - UE Initiated
 Session Teardown - WLC Initiated
Session Teardown - AAA Initiated

This section presents the call flow for AAA-initiated Session Teardown scenario.
92
How it Works ▀
Figure 19. Session Teardown - AAA Initiated Call Flow
Session Teardown - GGSN Initiated

This section presents the call flow for GGSN-initiated Session Teardown scenario.
Figure 20. Session Teardown - GGSN Initiated Call Flow
Session Teardown - UE Initiated

This section presents the call flow for UE-initiated Session Teardown scenario.
93
▀ How it Works
Figure 21. Session Teardown - UE Initiated Call Flow
Session Teardown - WLC Initiated

This section presents the call flow for WLC-initiated Session Teardown scenario.
Figure 22. Session Teardown - WLC Initiated Call Flow
Session Update
This section presents call flows for session update scenarios.
 Session Update - AAA Initiated
 Session Update - GGSN Initiated
 Session Update - WLC Initiated
94
How it Works ▀
Session Update - AAA Initiated

This section presents call flow for the AAA-initiated session update scenario.
Figure 23. Session Update - AAA Initiated Call Flow
Session Update - GGSN Initiated

This section presents call flow for the GGSN-initiated session update scenario.
GGSN-initiated UPC Request for QoS update would be processed at D-eWAG and the QoS associated with the session
would be updated. UPC request for update of any other parameter would be rejected by D-eWAG. The GGSN may
initiate a DPC because of this.
Important: Note that D-eWAG internally uses R7-QoS regardless of which QoS is requested and negotiated.
When D-eWAG receives UPC from GGSN, it compares it with QoS requested by AAA, and QoS with smaller version
is selected for UPC response. In case of same version, QoS with small Maximum Bit Rate (MBR) is selected.
Important: In this release, D-eWAG does not generate CoA RADIUS Request to WLC.
95
▀ How it Works
Figure 24. Session Update - GGSN Initiated Call Flow
Session Update - WLC Initiated

This section presents call flow for the WLC-initiated session update scenario.
WLC cannot send 3gpp-qos. Thus the UPC from D-eWAG to GGSN for QoS change from WLC will not happen. UPC
will only be sent for AP information change.
Figure 25. Session Update - WLC Initiated Call Flow
96
Dependencies and Limitations ▀
Dependencies and Limitations

This section lists limitations to the D-eWAG solution in this release.
 IPSG-Service Configuration Restriction: Only one IPSG service must be configured per context. Multiple IPSG
services must not be configured in the same context as the IPSG will not be able to differentiate between uplink
and downlink packets.
Deployment Models
 General assumptions:
 D-eWAG acts as first-hop L3 router for WLC.
 WLC and D-eWAG nodes are in a centralized location and the connectivity between WLC and D-
eWAG is based on VLANs.
 D-eWAG acts as authentication-proxy and dhcp-server for all the 3G-SSID being served by WLC.
 Data path follows flexconnect (or H-REAP) model in Wi-Fi access with the data forwarded to the
controller in the centralized location from all the APs.
 The RADIUS control path and {dhcp+datapath} can be in the same or different VLAN between WLC
and D-eWAG depending on whether the AP-Group or AAA-VLAN-Override feature is enabled or
disabled.
Note that enabling the AP-Group at WLC or AAA-VLAN-Override feature at 3GPP-AAA server will
not affect D-eWAG functionality as Overlapping IP address is not supported in this release.
 This D-eWAG solution is not tested against non-Cisco WLC nodes. However, it should work with
WLCs from any vendors as long as it satisfies the requirements mentioned in the Requirements in
WLC section, though it is advised to use Cisco WLC nodes for better interoperability.
 Assumptions in uplink:
 UE default-router (gateway) configuration is provided by ASR5000 chassis in DHCP Response with IP
address in the same subnet as the UE IP address.
 WLC forwards the ARP requests for default-gateway from UE to the appropriate ASR5000 chassis
VLAN interface.
 ASR5000 chassis responds to default-gateway ARP requests with MAC address of the VLAN interface
on which it is received.
 UE uses the ASR5000 chassis returned MAC addresses as destination MAC for uplink data packets.
 ASR5000 chassis identifies the session for the data packet based on Source-IP flow.
 Overlapping IP address is not supported in this release.
 Assumptions for downlink:
 D-eWAG is aware of the VLAN mapped to data path of the UE-Session. This is the same VLAN used
for communication of DHCP-signaling between WLC and D-eWAG.
 D-eWAG sends the data packet with Dest-IP as UE-IP and Dest-MAC as UE-MAC to WLC on the data
VLAN.
97
Requirements in WLC
WLC node capabilities for D-eWAG service:
 Each 3G-SSID served by WLC should be mapped to a VLAN. The default-gateway for this VLAN should be
configured with the IP address of the corresponding VLAN interface at D-eWAG so that any signaling packet
generated for that SSID (like RADIUS Access-Request, DHCP, etc) will reach D-eWAG.
 RADIUS server IP address for the 3G-SSID at WLC should be configured with the D-eWAG service IP address.
This is required since D-eWAG acts as RADIUS Proxy and inspects the authentication exchanges between UE
and 3GPP-AAA for obtaining the 3G attributes required to create PDP-context with the GGSN.
 DHCP server IP address for the 3G-SSID at WLC should be configured with the D-eWAG service IP address.
This is required since D-eWAG acts as DHCP-server and notifies the IP address allocated by GGSN using
DHCP signaling to the UE.
 WLC should be configured to use its VLAN interface's IP as Source-IP for RADIUS/DHCP Relay signaling
packets and not the management interface IP. This is required since D-eWAG verifies the shared-secret for
RADIUS communication based on this IP address.
Requirements at GGSN
The IP-Pool subnet range configured at GGSN for APN network access should have one IP-address dedicated as
default-gateway address for that subnet and not allocated to any UE. This IP address should be configured at D-eWAG
node as default-gateway IP address for that APN.
For example, if the IP-pool subnet range for an APN is 12.0.0.1 to 12.0.0.100, then one IP-address from this range, say
12.0.0.1 is dedicated as default-gateway address for this subnet range. Thus, the GGSN IP-pool configuration in the D-
eWAG-based solution should be changed to { 12.0.0.2 to 12.0.0.100 } range and the IP-address 12.0.0.1 is configured at
D-eWAG node. Also, 12.0.0.1 is conveyed to UE as default-gateway during DHCP-Offer message by D-eWAG so that
it acts as default-gateway for all the uplink data-packets from the UE.
98
Chapter 5
DHCP-based Enhanced Wireless Access Gateway
Configuration
This chapter provides information on configuring the DHCP-based Enhanced Wireless Access Gateway (D-eWAG)
solution.
 Before You Begin
 D-eWAG Configuration
 D-eWAG Administration
99
DHCP-based Enhanced Wireless Access Gateway Configuration
▀ Before You Begin
Before You Begin

Before you can configure the D-eWAG service:
1. Confirm that the chassis on which the D-eWAG software will be configured has been set up as described in the
2. Confirm that the eWAG license is installed.
The eWAG is a licensed Cisco product. Separate session and feature licenses may be required. Contact your
Cisco account representative for information on licensing requirements.
For information on installing and verifying licenses, refer to the Managing License Keys section of the
Software Management Operations chapter in the System Administration Guide.
100
D-eWAG Configuration ▀
D-eWAG Configuration
This section describes how to configure the D-eWAG service.
1. Create and configure the D-eWAG service as described in the Creating and Configuring the D-eWAG Service
section.
Important: From configuration perspective, note that the D-eWAG service is the IPSG
service configured in D-eWAG mode. There is no separate D-eWAG configuration mode.
2. Create and configure a DHCP service for D-eWAG as described in the Configuring DHCP Service section.
3. Create/configure subscriber template for D-eWAG as described in the Configuring the Subscriber Template
section.
4. Create and configure an SGTP service for D-eWAG as described in the Configuring the SGTP Service section.
5. Save your configuration to the flash memory, an external memory device, and/or a network location using the
Exec Mode command save configuration. For additional information on how to verify and save
configuration files, refer to the System Administration Guide and the Command Line Interface Reference.
Important: Commands used in the configuration examples in this section provide base functionality to the extent
that the most common or likely commands and/or keyword options are presented. In many cases, other optional
commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete
information regarding all commands.
Creating and Configuring the D-eWAG Service

This section describes how to create and configure the D-eWAG service.
 Creating the D-eWAG Service
 Configuring the D-eWAG Service
Creating the D-eWAG Service

To create the D-eWAG service use the following configuration:
configure
context <context_name> [ -noconfirm ]
ipsg-service <ewag_service_name> mode radius-server ewag [ -noconfirm ]
end
Notes:
 The ewag keyword enables the D-eWAG service (IPSG service in D-eWAG mode), and enters the IPSG
RADIUS Server Configuration Mode, which is common for the eWAG and IPSG services.
101
▀ D-eWAG Configuration
 You can configure a maximum of 64 eWAG/IPSG services in the system, one per context. Only one IPSG
service must be configured per context. Multiple eWAG services must not be configured in the same context as
they will not be able to differentiate between uplink and downlink packets.
Configuring the D-eWAG Service

This section describes how to configure the D-eWAG service.
configure
ipsg-service <D-eWAG_service_name> mode radius-server ewag
#To bind the D-eWAG service to a logical AAA interface and specify the number of allowed
subscriber sessions:
bind authentication-proxy address <ip_address> [ acct-port <port_number> | auth-port

<port_number> | source-context <source_context> | max-subscribers <max_sessions> ]
#To configure the list of W-APN names that can be connected through D-eWAG and the
default-gateway IP addresses to be used by UE for connecting to the W-APN network:
w-apn <apn_name> default-gw <ip_address>/<maskbits> +
#To bind the D-eWAG service to a logical AAA interface and configure the number of

<port_number> | source-context <source_context_name> ]
#To enable subscriber template profile for D-eWAG:
profile subscriber

102

<aaa_server_group_name> ] [ clear-sessions ] + ] [ dictionary <dictionary_name> ] [
the GGSN:
map ue-mac-to-imei
#To configure timeout for D-eWAG session setup attempts:
end
Notes:
 <dictionary_name> specifies the RADIUS dictionary to use for the D-eWAG service. For information on
which dictionary to use in your setup, contact your Cisco account representative. For D-eWAG, the default
dictionary is starent.
 In the RADIUS accounting parameter configurations, the disconnect-message option enables sending
RADIUS accounting messages to the configured RADIUS accounting client if the call goes down due to any
failure. If this option is not configured, the D-eWAG will not send Disconnect-Message in call failure
scenarios.
in a different context than the D-eWAG service. If not configured, the system will default to the context in
which the D-eWAG service is configured.
 A maximum of four W-APN can be configured per D-eWAG service. Also, note that a maximum of four default
gateways can be configured per W-APN.
Configuring DHCP Service

This section describes how to configure a DHCP service for the D-eWAG service.
To create and configure the DHCP service for D-eWAG use the following configuration:
configure
dhcp-service <dhcp_service_name> [ -noconfirm ]
#To configure DHCP servers with which the DHCP service is to communicate:
dhcp server <ipv4_address> [ priority <priority> ]
103
#To bind the DHCP service to a logical IP interface facilitating the system's connection
to the DHCP server:
bind address <ipv4_address>
exit
Notes:
 The DHCP service must be configured in the same context as the D-eWAG service, and must use the same IP
address as used for the D-eWAG service bind.
Configuring the Subscriber Template

This section describes how to configure subscriber profile for the D-eWAG service. The D-eWAG uses this
configuration to specify certain attributes in the subscriber profile.
To configure a subscriber template for D-eWAG use the following configuration:
configure
subscriber { default | name <user_name> }
#To configure the accounting mode:
#To configure the default APN to be used for UE connections when the AAA server does not
return the subscriber APN name in the service-selection AVP in RADIUS Access-Accept
message:
w-apn <wapn_name>
exit
#To configure realm part for subscriber. This command must be configured in the same
context where the AAA Group is defined.
domain <domain_name>
end
Configuring the SGTP Service

To create and configure the SGTP service use the following configuration:
configure
sgtp-service <sgtp_service_name>
104
#To configure GTP-C parameters:
gtpc { bind address <ipv4_address> | dns-sgsn context <context_name> | echo-

interval <echo_interval_seconds> | echo-retransmission { exponential-backoff [ [ min-
timeout <min_retrans_timeout_seconds> ] [ smooth-factor <smooth_factor> ] + ] | timeout
<retrans_timeout_seconds> } | guard-interval <guard_interval_seconds> | ignore response-
port-validation | ip qos-dscp { af11 | af12 | af13 | af21 | af22 | af23 | af31 | af32 |
af33 | af41 | af42 | af43 | be | ef } | max-retransmissions <max_retransmissions> |
retransmission-timeout <retrans_timeout_seconds> | send { common flags | rab-context |
target-identification-preamble } }
#To configure GTP-U parameters:
gtpu { bind address <ipv4_address> | echo-interval <echo_interval_seconds> |

echo-retransmission { exponential-backoff [ [ min-timeout <min_retrans_timeout_seconds> ]
[ smooth-factor <smooth_factor> ] + ] | timeout <retrans_timeout_seconds> } | max-
retransmissions <max_retransmissions> | retransmission-timeout <retrans_timeout_seconds>
}
#To configure path failure detection policy:
path-failure detection-policy gtp { echo | non-echo } +
#To configure the restart counter change window to avoid service deactivations and
activations that could cause large bursts of network traffic if the restart counter
change messages from the GGSN are erroneous:
max-remote-restart-counter-change <variance>
end
Notes:
 The SGTP service must be associated in the D-eWAG service configuration.
Configuring NAT for Local Traffic Breakout Support

To configure NAT for Local Traffic Breakout support, use the following sample configuration:
configure
active-charging service ecs_service_name
fw-and-nat firewall_nat_policy_name
nat policy ipv4-only default-nat-realm nat_pool_default
access-rule priority 10 access-ruledef ruledef_1 permit nat-realm nat_pool_1
access-rule priority 105 access-ruledef ruledef_4 permit
105
access-rule priority 115 access-ruledef ruledef_5 permit bypass-nat
access-rule no-ruledef-matches uplink action permit nat-realm nat_pool_3
access-rule no-ruledef-matches downlink action permit
end
Notes:
 NAT is applied only on packets in the uplink direction.
 The Firewall-and-NAT policy can either be specified in the ECS rulebase, which can in turn be specified in the
Subscriber Template, or the policy can be specified directly in the Subscriber Template. Note that the
Subscriber configuration has higher priority than the ECS rulebase configuration. Therefore, if Firewall-and-
NAT policies are configured both in the Subscriber Template and in the ECS rulebase, the policy specified in
the Subscriber Template will be applied for the subscriber.
 A maximum of three realms can be configured in a Firewall-and-NAT policy. In the above sample configuration
nat_pool_1, nat_pool_2, nat_pool_3, and nat_pool_default are the realm names.
 In the above sample configuration:
 NAT realm nat_pool_1 will be used for all packets matching the ruledef ruledef_1.
 NAT realm nat_pool_2 would be used for all packets matching the ruledef ruledef_2.
 NAT realm nat_pool_1 would be used for all packets matching the ruledef ruledef_3.
 NAT realm nat_pool_default would be used for all the packets matching the ruledef ruledef_4.
 NAT will be bypassed for all the packets matching the ruledef ruledef_5.
 In case there are no rules matching a packet, then the NAT realm to be used for the flow is taken from
the following configuration:
access-rule no-ruledef-matches uplink action permit nat-realm nat_pool_3
That is, if no ruledef matches the packet, NAT realm nat_pool_3 will be used for those packets. If
there was no realm name configured as part of matching ruledef, and default-nat-realm is not
configured, then NAT will be bypassed.
Additional Configurations
This section covers the following configurations:
 Configuring Bulk Statistics
 Configuring Congestion Control
 Configuring Session Recovery
 Configuring Offline Charging for D-eWAG
Configuring Bulk Statistics

To configure bulk statistics collection for D-eWAG service, use the following configuration:
configure
106
bulkstats mode
ipsg schema <schema_name> format <schema_format>
end
Notes:
 For detailed information on D-eWAG-related bulk statistics available in the IPSG schema, refer to the IPSG
Schema chapter of the Statistics and Counters Reference, and for those available in the System schema, refer to
the System Schema chapter of the Statistics and Counters Reference.
 Apart from the IPSG and System schema, as needed you can also configure variables available in the other
schema, including:
 APN: For Access Point Name (APN) related statistics
 Card: For card-level statistics
 Context: For context service related statistics
 Port: For port-level statistics
 RADIUS: For per-RADIUS server statistics
 The following is a sample schema format for D-eWAG statistics:
“D-eWAG Schema: Test\n ----------------------\nVPN Name:%vpnname%,\nService
Name:%servname%,\n Session Statistics: \n Total Current Sessions
:%total_current_sessions%,\n Total Sessions Setup: %total_sessions_setup%,\n -----
-----------------\n”
Configuring Congestion Control
Important: In this release the Congestion Control Support feature is not qualified, it is available only for lab /
testing purposes.
To enable Congestion Control, use the following configuration:
configure
#To enable Congestion Control:
congestion-control
#To configure Congestion Control policy:
congestion-control policy ipsg-service action { drop | none }
#To configure Congestion Control thresholds:
congestion-control threshold { { license-utilization | max-sessions-per-service-

utilization | message-queue-utilization | port-rx-utilization | port-specific {
<slot/port> | all { rx-utilization | tx-utilization } } | port-specific-rx-utilization |
port-specific-tx-utilization | port-tx-utilization | service-control-cpu-utilization |
system-cpu-utilization | system-memory-utilization | tolerance } [ critical ]
107
<percentage> | message-queue-wait-time [ critical ] <seconds> | { port-specific-rx-

utilization | port-specific-tx-utilization } [ critical ] }
end
Notes:
 Congestion policies are configurable for each service. These policies dictate how the services respond when the
system detects that a congestion condition threshold has been crossed. For more information on the Congestion
Control feature, refer to the Congestion Control chapter of the System Administration Guide.
 In the above configuration, the Congestion Control thresholds featured are at the system level and are not
specific to D-eWAG.
 eWAG supports only critical threshold values.
Verifying your Configuration

To verify your Congestion Control configuration, in the Exec Mode issue the following command:
show congestion-control configuration
The output of this command displays information including whether or not Congestion Control is enabled/disabled,
Congestion Control threshold parameter settings, Congestion Control policy, and more.
Configuring Session Recovery

To enable Session Recovery, use the following configuration:
configure
require session recovery
end
Notes:
 For more information on the Session Recovery feature, refer to the Session Recovery chapter of the System
 A valid feature key is required for this configuration. This command enables/disables the feature to try to
perform hitless session recovery for all session types supported by the software release. After enabling session
recovery through this configuration, make sure that session recovery status is “ready”.
Configuring Offline Charging for D-eWAG

To configure Offline Charging for D-eWAG, use the following configuration:
configure
gtpp single-source
#To configure GTPP Group:
108
gtpp group <gttp_group_name>
#To configure charging agent:
gtpp charging-agent address <server_ip_address>
#To configure GTPP dictionary:
gtpp dictionary <gtpp_dictionary>
#To configure remote server address:
gtpp server <ip_address>
#To configure triggers:
gtpp trigger volume-limit
#To configure CDR attributes:
gtpp attribute local-record-sequence-number
gtpp attribute msisdn
gtpp attribute rat
exit
#To configure accounting policy:
policy accounting <accounting_policy>
cc profile <profile_bit_value> volume total <no_of_octets>
exit
#To configure accounting in IPSG service configuration:
ipsg-service <service_name> mode radius-server ewag
accounting-context <ewag_accounting_context_name>
associate accounting-policy <accounting_policy_name>
exit
#To configure accounting mode in the Subscriber configuration:
subscriber default
end
Notes:
 For information on the GTPP dictionary to use contact your Cisco account representative.
109
▀ D-eWAG Administration
D-eWAG Administration
This section describes D-eWAG administrative procedures.
This section includes the following topics:
 Logging Support
 Protocol Monitoring Support
 Gathering D-eWAG-related Statistics and Information
Logging Support
To view IPSG-related logs, in the Exec Mode use the following command:
logging filter active facility { ipsg | ipsgmgr } level <severity_level> [ critical-info

| no-critical-info ]
To view SGTP-related logs, in the Exec Mode use the following command:
logging filter active facility { sgsn-gtpc | sgsn-gtpu | sgtpcmgr } level

To view SessMgr-related logs, in the Exec Mode use the following command.
logging filter active facility sessmgr level <severity_level> [ critical-info | no-

critical-info ]
To view ECS and NAT related logs for Local traffic Breakout support, in the Exec Mode use the following command.
logging filter active facility { acl-log | acsmgr | ecs-css | firewall } level

Protocol Monitoring Support

The system provides protocol monitor and test utilities that can are useful when troubleshooting or verifying
configurations. The information generated by these utilities can in many cases either identify the root cause of a
software or network configuration issue or, at the very least, greatly reduce the number of possibilities.
For troubleshooting purposes, the system provides a powerful protocol monitoring utility. This tool can be used to
display protocol information for a particular subscriber session or for every session being processed.
For more information on Monitor Protocol and Monitor Subscriber, refer to the System Administration Guide.
Monitor Protocol
The system’s protocol monitor displays information for every session that is currently being processed. Depending on
the number of protocols monitored, and the number of sessions in progress, a significant amount of data is generated. It
is highly recommended that logging be enabled on your terminal client in order to capture all of the information that is
generated.
110
D-eWAG Administration ▀
To view monitor protocol based logging information, in the Exec Mode use the following command:
monitor protocol
For D-eWAG use the following filters:

 12 — RADIUS Authentication
 13 — RADIUS Accounting
 19 — User L3
 20 — USERTCP STACK
 24 — GTPC
 26 — GTPU
 27 — GTPP
 28 — DHCP
 29 — CDR
 31 — RADIUS COA
 34 — CSS Data: In case of Local Traffic Breakout support, shows data packets after NAT is done.
 41 — IPSG RADIUS Signal: Must be used to view the RADIUS accounting messages on the control path for
IPSG session management.
 70 — DNS Client
Monitor Subscriber
The system’s protocol monitor can be used to display information for a specific subscriber session that is currently
being processed. Depending on the number of protocols monitored, and the number of sessions in progress, a significant
amount of data is generated. It is highly recommended that logging be enabled on your terminal client in order to
capture all of the information that is generated.
To view monitor subscriber based logging information, in the Exec Mode use the following command:
monitor subscriber
The following filters are available for monitor subscriber based logging in D-eWAG.
Monitor Subscriber for full call flow can be checked with the options next-call, type, and username. Other options like
IMSI, MSISDN, and MSID are not applicable for calls as they are not known to D-eWAG at the initial stage of
authentication (D-eWAG gets this information only after receiving Access-Accept from the AAA server.
Gathering D-eWAG-related Statistics and Information

Table 7. D-eWAG-related Statistics and Information
D-eWAG-related statistics or CLI command to use

information
To view concise D-eWAG service- show ipsg service all
level information.
111

information
To view detailed D-eWAG service- show ipsg service all verbose
level information.
To view D-eWAG service-level show ipsg statistic
statistics, including session and
RADIUS message-level statistics.
To view D-eWAG session counter show ipsg sessions counters
information.
To view D-eWAG subscriber show subscribers ipsg-only
information.
To view detailed D-eWAG session show ipsg sessions full all
information, for all sessions.
To view detailed subscriber show subscribers full all
information, for all subscribers.
To view session progress information show session progress
for in-progress calls.
To view IPSG Manager related show session subsystem facility ipsgmgr
information.
To view APN-related information. show apn name <apn_name>
To view SNMP trap history. show snmp trap history | grep IPSG
To view SNMP trap statistics, for all show snmp trap statistics
services including D-eWAG and
SGTP.
To view IPSG facility information. logging filter active facility ipsg
To view IPSG Manager facility logging filter active facility ipsgmgr

information.
To view information of logging show logging
filters for current context.
To view DHCP related information. show dhcp
To view DHCP service related show dhcp statistics dhcp-service <dhcp_service>

information.
To view counters associated with show dhcp counters all
DHCP.
To view all available DHCP related show dhcp full all
information.
To view status of DHCP servers. show dhcp status
To view summary of DHCP related show dhcp summary all

statistics.
To view DHCP related information show dhcp imsi <imsi>
for specified IMSI.
112
D-eWAG Administration ▀

information
To view thresholding related show threshold
information.
To view alarm related information. show alarm all
To view SNMP event statistics. show snmp trap statistics
To view counters for configured show radius counters all

RADIUS servers.
For Local Traffic Breakout support. show active-charging firewall statistics { acsmgr instance
To view ECS Stateful Firewall <instance_number> | callid <call_id> | domain-name <domain_name>|
statistics. protocol <protocol>| nat-realm <realm_name> | username <user_name>}
[ debug-info | verbose ]
For Local Traffic Breakout support. show active-charging sessions nat { required [ nat-realm
To view session information for <realm_name> ] | not-required }
sessions with NAT required or not
required.
For Local Traffic Breakout support. show subscribers nat { required [ nat-realm <realm_name> ] [ nat-ip
To view information for subscribes <ip_address> ] | not-required }
with NAT enabled or disabled.
For Local Traffic Breakout support. show active-charging analyzer statistics name <analyzer_name>
To view ALG statistics.
To view GTPP statistics. show gtpp statistics
113
Appendix A
RADIUS-based Enhanced Wireless Access Gateway AAA
AVP Support
This appendix presents a quick reference for AAA message-level AVP support for R-eWAG.
The following table describes the indicators used in the quick reference table.
Table 8. Indicators used in the Quick Reference Table
Indicator Description
M Mandatory, one or more instances of the AVP MUST be present in the message.
O Optional, zero or more instances of the AVP MAY be present in the message.
Table 9. R-eWAG AVP Support Quick Reference Table
Attribute Accounting- Accounting- Accounting- Disconnect- Notes

Request-Start Request- Request-Stop Message Request
Interim (PoD message
initiated by R-
eWAG)
3GPP-Charging O O O Optional, otherwise attribute omitted
Characteristics in CPC Request.
3GPP-IMSI M M M UTF-8 encoded characters of IMSI
identifying the UE. Included in CPC
request.
3GPP- O O O Optional, otherwise R-eWAG
Negotiated-QoS- configured value used in CPC
Profile Request.
3GPP-RAT- O O O Ignored. Hard coded to 3 by R-
Type eWAG.
3GPP-SGSN- O O O UTF-8 encoded MCC/MNC used by
MCC-MNC R-eWAG to build RAI identifying
Wi-Fi network, otherwise currently
only R-eWAG-configured value is
used and this attribute is ignored.
Acct-Session-Id M M M O Accounting Session Identifier string.
Acct-Session- O
Time
115
RADIUS-based Enhanced Wireless Access Gateway AAA AVP Support
Attribute Accounting- Accounting- Accounting- Disconnect- Notes

Request-Start Request- Request-Stop Message Request
Interim (PoD message
initiated by R-
eWAG)
Acct-Status- M M M
Type
Acct-Terminate- O
Cause
Called-Station- O O O APN identifying the target network
ID in UTF-8 encoded string. If not
specified, R-eWAG configured
default APN should be used.
Calling-Station- M M M O MSISDN in UTF-8 encoded decimal
ID character.
Event- O O O O Timestamp of the accounting
Timestamp message in Unsigned integer.
Framed-IP- M M M O IPv4 address allocated to the UE in
Address Wi-Fi domain.
NAS-IP-Address M M M M Contains ISG/WLC IP address that
initiated the accounting message.
SN-WLAN-AP- O O O Contains LAC_CI of the WLAN
Identifier Access Point. R-eWAG uses the
information in filling ULI of CPC.
SN-WLAN-UE- O O O O Contains MAC address of the UE.
Identifier R-eWAG sends it in IMEIsV of
CPC.
User-Name M M M M
116
Appendix B
DHCP-based Enhanced Wireless Access Gateway AAA
AVP Support
This chapter presents quick references for AAA AVP support in accounting and authentication messages for D-eWAG.
117
DHCP-based Enhanced Wireless Access Gateway AAA AVP Support
▀ AAA AVP Support in Accounting Messages
AAA AVP Support in Accounting Messages

This section presents a quick reference for AAA AVP support in accounting messages for D-eWAG.
Table 10. D-eWAG AVP Support in Accounting Messages Quick Reference Table
Attribute Accounting Accounting Accounting Co Disconnect Notes

-Request- -Request- -Request- A -Message
Start Interim Stop Request
(PoD
message
initiated by
D-eWAG)
3GPP- X X X Charging chars received from GGSN is sent.
Charging
Characteristic
s
3GPP- X X X
Negotiated-
QoS-Profile
3GPP-RAT-
Type
Acct- X X X
Authentic
Acct-Input- X X
Octets
Acct-Input- X X
Packets
Acct-Interim-
Interval
Acct-Output- X X
Octets
Acct-Output- X X
Packets
Acct-Session- X X X
ID
Acct-Status- X X X
Type
Acct- X
Terminate-
Cause
Called- X X X Whatever is received from WLC the same is
Station-ID sent.
118
AAA AVP Support in Accounting Messages ▀

(PoD
message
initiated by
D-eWAG)
Calling- X X X X X Carries the MAC address of the WLAN-UE.
Station-ID
Chargeable- This attribute contains the MSISDN and/or the
User-Identity IMSI of the user. The encoding of the MSISDN
and the IMSI is defined in GSMA PRD IR.61.
This value will be cached by eWAG when
received in Access-Accept message.
Event- X X X X X
Timestamp
Framed-IP- X X X Contains the IP address allocated to the UE.
Address
Idle-Timeout
Message
Authenticator
NAS-IP- X X X X X Contains the IP address of the RADIUS
Address Accounting Client configured in D-eWAG.
NAS-Port X X X Contains the D-eWAG RADIUS Accounting
Client port number used for sending the
RADIUS messages.
NAS-Port- X X X
Type
Reply-
Message
Service-
Selection
Service-Type X X X X X
Session-
Timeout
SN-LBO- X X Indicates number of octets sent by UE directly to
Acct-IN- the Internet.
Octets
SN-LBO- X X Indicates number of packets sent by UE directly
Acct-IN-Pkts to the Internet.
SN-LBO- X X Indicates number of octets received by UE
Acct-Out- directly from the Internet.
Octets
119
▀ AAA AVP Support in Accounting Messages

(PoD
message
initiated by
D-eWAG)
SN-LBO- X X Indicates number of packets received by UE
Acct-Out-Pkts directly from the Internet.
Tunnel-
Medium-Type
Tunnel- Assigned VLAN ID for the subscriber.
Private-
Group-ID
Tunnel-Type
User-Name X X X X X Contains the identify of the user in

IMSI@Realm format as defined in 3GPP TS
23.003 as follows:
[email protected]
rg
120
AAA AVP Support in Authentication Messages ▀
AAA AVP Support in Authentication Messages

This section presents a quick reference for AAA AVP support in authentication messages for D-eWAG.
Table 11. D-eWAG AVP Support in Authentication Messages Quick Reference Table
Attribute Acces Acces Acces Access- Acc Acct- Acc PoD/D Notes
s- s- s- Challen t- Interi t- M
Reque Reject Accep ge Star m Sto
st t t p
3GPP- X X X X D-eWAG will cache this information for
Charging the UE session. This value will be used
Characterist during GTP tunnel creation with GGSN.
ics
3GPP- X D-eWAG will cache this information for
Negotiated- the UE session. This value will be used
QoS-Profile during GTP tunnel creation with GGSN.
3GPP-RAT- X X Ignored. Hard coded to be 3 by D-eWAG.
Type
Acct- X X X D-eWAG does not do anything with this.
Authentic
Acct-Input- X X D-eWAG does not do anything with this.
Octets
Acct-Input- X X D-eWAG does not do anything with this.
Packets
Acct- X D-eWAG does not do anything with this.
Interim-
Interval
Acct- X X D-eWAG does not do anything with this.
Output-
Octets
Acct- X X D-eWAG does not do anything with this.
Output-
Packets
Acct- X X X
Session-ID
Acct-Status- X X X
Type
Acct- X D-eWAG does not do anything with this.
Terminate-
Cause
121
▀ AAA AVP Support in Authentication Messages
st t t p
Called- X X X X WLC can fill this AVP with “AP-
Station-ID MAC:SSID” in Access-Request. For ULI
support, WLC should send this AVP in
AP-Identifier format LAC_CI.
Calling- X X X X X Carries the MAC address of the WLAN-
Station-ID UE for verification at the 3GPP AAA
server.
Chargeable- X This attribute contains the MSISDN and/or
User- the IMSI of the user. The encoding of the
Identity MSISDN and the IMSI is defined in
GSMA PRD IR.61. This value will be
cached by eWAG when received in
Access-Accept message.
Class X D-eWAG does not do anything with this.
EAP- X X X X D-eWAG does not do anything with this.

Message
Event- X X
Timestamp
Framed-IP- X X X Contains the IP address allocated to the
Address UE.
Idle- X D-eWAG does not do anything with this.
Timeout
Message X X X X
Authenticat
or
MS-MPPE- X D-eWAG does not doing anything with
Recv-Key this attribute. WLC will be using it to
encrypt the traffic over WLAN network.
MS-MPPE- X D-eWAG does not doing anything with
Send-Key this attribute. WLC will be using it to
encrypt the traffic over WLAN network.
NAS-IP- X X X X X Contains the IP address of the WLC
Address (RADIUS Client) which initiates the
RADIUS messages.
NAS-Port X X X X Contains the WLC port number used for
sending the RADIUS messages.
NAS-Port- X
Type
Reply- X D-eWAG does not do anything with this.
Message
122
AAA AVP Support in Authentication Messages ▀
st t t p
Service- X 3GPP-AAA provides the subscribed APN
Selection name (RFC 6572).
Service- X X
Type
Session- X D-eWAG does not do anything with this.
Timeout
Tunnel- X
Medium-
Type
Tunnel- X Assigned VLAN ID for the subscriber.
Private-
Group-ID
Tunnel- X VLAN
Type
User-Name X X X X X X X Contains the identify of the user in
IMSI@Realm format as defined in 3GPP
TS 23.003 as follows:
[email protected]
work.org
123

15 0 eWAG Admin

Uploaded by

Copyright:

Available Formats

15 0 eWAG Admin

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

15 0 eWAG Admin

Uploaded by

Copyright:

Available Formats

Cisco ASR 5000 Enhanced Wireless Access

Gateway Administration Guide

Last Updated November 30, 2013

© 2013 Cisco Systems, Inc. All rights reserved.

About this Guide ............................................................................................... vii

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

GTP Tunnel Setup Failure ............................................................................................................. 38

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Control Plane ................................................................................................................................. 72

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

Configuring the D-eWAG Service ................................................................................................ 102

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

Icon Notice Type Description

Caution Alerts you of potential damage to a program, device, or system.

Typeface Conventions Description

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Contacting Customer Support

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Figure 1. eWAG-based MPC access from WLAN

Network Deployments and Network Interfaces

 Combo R-eWAG + TTG deployment on the same ASR 5000 chassis.

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

R-eWAG-WLC/Wi-Fi AAA Interface

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

Control and Data Interfaces

R-eWAG-GGSN Gn' Interface

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Network Layer Service Access Point Identifier Allocation

Routing Area Identification Encoding

Differentiated Services Code Point Marking

Table 1. Traffic Class to QCI Mapping

GPRS QoS Class Identifier Value UMTS QoS Parameters

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

GPRS QoS Class Identifier Value UMTS QoS Parameters

Access Point Name Selection

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Quality of Service Profile Selection

GGSN Failover Case

Network Address Translation and Application Level Gateway Support

Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄

Virtual APN Support

Offline Charging Support

▄ Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

 Gz/Wz Reference Point

Triggers for Charging Information Addition and CDR Closure

Triggers for S-CDR Closure

Triggers for S-CDR Charging Information Addition

Billing Record Transfer

UE Identity and Location Information Support

UE Identity Information Support