Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

Transcription

1 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 USA Tel: NETS (6387) Fax:

2 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 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.

3 CONTENTS About this Guide... vii Conventions Used... viii Contacting Customer Support...ix Additional Information... x Enhanced Wireless Access Gateway Overview Introduction Platform Requirements License Requirements RADIUS-based Enhanced Wireless Access Gateway Overview Product Overview Network Deployments and Network Interfaces Network Deployments Network Interfaces Feature Description R-eWAG-WLC/Wi-Fi AAA Interface Control and Data Interfaces R-eWAG-GGSN Gn' Interface IP Address Allocation Network Layer Service Access Point Identifier Allocation Routing Area Identification Encoding 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 Triggers for Charging Information Addition and CDR Closure Billing Record Transfer UE Identity and Location Information Support UE Identity Information Support UE Location Information Support Lawful Intercept Support Bulk Statistics Support Threshold Crossing Alerts Support Congestion Control Support Redundancy Support How it Works Session Setup Session Setup using Accounting-Interim Session Replacement Session Setup Failure Mandatory AVP Missing / No Resource Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide iii

4 Contents 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 Timeouts/Admin Disconnect Dependencies and Limitations ewag + GGSN Combo Deployments Virtual APN Configuration in R-eWAG + GGSN Combo Deployments ewag + TTG Combo Deployments SGTP Service Configuration in R-eWAG + TTG Combo Deployments ewag + TTG + GGSN Combo Deployments Mobility Setup Considerations G-eWAG-TTG Mobility using Proxy-MIP at GGSN RADIUS-based Enhanced Wireless Access Gateway Configuration Before You Begin R-eWAG Configuration Creating and Configuring the R-eWAG Service Creating the R-eWAG Service Configuring the R-eWAG Service Configuring the APN Configuring the SGTP Service Configuring NAT/ALG Support Configuring ECS Rulebase with Firewall-and-NAT Policy Configuring APN with Firewall-and-NAT Policy Configuring Routing Rules and NAT ALG Additional Configurations Configuring Access Lists Configuring Bulk Statistics Configuring Congestion Control Configuring Offline Charging for R-eWAG Configuring Session Recovery R-eWAG Administration Logging Support Protocol Monitoring Support Monitor Protocol Monitor Subscriber Gathering R-eWAG-related Statistics and Information DHCP-based Enhanced Wireless Access Gateway Overview Product Overview Deployment Models G-SSID Association Process x EAP-SIM/AKA Authentication Process IP Address Allocation Process Data Traffic between WLAN and 3G Network D-eWAG as First-Hop Router to WLAN Network D-eWAG as Default Gateway APN Selection D-eWAG Service in the ASR5000 Chassis WLC - D-eWAG Interface iv Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

5 Contents Control Plane D-eWAG - AAA Interface RADIUS CoA/DM Support RADIUS Accounting Support D-eWAG - GGSN (Gn') GGSN Selection GTP Messages IP Address Allocation NSAPI Allocation UE Identity and Location Information Support Data-Plane Uplink Data Path Downlink Data Path Overlapping IP Address Support Local Traffic Breakout APN Selection IP Address Allocation Controlling Local Traffic Breakout NAT In-line Service Support Data Path Flow Data Path Changes Recovery Support Accounting Support Differentiated Services Code Point Marking Bulk Statistics Support Threshold Crossing Alerts Support Congestion Control Support Redundancy Support Charging Offline Charging Triggers for Charging Information Addition and CDR Closure Billing Record Transfer Lawful Intercept Support D-eWAG + R-eWAG Combo Deployment How it Works 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 Dependencies and Limitations Deployment Models Requirements in WLC Requirements at GGSN DHCP-based Enhanced Wireless Access Gateway Configuration Before You Begin D-eWAG Configuration Creating and Configuring the D-eWAG Service Creating the D-eWAG Service Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide v

6 Contents Configuring the D-eWAG Service Configuring DHCP Service Configuring the Subscriber Template Configuring the SGTP Service Configuring NAT for Local Traffic Breakout Support Additional Configurations Configuring Bulk Statistics Configuring Congestion Control Configuring Session Recovery Configuring Offline Charging for D-eWAG D-eWAG Administration Logging Support Protocol Monitoring Support Monitor Protocol Monitor Subscriber Gathering D-eWAG-related Statistics and Information RADIUS-based Enhanced Wireless Access Gateway AAA AVP Support 115 DHCP-based Enhanced Wireless Access Gateway AAA AVP Support AAA AVP Support in Accounting Messages AAA AVP Support in Authentication Messages vi Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

7 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide vii

8 Conventions Used About this Guide 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 Text represented as a screen display Description This typeface represents displays that appear on your terminal screen, for example: Login: Text represented as commands Text represented as a command variable Text represented as menu or submenu names 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. This typeface represents a variable that is part of a command, for example: show card slot_number slot_number is a variable representing the desired chassis slot number. This typeface represents menus and sub-menus that you access within a software application, for example: Click the File menu, then click New viii Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

9 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 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ix

10 Additional Information About this Guide 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

11 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 11

12 Introduction Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

13 Enhanced Wireless Access Gateway Overview 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 13

14 License Requirements Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

15 Chapter 2 RADIUS-based Enhanced Wireless Access Gateway Overview This chapter provides an overview of the RADIUS-based Enhanced Wireless Access Gateway (R-eWAG). The following topics are covered in this chapter: Product Overview Feature Description How it Works Dependencies and Limitations Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 15

16 Product Overview RADIUS-based Enhanced Wireless Access Gateway 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

17 RADIUS-based Enhanced Wireless Access Gateway Overview 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 17

18 Product Overview RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

19 RADIUS-based Enhanced Wireless Access Gateway Overview 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 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 19

20 Feature Description RADIUS-based Enhanced Wireless Access Gateway Overview 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. ewag GGSN (Gn ): 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. 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

21 RADIUS-based Enhanced Wireless Access Gateway Overview Feature Description 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 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 21

22 Feature Description RADIUS-based Enhanced Wireless Access Gateway Overview GPRS QoS Class Identifier Value UMTS QoS Parameters Traffic Class THP Signalling Indication Source Statistics Descriptor 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 7 Interactive 2 No N/A 8 Interactive 3 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

23 RADIUS-based Enhanced Wireless Access Gateway Overview Feature Description 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 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) inline 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)). Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 23

24 Feature Description RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

25 RADIUS-based Enhanced Wireless Access Gateway Overview Feature Description 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 25

26 Feature Description RADIUS-based Enhanced Wireless Access Gateway Overview 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, A 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_ 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

27 RADIUS-based Enhanced Wireless Access Gateway Overview Feature Description 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 27

28 Feature Description RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

29 RADIUS-based Enhanced Wireless Access Gateway Overview Feature Description Important: For more information on Congestion Control feature, refer to the Congestion Control chapter in the System Administration Guide. 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 29

30 How it Works RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

31 RADIUS-based Enhanced Wireless Access Gateway Overview How it Works Figure 2. Session Setup Call Flow Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 31

32 How it Works RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

33 RADIUS-based Enhanced Wireless Access Gateway Overview 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 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 33

34 How it Works RADIUS-based Enhanced Wireless Access Gateway Overview Figure 3. Session Setup using Accounting-Interim Call Flow 34 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

35 RADIUS-based Enhanced Wireless Access Gateway Overview 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 35

36 How it Works RADIUS-based Enhanced Wireless Access Gateway Overview 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 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

37 RADIUS-based Enhanced Wireless Access Gateway Overview 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. 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 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). 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 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. 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 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. 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 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 37

38 How it Works RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

39 RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 39

40 How it Works RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

41 RADIUS-based Enhanced Wireless Access Gateway Overview 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 41

42 How it Works RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

43 RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 43

44 Dependencies and Limitations RADIUS-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

45 RADIUS-based Enhanced Wireless Access Gateway Overview 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 /24 and the RADIUS accounting-client that is sending Accounting- Start message to the R-eWAG is also in the same subnet /24, the virtual-apn is configured under real-apn as follows: virtual-apn preference 1 apn ewag_corp1 access-gw-addr /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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 45

46 Dependencies and Limitations RADIUS-based Enhanced Wireless Access Gateway Overview is not received then SGTP will not start with GTPv0. The call will be rejected with disconnect reason actrejected-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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

47 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. The following topics are covered in this chapter: Before You Begin R-eWAG Configuration R-eWAG Administration Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 47

48 Before You Begin RADIUS-based Enhanced Wireless Access Gateway Configuration 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 System Administration Guide. 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

49 RADIUS-based Enhanced Wireless Access Gateway Configuration 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 Notes: context <context_name> [ -noconfirm ] ipsg-service <ipsg_service_name> mode radius-server ewag [ -noconfirm ] end 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 49

50 R-eWAG Configuration RADIUS-based Enhanced Wireless Access Gateway 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 { { { } { } allocation-retention-priority { } } { 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

51 RADIUS-based Enhanced Wireless Access Gateway Configuration R-eWAG Configuration <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: Notes: setup-timeout <setup_timeout> end 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 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> ] Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 51

52 R-eWAG Configuration RADIUS-based Enhanced Wireless Access Gateway Configuration #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 <apn_name> ] #To configure QoS DSCP parameters: ip { gnp-qos-dscp qos-dscp } qci { { { } { } allocation-retention-priority { } } { 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 <aaa_server_group_name> ] [ clear-sessions ] + ] [ dictionary <dictionary> ] [ 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: Notes: setup-timeout <setup_timeout> end 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 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. 52 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

53 RADIUS-based Enhanced Wireless Access Gateway Configuration R-eWAG Configuration 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. 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 context <context_name> 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> } Notes: end 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 53

54 R-eWAG Configuration RADIUS-based Enhanced Wireless Access Gateway Configuration 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 context <context_name> sgtp-service <sgtp_service_name> #To configure GTP-C parameters: gtpc { bind address <ipv4_address> dns-sgsn context <context_name> echointerval <echo_interval_seconds> echo-retransmission { exponential-backoff [ [ mintimeout <min_retrans_timeout_seconds> ] [ smooth-factor <smooth_factor> ] + ] timeout <retrans_timeout_seconds> } guard-interval <guard_interval_seconds> ignore responseport-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> } maxretransmissions <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: Notes: max-remote-restart-counter-change <variance> end The SGTP service must be associated in the R-eWAG service configuration. 54 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

55 RADIUS-based Enhanced Wireless Access Gateway Configuration R-eWAG Configuration 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 context <context_name> 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: Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 55

56 R-eWAG Configuration RADIUS-based Enhanced Wireless Access Gateway Configuration ruledef <ftp_control_ruledef_name> tcp either-port <operator> <value> rule-application routing exit ruledef <ftp_data_ruledef_name> tcp either-port <operator> <value> rule-application routing exit #SIP ALG: ruledef <sip_ruledef_name> udp either-port <operator> <value> rule-application routing exit #RTSP ALG: ruledef <rtsp_ruledef_name> tcp either-port <operator> <value> rule-application routing exit #PPTP ALG: ruledef <pptp_ruledef_name> tcp either-port <operator> <value> rule-application routing exit #TFTP ALG: ruledef <tftp_ruledef_name> tcp either-port <operator> <value> rule-application routing exit #H323 ALG: 56 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

57 RADIUS-based Enhanced Wireless Access Gateway Configuration R-eWAG Configuration ruledef <h323_ruledef_name> udp either-port <operator> <value> rule-application routing exit ruledef <h323_multi_ruledef_name> udp either-port <operator> <value> rule-application routing exit ruledef <h323_tcp_ruledef_name> tcp either-port <operator> <value> rule-application routing exit #To configure the routing rule priorities in the rulebase: rulebase <rulebase_name> route priority <route_priority> ruledef <ftp_control_ruledef_name> analyzer ftpcontrol route priority <route_priority> ruledef <ftp_data_ruledef_name> analyzer ftpdata 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 57

58 R-eWAG Configuration RADIUS-based Enhanced Wireless Access Gateway Configuration Notes: firewall nat-alg sip firewall nat-alg h323 end 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 Notes: context <context_name> ip access-list <access_list_name> redirect css service <ecs_service_name> <keywords> <options> end <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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

59 RADIUS-based Enhanced Wireless Access Gateway Configuration R-eWAG Configuration 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-serviceutilization 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-rxutilization 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 59

60 R-eWAG Configuration RADIUS-based Enhanced Wireless Access Gateway Configuration 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 context <context_name> #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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

61 RADIUS-based Enhanced Wireless Access Gateway Configuration R-eWAG Configuration 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: Notes: apn <apn_name> accounting-mode gtpp gtpp group <gtpp_group_name> accounting-context <ewag_accounting_context_name> end 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 context <context_name> apn <apn_name> cc-ipsg { { home-subscriber-use-local roaming-subscriber-uselocal 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 61

62 R-eWAG Configuration RADIUS-based Enhanced Wireless Access Gateway Configuration require session recovery end Notes: For more information on the Session Recovery feature, refer to the Session Recovery chapter of the System Administration Guide. 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

63 RADIUS-based Enhanced Wireless Access Gateway Configuration 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 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 nocritical-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: Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 63

64 R-eWAG Administration RADIUS-based Enhanced Wireless Access Gateway Configuration 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 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 To view concise R-eWAG service-level information. To view detailed R-eWAG service-level information. To view R-eWAG service-level statistics, including session and RADIUS message-level statistics. To view R-eWAG session counter information. To view R-eWAG subscriber information. To view detailed R-eWAG session information, for all sessions. To view detailed subscriber information, for all subscribers. To view session progress information for in-progress calls. To view IPSG Manager related information. CLI command to use show ipsg service all show ipsg service all verbose show ipsg statistic show ipsg sessions counters show subscribers ipsg-only show ipsg sessions full all show subscribers full all show session progress show session subsystem facility ipsgmgr 64 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

65 RADIUS-based Enhanced Wireless Access Gateway Configuration R-eWAG Administration ewag-related statistics or information To view APN-related information. To view APN-related statistics. To view SNMP trap history. To view SNMP trap statistics, for all services including R-eWAG and SGTP. To view Congestion Control statistics for IPSG Manager. To view Congestion Control configuration. To view NAT-related statistics. To view ECS session-level information. To view detailed ECS session-level information. To view information for subscribers with NAT enabled. To view information for ECS flows with NAT enabled. To view information for all ECS flows. To view ECS statistics for specific analyzer. To view ECS statistics for specific rulebase. To view detailed ECS subsystem-level information. To view GTPP statistics. CLI command to use show apn name <apn_name> show apn statistics show snmp trap history grep IPSG show snmp trap statistics show congestion-control statistics ipsgmgr show congestion-control configuration show active-charging firewall statistics show active-charging sessions show active-charging sessions full show subscribers nat required show active-charging flows full nat required show active-charging flows all show active-charging analyzer statistics name <analyzer_name> show active-charging rulebase name <rulebase_name> show active-charging subsystem all show gtpp statistics Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 65

66

67 Chapter 4 DHCP-based Enhanced Wireless Access Gateway Overview This chapter describes the DHCP-based Enhanced Wireless Access Gateway (D-eWAG) solution. The following topics are covered in this chapter: Product Overview How it Works Dependencies and Limitations Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 67

68 Product Overview 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 x 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

69 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 69

70 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 Association process, the access points allocate resources for UE communication and synchronize with the UE. This is as per the standard process and D-eWAG is not involved in this process x 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 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

71 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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: Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 71

72 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

73 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview DHCP Requirements 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. The WLC should act as DHCP-Relay and should be configured with D-eWAG service IP address as the external dhcpserver 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 (DeWAG) 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 73

74 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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. Filter-ID QoS Firewall Policy Rulebase 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. 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). 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. 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. CoA can have Rulebase AVP to specify new rulebase to apply to subscriber. 74 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

75 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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 IMSI@wlan.mncXXX.mccYYY.3gppnetwork.org. 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 75

76 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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. IP Address Allocation 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

77 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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 RAI ULI The D-eWAG supports sending UE identity and location information to the GGSN, which the GGSN can use for Lawful Intercept support. The RAI IE in CPC Request sent to GGSN is encoded using the MCC MNC or PLMN ID configured at D-eWAG. 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_ As per 3GPP TS , 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 77

78 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 VLAN mapped to one APN. One SSID mapped to one VLAN mapped to multiple APN. One SSID mapped to multiple VLAN mapped to one APN. Yes, the VLAN has to be always different for different APN. No Yes, the VLAN has to be always different for different APN. a. Each SSID should always be mapped to unique VLAN in this case even if it is served using multiple WLCs. 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. a. Each SSID should always be mapped to a unique VLAN in this case, even if it is served using multiple WLCs. b. Same VLAN used for all UE sessions and uplink packets cannot be identified uniquely with {vlan+src.ip} pair at D-eWAG. a. WLCs can be different with different VLAN for same SSID. b. WLC can be configured with AP-Group to use different VLAN. c. Set of VLANs serving one APN are different from set of VLANs serving another APN. This way overlapping-ip can be supported. 78 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

79 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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. IP Address Allocation 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 79

80 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

81 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 81

82 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 ). 82 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

83 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview Table 6. Traffic Class to QCI Mapping GPRS QoS Class Identifier Value UMTS QoS Parameters Traffic Class THP Signalling Indication Source Statistics Descriptor 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 7 Interactive 2 No N/A 8 Interactive 3 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 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 83

84 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

85 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 85

86 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

87 DHCP-based Enhanced Wireless Access Gateway Overview Product Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 87

88 Product Overview DHCP-based Enhanced Wireless Access Gateway Overview 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 Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide

89 DHCP-based Enhanced Wireless Access Gateway Overview 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. Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide 89