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

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.

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® ASR 5000 Series chassis on which the eWAG is deployed is a very 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 many 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.

Figure 1. eWAG-based MPC access from WLAN

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.

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.

Supported Standards

The eWAG-based MPC access from WLAN is a Cisco-developed solution, and is not standards based.

Network Deployments and Network Interfaces

This section describes deployment options and network interfaces supported by the eWAG.

Network Deployments

The eWAG can be deployed in any of the following ways:

  • Stand-alone eWAG deployment on an ASR 5000 chassis.
  • Combo 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 eWAG + TTG deployment on the same ASR 5000 chassis.
  • Combo eWAG + TTG + GGSN deployment on the same ASR 5000 chassis.

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 eWAG and the GGSN supporting GTPv1 and GTPv0 protocols. eWAG supports GTP Path messages towards GGSN. Here, the eWAG acts as an SGSN and initiates the PDP Context Creation procedure. For every UE, the 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 eWAG.

Feature Description

This section presents general description of features supported by the eWAG.

RADIUS AAA Support

The eWAG provisions a RADIUS server, as defined in RFC 2865, which enables the eWAG to act as a RADIUS accounting server supporting receiving and responding to RADIUS accounting messages as defined in RFC 2866.

For the list of RADIUS attributes supported by eWAG, refer to the Enhanced Wireless Access Gateway AAA AVP Support appendix.

The eWAG provisions configuring one or more RADIUS clients (with corresponding authentication keys) to create a trusted set of AAA. The eWAG discards RADIUS messages from any device that is not in the RADIUS client list. The eWAG authenticates each RADIUS message using a configured authentication key. The 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 eWAG. Here, Wi-Fi AAA acts as the RADIUS accounting client and eWAG as the RADIUS accounting server. eWAG extracts the necessary attributes required to create the GTP tunnel to GGSN. 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, 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 eWAG. The 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 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 – 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 eWAG. eWAG receives the original IP packets generated by UE in WLAN. There could be other network elements (routers) between WLC and eWAG, which can provide Layer 2 or Layer 3 tunneling to route the WLAN-generated packets across the public network.

      IMPORTANT:

      In this release, eWAG does not support Tunneling (IP over GRE).

      ICMP Processing: ICMP packets in the downlink direction are remapped and sent to the UE.
  • eWAG – GGSN (Gn’):
    • PDP Activation Messages: The following messages are supported over the Gn’ reference point:
      • Create PDP Context Request / Response
      • Update PDP Context Request / Response: 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

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 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 eWAG allocates Network Layer Service Access Point Identifier (NSAPI) values before sending the Create PDP Context Request message to the GGSN. Although the 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 eWAG transparent to the WLAN UE.

IMPORTANT:

In this release, the 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 eWAG.

Differentiated Services Code Point Marking

Differentiated Services Code Point (DSCP) levels can be assigned to specific traffic patterns in order to ensure that data packets are delivered according to the precedence with which they are tagged. The DiffServ markings are applied to the IP header for every subscriber data packet transmitted in the downlink and/or uplink direction. The four traffic patterns have the following order of precedence:

  1. Background (lowest)
  2. Interactive
  3. Streaming
  4. Conversational (highest)

In addition, for class type Interactive, further categorization is done in combination with traffic handling priority and allocation-retention priority. Data packets falling under the category of each of the traffic patterns are tagged with a DSCP marking. Each traffic class is mapped to QCI value according to mapping mentioned in TS 23.203. Therefore, DSCP values must be configured for different QCI values. The following table lists mapping for traffic class to QCI.


Table 1. Traffic Class to QCI Mapping
GPRS QoS Class Identifier Value UMTS QoS Parameters
Traffic Class THP Signalling Indication Source Statistics Descriptor

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 eWAG, hence TOS field in subscriber IP packet is marked with DSCP value directly.

For uplink traffic—traffic from 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 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 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 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 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 eWAG.

Quality of Service Profile Selection

If the “3GPP-GPRS-Negotiated-QoS-Profile” AVP is not supplied in Accounting-Start Request message, a default Quality of Service (QoS) profile is used. This value is hardcoded to maximum values in the QoS profile as defined in TS 24.008.

GGSN Selection

In this release, 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 eWAG service is used. Note that in both these cases only the Network Identifier (NI) part has to be configured as APN at eWAG.

GGSN Failover Case

IMPORTANT:

In this release, GGSN Failover Support is not fully qualified and is not supported, it is available only for lab / testing purposes.

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

Network Address Translation and Application Level Gateway Support

For the interworking between trusted WLANs and 3G MPC, the eWAG uses Network Address Translation (NAT) in-line service support to map Wi-Fi IP addresses to MPC IP addresses and vice versa.

A UE connected to Wi-Fi has IP address allocated from Wi-Fi. It will also have another IP address allocated from the MPC. The translation involves remapping of the Wi-Fi IP address to the MPC IP address and vice versa in the IP header as well as in the payload (Application Level Gateway (ALG)).

On successful creation of the GTP tunnel, the 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 eWAG/NAT.

In the uplink direction, the 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 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 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, eWAG call will not setup. For NAT/ALG, 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 eWAG + GGSN combo deployments, virtual-APN configuration is required to separate the rulebases required for 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 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 eWAG + GGSN combo deployments, the virtual-APN configuration is required to ensure that the rulebases required for eWAG (for NAT) and GGSN (for DPI, NAT, P2P, and others) work without any issues. For more information on virtual-APN support in eWAG + GGSN combo deployments refer to the Dependencies and Limitations section.

UE Identity and Location Information Support

The 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 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 eWAG encodes the UE identity information into IMEIsV IE of Create PDP Context. The UE identity information is composed of the UE's MAC address in the “Calling-Station-Id” AVP’s format as per RFC 3580, that is the MAC address in ASCII format (upper case only), with octet values separated by hyphens. For example, “00-10-A4-23-19-C0”.

IMPORTANT:

Note that 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 eWAG instead encodes the last two bytes as FFFE.

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 eWAG uses the “starent” RADIUS dictionary, if not eWAG will ignore the AVP.

UE Location Information Support

The 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 eWAG encodes this access point identity information into ULI IE of Create PDP Context. In Accounting-Interim, if a new AP identifier is provided it is sent to the GGSN in ULI IE of Update PDP Context. The access point identity is composed of the Location Area Code Cell Identity (LAC_CI) — that is, Location Area Code (LAC) and Cell Id (CI) separated by an underscore. For example, if the access point is assigned LAC = 123 and CI = 56789, then SN-WLAN-AP-Identifier AVP will contain 123_56789.

IMPORTANT:

Note that the “SN-WLAN-AP-Identifier” AVP is available only in the “starent” RADIUS dictionary. Therefore, UE Location Information support is available only if eWAG uses the “starent” RADIUS dictionary, if not eWAG will ignore the AVP.

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

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, 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 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 eWAG Session Recovery support, existing IPSG Session Recovery framework is reused for recovering access side attributes common between IPSG and eWAG sessions. New fields are added in IPSG Session Recovery record to recover attributes specific to eWAG session such as WLAN IP address, MPC IP address, eWAG GTP information, and so on. eWAG GTP context information will be recovered similar to TTG since Gn' interface is used by both.

How it Works

This section presents call procedure flows for the following scenarios:

Session Setup

This section presents call flow for the session setup scenario.


Figure 2. Session Setup Call Flow

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

19

The eWAG creates a new session based on this Accounting-Start message. It assumes the default APN configured under eWAG service if it is not available in the Accounting-Start message. It also assigns a default QoS value for the eWAG session if not available in the Accounting-Start message.

20

The eWAG identifies the GGSN it needs to connect with using the same 3G procedure of identifying GGSN from SGSN(/TTG) using DNS resolution. The eWAG then sends the Create PDP Context Request message to the GGSN to create the GTP tunnel.

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 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 eWAG session.

23

The 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 eWAG from the WLAN network.

25

The eWAG performs NAT on this data packet (Layer 3 to Layer 7), from Wi-Fi IP address to MPC IP address.

26

The 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 eWAG.

30

The eWAG performs reverse-NAT on the downlink IP packet (received over the GTP-U tunnel from the GGSN) and converts all MPC IP addresses to Wi-Fi IP addresses from Layer 3 to Layer 7.

31

The eWAG sends the plain IP packet downlink to the UE.


Session Setup using Accounting-Interim

The 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 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, eWAG creates the session based on the first accounting-interim. If this configuration is not enabled and the Accounting-Interim is received at 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 eWAG, the consecutive Accounting-Interim messages received by 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, eWAG will drop Accounting-Interim with different AVP values.

This section presents call flow for session setup using accounting-interim scenario.


Figure 3. Session Setup using Accounting-Interim Call Flow

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 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 eWAG. And, the eWAG creates the session based on this message and establishes GTP tunnel with the GGSN.

18

The eWAG creates new session based on this Accounting-Interim message. It assumes the default APN configured in the eWAG service if it is not available in the Accounting-Interim message. It also assigns a default QoS value for the eWAG session if not available in the Accounting-Interim message.

19

The eWAG identifies the GGSN to connect to using the same 3G procedure of identifying GGSN from SGSN/TTG using DNS resolution. The eWAG then sends the Create PDP Context Request message to the GGSN to create the GTP tunnel.

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 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 eWAG session.

22

The 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 eWAG from the WLAN network.

24

The eWAG performs NAT on this data packet (Layer 3 to Layer 7), from Wi-Fi IP address to MPC-IP address.

25

The 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 eWAG.

29

The eWAG performs reverse-NAT on the downlink IP packet received over the GTP-U tunnel from the GGSN, and converts all MPC IP addresses to Wi-Fi IP addresses from Layer 3 to Layer 7.

30

The eWAG sends the plain IP packet downlink to the UE.


Session Replacement

Session identification at eWAG is done using the following parameters:

  • Username+MSISDN combination
  • Wi-Fi IP address

If the 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 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 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 eWAG. So the session at 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”.

    If 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:
    1. Matching session found at 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.
    2. Matching session found at 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).
    3. Matching session found at 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.
    4. Matching session found at 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.
    5. Matching session found at 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, 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 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, 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

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.


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

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

IMPORTANT:

In this release, GGSN-initiated Update PDP Context Support is not fully qualified and is not supported, it is available only for lab testing purposes.

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 eWAG and the QoS associated with the session is updated. Update PDP Context Request for update of any other parameter will be rejected by eWAG. GGSN might initiate a DPC because of this.

IMPORTANT:

The eWAG does not generate any CoA RADIUS Request to Wi-Fi AAA as the 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

This section presents call flow for the UE Detach - Accounting Stop scenario.


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

eWAG Timeouts/Admin Disconnect

This section presents call flow for the Session Teardown – eWAG Timeouts and Admin Disconnect scenarios.


Figure 10. Session Teardown Call Flow – eWAG Timeouts/Admin Disconnect

Dependencies and Limitations

This section lists limitations to the 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 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 eWAG, the packets will not have NAT applied. But because of the presence of redirect ACLs, packets will still go through ECS processing.
    • The eWAG call gets created upon receiving Accounting Start Request from Wi-Fi AAA. Before creation of the GTP tunnel between the eWAG and GGSN, if any data packets are received from the Wi-Fi UE, such packets will be dropped at eWAG.
    • Static NAT is the only type of NAT that will be performed on eWAG. Regular NAT/Stateful Firewall will be disabled on eWAG even if configured through the policy.
      If Static NAT is disabled on eWAG, then 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 eWAG.

eWAG + GGSN Combo Deployments

This section lists dependencies and limitations for eWAG + GGSN combo deployments.

Virtual APN Configuration in 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 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 eWAG (assuming that the subscriber is connecting through eWAG to reach that APN using the collocated GGSN). So, when some APN-specific configuration is added, it will be referred by both 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 eWAG node as well, the data packets reaching 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 eWAG and GGSN, virtual-APN support is enabled in the eWAG so that eWAG+GGSN residing in the same chassis can use different set of APN configurations. 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. 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 eWAG, clearly separating out the APN configuration being used by colocated eWAG+GGSN. So, after enabling virtual-APN for eWAG in colocated chassis as explained above, the configurations under virtual-APN are used only by 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 eWAG+GGSN combo deployment with an SGSN connecting to the GGSN for 3G access. In this case, if the SGSN service's IP address subnet is 111.2.3.4/24 and the RADIUS accounting-client that is sending Accounting-Start message to the eWAG is also in the same subnet 111.2.3.4/24, the virtual-APN is configured under real-APN as follows:

virtual-apn preference 1 apn ewag_corp1 access-gw-addr 111.2.3.4/24

In the above case, when the call is coming through 3G macro-access and landing in GGSN, the virtual-APN criteria matches for the GGSN call line as the AGW address in this case is SGSN node, which matches the subnet. So, the GGSN call line will start using virtual-APN profile. In the same way, when the call is coming through Wi-Fi access through eWAG, then the virtual-APN criteria matches for the eWAG callline as the AGW address in this case is RADIUS accounting-client which matches the subnet. So the eWAG call line will start using virtual-APN profile as well. Also, if the 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 eWAG and GGSN call lines start using the virtual-APN profiles only ignoring real-APN. This is because AGW address for eWAG call is RADIUS accounting-client and the AGW address for GGSN call is 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 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 eWAG + TTG combo deployments.

SGTP Service Configuration in eWAG + TTG Combo Deployments

The eWAG and TTG both require SGTP service configuration, and in a combo deployment they can share the same SGTP service. Note that eWAG always allocates NASPI value 15, while TTG allocates NSAPI starting from 5 (maximum 15).

In an eWAG + TTG combo deployment sharing the same SGTP service:

  • If 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 is not received then SGTP will not start with GTPv0. The call will be rejected with disconnect reason “act-rejected-by-ggsn”. The same is true if the TTG call is setup first and then the eWAG call comes up.
  • If the 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 eWAG call comes up.
  • If the 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 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 eWAG + TTG + GGSN combo deployments.

The 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, 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, 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 username. 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.