RADIUS-based Enhanced Wireless Access Gateway Overview
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:
under the real-APN, the call will get dropped with unknown-APN as the reason.
Consider the R-eWAG+GGSN combo deployment with an SGSN connecting to the GGSN for 3G access. In this case,
if the SGSN service's IP address subnet is 111.2.3.4/24 and the RADIUS accounting-client that is sending Accounting-
Start message to the R-eWAG is also in the same subnet 111.2.3.4/24, the virtual-APN is configured under real-APN as
follows:
virtual-apn preference 1 apn ewag_corp1 access-gw-addr 111.2.3.4/24
In the above case, when the call is coming through 3G macro-access and landing in GGSN, the virtual-APN criteria
matches for the GGSN call line as the AGW address in this case is SGSN node, which matches the subnet. So, the
GGSN call line will start using virtual-APN profile. In the same way, when the call is coming through Wi-Fi access
through R-eWAG, then the virtual-APN criteria matches for the R-eWAG callline as the AGW address in this case is
RADIUS accounting-client which matches the subnet. So the R-eWAG call line will start using virtual-APN profile as
well. Also, if the R-eWAG service's IP address subnet matches with the RADIUS accounting-client IP address and there
is a virtual-APN configuration based on this subnet range as AGW address, then both R-eWAG and GGSN call lines
start using the virtual-APN profiles only ignoring real-APN. This is because AGW address for R-eWAG call is
RADIUS accounting-client and the AGW address for GGSN call is R-eWAG (GTP-peer) and both of them are in the
same subnet making the virtual-APN condition to be true for both call lines. It is important to be aware of above
possibilities to avoid any mis-configurations or undetermined behavior.
eWAG + TTG Combo Deployments
Important:
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
Note that if the virtual-APN profile configuration is not available for the virtual-APN name specified
In this release, the R-eWAG + TTG combo deployment option is not fully qualified and is not
Cisco ASR 5000 Enhanced Wireless Access Gateway Administration Guide ▄
Dependencies and Limitations ▀
45