Product Description
The Cisco® Packet
Data Gateway/Tunnel Termination Gateway (PDG/TTG)
enables mobile operators with 3G UMTS wireless data networks to
provide Fixed Mobile Convergence (FMC) services to subscribers with
dual-mode handsets and dual-mode access cards via WiFi access points.
The PDG/TTG makes it possible for operators to provide
secure access to the operator’s 3G network from a non-secure
network, reduce the load on the macro wireless network, enhance
in-building wireless coverage, and make use of existing backhaul
infrastructure to reduce the cost of carrying wireless calls.
The
PDG is a network element that provides WLAN-to-3GPP network interworking.
This interworking is achieved by the subscriber UEs in the WLAN initiating
an IKEv2/IPSec tunnel toward the PDG, which functions as
a security gateway that provides the UEs a secure connection to
the Packet Data Network (PDN).
The
TTG is a network element that enables PDG functionality for existing
GGSN deployments. The TTG and a subset of existing GGSN functions
work together to provide PDG functionality to the subscriber UEs
in the WLAN.
Platform Requirements
The PDG/TTG
software runs on a Cisco® ASR 5000 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.
Licenses
The PDG/TTG
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.
Summary of PDG/TTG
Features and Functions
The TTG features and
functions include:
- PDG service
-
PDG mode
- TTG mode
- IKEv2 and IP Security
(IPSec) encryption
- Multiple digital certificate
selection based on APN
- Subscriber traffic policing
for IPSec access
- DSCP marking for IPSec
access
- WLAN access control
- RADIUS and Diameter support
- EAP fast re-authentication
- Pseudonym NAI support
- Multiple APN support
for IPSec access
- Multiple authenctication
support
- Lawful intercept
- IMS emergency call handling
- Session recovery support
- Congestion control
- Bulk statistics
- Threshold crossing alerts
(TCAs)
-
DIAMETER authentication/authorization
support
-
QCI-level QoS configuration
support
-
AAA mediation accounting
and offline charging
Network Deployment(s)
and Interfaces
This section describes
the PDG/TTG as it functions in a GPRS/UMTS data
network.
The PDG in a GPRS/UMTS
Data Network
The PDG is a network
element that provides WLAN-to-3GPP network interworking. This interworking
is achieved by the subscriber UEs in the WLAN access network initiating
an IKEv2/IPSec tunnel to the 3GPP PDG, which functions
as a security gateway that provides the UEs a secure connection
to the Packet Data Network (PDN) or Internet.
The following figure
shows a sample PDG implementation.
Figure 1. Sample PDG Implementation
In the implementation
above, the subscriber UEs first gain access to the WLAN via a Wi-Fi access
point. The UEs get an IP address from the WLAN and use this IP address
for communication over the access IP network. To gain access to
the PDN/Internet, the UEs use IKEv2 protocol to request
a secure IPSec tunnel from the PDG. The UEs may get the IP address of
the PDG either from a statically configured IP address, or they
may use DNS resolution. During IKEv2 negotiation, the PDG allocates
a remote IP address for each subscriber UE to use to access the
PDN/Internet. The PDG binds each UE’s local IP
address with its allocated remote IP address.
The authorization decision
for tunnel establishment for access to a 3GPP W-APN belongs to the
3GPP AAA server. Upon authorization, the PDG terminates a secure
IPSec tunnel for each WLAN UE subscriber session established over
the Wu reference point. The UE establishes a corresponding connection
over the Wi reference point toward the PDN/Internet after
the call is set up by the PDG.
The TTG in a GPRS/UMTS
Data Network
The TTG is a GPRS/UMTS
network element that enables the implementation of PDG functionality
in existing GGSN deployments. It achieves this by using a subset
of the Gn reference point called the Gn' (Gn prime) reference point
to connect to currently-deployed GGSNs. This provides the means
by which GPRS mobile operators can offer new services to current
subscribers by implementing PDG functionality using existing infrastructure.
The following figure
shows a PDG implementation that consists of the TTG working together
with a currently-deployed GGSN. In this implementation, only a subset
of the GGSN functionality is used.
Figure 2. The TTG and GGSN
in a PDG Implementation
In the implementation
above, the TTG terminates a secure IPSec tunnel for each WLAN UE subscriber
session established over the Wu reference point. The TTG also establishes
a corresponding GTP (GPRS Tunneling Protocol) tunnel over the Gn'
reference point to the GGSN. The TTG and the subset of GGSN functions
work together to provide PDG functionality to the UEs in the WLAN.
The TTG functions as
an SGSN in the GPRS/UMTS network to provide an SGTP (SGSN GPRS
Tunneling Protocol) service. The SGTP service enables the TTG to
use GTP over the Gn' interface to carry packet data between itself
and the GGSN. The GGSN establishes a corresponding connection over
the Gi reference point toward the PDN/Internet.
PDG/TTG Logical
Network Interfaces (Reference Points)
The following
table provides descriptions of the logical network interfaces supported
by the PDG/TTG in a GPRS/UMTS data network.
Table 1. PDG/TTG Logical
Network Interfaces
Interface |
Description |
Wu
|
The Wu reference point
is located between the WLAN UE and the PDG/TTG.
The Wu interface carries
the secure IPSec tunnels between the UEs in the WLAN and the PDG/TTG.
The IPSec tunnels carry the ESP (Encapsulating Security Payload)
packets between the UEs and the PDG/TTG.
|
Wm
|
The Wm reference point
is located between the 3GPP AAA server and the PDG/TTG.
The PDG/TTG uses this reference point to retrieve tunneling
attributes and UE IP configuration parameters.
|
Wi (PDG mode only)
|
The Wi reference point
is located between the PDG and the Packet Data Network (PDN) for
WLAN IP access.
|
Gn' (TTG mode only)
|
The Gn' reference point
is located between the TTG and the GGSN.
To provide PDG functionality
in existing GGSN deployments, the TTG functions as an SGSN. For
every IPSec tunnel that is established between the TTG and a WLAN
UE, the TTG initiates a PDP context and a corresponding GTP tunnel over
the Gn' interface to the GGSN. The TTG forwards the W-APN and IMSI
of the WLAN UE to the GGSN in the Create-PDP-Context-Request message.
The following messages
are supported over the Gn' reference point:
- Create PDP Context Request / Response
- Update PDP Context Request / Response
- Delete PDP Context Request / Response
- Error Indication
- Version Not Supported
- GTP Payload Forwarding
- GTP Echo
|
Gi (TTG mode only)
|
The Gi reference point
is located between the GGSN and the Packet Data Network (PDN) for
WLAN IP access when the PDG/TTG is in TTG mode.
|
Features and Functionality
This section describes
the features and functions supported by the PDG/TTG software.
The following features
are supported and described in this section:
PDG Service
The PDG service
provides both PDG and TTG functionality, operating in either PDG
mode or TTG mode. The PDG service enables the UEs in the WLAN to
connect with the core network elements via a secure IPSec interface.
During configuration,
you create the PDG service in a PDG context, which is a routing
domain on the ASR 5000. PDG context and service configuration includes
the following main steps:
- Configure the IPv4 address
for the service: This is the IP address of the TTG to which
the UEs in the WLAN attempt to connect, sending IKEv2 messages to
this address to establish IPSec tunnels.
- Configure the name of
the crypto template for IKEv2/IPSec: A crypto template
is used to define an IKEv2/IPSec policy. It includes IKEv2
and IPSec parameters for keepalive, lifetime, NAT-T, and cryptographic
and authentication algorithms. There must be one crypto template
per PDG service.
- The name of the EAP profile: The
EAP profile defines the EAP authentication method and associated
parameters.
- Multiple authentication
support: Multiple authentication is specified as a part of crypto
template configuration.
- IKEv2 and IPSec transform
sets: Transform set defines the negotiable algorithms for IKE
SAs and Child SAs to enable calls to connect to the PDG/TTG.
- The setup timeout value: This
parameter specifies the session setup timeout timer value. The PDG/TTG
terminates a UE connection attempt if the UE does not establish
a successful connection within the specified timeout period.
- Max-sessions: This
parameter sets the maximum number of subscriber sessions allowed
by this PDG service.
PDG Mode
The PDG mode of
operation uses IKEv2/IPsec tunnels to deliver packet data
services over untrusted Wireless Local Area Networks (WLANs) with
connectivity to the Internet or managed networks.
IMPORTANT:
PDG mode is not fully
qualified and is not supported for field deployment. It is available
for lab use only.
In PDG mode, the system
terminates an IPSec tunnel for each WLAN UE subscriber session established
over the Wu reference point. The UE establishes a corresponding
connection over the Wi reference point toward the PDN/Internet
after the call is set up by the PDG.
TTG Mode
The TTG mode of
operation uses IKEv2/IPsec tunnels to deliver packet data
services over untrusted WLANs with connectivity to the Internet
or managed networks.
In TTG mode, the system
terminates an IPSec tunnel for each WLAN UE subscriber session established
over the Wu reference point. The TTG also establishes a corresponding
GTP tunnel over the Gn' reference point to the GGSN. The TTG and
a subset of GGSN functions work together to provide PDG functionality
to the WLAN UEs. In this configuration, the GGSN sees the TTG as
an SGSN, and no additional changes are required at the GGSN to support
this functionality.
IKEv2 and IP Security
(IPSec) Encryption
The PDG/TTG
supports IKEv2 and IPSec encryption using IPv4 addressing. IKEv2
and IPSec encryption enables network domain security for all IP
packet-switched networks in order to provide confidentiality, integrity,
authentication, and anti-replay protection. These capabilities are
insured through use of cryptographic techniques.
IKEv2 and IP Security
(IPSec) encryption includes the following options:
- IKEv2 encryption protocols: AES-CBC
with 128 bits, AES-CBC with 256 bits, 3DES-CBC, and DES-CBC
- IKEv2 pseudo-random
functions: PRF-HMAC-SHA1, PRF-HMAC-MD5
- IKEv2 integrity: HMAC-SHA1-96,
HMAC-MD5
- IKEv2 Diffie-Hellman
groups: 1, 2, 5, and 14
- IPSec ESP (Encapsulating
Security Payload) encryption: AES-CBC with 128 bits, AES-CBC
with 256 bits, 3DES-CBC, and DES-CBC
- IPSec integrity: HMAC-SHA1-96,
HMAC-MD5
- IKEv2 and IPSec rekeying
Multiple Digital Certificate
Selection Based on APN
Selecting digital
certificates based on Access Point Name (APN) allows you to apply
digital certificates per the requirements of each APN and associated
packet data network. A digital certificate is an electronic credit
card that establishes a subscriber’s credentials when doing
business or other transactions on the Internet. Some digital certificates
conform to ITU-T standard X.509 for a Public Key Infrastructure (PKI)
and Privilege Management Infrastructure (PMI). X.509 specifies standard
formats for public key certificates, certificate revocation lists,
attribute certificates, and a certification path validation algorithm.
During session establishment,
the PDG/TTG can select a digital certificate from multiple
certificates based on the APN. The selected certificate is associated
with the APN that the WLAN UE includes in the IDr payload of the
first IKE_AUTH_REQ message.
When configuring APN-based
certificate selection, ensure that the certificate names match the
associated APNs exactly. The PDG/TTG can then examine each
APN received in the IDr payload and select the correct certificate.
The PDG/TTG
generates an SNMP notification when the certificate is within 30
days of expiration and approximately once a day until a new certificate
is provided. Operators need to generate a new certificate and then
configure the new certificate using the system’s CLI. The certificate
is then used for all new sessions.
Subscriber Traffic
Policing for IPSec Access
Traffic policing
allows you to manage bandwidth usage on the network and limit bandwidth allowances
to subscribers. QoS configurations are stored per QCI level (Quality
of Service class identities.
Traffic policing enables
the configuration and enforcement of bandwidth limitations on individual
subscribers of a particular traffic class in a 3GPP service. Bandwidth
enforcement is configured and enforced independently in the downlink
and uplink directions.
When configured in the
Subscriber Configuration Mode of the system’s CLI, the
PDG/TTG performs traffic policing. However, if the GGSN
changes the QoS via an Update PDP Context Request, the PDG/TTG
uses the QoS values from the GGSN.
Per RFC 2698, a Token
Bucket Algorithm is used to implement the traffic policing feature on
the PDG/TTG. The following criteria is used when determining
how to mark a packet:
- Committed Data Rate (CDR): The
guaranteed rate (in bits per second) at which packets can be transmitted/received
for the subscriber during the sampling interval. Note that the committed
(or guaranteed) data rate does not apply to the Interactive and Background
traffic classes.
- Peak Data Rate (PDR): The
maximum rate (in bits per second) that subscriber packets can be
transmitted/received for the subscriber during the sampling interval.
Using negotiated QoS
data rates, the system calculates the burst size, which is the maximum
number of bytes that can be transmitted/received for the
subscriber during the sampling interval for both committed and peak
rate conditions. The committed burst size (CBS) and peak burst size
(PBS) for each subscriber depends on the guaranteed bit rate (GBR)
and maximum bit rate (MBR) respectively. This represents the maximum
number of tokens that can be placed in the subscriber’s “bucket”.
The burst size is the bucket size used by the Token Bucket Algorithm.
Tokens are removed from
the subscriber’s bucket based on the size of the packets
being transmitted/received. Every time a packet arrives,
the system determines how many tokens need to be added (returned)
to a subscriber’s CBS (and PBS) bucket. This value is derived
by computing the product of the time difference between incoming
packets and the CDR (or PDR). The computed value is then added to
the tokens remaining in the subscriber’s CBS (or PBS) bucket.
The total number of tokens can not be greater than the burst size.
If the total number of tokens is greater than the burst size, the
number is set to equal the burst size.
After passing through
the Token Bucket Algorithm, the packet is internally classified
with a color, as follows:
- If there are not enough
tokens in the PBS bucket to allow a packet to pass, the packet is
considered to be in violation and is marked “red” and
the violation counter is incremented by one.
- If there are enough tokens
in the PBS bucket to allow a packet to pass, but not in the CBS “bucket”,
then the packet is considered to be in excess and is marked “yellow”,
the PBS bucket is decremented by the packet size, and the exceed
counter is incremented by one.
- If there are more tokens
present in the CBS bucket than the size of the packet, then the packet
is considered as conforming and is marked “green” and
the CBS and PBS buckets are decremented by the packet size.
The system can be configured
with actions to take for red and yellow packets. Any of the following
actions may be specified:
- Drop: The offending
packet is discarded.
- Transmit: The offending
packet is passed.
- Lower the IP Precedence: The
packet's ToS octet is set to “0”, thus downgrading
it to Best Effort, prior to passing the packet.
Different actions can
be specified for red and yellow, as well as for uplink and downlink directions
and for different 3GPP traffic classes.
DSCP Marking for IPSec
Access
The Differentiated
Service Code Point (DSCP) marking feature on the PDG/TTG
provides support for more granular configuration of DSCP marking.
IMPORTANT:
Support for storing the
QoS configuration on a per-QCI level instead of the class level
is not fully qualified and is not supported for field deployment.
It is available for lab use only.
The PDG/TTG
functioning as a TTG can perform DSCP marking of packets sent over
the Wu interface in the downlink direction to the WLAN UEs and over
the Gn' interface in the uplink direction to the GGSN.
In the PDG Service Configuration
Mode of the system’s CLI, you use the ip qos-dscp command
to control DSCP markings for downlink packets sent over the Wu interface
in IPSec tunnels, and use the ip gnp-qos-dscp command
to control DSCP markings for uplink packets sent over the Gn' interface
in GTP tunnels.
The DSCP markings are
applied to the IP header of every transmitted subscriber data packet. DSCP
levels can be assigned to specific traffic patterns in order to
ensure that the data packets are delivered according to the precedence
with which they are tagged. The four traffic patterns have the following
order of precedence: background (lowest), interactive, streaming,
and conversational (highest).
For the interactive traffic
class, the PDG/TTG supports per-gateway service and per-APN configurable
DSCP marking for the uplink and downlink directions based on Allocation/Retention
Priority in addition to the current priorities.
The following matrix
can be used to determine the DSCP markings used based on the configured
traffic class and Allocation/Retention Priority:
Table 2. Default DSCP Value
Matrix
Allocation
Priority |
1 |
2 |
3 |
Traffic
Handling Priority |
. |
. |
. |
1 |
ef |
ef |
ef |
2 |
af21 |
af21 |
af21 |
3 |
af21 |
af21 |
af21 |
You can assign DSCP
to specific traffic patterns to ensure that data packets are delivered according
to the precedence with which they are tagged. The diffserv markings
are applied to the outer IP header of every GTP data packet. The
diffserv marking of the inner IP header is not modified.
The traffic patterns
are defined by QCI (1 to 9). Data packets falling under the category
of each of the traffic patterns are tagged with a DSCP that further
indicate their precedence as shown in the following tables:
Table 3. Class structure
for assured forwarding (af) levels
Drop Precedence |
Class |
Class 1 |
Class 2 |
Class 3 |
Class
4 |
Low
|
af11
|
af21
|
af31
|
af41
|
Medium
|
af12
|
af22
|
af32
|
af41
|
High
|
af13
|
af23
|
af33
|
af43
|
Table 4. DSCP Precedence
Precedence (low to
high) |
DSCP |
0
|
Best Effort (be)
|
1
|
Class 1
|
2
|
Class 2
|
3
|
Class 3
|
4
|
Class 4
|
5
|
Express Forwarding
(ef)
|
WLAN Access Control
The PDG/TTG
in TTG mode enables WLAN access control by enabling you to limit
the number of IKEv2/IPSec tunnels per subscriber session.
IMPORTANT:
WLAN access control is
supported in TTG mode only.
In the PDG Service
Configuration Mode of the system’s CLI, the max-tunnels-per-ue command
can be used to specify the maximum number of IKEv2/IPSec
tunnels per subscriber session.
The number of tunnels
per UE is limited by the Network Service Access Point Identifier (NSAPI)
range, which is 5 to 15. Hence, the configurable maximum number
of tunnels is 11, within the range of 1 to 11, with a default value
of 11.
RADIUS and Diameter
Support
RADIUS and Diameter
support on the PDG/TTG provides a mechanism for performing
authentication, authorization, and accounting (AAA) for subscribers.
IMPORTANT:
Diameter is not fully
qualified and is not supported for field deployment. It is available
for lab use only.
The benefits of using
AAA are:
- Higher flexibility for
subscriber access control
- Better accounting, charging,
and reporting options
- Industry-standard RADIUS
and Diameter authentication
The Remote Authentication
Dial-In User Service (RADIUS) and Diameter protocols can be used
to provide AAA functionality for subscribers. The PDG/TTG
supports EAP authentication based on both RADIUS and Diameter protocols.
The AAA functionality
on the PDG/TTG provides a wide range of configuration options
via AAA server groups, which allow a number of RADIUS/Diameter
parameters to be configured in support of the PDG service.
Currently, two types
of authentication load-balancing methods are supported: first-server and
round-robin. The first-server method sends requests to the highest
priority active server. A request will be sent to a different server
only if the highest priority server is not reachable. With the round-robin
method, requests are sent to all active servers in a round-robin
fashion.
The PDG/TTG
can detect the status of the AAA servers. Status checking is enabled
by configuration in the AAA Server Group Configuration Mode of the
system’s CLI. Once an AAA server is detected to be down,
it is kept in the down state up to a configurable duration of time called
the dead-time period. After the dead-time period expires, the AAA
server is eligible to be retried. If a subsequent request is directed
to that server and the server properly responds to the request,
the system makes the server active again.
The PDG/TTG
generates accounting messages on successful session establishment.
For a TTG session, the system creates an IPSec SA for a subscriber
session after it creates the GTP tunnel to the GGSN over the Gn'
interface. The TTG sends an accounting START message to the AAA
server after successful completion of both GTP tunnel creation on
the Gn' interface and IPsec SA creation on the Wu interface.
Additional Command
Option for APN Configuration for Diameter AAA
For APN configuration
for Diameter AAA on the PDG, the APN profile can specify whether the
PDG combines authentication and authorization in the same access
request to the AAA server, or sends an authentication access request
followed by a separate authorization access request. The command
syntax for this authentication command option in the APN Configuration
Mode of the system CLI is:
authentication eap initial-access-request { authenticate-authorize | authenticate-only }
When set to authenticate-authorize,
the PDG performs EAP authentication and authorization using a Diameter
DER-DEA message exchange for all subscribers requesting access to
the specified APN. When set to authenticate-only, the PDG performs
authentication only using a Diameter DER-DEA message exchange. A
successful authentication will be followed by a separate authorization
access request via an AAR-AAA message exchange.
This command option
applies to the PDG/TTG in PDG mode only.
IMPORTANT:
For more information
on AAA configuration, refer to the AAA and GTPP Interface
Administration and Reference.
EAP Fast Re-authentication
Support
When subscriber
authentication is performed frequently, it can lead to a high network
load, especially when the number of currently connected subscribers
is high. To address this issue, the PDG/TTG can employ
fast re-authentication, which is a more efficient method than full
authentication.
Fast re-authentication
is an EAP (Extensible Authentication Protocol) exchange that is
based on keys derived from a preceding full authentication exchange. The
fast re-authentication mechanism can be used during both EAP-AKA
and EAP-SIM authentication.
When fast re-authentication
is enabled, the PDG/TTG receives a fast re-auth ID from
the UE in the IDi payload of the IKE_AUTH_REQ
message. The PDG/TTG sends the fast re-auth ID to the AAA
server in an Authentication Request message to initiate fast re-authentication.
During fast re-authentication,
the PDG/TTG handles two separate IKE/IPSec SAs,
one for the original session and one for re-authentication. The
re-authentication SA remains for a very short period until the fast
re-authentication is successful. After the successful fast re-authentication,
the PDG/TTG assigns the UE with the same IP address. The
SGTP service running on the PDG/TTG identifies the original
session and replicates the same session using the same IP address
assignment. The PDG/TTG then deletes the original session
SA.
The AAA server falls
back to full authentication in the following scenarios:
- When the AAA server does
not support fast re-authentication.
- When the number of times
a fast re-authentication is allowed after a successful full authentication
exceeds the limit configured on the AAA server.
- When the EAP server does
not have the permanent subscriber identity to perform a fast re-authentication.
Pseudonym NAI Support
The PDG/TTG
supports the use of pseudonym Network Access Identifiers (NAIs)
to protect the identity of subscribers against tracing from unauthorized
access networks.
Pseudonym NAIs are
allocated to the WLAN UEs by the EAP server along with the last
successful full authentication. The EAP server maintains the mapping
of pseudonym-to-permanent identity for each subscriber. The UEs
store this mapping in non-volatile memory to save it across reboots,
and then use the pseudonym NAI instead of the permanent one in responses
to identity requests from the EAP server.
Multiple APN Support
for IPSec Access
The PDG/TTG
supports multiple wireless APNs for the same UE (the same IMSI)
for use during subscriber authorization.
To support subscribers
while they attempt to access multiple services, the PDG/TTG
enables multiple subscriber authorizations via multiple wireless
APNs. Each time a UE attempts to access a service, the PDG/TTG
receives a new APN from the UE in the IDr payload of its first IKE_AUTH_REQ
message, and the PDG/TTG initiates a new authorization
as a distinct session.
Multiple Authentication
Support
The PDG/TTG
operating in PDG mode supports multiple authentication phases per
TS 23.234 and RFC 4739. For EAP protocol, the PDG service operates
in authenticator pass-through mode. For PAP and CHAP protocols,
the PDG service operates in EAP authenticator terminator mode. The
PDG exchanges authentication credentials on the access side using
EAP-GTC for PAP payloads and EAP-MD5 for CHAP payloads, and on the
PDN side, it exchanges the same parameters inside RADIUS or Diameter
AAA protocol messages.
IMPORTANT:
Multiple authentication
is not fully qualified and is not supported for field deployment.
It is available for lab use only.
When an APN access
request received from a WLAN UE requires authentication and authorization,
the PDG negotiates with the UE to determine whether it supports
multiple authentication exchanges in IKEv2 protocol. If the UE supports
multiple authentication exchanges, and if the UE requests additional
authentication with the 3GPP AAA server after successful initial
EAP authentication, the PDG performs the next phase of authentication
with the external AAA server.
The PDG requests additional
authentication of the UE from the external AAA server as follows:
- If an EAP procedure
is required (EAP profile = AKA/SIM), the PSG performs
a second phase authentication similar to the first phase authentication
using EAP-AKA or EAP-SIM. If the PDG receives a Legacy-Nak response
from the UE, the PDG sends an EAP-Failure message to the UE.
- If a PAP procedure
is required (EAP profile = GTC), the PDG sends an EAP-GTC request
to the UE. Upon receiving an EAP-GTC response from the UE within
an IKE_AUTH request, the PDG performs the next phase authentication
with the AAA server. If the PDG receives a Legacy-Nak response containing
the type EAP-MD5, and if the specified W-APN allows it, the PDG
changes the authentication and authorization procedure to CHAP.
If the specified W-APN does not allow CHAP procedures or if the
PDG receives a Legacy-Nak response that does not contain EAP-MD5,
the PDG sends an EAP-Failure message to the UE.
- If a CHAP procedure
is required (EAP profile = MD5), the PDG sends an MD5-Challenge
request to the UE. Upon receiving an MD5-Challenge response from
the UE within an IKE_AUTH request, the PDG performs the
next phase authentication with the AAA server. If the PDG receives
a Legacy-Nak response containing the type EAP-GTC, and if the specified
W-APN allows it, the PDG changes the authentication and authorization
procedure to PAP. If the specified W-APN does not allow PAP procedures
or if the PDG receives a Legacy-Nak response that does not contain
EAP-GTC, the PDG sends an EAP-Failure message to the UE.
Fast Re-authentication
and Pseudonym Re-authentication
After a successful
call set-up, if the UE sends a re-authentication request to the
PDG using fast re-authentication or pseudonym re-authentication
(received in the first phase EAP authentication in the IDi payload
of the IKE_AUTH message), the PDG performs EAP-based re-authentication
with the 3GPP AAA server. If the UE sends an ANOTHER_AUTH_FOLLOWS
Notify payload and IDi for a second phase authentication after that,
the PDG performs a second phase authentication with the external
AAA server. If the UE sends a re-authentication request to the PDG
using fast re-authentication or pseudonym re-authentication (received
in the second phase EAP authentication in the IDi payload of the
IKE_AUTH message), the PDG drops the call. In the case
of PAP and CHAP, neither the UE nor the PDG initiate re-authentication for
a second phase authentication directly.
Re-authorization
and RADIUS CoA Handling
An AAA-initiated
change-of-authorization / re-authorization for the external
AAA server is handled in the same way as is handled for the 3GPP
AAA server.
Message Flows
Multiple authentication
support is configured on the PDG on a W-APN basis. For detailed message
flows of multiple authentication scenarios on the PDG, see the section How the PDG/TTG Works later
in this chapter.
Lawful Intercept
The Cisco Lawful
Intercept feature is supported on the PDG/TTG. Lawful Intercept
is a license-enabled, standards-based feature that provides telecommunications
service providers with a mechanism to assist law enforcement agencies
in monitoring suspicious individuals for potential illegal activity. For
additional information and documentation on the Lawful Intercept
feature, contact your Cisco account representative.
IMS Emergency Call
Handling
The PDG/TTG
supports IMS emergency call handling per 3GPP TS 33.234. This feature
is enabled by configuring a special WLAN access point name (W-APN),
which includes a W-APN network identifier for emergency calls (sos,
for example), and can be configured with no authentication.
The DNSs in the network
are configured to resolve the special W-APN to the IP address of
the PDG/TTG. When a WLAN UE initiates an IMS emergency
call, the UE sends a W-APN that includes the same W-APN network
identifier (sos) as the one that is configured on the PDG/TTG.
This W-APN network identifier is prefixed to the W-APN operator identifier
per 3GPP TS 23.003. The W-APN operator identifier sent by the UE
must match the PLMN ID (MCC and MNC) that is configured on the PDG/TTG
(visited network). When the PDG/TTG receives the W-APN
from the UE in the IDr, the PDG/TTG marks the call as an emergency
call and proceeds with call establishment, even in the event of
an authentication or EAP failure from the AAA/EAP server.
If the PDG/TTG
detects that an old IKE SA for the special W-APN already exists,
it deletes the IKE SA and sends an INFORMATIONAL message with a
Delete payload to the WLAN UE to delete the old IKE SA on the UE.
Session Recovery
Support
The session
recovery feature provides seamless failover and nearly instantaneous
reconstruction of subscriber session information in the event of
a hardware or software fault within the same chassis, preventing
a fully-connected user session from being dropped.
IMPORTANT:
Use of the session recovery
feature requires that a valid license key be installed. Contact
your Cisco account representative for detailed information on specific
licensing requirements.
Session recovery is
performed by mirroring key software processes (the IPSec manager, session
manager, and AAA manager, for example) on the PDG/TTG.
These mirrored processes remain in an idle state (in standby mode),
where they perform no processing until they may be needed in the
case of a software failure (a session manager task aborts, for example).
The system spawns new instances of standby mode sessions and AAA
managers for each active control processor being used.
Additionally, other
key system-level software tasks such as VPN manager are performed
on a physically separate packet processing card to ensure that a
double software fault (the session manager and the VPN manager fail
at same time on same card, for example) cannot occur. The packet
processing card used to host the VPN manager process is in active
mode and is reserved by the operating system for this sole use when
session recovery is enabled. At a minimum, four packet processing
cards (3 active and 1 standby) are required on the chassis to support
the session recovery feature.
Congestion Control
Congestion control
allows you to set policies and thresholds and specify how the system
reacts when faced with a heavy load condition.
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.
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, starCongestion, 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,
starCongestionClear, is then triggered.
-
Port Utilization Thresholds: If
you set a port utilization threshold, when the average utilization
of all ports in the system reaches the specified threshold, congestion control
is enabled.
-
Port-specific Thresholds: If
you set port-specific thresholds, when any individual port-specific
threshold is reached, congestion control is enabled system-wide.
-
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.
Bulk Statistics
Bulk statistics
allow operators to choose to view not only statistics that are of
importance to them, but to also configure the format in which they
are 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. The following is a partial list of supported schemas:
- System: Provides
system-level statistics
- Card: Provides card-level
statistics
- Port: Provides port-level
statistics
- PDG: Provides PDG
service statistics
- APN: Provides Access
Point Name statistics
The system supports
the configuration of up to four sets (primary/secondary)
of receivers. Each set can be configured to collect specific sets
of statistics from the various schemas. 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 be configured by the user. Users 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 user 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 of the System Administration Guide.
Threshold Crossing
Alerts
Thresholding on
the system is used to monitor the system for conditions that could
potentially cause errors or outages. 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.
IMPORTANT:
The threshold crossing
alerts feature for the PDG/TTG is not fully qualified and
is not supported for field deployment. It is available for lab use
only.
The system supports threshold
crossing alerts for certain key resources such as CPU, memory, IP
pool addresses, etc. With this capability, the operator can configure
a threshold on these resources whereby, should the resource depletion
cross the configured threshold, an SNMP trap would 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 again 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 again 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 for which active and event logs can be generated.
As with other system facilities, logs are generated messages pertaining
to the condition of a monitored value and 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 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.
IMPORTANT:
For more information
on threshold crossing alert configuration, refer to the Thresholding Configuration
Guide.
AAA Mediation Accounting
and Offline Charging
Offline charging
is a process where charging information is collected at the same
time as resource use. The charging information is then passed through
a chain of charging functions. At the end of the process, CDR files
are generated by the network, which are then transferred to the
network operator’s billing domain.
IMPORTANT:
AAA mediation accounting
and offline charging is not fully qualified and is not supported
for field deployment. It is available for lab use only.
The charging trigger
function (CTF) generates charging events and forwards them to the charging
data function (CDF). The CDF, in turn, generates CDRs which are
transferred to the charging gateway function (CGF). Finally, the
CGF creates CDR files and forwards them to the billing domain.
The CTF and CDF are integrated in the PDG, however, the CGF may
exist as a separate entity or be integrated with the PDG. If the
CGF is external to the PDG then the CDF forwards the CDRs to the
CGF using the GTPP protocol.
In the ASR 5000, the
PDG is integrated with the CTF and CDF and generates WLAN-CDRs based
on triggered events over the Wz interface. The PDG offline charging
involves the following functionalities for WLAN 3GPP IP access:
- Charging Trigger Function
- Charging Data Function
- Wz Reference Point
Accounting Session
Management
The WLAN-CDR
is generated as part of AAAmgr accounting management in PDG. When the
Accounting-Mode is set to GTPP, it indicates that the charging is
enabled and the Wz reference point is to be used for passing charging
records to the CGF.
Triggers for WLAN
CDRs Charging Information
The PDG/TTG
uses the charging characteristics to determine whether to activate
or deactivate CDR generation. The charging characteristics al set
the chargeable event conditions, such as the time/volume
limits that trigger CDR generation or the addition of information.
Multiple charging characteristics profiles may be configured on
the PDG to allow different sets of trigger values.
Triggers for WLAN-CDR
Closure
The following
events trigger closure and sending of a partial WLAN-CDR:
-
Time trigger: every
x seconds configured using interval x.
- Volume trigger:
every x octets configured using volume x
- The command gtpp interim now
A WLAN-CDR is closed
as the final record of a session for the following events:
- normalRelease: UE terminates
the IPSec tunnel. The call is handed from one PDG to another PDG.
- abnormalRelease:
Failure due to multiple software failures.
- volumeLimit: The
configured volume threshold has been exceeded.
- timeLimit: the configured
interval has been reached.
- maxChangeCondition:
the limit for the LOTV containers has been exceeded.
- managementIntervention:
The command gtpp
interim now has been issued.
- managementIntervention:
The command clear
sub all has been issued.
Triggers for WLAN-CDRs
Charging Information Addition
The List of Traffic
Volumes attribute of the WLAN-CDR consists of a set of containers, which
are added when specific trigger conditions are met. They identify
the volume count per PDP context, and are separated for uplink and
downlink traffic:
-
QoS Change: A change
in the QoS results in closing the List of Traffic Data Volumes that
were open. The volumes are added to the CDR and a new bearer-specific
container is opened.
- tariffTime: On reaching
the Tariff Time Change, a List of Traffic Data Volumes container
is added to the CDR.
-
recordClosure: A
list of List of Traffic Data Volumes containers is added to the WLAN
CDR.