ASN Gateway Overview
Access Service
Network Gateway (ASN Gateway) is the subscriber-aware mobility access
gateway for IEEE 802.16 mobile WiMAX radio access networks. These
carrier- and enterprise-class platforms provide exceptional reliability
and performance characteristics for mobile WiMAX operators.
The ASN Gateway provides
inter-technology mobility for 3GPP, 3GPP2, DSL, and WiFi access
technologies. This assures common billing and seamless inter-technology handover.
ASN Gateway is available
for all chassis running StarOS Release 7.1 or later.
IMPORTANT:
The ASN Gateway is
a licensed product that requires an Access Service Network Gateway
support license.
ASN Gateway provides
the following functionality, all of which is integrated with the
chassis:
- ASN Mobility Managment
- DHCP proxy server
- DHCP Relay
- Connectivity Service
Network (CSN) mobility
- Intra-ASN and inter-ASN
handover
- Paging controller/location
register
- Radio resource controller
relay function
- Service Flow Authenticator
(SFA)
- Proxy-Mobile Internet
Protocol (P-MIP) client
- Mobile IP Foreign
Agent (MIP FA) protocol
- Data path function
- Context server function
- Handover relay function
-
WiMax NSP-ID functionality
- 802.1P QoS support
- RADIUS-based prepaid
accounting and hotlining for WiMAX
- DHCP relay support
for ASNGW
-
Creation, modification,
and deletion of pre-provisioned/dynamic service flows
ASN Mobility Management
The Access
Service Network Gateway (ASN Gateway) processes subscriber control
and bearer data traffic. It also supports connection and mobility
management across cell sites and inter-service provider network
boundaries. An ASN Gateway is a logical entity in the Access Service
Network (ASN) of a WiMAX radio access network and interfaces directly
with base transceiver station or base station via an R6 GRE reference
interface. An ASN Gateway performs control plane functions, bearer
plane routing or bridging functions, resident functions in the connectivity
service network, or a function in another ASN.
The ASN Gateway is
placed at the edge of an ASN and is the link to the CSN. Each ASN
Gateway can concentrate traffic from multiple radio base stations.
This reduces the number of devices to manage and minimizes connection
set-up latency by decreasing the number of call handovers in the
network.
Figure 1. Basic ASN Gateway
Network
To support Mobile
IP and/or Proxy Mobile IP data applications, you can configure
the system to perform the role of the ASN Gateway/foreign
agent and/or the home agent within the connectivity service
network (CSN) of your WiMAX data network. When functioning as a
home agent, the system can be located within your WiMAX network
or in the CSN of an external enterprise or ISP network. In either
case, the ASN Gateway/foreign agent terminates the mobile subscriber’s
call session and then routes the subscriber’s data to and
from the appropriate home agent.
Figure 2. Basic ASN Gateway
Mobile IP Network
EAP User Authentication
The ASN Gateway
serves as the Extensible Authentication Protocol (EAP) authenticator
and mobility key holder for subscriber connections and RADIUS clients
to attached Authorization, Authentication, and Accounting (AAA)
servers.
ASN Gateway and
AAA
ASN control
is handled by the ASN Gateway and the base station. The ASN Gateway
control plane handles the feature set, including AAA functions,
context management, profile management, service flow authorization,
paging, radio resource management, and handover. The data plane
feature set includes mapping radio bearer to the IP network, packet
inspection, tunneling, admission control, policing, QoS, and data
forwarding.
The ASN Gateway acts
as an authenticator. It operates in pass-through mode for EAP authentication
between the EAP client (the mobile station) and the EAP (AAA) server.
After successful EAP authentication, the AAA server sends the master
session key (MSK) to the ASN Gateway. The ASN Gateway, as authenticator,
performs authorization key (AK) context management. It derives the
AK from the MSK and sends it to the base station. As part of the
AK context, other information, such as the AkID and CMAC are sent
to the base station to secure the R1 interface.
An AAA module in the
ASN Gateway provides flow information for accounting. Every detail
about a flow, such as the transferred or received number of bits,
the duration of the connection, and the applied policy, is retrievable
from the data plane.
Profile Management
The ASN Gateway
provides profile management and a policy function that resides in
the connectivity network. Profile management identifies a subscriber’s
feature set, such as the allowed QoS rate, number of flows, and
type of flows.
In addition, the ASN
Gateway maintains a context for the mobile subscriber and the base
station. Each subscriber’s context contains the subscriber’s
profile and security context, and the characteristics of the subscriber’s
mobile device. The subscriber’s context is retrieved and
exchanged between the serving base station and a target base station during
handover.
The ASN Gateway authorizes
service flows according to the subscriber’s profile. Allowed service
flows and active service flows can change over time, so the ASN
Gateway provides admission control for downlink traffic. The ASN
Gateway creates a GRE tunnel per service flow.
Inter-ASN Handovers
During a handover,
the ASN Gateway provides the subscriber’s context to a
target base station and when requested, changes the data path. To
minimize latency and packet loss, the ASN Gateway implements data
integrity through bi-casting or multi-casting. For paging, buffering
is also supported. A foreign agent maintains the IP connectivity
if the mobile subscriber initiates an inter-ASN handover. The ASN Gateway
supports either Proxy-Mobile IP (PMIP) or Client-Mobile IP (CMIP)
in order to communicate with home agents.
The ASN Gateway maintains
location information to provide the paging service that tracks subscribers
when they are operating in idle mode. If there is any download traffic,
ASN Gateway requests the PC to trigger paging. During active operation, location
information is also updated as the mobile subscriber moves to a
new base station.
Supported Features
The Access
Service Network Gateway (ASN Gateway) provides ASN Gateway control
and bearer plane routing functions:
- BS Interface: R6 IP/GRE
bearer plane
- Inter-ASN handovers
to other ASN Gateways: R4 IP/GRE bearer plane
- Interactions with
AAA management or policy servers: R3 RADIUS interface
- Mobile IP Interface
to HA in Connectivity Service Network: R3 IP-in-IP tunneling
A Profile C ASN Gateway
is one of three alternative designs for radio resource management proposed
by the WiMAX Forum. In Profile C architecture, the handover control
component resides in the base stations. The ASN Gateway represents
a transparent message relay point between neighboring base stations.
The Radio Resource Controller (RRC) component in every BTS periodically
polls its neighbors to build a resource availability database that
it checks prior to triggering call handovers.
Profile C provides
a high performance ASN Gateway platform with the following supported features
in the current software version.
IMPORTANT:
Not all features are
supported on all platforms.
Simple IPv4 Support
A Simple IP
model supports non-mobile IP terminals and provides ASN-anchored
mobility for fixed, nomadic, or portable mobility applications.
A Simple IP architecture removes dependencies for separate foreign
agent and home agent functions. ASN Gateway handles simultaneous
combinations of Simple IP, Mobile IP, or Proxy Mobile IP calls.
A Simple IP model permits the ASN to be combined or split from the
CSN, depending upon the need for roaming. The Simple IP implementation
includes a DHCP Proxy Server function for local or AAA-provided
IP address assignment.
Simple IP provides
a solution for stationary wireless DSL-like applications. It enables
mobility on intra-ASN handovers between neighboring base stations
and permits inter-ASN mobility via an R4 interface between ASN Gateways.
DHCP Proxy Server
Compared to
3G wireless technologies such as EV-DO (Evolution-Data Optimized)
or PDP (Packet Data Protocol) Type PPP (Point-to-Point Protocol)
contexts in General Packet Radio Service/Wideband Code
division Multiple Access (GPRS/W-CDMA) networks, WiMAX
networks do not use a PPP data link layer between access devices
and the ASN Gateway. An alternative approach to IP address allocation is
needed in Simple IP and Proxy Mobile IP usage models.
The ASN-GW includes
a DHCP proxy/server/relay that interacts with
the DHCP client function on the access device. In a Simple IP usage
model, the DHCP server allocates dynamic addresses from a local
address pool or fetches static addresses from subscriber profiles
during authentication from a AAA server. Alternatively, the ASN-GW
uses a DHCP relay process to forward the DHCP request to an external
DHCP server.
In a Proxy Mobile
IP use case, the ASN-GW uses a DHCP proxy to trigger a local foreign agent
function to initiate a Mobile IP Request via the R3 interface to
a home agent. The home agent returns the address via the Mobile
IP Response. The DHCP Proxy component on the ASN Gateway conveys
the address in a DHCP Response message to the DHCP client running
on the user’s access device.
This solution enables
mobility on intra-ASN handovers between neighboring base stations. It
also permits inter-ASN mobility via an R4 interface between ASN Gateways.
DHCP Relay Support
Following are the
enhancements and changes to the existing functionality of the DHCP
relay. Refer to the DHCP Relay section for details.
- DHCP Module enhancements,
including the addition of DHCP Relay Agent option in the relayed
messages to the DHCP server, DHCP Auth sub-option in the relayed messages
to the DHCP server. and decoding of the DHCP Auth sub-option from
the DHCP server messages
- DHCP Relay for SIP
and PMIPv4 calls
- DHCP Relay support
for Init reboot scenario
- DHCP NAK is also handled
through the DHCP Relay
- AAA related enhancements,
including receipt of the DHCP server address, DHCP-RK, DHCP-Key-ID
attributes from the AAA, and decryption of the DHCP-RK
- Session recovery support
for SIP and PMIPv4 call lines with DHCP Relay functionality
- CLI related enhancements,
such as changes to subscriber configuration to enable the DHCP relay
option, and configuration of DHCP Server Address, and DHCP-RK and
DHCP-Key-ID in the DHCP service
ASN Gateway Micro-Mobility
ASN Gateway
micro-mobility provides ASN Gateway-anchored L2 handovers. This
low-latency procedure assures the seamless mobility of mobile access
devices within a WiMAX network. The ASN Gateway supports both uncontrolled
and controlled handovers for micro-mobility.
Uncontrolled Handovers
In an uncontrolled
handover scenario, a mobile subscriber attempts to re-enter the
WiMAX network at a target base station without the handover preparation
procedures with the serving base station.
In order to authenticate
the roaming user, the target base station obtains the subscriber
and security context information from the serving ASN. The anchor authenticator
ASN Gateway conveys the context response message and assists in
the establishment of a new R6 GRE bearer connection to the target
base station. It is referred to as an L2 operation because the previously
assigned IP address for the binding remains the same on the anchor
authenticator/data path ASN Gateway while the L2 BSID (Ethernet
MAC address) is updated for the target base station.
Uncontrolled handovers
are supported for both Simple IP or Mobile IP use cases.With uncontrolled
L2 handover procedures, interactive and non-real-time applications
incur minimal performance degradation and packet loss during subscriber
movement between cell sites.
Controlled Handovers
A controlled
handover occurs when a subscriber access device explicitly requests
handover assistance from the serving base station to a new target
base station. This process minimizes packet loss to the WiMAX access
device. During the handover request, the serving base station provides
the subscriber’s context information to the anchor authenticator
ASN Gateway and a list of target base stations that are preferred
by the mobile device. Upon a successful response from potential
target base stations, the anchor authenticator ASN Gateway initiates
a data path for the mobile subscriber to the target base station.
It also transfers all contextual information for the session to
the target base station. The downlink traffic for the mobile subscriber
is simultaneously broadcast and subsequently buffered by each of
the target base stations.
Controlled handovers
may be triggered by the mobile access device or the serving base
station as a congestion overload control mechanism.
Controlled handovers
and associated data path pre-registrations minimize the impact on performance
to a greater extent than uncontrolled handovers and significantly
reduce datapath outages.
WiMAX R4 Inter-ASN
Mobility Management
R4 inter-ASN
mobility management procedures enable low latency call handovers
between neighboring ASN Gateways located in different geographical
regions or different operator networks. During mobility operations,
the call is anchored on the anchor authenticator ASN Gateway. When
a mobile subscriber roams to a destination cell site, the target
base station connects to the anchor gateway over the serving ASN
Gateway’s R4 interface. The R4 interface provides control
functions such as security context transfers and IP/GRE
bearer level connections. The data conveyed to the subscriber by
the remote hosts is subsequently tunneled over R4 by the anchor
authenticator gateway to the serving gateway. The current ASN Gateway
implementation supports the co-existence of anchor authenticator
and anchor datapath functions in the same ASN Gateway.
Supported R4 functionality
includes:
- R4 over Simple IP
connections
- R4 over Mobile IP
connections
- Anchor Gateway bi-casting
over simultaneous R6 and R4 sessions
- Co-location of DHCPv4
Proxy and PMIPv4 FA on anchor authenticator gateway
- Support for multiple
QoS service flows per-session via R4 tunnels
IMPORTANT:
Both the anchor gateway
session and non-anchor gateway sessions are counted towards the session
license separately. Licensed session limits are enforced based on
the total number of anchor and non-anchor sessions.
WiMAX R3 CSN Anchored
Mobility Management
The R3 reference
point defines a set of control plane protocols between the Access
Service Network (ASN) and Connectivity Service Network (CSN) to
support AAA, policy enforcement, and mobility management functions.
The R3 reference interface is used in a mobile IP application with
the home agent acting as the call anchor point. In contrast to L2-based
ASN anchored mobility procedures, CSN anchored mobility is L3-based
and supports both proxy mobile IP and mobile IP calls. The R3 interface
uses mobile IP signaling and IP-in-IP tunneling or GRE tunneling
and includes standard features such as dynamic Home of Address (HoA)
address allocation. Mobility signaling messages are authenticated
by the home agent based on a dynamic user identity called a pseudo-NAI
which changes after each authentication.
Mobile IP applications
are well suited for inter-provider roaming applications and inter-technology
handovers such as WiMAX-HRPD Rev A, WiMAX-WiFi, and WiMAX-W-CDMA.
Mobile IP also provides an attractive solution for operators with
a heterogeneous radio access network who want to support seamless
mobility across base transfer stations from multiple RAN suppliers.
IMPORTANT:
Support for this function
requires the HA feature license key.
Proxy Mobile IPv4
(PMIPv4)
The P-MIP procedure
is designed only for Simple IP-capable access devices for which
mobility procedures are performed entirely in the network. Certain
events on the access device require relocation of the L3 anchor
point (for example, CoA). One case is for the initial connection
establishment in which the home agent or H-AAA server assigns an
IP address and generates the mobility binding. Another is when the
mobile subscriber roams across cell sites or ASNs and attaches to
a target ASN Gateway.
Client Mobile IPv4
(CMIPv4)
CMIPv4 provides
mobility procedures for mobile IP-capable access devices. In contrast
to PMIPv4, where stateful DHCP proxy signaling triggers R3 signaling
between the ASN Gateway and the home agent, CMIPv4 uses agent advertisement
between the foreign agent component in the ASN Gateway and mobile
IP client on subscriber access device. Mobile IP signaling occurs
directly between the access device and the anchor foreign agent
component in the ASN Gateway.
Authenticator
The authenticator
function in the ASN Gateway acts as an anchored authenticator for
a subscriber for the duration of the session. For example, as a
subscriber moves between base stations served by the ASN Gateway,
the authenticator anchor remains stationary. If a subscriber moves
to a base station served by a different ASN Gateway, the anchor
authenticator is hosted at that ASN Gateway. If the R4 interface
is not supported between both gateways, only the subscriber needs
to be re-authenticated.
The RADIUS client
for authentication and accounting is collocated with the authenticator
function. The ASN Gateway acts as an EAP relay and is agnostic to
the EAP method. EAP transport between the ASN Gateway and the base
station is performed as a control exchange. The base station functions
as an EAP relay, converting Pair-wise Master Key version 2 (PKMv2)
to the EAP messages for the ASN Gateway. The ASN Gateway works in
pass-through mode and any EAP method that generates keys, such as
MSK or EMSK, is supported in the system.
PKMv2 performs over-the-air
user authentication. PKMv2 transfers EAP over the IEEE 802.16 air
interface between the MS and the base station. The base station
relays the EAP messages to the authenticator in the ASN Gateway.
The AAA client on the authenticator encapsulates the EAP message
in AAA protocol packets, and forwards them through one or more AAA
proxies to the AAA server in the CSN of the home NSP. In roaming
scenarios, one or more AAA brokers with AAA proxies may exist between
the authenticator and the AAA server. AAA sessions always exist
between the Authenticator and AAA server, with optional AAA brokers providing
a conduit for NAI realm-based routing.
EAP Authentication
Methods
WiMAX networks
use Ethernet as the L2 protocol for network access authentication.
The Extensible Authentication Protocol (EAP) provides the network
authorization function. The ASN Gateway represents the EAP authenticator
and supports a transparent relay point between the EAP client on
the subscriber access device and EAP server on the AAA. The ASN
Gateway triggers an EAP-identity request to the subscriber device.
The subscriber device responds with an EAP-identity response. It
subsequently unpacks EAP messages over the R6 interface and transfers
them via RADIUS or Diameter signaling to the AAA server.
EAP authentication
provide multiple authentication methods that can be tailored to
the operator’s preference toward user-level, device-level,
or user- and device-level network authorization. At the H-AAA server
in Home Network Service Provider (H-NSP), device-level authentication
in a roaming application guards against unauthorized network access by
users with stolen access devices.
Supported RADIUS
Methods
ASN Gateway
supports following EAP authentication and authorization methods
using RADIUS:
- EAP-Pre-shared Key
(EAP-PSK)
- EAP-Transport Layer
Security (EAP-TLS)
- EAP-Tunneled Transport
Layer Security (EAP-TTLS)
- EAP-Authentication
and Key Agreement (EAP-AKA)
EAP-Pre-shared
Key (EAP-PSK)
EAP-PSK is
a symmetric mutual authentication method that uses manually provisioned
pre-shared keys between an EAP client on an access device and an
EAP server component on AAA. The size of the pre-shared key can
be up to 256 bytes.
EAP-Transport Layer
Security (EAP-TLS)
EAP-TLS is
an asymmetric authentication method that uses X.509 digital certificates,
for example public/private key pairs, and enables device-based
authentication.
EAP-Tunneled Transport
Layer Security (EAP-TTLS)
EAP-TTLS is
a multi-level authentication scheme to enable device and user-based
authentication. The first level handshake provides device-level
authentication and uses the same encryption and ciphering algorithms
as EAP-TLS. The device can, but is not required to, be authenticated
via a CA-signed PKI certificate to the server. The secure connection
established through the first level handshake is then extended with
MS-CHAP-V2 authentication to verify user credentials. As with other
EAP methods, successful EAP transactions at AAA result in a Master
Session Key (MSK) that is returned over an encrypted connection.
The ASN Gateway uses the key to generate a derivative key for securing
the air interface between ASN and user access device.
EAP-Authentication
and Key Agreement (EAP-AKA)
EAP-AKA uses
symmetric cryptography based on pre-shared private client/server
keys and challenge-response mechanisms similar to other EAP methods.
It verifies credentials for users of Removable User Identity Modules
(R-UIMs).
Supported Diameter
Methods
ASN Gateway
supports the following Diameter methods for EAP authentication and
authorization:
EAP-Authentication
and Key Agreement (EAP-AKA)
EAP-AKA uses
symmetric cryptography based on pre-shared private client/server
keys and challenge-response mechanisms similar to other EAP methods.
It verifies credentials for users of Removable User Identity Modules
(R-UIMs).
WiMAX Prepaid Accounting
The system
supports prepaid accounting for clients on the ASN Gateway.
Clients can communicate
directly to a home AAA server or be proxied through a visited network’s
AAA server. The following figure shows a typical prepaid network
topology.
Figure 3. Prepaid Network Topology
Volume and Duration-based
Prepaid Accounting
Prepaid accounting
is a licensed-enabled feature. The ASN Gateway supports both volume threshold
and duration threshold based prepaid accounting. Even though session-level
accounting is performed for both volume and duration, the number
of bytes in a multi-flow session is applied to a duration-based
configuration.
RADIUS attributes
identify thresholds and quotas for both volume (number of bytes)
and duration (length of session).
Supported Enhanced
Features
All enhanced
features described in this section require the appropriate feature
license keys.
Lawful Intercept
The Cisco Lawful
Intercept feature is supported on the ASN Gateway. Lawful Intercept
is a licensed-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 local Cisco account representative.
Intelligent Traffic
Control
Intelligent
Traffic Control (ITC) supports customizable policy definitions.
The policies enforce and manage service level agreements for a subscriber
profile, thus enabling differentiated levels of services for native
and roaming subscribers.
ITC includes features
such as traffic prioritization, for example, marking DiffServ codepoints
to enable unique treatments for the five WiMAX classes of service, queue
redirection, and per-subscriber/per-flow traffic bandwidth
control. Traffic policing enables maximum rate-based services and
tiered bandwidth charging models. ITC includes a local policy engine
that runs on an ASN Gateway in a Simple IP usage model, or as a
home agent in a Mobile IP application. You can configure ITC policies
statically with Class-Maps to identify applications flows that use
L3/L4 5-tuple identifiers. You can then apply the resulting
policy actions through policy maps and policy groups. The detection
and programming of the local policy engine can alternatively be
triggered on network access at the ASN Gateway as it retrieves QoS
profiles for each authenticated user.
This feature provides
a policy mechanism so you can enable user entitlements and provision treatments
for native users and applications relative to roaming subscribers,
Mobile Virtual Network Operators (MVNOs), and offnet P2P traffic.
Hotlining/Dynamic
RADIUS Attributes
WiMAX is an
all IP-based networking technology in which mobile operators seek
a more profitable business model. One way to do this is to avoid
traditional device subsidization that accompanies the sale of locked
devices that restrict access to provisioned subscribers of an operator’s
network. The WiMAX Forum has proposed remote Over-the-Air (OTA)
activation protocols such as Open Mobile Alliance Device Management
(OMA DM) to enable self-provisioned, self-configured, retail subscription
models.
The ASN GW supports
hotlining on a session basis. This capability is enabled by default.
The rule-based hotlines use an IP redirection rule with the standard
attribute Filter-ID. The server sends the ACL names in the Filter-ID
attribute. This in turn, locates the rules.
Upon receiving a RADIUS
Access-Accept message containing the Filter-ID attribute, the ASN
GW locates the rule list, using the name contained in Filter-ID,
and applies them to the session.
Configure the rules
locally on the ASN GW under ACL groups.
In this scenario:
- A user with an unprovisioned
access device registers with a special decorated NAI that represents
him/her as a non-subscriber to the AAA.
- The AAA grants limited
network access by returning a hotlining filter rule to the ASN Gateway.
ASN GW hotlining support uses the standard attribute Filter-ID,
along with the session identification parameters User-Name, Calling-Station-ID,
and AAA-Session-ID.
- An IP address is assigned
during initial network entry. The ASN Gateway uses the redirect
address associated with the filter rule to hotline the call to a
web activation portal.
- The user profile and
subscription activation process is completed. The call is forwarded to
the OMA DM server.
- The OMA DM server
triggers a network-initiated bootstrapping session with the OMA DM
client on the user access device.
- The OMA DM uses XML
messaging over a secure OTA connection to remotely configure the
access device.
- If a session and an
ACL list are located, the rules are applied to the session and a
COA-ACK is returned. The AAA server transmits a RADIUS message to
the ASN Gateway instructing it to “unhotline” the
session.
- At this point, the
user is a known subscriber to the back-end subscription database
and is granted unrestricted access to the network.
This feature facilitates
a non-subsidized retail activation model through over-the-air user-driven
subscription and remote device configuration. It also prevents unprovisioned
users unrestricted access to the wireless operator’s network.
This is a complementary technique you can use with operator fraud
prevention systems by quarantining fraudulent user sessions or redirecting them
to a billing/web portal.
Multi-flow QoS
Within a WiMAX
ASN, QoS enforcement is administered by the Service Flow Authorization
(SFA) component in the ASN Gateway (also referred to as Anchor Policy
Charging Enforcement Function, or A-PCEF). SFA provides traffic
management and QoS policy management for subscriber service flows.
Multi-flow QoS enables
the establishment of static traffic policies for various subscriber
application level service flows. It can be used in Simple IP or
Mobile IP usage scenarios. The policies are stored in a Subscriber
Policy Repository (SPR) database and retrieved as authenticated
QoS profiles by the ASN Gateway. The A-PCEF negotiates via R6 with the
Service Flow Manager (SFM) function on the base station. If the
authorized QoS profile matches the available base station resources,
the request is granted. The A-PCEF provides the following:
- Traffic classification
- Admission control
- Prioritization (DSCP
marking)
- Per-session/per-flow
bandwidth control
- Flow mapping across
application-specific R6/R4 GRE tunnels
In conjunction with
multiflow QoS, the ASN Gateway offers configurable accounting on
a per-session, per-R6, or per-service flow basis. Multi-flow QoS
enables the OFDM radio access connection to be separated into multiple
logical Connection ID’s (CIDs) with each pair of forward and
reverse sub-channels transporting one or more application flows.
ASN Gateway supports
pre-provisioned as well as dynamic service flows. A total of up
to 12 uni-directional service flows per subscriber R6 or R4 session
are possible.
Multi-flow QoS provides
enhanced an user experience via end-to-end differentiated QoS connection-oriented
services and stringent treatment for isochronous voice and delay-sensitive multimedia
applications over broadband WiMAX networks. This feature also enables
service convergence and is the foundation for delivery of IMS service control.
802.1P QoS Support
Quality of
Service (QoS) is a method to better handle the challenges of reliability
and quality despite increasing bandwidth demands. 802.1p which is
a signaling technique for prioritizing network traffic at the data-link/MAC
sublayer (OSI Reference Model Layer 2).
Network administrators
have two major types of Quality of Service (QoS) techniques available.
They can negotiate, reserve, and hard-set capacity for certain types
of service, or simply prioritize data without reserving any capacity
setting.
The 802.1p header
includes a three-bit field for prioritization, which allows packets
to be grouped into various traffic classes. The packets contain
a 32-bit tag header located after a destination and source address
header. IEEE 802.1p-compliant switches pick up this tag, read it, and
put the packet in the appropriate priority queue. No bandwidth is
reserved nor requested with this technique.
There are eight priority
levels, numbered 0 throuh 7, and consequently, eight possible queues
that can be created. Level 7 represents the highest priority and
is assigned to mission-critical applications. Levels 6 and 5 are
designed for delay-sensitive applications such as interactive video
and voice. Levels 4 to 1 are suitable for regular enterprise data
transfer, as well as streaming video. Level 0 is assigned to traffic
that can tolerate a best-effort protocol.
For more information
and configuration examples, see “ASN Gateway QoS and Service Flow
Configuration” in this guide.
ASN Gateway Intra-Chassis
Session Recovery
This feature
enables the system to recover from single software or hardware faults
without interrupting subscriber sessions or losing accounting information.
Intra-chassis session recovery uses regular task check-pointing
of active call states to insure that the fail-over task has the
identical configuration and state as the failed process.
Session recovery is
supported for the following major features:
- Simple IP, Proxy Mobile
IP or Client Mobile IP calls
- R6 or R4 control signaling
and bearer level subscriber traffic
- Paging Controller/Location
Register (PC/LR) idle mode sessions. PC/LR is
a licensed-based feature.
- L2TP LAC & LNS
tunnels and sessions
IMPORTANT:
Minimum hardware requirements
consist of four processing cards (3 Active, 1 Standby). When session
recovery is enabled, overall system capacity may be reduced, depending
upon configuration.
Intra-chassis session
recovery provides hitless in-service recovery that increases system availability.
This eliminates the need for the Radio Access Network to re-register
large blocks of simultaneous users. It also minimizes the likelihood
of revenue leakage due to the failure of network elements.
This feature requires
a feature license key for ASN Gateway session recovery.
Robust Header Compression
(ROHC)
Header compression
is applied to ASNGW service flows when ROHC is enabled on the ASNGW
and the MS and the AAA server authorize ROHC for the ASNGW call.
ROHC parameter values are negotiated over R6. Unidirectional and
bi-directional ROHC service flows are supported.
Supported Inline
Services
All inline services
described in this section require the appropriate feature license keys.
Enhanced Charging
Service
The Enhanced
Charging Service (ECS) is an in-line service feature integrated
with the system. ECS provides flexible, differentiated, and detailed
billing to subscribers by using Layer 3 through Layer 7 packet inspection.
ECS can integrate with a back-end billing system. ECS functionality
is supported at the point where sessions are anchored—for
example, on the ASN Gateway for Simple IP sessions and on the home
agent for Mobile IP sessions.
For more information
about ECS, refer to the Enhanced Charging Services Administration
Guide.
Multi-host Support
ASN Gateway’s
multi-host feature provides multiple host connectivity.
A WiMAX CPE modem
supports multiple IP hosts in fixed/nomadic applications.
The modem shares a single WiMAX airlink to connect to the WiMAX
IP network. This feature is an effective solution for small or home
office users to provide multiple station connectivity through one
airlink.
Figure 4. Multi Host Support
in WiMAX Network
The WiMAX ASN Gateway
allows each WiMAX MS (identified by its 6-byte MSID) to be assigned
a single IP address. IP accounting is maintained for the IP address.
How it Works
The DHCP proxy
server and the IP pool hosted locally on the ASN Gateway provide
the primary IP address from a primary IP pool to the WiMAX customer
premise equipment (CPE). The CPE is identified by its WiMAX R6 MSID
(6-byte MAC address).
IMPORTANT:
Multiple IP hosts
feature is not supported for Proxy-MIP session.
Once a primary IP
address is assigned dynamically to the WiMAX CPE, additional IP addresses
are assigned dynamically to other IP hosts. Each of the IP hosts
is identified by its unique 6-byte MAC address. The DHCP proxy on
the ASN Gateway manages the IP addresses by mapping them to the
unique MAC addresses supplied by the client in the chaddr option
field in DHCP DISCOVER or REQUEST messages.
The primary IP address
is assigned to the CPE first via DHCP. It is followed by requests
for additional IP addresses by individual IP hosts behind the CPE.
The ASN Gateway allocates secondary hosts on-demand, up to the configured
limit of 4.
Primary IP addresses
assigned to WiMAX CPE and secondary IP addresses assigned to the IP
hosts, are configured in separate IP pools or the same IP pool.
Accounting is based on the primary IP address assigned to CPE and
UDR accounting is enabled only for the primary session (flow/session
based). No accounting is performed for secondary sub-sessions.
Using the device credentials
of the WiMAX CPE, authentication is performed with the EAP-TLS method.
There is no authentication for each assigned IP address, and no
validation of MAC addresses contained in DHCP requests, except to
make sure that they are unique across all subscribers connected
to the DHCP proxy server.
IP Address Allocation
through DHCP
The dynamic
IP address allocation procedure for primary node and secondary hosts
is described below:
- After the initial
network entry for WiMAX CPE is completed, the WiMAX CPE acts as
a primary node and starts the DHCP process with the WiMAX ASN Gateway.
- The DHCP proxy server
hosted on the ASN Gateway allocates the Primary IP address to the
WiMAX CPE as a primary node from the configured primary IP Pool.
- The primary IP address
is the first IP address assigned to the WiMAX CPE. The DHCP DISCOVER
and REQUEST messages for this must contain the WiMAX R6 MSID as
the chaddr field.
After this IP address is assigned, the session goes into Connected
state and is ready to accept DHCP requests for additional IP addresses
for other IP hosts.
- Once the primary IP
address is assigned to the primary node (WiMAX CPE), hosts behind
the CPE start the DHCP process with the WiMAX ASN Gateway for each
host mapping to its 6-byte MAC address.
- The DHCP proxy server
hosted in the ASN Gateway allocates the secondary IP addresses to
the hosts behind the CPE as an auxiliary node from the configured
secondary IP Pool.
- When session termination
is requested, the primary IP address is the last IP address to be
released by the clients and ASN Gateway. This means the primary
IP address must be in use and in lease for the session to continue
in Connected state. When the Primary IP address is released, the
ASN Gateway session is terminated and all IP addresses are freed.
- The auxiliary IP addresses
can be assigned and freed any time during the call via DHCP messages.
ASN Gateway in
a WiMAX Network
In a WiMAX
network architecture, each of the entities, Subscriber Station (SS)/Mobile
Station (MS), Access Service Network (ASN) and Connectivity Service
Network (CSN) represent a grouping of functional entities.
Each of these functions
may be in a single physical device or distributed over multiple
physical devices to meet functional and interoperability requirements. The
following figure shows a high-level example of WiMAX network architecture
Figure 5. WiMAX Network Architecture
Access Service
Network (ASN)
The ASN is
an aggregation of functional entities and corresponding message
flows associated with the access services. The ASN represents a
boundary for functional interoperability with WiMAX clients, WiMAX
connectivity service functions, and other vendor-specific functions.
An ASN is defined
as a complete set of network functions that provide radio access
to a WiMAX subscriber. The ASN provides the following functions:
- WiMAX Layer-2 (L2)
connectivity with WiMAX SS/MS
- The transfer of AAA
messages to WiMAX subscribers’ Home Network Service Provider
(H-NSP) for authentication, authorization, and session accounting
for subscriber sessions
- Network discovery
and the selection of an appropriate NSP from which WiMAX subscribers
accesses WiMAX service(s)
- Relay functionality
for establishing Layer-3 (L3) connectivity with a WiMAX SS/MS (IP
address allocation)
- Radio resource management
- ASN-CSN tunneling
In addition to the
above mandatory functions, for a portable and mobile environment
the ASN supports the following functions:
- ASN anchor mobility
- CSN anchor mobility
- Paging and location
management
The ASN has the following
network elements:
- The WiMAX base station,
which is a logical entity that embodies a full instance of the WiMAX
Medium Access Control (MAC) layer and physical layer in compliance
with the IEEE 802.16 suite of applicable standards. The base station
may host one or more access functions and is logically connected
to one or more ASN Gateways.
- The ASN Gateway (ASN
Gateway), which is a logical entity that represents an aggregation
of control plane functional entities. These entities are paired
with a corresponding function in the ASN, for example a base station
instance, a resident function in the CSN, or a function in another
ASN.
The ASN Gateway may
also perform bearer plane routing or bridging functions.
The ASN consists of
at least one instance of a base station and at least one instance
of an ASN Gateway (ASN Gateway). An ASN may be shared by more than
one Connectivity Service Networks (CSN).
The ASN decomposition
with Network Reference Model (NRM) is shown in the following figure.
Figure 6. ASN Network Reference
Model with ASN Gateway
Connectivity Service
Network (CSN)
The Connectivity
Service Network (CSN) is a set of network functions that provide
IP connectivity services to the WiMAX subscriber. A CSN provides
the following functions:
- SS/MS IP
address and endpoint parameter allocation for user sessions
- Internet access
- AAA proxy or server
- Policy and admission
control based on user subscription profiles
- ASN-CSN tunneling
support,
- WiMAX subscriber billing
and inter-operator settlement
- Inter-CSN tunneling
for roaming
- Inter-ASN mobility
- Home agent
The CSN also provides
location-based services, connectivity for peer-to-peer services, provisioning,
authorization and/or connectivity to IP multimedia services,
and support for lawful intercept services in the WiMAX radio access
network.
IMPORTANT:
CSN is out of the
scope of this document.
WiMAX Reference
Points and Interfaces
A reference
point (RP) in a WiMAX network is a conceptual link. An RP connects
two groups of functions that reside in different functional entities
of an ASN, CSN, or mobile station (MS). It is not necessarily a
physical interface; an RP becomes a physical interface only when
the functional entities on either side of it are contained in different
physical devices.
Following are the reference
points implemented with the ASN Gateway for WiMAX mobility functions:
- R3 Reference Point—Consists
of the set of control plane protocols between the ASN and the CSN
to support AAA, policy enforcement, and mobility management capabilities.
It also encompasses the bearer plane methods (for example, tunneling) to
transfer user data between the ASN and the CSN. R3 supports three
types of clients: CMIPv4 (for MS/client capable of mobile
IP), and PMIPv4 and PMIPv6 (proxy mobile IPv4 and IPv6, where ASNGW/FA
proxy mobile IP supports MS/client) .
- R4 Reference Point—Consists
of the set of control and bearer plane protocols originating and
terminating in various functional entities of an ASN that coordinate
MS mobility between ASNs and ASN Gateways. R4 is the only interoperable
RP between similar or heterogeneous ASNs.
- R5 Reference Point—Consists
of the set of control plane and bearer plane protocols for internetworking
between the CSN operated by the home NSP and that operated by a visited
NSP.
- R6 Reference Point—Consists
of the set of control and bearer plane protocols for communication
between the base station and the ASN Gateway. The bearer plane is an
intra-ASN datapath between the base station and ASN gateway. The
control plane includes protocols for datapath establishment, modification,
and release control, in accordance with the MS mobility events.
R6, in combination with R4, may serve as a conduit for exchange
of MAC state information between base stations that cannot interoperate
over R8.
- R7 Reference Point—Consists
of an optional set of control plane protocols, for example, AAA
and policy coordination in the ASN gateway as well as other protocols
for coordination between the two groups of functions identified
in R6. The decomposition of the ASN functions using the R7 protocols
is optional.
IMPORTANT:
To provide high throughput
and high density call processing, the ASN Gateway integrates both
the Decision Point and Enforcement Point functions. Therefore, the
R7 reference point is not exposed.
Message Relay in
ASN
The ASN Gateway
provides relay procedures to send or distribute received messages
with responses from a base station or another ASN Gateway. Supported
types of relay functions are:
- Passive Relay:
In this type of message relay, when the ASN Gateway receives a message
on an R4 or R6 interface, it retrieves the destination ID and forwards
the same request message to the given destination.
- Active Relay:
In this type of message relay, upon receiving the message on R4/R6
interface, the ASN Gateway creates a similar R4/R6 message
on the basis of original message and relays it to the destination.
For example, if during the inter-ASN Gateway handover a non-anchor
ASN Gateway receives the data path registration request from the
target base station, it creates a new data path registration request
and sends it to the anchor ASN Gateway. After receiving the duplicate
message, the anchor ASN Gateway sends the data path registration response
to the non-anchor ASN Gateway. When it receives that message, the
non-anchor ASN Gateway creates a new response message and sends
the new data path registration response to the target base station.
ASN Gateway Architecture
and Deployment Profiles
The ASN Gateway
is part of the Access Service Network (ASN) within the WiMAX network.
The ASN Gateway comprises logical and functional elements that provide
different functionality in an ASN.
ASN profiles provide
a framework for interoperability among entities within an ASN. At
a high level, the WiMAX forum has defined groups of functionality
for an ASN. These are called Profile Mappings A, B, and C. The key
attributes of the profile mappings are:
- ASN Profile-A
Handover control and
Radio Resource control (RRC) in the ASN Gateway
ASN anchored mobility
among base stations using R6 and R4 reference points
CSN anchored mobility
among ASNs using PMIP/CMIP (R3)
Paging Controller
and Location Register in the ASN Gateway
- Profile-B: ASN
Profile-B removes the ASN Gateway altogether and pushes all its
functionality into the base station. This functionality includes
the following:
Radio Resource control
(RRC) handling within the base station
R3 reference point
R4 reference point
- Profile-C: ASN
Profile-C functionality is a subset of Profile-A with following
functionality in Base Station:
HO control
Radio Resource Controller
(RRC)
The ASN Gateway supports
ASN Profile-C functionality. Form more information on supported
features and functionality, refer to the Supported Feature section.
The following figure
shows the mapping of functional entities in an ASN Gateway for Profile-C.
Figure 7. Functional view of
ASN Gateway Profile-C
WiMAX Network Deployment
Configurations
This section
provides examples of how the system can be deployed within a WiMAX
carrier’s network. As noted previously, the system can
be deployed in standalone configurations, serving as an Access Service
Network Gateway/Foreign Agent (ASN Gateway/FA),
a Home Agent (HA), or in a combined ASN Gateway/FA/HA
configuration which provides all services from a single chassis.
Standalone ASN
Gateway/FA and HA Deployments
The ASN Gateway/foreign
agent (FA) serves as an integral part of a WiMAX network by providing
packet processing and re-direction to a mobile user’s home
network through communications with the home agent (HA). No redirection
is required when mobile users connect to an ASN Gateway that serves
their home network.
The following figure
shows an example of a network configuration in which the ASN Gateway/FA
and HA are separate systems.
Figure 8. ASN Gateway/FA
and HA Network Deployment Configuration Example
Co-Located Deployments
An advantage
of the system is its ability to support both high-density ASN Gateway/FA
and HA configurations within the same chassis. The economies of
scale presented in this configuration example provide both improved
session handling and reduced cost in deploying a WiMAX data network.
The following figure
shows an example of a co-located deployment.
Figure 9. Co-located ASN Gateway/FA
and HA Network Deployment Configuration Example
ASN Call Procedure
Flows
This section
provides information on the function of the ASN Gateway in a WiMAX
network and presents call procedure flows for different stages of
session setup.
Functional Components
for Handover
This section
describes the functional components used during handover between
ASN Gateways on R4 and R6 interfaces.
Anchor ASN Gateway
The anchor
ASN Gateway is the ASN Gateway that holds the anchor data path functions
for a given MS. As shown in the following figure, the anchor ASN
Gateway hosts the following functions:
- Authenticator (includes
Accounting Client)
- Anchor DP function
- DHCP proxy
- DHCP Relay
- PMIP client
- MIP FA
- Anchor SFA
- DHCP proxy function
The ASN Gateway service
IP address is the R6 and R4 tunnel endpoint and handles both R6 and
R4 traffic.
Anchor Session
The following
identifiers identify the anchor ASN Gateway session:
- MSID
- MS NAI
- MS IP address
- DHCP MAC address
The ASN Gateway session
consists of an access R6 session and a MIP FA network session. The
R6 session has a GRE data path to a base station for an active session.
In this session the ASN Gateway service IP address is the R6 and
R4 tunnel endpoint and handles both R6 and R4 traffic.
Upon initial network
entry, when the DPF is in the anchor ASN Gateway, there is no R4 session.
After a MS does a handover to a target BS, it connects to the anchor
GW over R4 via a different serving ASN Gateway. At this point, the
anchor GW session has an access R4 session and a MIP FA network
session. The anchor GW can maintain the R6 session and a R4 session simultaneously.
Note that R6 and R4
tunnels are handled uniformly by the anchor GW as both are access-side
tunnels. The anchor GW can check the IP address of the non-anchor
GW peer against the configured list of peer ASN Gateway’s,
so that it can control which R4 connections are accepted.
The anchor GW handles
all the Layer 3 processing for the subscriber without including
any other rule and policy.
When an anchor GW
receives a request message, it reads the source ID in this request
and sends the response to this source ID as destination ID. The
anchor ASN Gateway remembers the source IP address of the peer from
where the message was received, if it is different from the source
ID of the message. The response message is sent to this peer IP
address, which is the immediate peer.
Non-Anchor ASN
Gateway
The non-anchor
ASN Gateway hosts the following functions:
- Serving DP Function:
The subscriber data is not processed in the non-anchor GW. It relays
the subscriber data to anchor ASN Gateway over R4. When the inner
IP packet emerges from the R6 tunnel at the non-anchor ASN Gateway, the
packet is sent over R4 data path tunnel to the Anchor ASN Gateway.
- Serving SFA Function:
No packet classification is performed in this function. It provides
only tunnel switching between R4 to R6 or vice versa.
- DHCP Proxy relay Function:
DHCP messages are not processed in the non-anchor GW and relayed
to the DHCP proxy in the anchor ASN Gateway over R4. When the inner
IP packet emerges from the R6 tunnel at the non-anchor ASN Gateway,
a check is made to see whether the DHCP proxy is co-located in the
ASN Gateway and whether or not to process DHCP packet locally. If
the session is not anchored locally, that is, the DHCP proxy is
not co-located, the non-anchor ASN Gateway sends the DHCP packet
over an R4 data path tunnel to the anchor ASN Gateway.
- Relay Function:
The non-anchor ASN Gateway provides relay functions to distribute
received messages and subscriber information. The message relay
is supported for following functions:
Context transfer
Paging
Accounting
Authentication
Handover (HO)
Radio Resource Controller (RRC)
Non-Anchor Session
A non-anchor
session is created upon receiving an R6 Data Path Registration Request
from the target base station. Note that the non-anchor ASN Gateway
session is identified by MSID only. This non-anchor ASN Gateway
does NOT know the MS NAI and MS IP address of the subscriber, since
the authenticator, DHCP and PMIP functions are not exposed here
and the MSID is used as the username in session manager. The non-anchor
session has the following attributes:
- The Registration Type
in the request is set to HO.
- The Destination ID
in the message does not match the destination IP address of the message.
It needs to match the anchor ASN Gateway ID in the message if an
R6 and R4 Data Path setup is intended.
- The anchor ASN Gateway
is one of the peer ASN Gateway configured in the ASN Gateway service.
Initial Network
Entry and Data Path Establishment without Authentication
This section
describes the procedure of initial entry and data session establishment
for a WiMAX subscriber station (SS) or MS without authentication
by ASN Gateway.
Figure 10. Initial Network Entry
and Data Session Establishment without Authentication Call Flow
Table 1. Initial Network
Entry and Data Session Establishment without Authentication Call
Flow Description
Step |
Description |
1 |
MS
performs initial ranging with the ASN BS. Ranging is a process by
which an MS becomes time-aligned with the ASN BS. The MS is synchronized
with the BS at the successful completion of ranging and is ready
to set up a connection. |
2 |
MS
sends basic capability exchange request (SBC-REQ) to ASN BS. |
3 |
ASN
BS sends MS-Pre-Attachment Request (authorization policy request)
to ASN Gateway. |
4 |
ASN
Gateway sends MS-Pre-Attachment Response on the basis of authorization
policy to ASN BS for MS. |
5 |
ASN
BS sends basic capability exchange response (SBC-RSP) to MS. |
6 |
If
authorization policy allows, ASN BS sends MS Pre-Attachment Acknowledgement
to ASN Gateway. |
7 |
MS
sends Registration-Request (REG-REQ) to ASN BS. |
8 |
ASN
BS sends MS-Attachment-Request to ASN Gateway. |
9 |
ASN
Gateway sends MS-Attachment-Response to ASN BS and reserves the
resource. |
10 |
ASN
BS sends Registration-Response to MS. |
11 |
ASN
BS sends MS-Attachment-Acknowledgement to ASN Gateway. |
12 |
ASN
Gateway sends Path Registration Request to ASN BS. |
13 |
ASN
BS creates 802.16 connection and establishes path with MS. |
14 |
ASN
BS sends Path Registration Response to ASN Gateway and ASN Gateway
creates service flow with CSN over which PDUs can be sent and received. |
15 |
ASN
Gateway sends Path Registration Acknowledgment to ASN BS. |
16 |
GRE
tunnel mapped to 802.16 connection between MS and ASN BS. |
17 |
R6
GRE data path established between ASN BS and ASN Gateway and data
flow starts. |
Initial Network
Entry and Data Path Establishment with Authentication (Single EAP)
This section
describes the procedure of initial entry and data session establishment
for a WiMAX Subscriber Station (SS) or MS with single EAP authentication.
The following figure
provides a high-level view of the steps involved for initial network
entry of an SS/MS with EAP authentication and data link establishment.
The following table explains each step in detail.
Figure 11. Initial Network Entry
and Data Session Establishment with Authentication Call Flow
Table 2. Initial Network
Entry and Data Session Establishment with Authentication Call Flow
Description
Step |
Description |
1 |
MS
performs initial ranging with the BS. Ranging is a process by which
an MS becomes time aligned with the BS. The MS is synchronized with
the BS at the successful completion of ranging and is ready to set
up a connection. |
2 |
SS
Basic capability exchange (SBC-REQ) between MS and BS starts and
MS-Info-Request for authorization policy sent to AAA client/authenticator
in ASN Gateway. |
3 |
AAA
client/authenticator (ASN Gateway) sends MS-Info-Report
to BS and BS sends SS Basic Capability Response (SBC-RSP) to MS. |
4 |
BS
acknowledges the MS-Info-Report to AAA client/authenticator. |
5 |
AAA
client/authenticator (ASN Gateway) starts EAP transfer
request to BS and MS. |
6 |
MS
and BS sends EAP transfer response to AAA client/authenticator. |
7 |
The
MS progresses to an authentication phase with home AAA Server. Authentication
is based on PKMv2 as defined in the IEEE standard 802.16 specification.
EAP authentication process starts |
8 |
EAP
authentication successful and AAA client/authenticator
starts security context transfer. |
9 |
PKMv.2-RSP/EAP-Transfer/SA-TEK-Challenge-Request-Response/Key-Request-Response
exchange between MS and BS. |
10 |
MS
sends 802.16 Registration Request (REG-REQ) to ASN BS and ASN BS
sends MS-Info-Request to AAA client/authenticator. |
11 |
AAA
client/authenticator sends MS-Info-Report to BS and BS
sends Registration Response (REG-RESP) to MS and MS-Info-Report
Acknowledge to AAA client/authenticator. |
12 |
ASN
Gateway sends Path Registration Request to ASN BS. |
13 |
ASN
BS creates 802.16e connection and establishes path with MS. |
14 |
ASN
BS sends Path Registration Response to ASN Gateway and ASN Gateway
creates service flow with CSN over which PDUs can be sent and received. |
15 |
ASN
Gateway sends Path Registration Acknowledgment to ASN BS. |
16 |
GRE
tunnel mapped to 802.16 connection between MS and ASN BS. |
17 |
R6
GRE data path established between ASN BS and ASN Gateway and data
flow starts. |
Unexpected Network
Re-entry
An unexpected
network re-entry is when a mobile station starts the process of
initial network entry to the ASN Gateway via the same or new base
station while an existing call for the MS is still in progress or
being set up. When this occurs, the ASN Gateway’s default
behavior is to:
- Accept the new call
regardless of the existing call state if the pre-attachment request
of the new call comes from a different BS.
- Accept the new call
if the original call is in any state past the pre-attachment phase
and the pre-attachment request of the new call comes from the same
BS.
- Drop the original
call in favor of new call.
To disable this default
behavior use the policy
ms-unexpected-network-reentry command in the ASN Gateway
Service Configuration Mode. For more information regarding this
command, refer to the Command Line Interface Reference.
MS Triggered Network
Exit
This section
describes the procedure of MS Triggered network exit for a WiMAX
Subscriber Station (SS) or MS in normal mode.
The following figure
provides a high-level view of the steps involved for network exit
of an SS/MS in normal mode. The following table explains
each step in detail.
Figure 12. MS Triggered Network
Exit Call Flow
Table 3. MS Triggered Network
Exit Call Flow Description
Step |
Description |
1 |
MS
sends DREG_REQ message to ASN BS in serving ASN, including
De-Registration_Request Code=0x00. |
2 |
ASN
BS sends R6 Path_Dereg_Req message to ASN Gateway. |
3 |
ASN
Gateway/FA and HA starts MIP release procedure. |
4 |
ASN
Gateway/FA starts MS context delete procedure. |
5 |
ASN
Gateway sends Accounting-Stop-Request (Release Indication) message
to AAA. |
6 |
AAA
replies with Accounting-Stop-Response message to ASN Gateway. |
7 |
ASN
Gateway/FA replies with Path_Dereg_Response
message to ASN BS. |
8 |
ASN
BS sends DREG_CMD message to MS, including Action Code=0x04. |
9 |
ASN
BS sends R6 Path_Dereg_Ack to the ASN Gateway
and related entities releases the retained MS context and the assigned
data path resource for the MS. |
Network Triggered
Network Exit
This section
describes the procedure of a network triggered network exit for
a WiMAX Subscriber Station (SS) or MS in normal mode.
The following figure
provides a high-level view of the steps involved for a network-triggered
network exit of an SS/MS in normal mode. The following
table explains each step in detail.
Figure 13. Network Triggered
Network Exit Call Flow
Table 4. Network Triggered
Network Exit Call Flow Description
Step |
Description |
1 |
Network
entities, such as AAA Server, ASN Gateway FA/HA, trigger
Session Release Trigger to ASN BS. This can be from H-AAA ServerAnchor
ASN Gateway/FA/HAServing ASN BS, etc. |
2 |
ASN
BS sends DREG_CMD message to MS, including Action Code=0x00
to indicate MS existing network. |
3 |
IP
session for DHCP/MIP release starts between MS and network
entities. |
4 |
MS
sends DREG_REQ to ASN BS with De-Registration_Request_Code=0x02. |
5 |
ASN
BS sends Path_Dereg_Req message to ASN Gateway. |
6 |
Auth
Context Request and Report Exchange between target BS and ASNGW. |
7 |
ASN
Gateway/FA and HA starts MIP release procedure. |
8 |
ASN
Gateway/FA exchanges NetExit_MS_State_Change_Req
and NetExit_MS_State_Change_Rsp
messages with the anchor accounting client, anchor authenticator,
and MIP client to delete MS contexts. |
9 |
ASN
Gateway sends Accounting-Stop-Request (Release Indication) message
to H-AAA. |
10 |
AAA
replies with Accounting-Stop-Response message to ASN Gateway. |
11 |
ASN
Gateway/FA replies with Path_Dereg_Response
message to ASN BS. |
12 |
HO
Complete message sent from target BS to serving BA via ASNGW. |
13 |
ASN
BS sends R6 Path_Dereg_Ack to the ASN Gateway
and related entities releases the retained MS context and the assigned
data path resource for the MS. |
Intra-ASN Gateway
Handover
This section
describes the handover procedure between two ASN BSs connected to
one ASN Gateway. The ASN Gateway supports following types of handover:
- Intra-anchor ASN Gateway
Uncontrolled Handover
- Intra Non-anchor ASN
Gateway Uncontrolled Handover
- Intra-anchor ASN Gateway
Controlled Handover
- Intra Non-anchor ASN
Gateway Controlled Handover
Details regarding
controlled and uncontrolled handovers for the anchor ASN gateways
are provided below.
Intra-anchor ASN
Gateway Uncontrolled Handover
This section
describes the procedure for an uncontrolled intra-anchor ASN Gateway
handover for a WiMAX Subscriber MS.
The following figure
provides a high-level view of the steps involved in an intra-anchor
ASN Gateway uncontrolled handover of an SS/MS. The following table
explains each step in detail.
Figure 14. Intra-ASN Gateway
Uncontrolled Handover Call Flow
Table 5. Intra-ASN Gateway
Uncontrolled Handover Call Flow Description
Step |
Description |
1 |
MS
sends RNG-REQ message to target ASN BS. |
2 |
Target
ASN BS sends Context-Request message to anchor ASN Gateway for this
MS. |
3 |
Anchor
ASN Gateway forwards Context-Request message to serving ASN BS. |
4 |
Serving
ASN BS sends Context-Report message with MS context information
to anchor ASN Gateway. |
5 |
Anchor
ASN Gateway forwards Context-Report message with MS context information
to target ASN BS. |
6 |
Target
ASN BS sends Path Registration Request to anchor ASN Gateway. |
7 |
Anchor
ASN Gateway replies with Path Registration Response to target ANS
BS. |
8 |
Target
ANS BS sends ranging response with RNG_RSP message to MS. |
9 |
Target
ASN BS sends Path Registration Acknowledge to anchor ASN Gateway. |
10 |
R6
GRE data path established between target ASN BS and anchor ASN Gateway
and data flow starts. |
11 |
Target
ASN BS sends CMAC Key Count Update message to anchor ASN Gateway. |
12 |
Anchor
ASN Gateway replies with CMAC Key Count Update ACK message to target
ASN BS. |
13 |
Anchor
ASN Gateway sends Path_De-Reg_Req message to release
data path to serving BS. |
14 |
Serving
ASN BS sends Path_De-Reg_Rsp message to anchor
ASN Gateway. |
15 |
R6
GRE data path terminated between serving ASN BS and anchor ASN Gateway. |
Intra-anchor ASN
Gateway Controlled Handover
An intra-anchor
ASN Gateway controlled handover consists of the following types
and phases.
MS Initiated Intra-anchor
ASN Gateway Controlled Handover
This section
describes the intra-anchor ASN Gateway controlled handover between
two base stations initiated by a mobile station.
HO Preparation Phase
This is the initial
phase for a controlled handover between two BSs.
The following figure
and table describe the call flow for the steps involved in a controlled intra-ASN
Gateway handover preparation phase between two BSs.
Figure 15. MS initiated Controlled
Intra-ASN Gateway Handover Preparation Phase
Table 6. MS initiated Controlled
Intra-ASN Gateway Handover Preparation Phase Description
Step |
Description |
1 |
MS
sends MOB_MSHO_REQ messages to serving BS |
2 |
Upon
receiving MS initiated handover request (MOB_MSHO_REQ),
the serving BS sends HO_Req messages to target BS selected
by MS and starts R8_HO_Req timer |
3 |
Targeted
BS tests the acceptability of the requested HO by comparing the
amount of available resources and required bandwidth/QoS
parameters in the HO request received from serving BS |
4 |
Once
a target BS accepts the request it sends the HO_Rsp message
to the serving BS |
5 |
Serving
BS sends MOB_MSHO_RSP response t o MS |
6 |
Serving
BS sends HO_Ack message to the target BS and HO preparation
phase is completed |
HO Action Phase
The following figure
and table describe the call flow for the steps involved in uncontrolled intra-ASN
Gateway handover action phase between two BSs.
Figure 16. MS initiated Controlled
Intra-ASN Gateway Handover Action Phase
Table 7. MS initiated Controlled
Intra-ASN GW Handover Phase
Step |
Description |
1 |
Once
HO preparation phase is completed and target BS receives HO-Ack
message, the MS sends MOB_HO-IND messages to the serving
BS. |
2 |
The
serving BS sends HO_Conf messages to the selected target
BS with other context information and starts R8_HO_Confirm
Timer. |
3 |
The
target BS accepts the request and sends the HO_Ack message
to serving BS and serving BS stops R8_HO_Confirm
Timer. |
4 |
Target
BS sends MAC Context Request message to the anchor ASN Gateway. |
5 |
The
anchor ASN Gateway forwards the MAC Context Request to the serving
BS. |
6 |
Serving
BS sends MAC Context Report information to anchor ASN Gateway. |
7 |
Anchor
ASN Gateway forwards MAC Context Report information to the target
BS. |
8 |
Target
BS sends Authentication Context Request to anchor ASN Gateway. |
9 |
Anchor
ASN Gateway transfers Authentication Context information to target
BS. |
10 |
MS
starts ranging with target BS and sends RNG-REQ to the target BS
and network reentry completed. |
11 |
Target
BS sends Data Path Registration Request to anchor ASN Gateway. |
12 |
Anchor
ASN Gateway sends Data Path Registration Response to target BS. |
13 |
Target
BS sends Data Path Registration Ack message to Anchor ASN Gateway
and R6 data path is established. |
14 |
Target
BS sends CMAC Key count Update message to anchor ASN Gateway. |
15 |
Anchor
ASN Gateway sends CMAC Key Count Update Ack message to target BS
and handover completed. |
16 |
Anchor
AS NGW starts Data Path De-registration process with serving BS. |
17 |
Serving
BS releases all resources and terminates data path with MS. |
BS Initiated Intra
Anchor ASN Gateway Controlled Handover
This section
describes the intra-anchor ASN Gateway controlled handover between
two base stations initiated by serving base station.
HO Preparation Phase
This is the initial
phase for a controlled handover between two BSs.
The following figure
and table describe the call flow for the steps involved in uncontrolled intra-ASN
Gateway handover preparation phase between two BSs.
Figure 17. BS initiated Controlled
Intra-ASN Gateway Handover Preparation Phase
Table 8. BS initiated Controlled
Intra-ASN Gateway Handover Preparation Phase Description
Step |
Description |
1 |
In
BS initiated HO scenario, the serving BS sends HO_Req messages
to target BS from its peer list and starts R8_HO_Req
timer. |
2 |
Targeted
BS tests the acceptability of the requested HO by comparing the
amount of available resources and required bandwidth/QoS
parameters in the HO request received from serving BS. |
3 |
Once
a target BS accepts the request it sends the HO_Rsp message
to the serving BS. |
4 |
Serving
BS sends MOB_MSHO_RSP response t o MS. |
5 |
Serving
BS sends HO_Ack message to the target BS and HO preparation
phase is completed. |
HO Action Phase
The following figure
and table describe the call flow for the steps involved in an uncontrolled
intra-ASN Gateway handover action phase between two BSs.
Figure 18. BS initiated Controlled
Intra-ASN Gateway Handover Action Phase
Table 9. BS initiated Controlled
Intra-ASN Gateway Handover Action Phase Description
Step |
Description |
1 |
Handover
preparation phase is completed and data path is established. |
2 |
The
serving BS sends HO_Conf messages to the selected target
BS with other context information and starts R8_HO_Confirm
Timer. |
3 |
The
target BS accepts the request and sends the HO_Ack message
to serving BS and serving BS stops R8_HO_Confirm
Timer. |
4 |
Target
BS sends MAC Context Request message to the anchor ASN Gateway. |
5 |
The
Anchor ASN Gateway forwards the MAC Context Request to the serving
BS. |
6 |
Serving
BS sends MAC Context Report information to anchor ASN Gateway. |
7 |
Anchor
ASN Gateway forwards MAC Context Report information to the target
BS. |
8 |
Target
BS sends Authentication Context Request to anchor ASN Gateway. |
9 |
Anchor
ASN Gateway transfers Authentication Context information to target
BS. |
10 |
MS
starts ranging with target BS and sends RNG-REQ to the target BS
and network reentry completed. |
11 |
Target
BS sends Data Path Registration Request to anchor ASN Gateway. |
12 |
Anchor
ASN Gateway sends Data Path Registration Response to target BS. |
13 |
Target
BS sends Data Path Registration Ack message to anchor ASN Gateway
and R6 data path established. |
14 |
Target
BS sends CMAC Key count Update message to anchor ASN Gateway. |
15 |
Anchor
ASN Gateway sends CMAC Key Count Update Ack message to target BS
and handover completed. |
16 |
Anchor
AS NGW starts Data Path De-registration process with serving BS. |
17 |
Serving
BS releases all resources and terminates data path with MS. |
Inter-ASN Gateway
Handover
This section
describes the procedure of inter-ASN Gateway handovers through an
R4 interface for a WiMAX Subscriber Station (SS). The R4 reference
is the interface over which ASN control and data messages are exchanged
between two ASN Gateways, either within the same ASN or across separate ASNs.
For a given subscriber,
a WiMAX session may be handled by ASN Gateway functions located
in different physical nodes in the network. For example, the authenticator
and FA may be located in ASN Gateway x and the R6 Data
Path Function in ASN Gateway y.
The various ASN Gateway functions communicate over the R4 interface.
The following inter-ASN
Gateway handover scenarios are supported on the ASN Gateway over
the R4 interface:
IMPORTANT:
Not all features are
supported on all platforms.
- Controlled Anchor
ASN Gateway to Non-Anchor ASN Gateway Handover
- Controlled Non-Anchor
ASN Gateway to Anchor ASN Gateway Handover
- Controlled Non-Anchor
ASN Gateway to Non-Anchor ASN Gateway Handover
- Uncontrolled Anchor
ASN Gateway to Non-Anchor ASN Gateway Handover
- Uncontrolled Non-Anchor
ASN Gateway to Anchor ASN Gateway Handover
- Uncontrolled Non-Anchor
ASN Gateway to Non-Anchor ASN Gateway Handover
ASN Gateway Function
for Handovers
An ASN Gateway
configured for inter-ASN Gateway handovers requires the following
functionality to support the handover via an R4 interface.
The following figure
provides a high-level view of the components and functions distribution
in ASN Gateway.
Figure 19. Distribution of
Components and Function in ASN Gateway for Handover
Controlled Anchor
ASN Gateway to Non-Anchor ASN Gateway Handover
For Controlled
handovers, the ASN Gateway provides and/or supports the
following functions:
- Message Relay:
The ASN Gateway provides the passive relay function for HO Request,
HO Response, HO Ack, HO Confirm, and HO Complete messages in a stateless
fashion. The gateway keeps the statistics of the different types
of messages it has relayed. Retransmission of these messages is
handled by the BS.The serving BS generates
these messages. The serving BS generates a different HO Request transaction
for each target BS. In other words, the gateway does not generate
multiple HO Request messages after receiving a single HO Request
message with multiple target BSs. Generally, the HO transaction
is initiated by the serving BS which also chooses the selected target BS
to which the handover will take place.
- Security Context Retrieval:
The ASN Gateway supports the retrieval of the security context using
Context Request and Context Report messages. This retrieval is also stateless.
The context retrieval operation can be performed at any time during
the lifetime of a call.
- Data Path Registration:
After Pre-Registration, the target BS performs Data Path Registration.
Data Path Registration is performed using a 3-way handshake. If
Pre-Registration has occurred, the Data Path Registration messages
do not contain any service flow information.
If Pre-Registration
has not occurred, the Data Path Registration messages carry the service
flow information.
Data Path Pre-Registration
and Data Path Registration is initiated by the BS.
Preparation Phase
The following
figure and table provides a high-level view of the steps involved
during the preparation phase of a controlled inter-ASN Gateway handover
of an SS/MS from an anchored gateway to a non-anchored
gateway.
Figure 20. Controlled Inter-ASN
Gateway Handover Procedure - Preparation Phase
Table 10. Controlled Inter-ASN
Gateway Handover Procedure - Preparation Phase Description
Step |
Description |
1 |
MS
sends a MOB_MSHO-REQ message to the serving ASN BS. |
2 |
Serving
ASN BS sends a Handover Request message to the target ASN BS. |
3 |
Target
ASN BS sends a Context-Request message to the target non-anchor
ASN Gateway for this MS. |
4 |
Target
non-anchor ASN Gateway forwards the Context-Request message to the
anchor ASN Gateway. |
5 |
Anchor
ASN Gateway sends a Context-Report message to the target non-anchor
ASN Gateway. |
6 |
Target
non-anchor ASN Gateway forwards the Context-Report message to the
target ASN BS. |
7 |
Target
ASN BS sends a Path Pre-Registration Request message to the target
non-anchor ASN Gateway. Pre-registration is optional. |
8 |
Target
non-anchor ASN Gateway forwards the Path Pre-Registration Request
message to the anchor ASN Gateway. Pre-registration is optional. |
9 |
Anchor
ASN Gateway sends a Path Pre-Registration Response message to the
target non-anchor ANS GW. Pre-registration is optional. |
10 |
Target
non-anchor ASN Gateway forwards the Path Pre-Registration Response
message to the target ASN BS. Pre-registration is optional. |
11 |
Target
ASN BS sends a Path Pre-Registration Acknowledge message to the
target non-anchor ASN Gateway. Pre-registration is optional. |
12 |
Target
non-anchor ASN Gateway forwards the Path Pre-Registration Acknowledge
message to the anchor ASN Gateway. Pre-registration is optional. |
13 |
Target
BS sends a Handover Response message to the serving BS. |
14 |
Serving
BS sends a MOB_BSHO-RSP message to the MS. |
15 |
Serving
BS sends a Handover Acknowledge message to the target BS. |
Action Phase
The following
figure and table provides a high-level view of the steps involved
during the action phase of a controlled inter-ASN Gateway handover
of an SS/MS from an anchored gateway to a non-anchored
gateway.
Figure 21. Controlled Inter-ASN
Gateway Handover Procedure - Action Phase
Table 11. Controlled Inter-ASN
Gateway Handover Procedure - Action Phase Description
Step |
Description |
1 |
MS
sends a MOB_MSHO-IND message to the serving ASN BS. |
2 |
Serving
ASN BS sends a Handover Confirm message to the target ASN BS. |
3 |
Target
ASN BS sends a Handover Acknowledge message to the serving ASN BS. |
4 |
MS
moves off of the serving ASN Gateway and re-enters the network through
target ASN BS. |
5 |
Target
ASN BS sends a Path Registration Request message to the target non-anchor
ASN Gateway. |
6 |
Target
non-anchor ASN Gateway forwards the Path Registration Request message
to the anchor ASN Gateway. |
7 |
Anchor
ASN Gateway sends a Path Registration Response message to the target
non-anchor ANS GW. |
8 |
Target
non-anchor ASN Gateway forwards the Path Registration Response message
to the target ASN BS. |
9 |
Target
ASN BS sends a Path Registration Acknowledge message to the target
non-anchor ASN Gateway. |
10 |
Target
non-anchor ASN Gateway forwards the Path Registration Acknowledge
message to the anchor ASN Gateway. |
11 |
Target
non-anchor ASN Gateway sends/receives CMAC Key Count Update
and Acknowledge messages to/from anchor ASN Gateway. |
12 |
Target
ASN BS sends a Handover Complete message to the serving ASN BS. |
13 |
Anchor
ASN Gateway sends/receives Path De-Reg Req/Rsp/Ack
messages (to release the data path) to/from Serving BS. |
14 |
R6
GRE data path terminated between Serving ASN BS and Anchor ASN Gateway. |
Uncontrolled Anchor
ASN Gateway to Non-Anchor ASN Gateway Handover
The following
figure and table provides a high-level view of the steps involved
in an uncontrolled inter-ASN Gateway handover of an SS/MS
from an anchored gateway to a non-anchored gateway.
Figure 22. Uncontrolled Inter-ASN
Gateway Handover Procedure
Table 12. Uncontrolled Inter-ASN
Gateway Handover Procedure Description
Step |
Description |
1 |
MS
sends RNG-REQ message to target ASN BS. |
2 |
Target
ASN BS sends Context-Request message to serving ASN BS. |
3 |
Serving
ASN BS sends Context-Report message with MS context information
to target ASN BS. |
4 |
Target
ASN BS sends Context-Request message to target non-anchor ASN Gateway. |
5 |
Target
non-anchor ASN Gateway forwards Context-Request message to anchor
ASN Gateway. |
6 |
Anchor
ASN Gateway sends Context-Report message with MS context information
to target non-anchor ASN Gateway. |
7 |
Target
non-anchor ASN Gateway forwards Context-Report message to target
ASN BS. |
8 |
Target
ASN BS sends Path Registration Request to target non-anchor ASN
Gateway. |
9 |
Target
non-anchor ASN Gateway forwards Path Registration Request to anchor
ASN Gateway. |
10 |
Anchor
ASN Gateway replies with Path Registration Response to target non-anchor
ANS GW. |
11 |
Target
non-anchor ASN Gateway forwards Path Registration Response to target
ASN BS. |
12 |
Target
ANS BS sends ranging response with RNG_RSP message to MS. |
13 |
Target
ASN BS sends Path Registration Acknowledge to target non-anchor
ASN Gateway. |
14 |
Target
non-anchor ASN Gateway forwards Path Registration Acknowledge to
anchor ASN Gateway. |
15 |
R6
GRE data path established between Target ASN BS and anchor ASN Gateway.
Data flow starts. |
16 |
Target
ASN BS sends/receives CMAC Key Count Update and Acknowledge
messages to/from anchor ASN Gateway via target non-anchor
ASN Gateway. |
17 |
Anchor
ASN Gateway sends/receives Path De-Reg Req/Rsp/Ack
messages to release data path to/from serving BS. |
18 |
R6
GRE data path terminated between Serving ASN BS and anchor ASN Gateway. |
RADIUS-based Prepaid
Accounting for WiMax
Online accounting
is set up by the exchange of RADIUS Access-Request and Access-Accept packets.
The initial Access-Request packet from the ASN GW and/or
the home agent includes a prepaid accounting capability (PPAC) vendor
specific attribute too the prepaid server (PPS). This indicates
support for online accounting at the ASN and/or the home
agent. If the subscriber’s session requires online charging, the
PPS assigns a prepaid accounting quota (PPAQ) to the PPC with RADIUS
Access-Accept packets. As the session continues, the PPC and the
PPS replenish the quotas by exchanging RADIUS packets.
Note the following:
- ASN GW operates as
the prepaid client (PPC).
- In the case of a mobile
IP call, both the ASN GW and the home agent work independently as
the prepaid client. Both the ASN GW and the home agent send online
access requests to the configured RADIUS servers independently.
- Only session-based
online accounting is supported.
Obtaining More
Quota after the Quota is Reached
The following figure
and table provide a high-level view of the steps involved in allocating
additional quotas for prepaid calls once the original quota is reached.
Figure 23. Call Flow Showing
How Additional Quota is Obtained
Table 13. Call Flow Showing
How Additional Quota is Obtained
Step |
Description |
1 |
During
network entry, a NAS sends an Access-Request packet to the HCSN.
If the NAS supports a PPC, the NAS includes the PPAC attributes,
indicating it prepaid capabilities. |
2 |
If
the subscriber session is a prepaid session, the PPS (HAAA) assigns
the initial prepaid quota(s) by including one or more PPAQ attributes
in the Access-Accept packet. |
3 |
Once
the threshold for the quota(s) is reached, the PPC sends an Authorize-Only
Access-Request to request additional quota. The request contains
one or more PPAQs that indicate which quota(s) need to be replenished
to the PPS. |
4 |
The
PPS responds with an Access-Accept packet that contains one or more
replenished quotas. |
5 |
Once
again, a threshold is reached for one or more of the quotas. The
PPC sends an Authorize-Only Access-Request to the PPS to request
more quota. |
6 |
The
PPS responds with the final quota in an Access-Accept. The final
quota is indicated by the presence of the Terminate-Action subtype.
The Terminate-Action subtype includes the action for the PPC to
take once the quota is reached. |
7 |
The
quota expires. The PPC sends an Authorize-Only Access-Request packet
to indicate that the quota has expired. |
8 |
The
PPS responds with an Access-Accept. If there are additional resources,
the PPS allocates additional quotas and the service continues. |
Applying HTTP Redirection
Rule when Quota is Reached
The following figure
and table provide a high-level view of the steps showing how the
HTTP Redirection Rule is applied once a quota is reached.
Figure 24. Call Flow for Applying
HTTP Redirection Rule on Quota-Reach
Table 14. Call Flow for Applying
HTTP Redirection Rule on Quota-Reach
Step |
Description |
1 |
The
Volume or Duration quota is reached. The Termination-Action is Request
More Quota. |
2 |
The
PPC sends an Online Access Request to the AAA server and waits for
Access-Accept. |
3 |
The
Access-Accept is received. It contains no additional quota attributes.
The Termination-Action is Redirect/Filter. There is an
HTTP Redirection Rule with redirect rule present in the Access-Accept. |
4 |
The
PPC (home agent) applies the HTTP Redirection Rule for the HTTP
traffic. All other traffic is dropped. During this period, the MS
recharges from the portal. |
5 |
The
PPC sends updated quota attributes to the AAA server based on the
MS recharge from the portal. |
6 |
The
AAA server sends a CoA message to the PPC (home agent) with the
new quota attributes in PPAQ and also sends the HTTP Redirection
Rule to clear the HTTP Redirection rule at the PPC. |
7 |
Normal
traffic, including HTTP traffic, is allowed, per the new quota attributes. |
Applying HTTP Redirection
Rule When CoA is Received
The following figure
and table show the steps involved in applying the HTTP Redirection
Rule when the PPAC receives a change of authorization (CoA) from
a AAA server.
Figure 25. Call Flow for Applying
HTTP-Redirection Rule when CoA is Received
Table 15. Call Flow for Applying
HTTP-Redirection Rule Received by CoA
Step |
Description |
1 |
The
PPS updates the AAA server so that the AAA server dynamically enforces
HTTP Redirection Rule at the PPC. |
2 |
The
AAA server sends a CoA message to the PPC (home agent) with the
HTTP Redirection Rule. |
3 |
The
PPC (home agent) applies the HTTP Redirection Rule for the HTTP
traffic. All other traffic is dropped. During this period, the MS
is recharged from the portal. |
4 |
The
PPC sends updated quota attributes to the AAA server based on the
MS recharge from the portal. |
5 |
The
AAA server sends a CoA message to the PPC (home agent) with the
new quota attributes in PPAQ and also sends the HTTP Redirection
Rule to clear the HTTP Redirection rule at the PPC. |
6 |
Normal
traffic, including HTTP traffic, is allowed, per the new quota attributes. |
Terminating the
Call when Quota is Reached
The following figure
and table provide a high-level view of the steps involved in allocating
additional quotas for prepaid calls once the original quota is reached.
Figure 26. Call Flow for Terminating
the Call on Quota-Reach
Table 16. Call Flow for Terminating
the Call on Quota-Reach
Step |
Description |
1 |
Volume
or Duration quota is reached. If the termination-action is Request-More-Quota,
step 2 occurs next. If termination-action is Terminate, step 4 occurs
next. |
2 |
If
the termination-action is Request-More-Quota, the PPC sends an Online-Access-Request
to the AAA server and waits for Access-Accept. |
3 |
The
PPC receives the Access-Accept, which contains no additional quota
attributes. |
4 |
Session
is terminated at the PPC (home agent) and at the ASN GW. |
5 |
The
PPC sends the final Online-Access-Request. |
DHCP Relay Support
for ASNGW
Following is
a description of DHCP functionality to support ASNGW service. The
functionality assumes the AAA to be RADIUS. To support Diameter
AAA, the Access-Accept messages are correlated to DEA messages of
the Diameter Protocol.
DHCP Keys
DHCP messages
between the DHCP relay and DHCP server are authenticated by the
DHCP Authentication Suboption. This requires that the DHCP relay
and the DHCP server have a shared secret we call the DHCP-key.
The DHCP-key is specific
between each DHCP Relay and DHCP server. The DHCP keys are derived
from the DHCP-RK. The DHCP-RK key generation is internal to the
AAA server and is transported as necessary to the authenticator
and DHCP server using AAA protocol. The DHCP Key is derived from
the DHCP-RK at the authenticator and at the DHCP server.
DHCP-RK and derived
keys are not bound to individual user or authentication sessions,
but to a specific DHCP server and DHCP relay/DHCP server)
pairs. DHCP-RK is generated only on demand, but not for each EAP
(re-)authentication taking place. Nevertheless, a DHCP-RK key along
with the key identifier and lifetime values, are delivered to the
authenticator during network access authentication of a MS (that
is, it is carried by but otherwise unrelated to this specific MS). The
lifetime and key identifier of DHCP-RK is managed by the AAA server.
It is the responsibility of the AAA server to deliver a new DHCP-RK
to the authenticator and DHCP server prior to the expiration of
the DHCP-RK.
Key Generation
The DHCP-RK is created
by the AAA server assigning the DHCP server to an authenticating
subscriber. A different 160-bit random DHCP-RK is generated for every
DHCP server.
From the DHCP-RK an
authenticator generates DHCP-key for a specific DHCP relay/ DHCP
server pair if requested by this DHCP relay. The DHCP-key is also
generated by the DHCP server when a DHCP message arrives from a
DHCP relay for which the DHCP server has no key yet.
From the DHCP-RK an
authenticator generates a DHCP-key for a specific DHCP relay/ DHCP
server pair if requested by this DHCP relay. The DHCP-key is also
generated by the DHCP server when a DHCP message arrives from a
DHCP relay for which the DHCP server has no key yet.
Key Distribution
The DHCP-RK
keys are generated by the AAA server and are transported to the
DHCP server and the Authenticator with the AAA protocol. The DHCP
key generated by the authenticator is transported to the DHCP relay
via WiMAX specific R4 signaling (Context Req/Rsp msg).
The DHCP keys generated by the DHCP server are never transported
outside of the DHCP server.
- DHCP-RK Key: Generated
by AAA, transported to authenticator and DHCP server through AAA
protocol.
- DHCP Key: Generated
by authenticator and DHCP server, transported to DHCP relay and
DHCP server via WiMAX-specific R4 signaling. Never transported outside
of the DHCP server.
DHCP key distribution
covers two scenarios. In the first scenario the authenticator and DHCP
relay are co-located in the same entity. In the second scenario,
no re-authentication takes place when the MS moves to a different
anchor ASN hosting a new DHCP relay, so the anchor authenticator
is continued to be used, and provisions the new DHCP relay with
the required keys.
DHCP Relay in ASNGW
for PMIPv4 Calls
The following
steps are based on R3 already being secured. If R3 is not secured,
the DHCP relay adds the authentication sub-option (as explained
in step 12 ) to have data integrity and replay protection for relayed
DHCP messages.
- The MS sends a DHCP
Discover as a broadcast message. The DHCP message is sent on the
MS's Initial service flow setup over R1 interface to the BS.
- The DHCP Discover
message is forwarded from the BS to the DHCP Relay present in the
ASN through the data path established for the ISF (Initial Service
Flow) traffic.
- The DHCP Relay in
ASN intercepts and changes the destination IP address from broadcast
to unicast and configures the giaddr field in the DHCP payload.
It then sends the DHCP Discover message to the DHCP server of the
MS based on configuration information. The configuration information
in the most generic case is downloaded via the AAA but it may also
be statically provisioned. If the Datapath is per MS or SF, the
MS context is found based on the Datapath and not on the MAC address.
If the Datapath is per BS the MS context is found based on the MAC
address or MS NAI
- DHCP servers receiving
the DHCP Discover request reply by sending a DHCP Offer message
including an offered IP address.
- The DHCP Relay in
the ASN forwards the DHCP replies to the MS. The DHCP Offer message
is sent from ASN GW to BS through the Data Path. The destination
IP address of the DHCP Offer message sent to MS is a unicast one.
Normally DHCP servers or relay agents attempt to deliver the DHCP
Offer to a MS directly using unicast delivery. However, some MS implementations
are unable to receive such unicast IP datagram until they know their
own IP addresses. To work around this, an MS's broadcast address
may be used in the DHCP Offer message. The ASN checks the BROADCAST
(B) flag in the DHCP Offer message. If this flag is set, the ASN
uses a broadcast address to send DHCP Offer message. Otherwise the
unicast address is sent, but the delivery is over a unicast CID
- BS sends DHCP Offer
message to the MS on the MS's Initial Service Flow.
- The MS receives a
DHCP Offer message and sends a DHCP Request to the selected DHCP
server as a broadcast message confirming its choice of the DHCP
Server.
- DHCP Request message
is sent from BS to DHCP relay in ASN through the established Data
Path.
- The DHCP Relay in
the ASN prompts the PMIP client to initiate the Mobile IP Registration
procedure. The PMIP client uses the HoA information to construct
a Mobile IP Registration Request message. This message contains
HoA and CoA for this MS. The source address for this R3 message
is CoA, and the destination address is HA address.
- The HA responds with
the Mobile IP Registration Response message in which the source
address for this R3 message is the HA address, and the destination
address is CoA.
- After the establishment
of the MIP tunnel the PMIP client informs the DHCP Relay with the
MIP registration result. The DHCP Relay in ASN relays the DHCP Request
with the optional MIP registration result encapsulated in the WiMAX
vendor specific relay agent suboption to the DHCP server.
- The selected DHCP
server receives the DHCP Request and replies with a DHCP Ack containing
the configuration information requested by the MS.
- The DHCP Relay relays
the DHCP Ack to the BS.
- BS sends DHCP Ack
message to the MS on the MS's provisioned Initial Service Flow.If
MS doesn't receive a DHCP Ack, or DHCP NAK message when timeout,
it retransmits the DHCP Request. If neither DHCP Ack nor DHCP NAK
is received when the maximum retransmission reached, MS restarst
the IP initialization process.
DHCP Relay Requirements
for Simple IP Calls
The DHCP relay
handles all DHCP messages sent by the MS to the broadcast IP address.
- The DHCP relay is
configured with the DHCP server address during the MS authentication.
The AAA server sends the address of the DHCP server in the AccessAccept
message. The DHCP relay uses this address to relay the DHCP messages
from the MS to the DHCP server.
- Upon receiving a DHCP
DISCOVER message from the MS, the DHCP relay verifies the "chaddr"
field in the DHCP header and matches the MS MAC address associated
with the R6/R4 over which the DHCP message is received.
This is feasible without any additional option in the DHCP message
since the DHCP relay is collocated with the Anchor ASN (ASN-GW for profiles
A and C). This is done to prevent MAC address spoofing by a rogue
MS.
- If the DHCP relay
determines that the MS has included a MAC address in the chaddr field
of the DHCP DISCOVER message that does not match the known MAC address
of the R6/R4 over which the DHCP message was received,
the DHCP relay consider the following action: A rogue MS is trying
to spoof MAC address. In this case, the DHCP relay informs the DPF
to initiate R6 teardown.
- After determining
the NAI to be used for the request, the DHCP relay adds the relay agent
option to the original DHCP message and sets the Subscriber-ID suboption
to the NAI used for MIP associated with MS. If there is a secure
communication channel between the DHCP relay and the DHCP server,
the relay and server may choose to omit the authentication suboption.
- If a DHCP Decline
message is received, the DHCP Relay forwards the message to the DHCP
Server. The messaging between the DHCP relay and DHCP server is
transported over the R3 interface.
- When DHCP relay receives
the DHCP OFFER message from the DHCP server, it relays it to the
MS. If the DHCP server included the authentication suboption is
in the relay agent option, the DHCP relay validates it before relaying
the DHCP OFFER to the MS.
- The DHCP relay behavior
for handling DHCPREQUEST or DHCPDECLINE from the MS is same as in
the case of DHCP DISCOVER.
- The DHCP relay intercepts
the DHCP renewal and release messages, and verifies the content
of the message. If R3 is not secured (e.g., by IPSec), the DHCP
relay adds the relay agent authentication suboption to the message
before relaying it to the DHCP server.
DHCP Relay Requirements
for PMIPv4 Calls
The DHCP relay
handles all DHCP messages sent by the MS to the broadcast IP address.
The DHCP relay is configured with the DHCP server address during
the MS authentication. The AAA server sends the address of the DHCP
server in the RADIUS AccessAccept message or Diameter WDEA command.
The DHCP relay uses this address to relay the DHCP messages from
the MS to the DHCP server.
- Upon receiving a DHCP
DISCOVER message from the MS, the DHCP relay verifies the chaddr
field in the DHCP header matches the MS MAC address associated with
the R6/R4 over which the DHCP message is received. This
is feasible without any additional option in the DHCP message since
the DHCP relay is collocated with the Anchor ASN (ASN-GW for profiles
A and C). This is done to prevent MAC address spoofing by a rogue
MS.
- If the DHCP relay
determines that the MS has included a MAC address in the chaddr field
of the DHCP DISCOVER message does not match with the known MAC address
associated with the R6/R4 over which the DHCP message was
received, the DHCP relay considers that a rogue MS is trying to
spoof the MAC address. In this case, the DHCP relay may inform the
DPF to initiate R6 teardown.
- After determining
the NAI to be used for the request, the DHCP relay adds the relay agent
option to the original DHCP message and sets the Subscriber-ID suboption
to the NAI used for MIP associated with MS. If there is a secure
communication channel between the DHCP relay and the DHCP server,
the relay and server may choose to omit the authentication suboption.
T
- If a DHCP Decline
message is received, the DHCP Relay forwards the message sto the DHCP
Server.
- When DHCP relay receives
the DHCP OFFER message from the DHCP server, it relays it to the
MS. If the DHCP server included the authentication suboption in
the relay agent option, the DHCP relay validates it before relaying
the DHCP OFFER to the MS.
- The DHCP relay behavior
for handling DHCP REQUEST or DHCP DECLINE from the MS is same as
in the case of DHCP DISCOVER
- When DHCP relay receives
the DHCP REQUEST message from the MS, it prompts the PMIP4 client
to initiate MIPv4 registration procedures. It passes the requested
IPv4 address and the HA information to the PMIP4 client. The PMIP4
client performs the registration with the FA and HA on behalf of
the MS. The PMIP4 client informs the DHCP relay with the MIPv4 registration
result.
- Upon receipt of such
indication, the DHCP relay relays the DHCP REQUEST message with
the MIP registration result encapsulated in the vendor specific
relay agent suboption code 1 to the DHCP Server. If this suboption
is not sent to the DHCP server and the MIP registration indicates
a failure, the DHCP relay does not forward the DHCP REQUEST message
to the DHCP server and the network performs an exit for the corresponding
MS. When the DHCP relay receives the DHCPACK message from the DHCP
Server, it relays the DHCPACK message to the MS.
- Since AAA can assign
different HAs (e.g., when dynamically assigning HA from a pool)
and each HA handles different MS subnets, the assigned HA needs
to be passed to DHCP server to allow choosing the matching MS address
pool. DHCPDISCOVER and DHCPREQUEST from MS SHOULD include HA IP
address in same vendor specific relay agent suboption code 2 to
the DHCP Server
RADIUS Based Procedures
for Prepaid Accounting
In prepaid
accounting, the ASNGW works as the prepaid client (PPC). When there
is a mobile IP call, both the ASNGW and HA can work as the PPC independently.
However, either the HA or ASNGW, not both, is responsible for prepaid
accounting. In the case of Simple IP calls, the ASNGW can act as
the prepaid client for prepaid subscriber calls.
Online accounting
is set up by the exchange of RADIUS Access-Request and Access-Accept
packets. The initial Access-Request packet from the ASNGW and or the
HA includes a prepaid accounting capability (PPAC) VSA to the PPS
indicating support for On-line accounting at the ASN and or the
HA.
If the subscription
session requires online charging, in the case of session-based prepaid accounting,
the AAA server (or PPS) assigns a prepaid accounting quota (PPAQ)
to the PPC (HA or ASNGW) by encoding the PPAQ values in the RADIUS
Access-Accept packets. As the session continues, the PPC and the
PPS replenish the quotas by exchanging RADIUS packets. In the case
of IP 5-tuple flow-based prepaid accounting, when traffic is received
for a configured prepaid IP flow, the PPAC sends an authorize-only
access-request to the AAA server to request and receive quota attributes
for that flow.
In the case of session-based
prepaid accounting, quotas are allocated to each session. The Service-ID
in the PPAQ is sent to the IP-Address corresponding to the IP-Session.
Flow- based Prepaid
Accounting
As per NWG
WiMAX architecture, flow-based prepaid accounting can be either
IP 5-tuple flow-based, PDF ID based. or SDF ID based. Currently,
only the IP 5-tuple flow-based prepaid accounting is supported.
The ASNGW receives
PPAQ attributes separately for each flow that requires flow-based
accounting. The ASNGW performs pre-paid accounting for each of the
flows for which prepaid accounting is configured. However, there
can be flows for which pre-paid accounting is not requested. For
those flows, session-based off-line accounting procedures are applied.
PPAQ attribute contains
the Rating-Group-ID attribute which corresponds to one or more IP 5-tuple
flows, depending on the configuration. The Rating-Group-ID identifies
the flow for which pre-paid accounting is applicable. The format
of Service-ID for flow-based accounting is as follows:
- When the first data
packet which belongs to a Rating-Group-ID for which prepaid is configured
is received, the PPC (ASNGW or HA) requests quota attributes for
this Rating-Group-ID. The PPC sends an Authorize-Only access-request
and encoding PPAQ with Rating-Group-ID in it. The AAA server sends
back the available/allocated quota attributes in an Access-Accept
by encoding the PPAQ with the same Rating-Group-ID along with quota parameters.
- In the case of IP
5-tuple flow-based prepaid accounting, the quota is requested based
on Rating-Group-ID only. Configuration is required to map IP flows
to Rating-Group-IDs.
- On quota expiry for
a Rating-Group-ID, the PPC (ASNGW/HA) sends an on-line access
request to renew the quota. The ASNGW/HA includes the PPAQ
for the corresponding Rating-Group-ID only in the on-line access
request.
- In the case of quota
expiry for a flow, the ASNGW/HA renews the quota for that particular
Rating-Group-ID. If there is no quota allocated for the rating-group,
the traffic for that rating-group is dropped for some period (based
on configuration). If there is any more traffic matching that rating-group
after that period (based on configuration), the quota is requested
again for that rating group.
Configuring Rating-Group-ID
IP 5-tuples
are configured by using current active charging service ruledef
configurations. Each ruledef is associated with a rating group ID
by configuration. Several ruledefs (i.e., several IP 5-tuple rules)
may be mapped to a single rating-group ID. Prepaid quota attributes
are requested only on a ratinggroup ID basis.
Prepaid Tariff
Switching
Prepaid Tariff
Switching will be supported for IP 5-.tuple flow-based prepaid accounting.
Hotlining with
Flow-based Prepaid Accounting
Hotlining is
applied on a session basis. That is, when hotling has to be applied
because of either quota expiry for a rating-group or because a CoA
is received with hotlining parameters for a session, the entire
session is hotlined even though there may be some rating-groups
with quota remaining.
RADIUS-based Procedures
for WiMAX Hotlining
The hotlining
feature provides a WiMAX operator with the capability to address
issues with users that would otherwise be unauthorized to access
packet data services. The hotlining device (HLD) can be located
at the ASN or CSN.
Types of Hotlining
There are two methods
defined by which the HAAA indicates that a user is to be hot-lined:
- Profile based hotlining:
Hot-line profile(s) with all hotlining rules are pre-provisioned
at the HAAA. The HAAA sends a hot-line profile identifier in the RADIUS
message (Access-Accept and Change of Authorization) when the hotlining
is activated.
- Rule based hotlining:
Hotlining rules (filter rules, IP or HTTP redirection rules) are
sent in the RADIUS message (Access-Accept and Change of Authorization)
by the HAAA when the hotlining is activated. Cisco Systems supports
profile based hotlining and rule-based hotlining with HTTP redirection
rules only. Rule-based hotlining with IP-Redirection-Rules and NAS-Filter-Rules
are currently not supported.
Based on the status
of the user's session, there are two ways users can be hot-lined:
- Active session hotlining:
The user starts a normal packet data session. At some point in the
session, the HAAA receives a trigger for hotlining from the hotlining
application (HLA).
- New session hotlining:
The trigger from the HLA arrives prior to the user access authentication.
Once the hotlining
is resolved, the packet data session returns to normal. Both these approaches
are discussed in the following sub-sections.
Hotlining for Prepaid
Accounting Sessions
In the case of mid-session
hotlining, if an access-request is sent by the system to replenish
the quota, the server may not have enough quota to allocate for
the session. The AAA server may send hotlining attributes (profile-id
or hotlining rules) and the termination-action in the PPAQ set to
"Redirect/Filter" in the access-accept. In this case, the
HA or ASNWG installs the hotlining rules when the quota is exhausted
and the session becomes a hotlined session. If a CoA is received
with hotline attributes, the hotlining rules are installed and the
session becomes a hotlined session.
In the case of hotlining
during initial session establishment, the AAA server may send hotlining
attributes and 0 quota in the PPAQ. The termination-action in the
PPAQ is set to "Redirect/Filter". In this case, the session
would start as a hotlined session and the hotline rules are nstalled.
Hotline rules are
either derived from the hotline rule attributes in access-accept
in the case of rule based hotlining, or from the locally configured
hotline profile-id (Filter/Redirection rules which are
configured under the locally configured active-charging rulebase).
The hotline profile-id is received from the AAA server in access-accept
or in a CoA
Active Session
Hot-lining Call Flows
The active IP session
hot-lining is invoked when the user is currently engaged in a packet
data session and the HAAA receives hot lining trigger from the HLA.
Below figure depicts the call flow between the HLD, HAAA and HLA.
- User is in an active
IP session which is not hotlined.
- The HLA detects that
the user needs to be hot-lined. This is indicated to the HAAA by sending
a Hotlining Active Trigger.
- When the home AAA
server receives notification from the hotline applicaiton, it records
the hotlining state against the user record in the database. The
home AAA server determines whether the user has an ongoing packet
data session. If the user has an ongoing packet data session, the
home AAA server initiates the Active-Session Hotlining procedure.
The home AAA server uses the contents of the Hotline Capability
VSA and other local policies to determine which access device will
be the Hotlining Device for the session. The home AAA server sends
a RADIUS CoA-Request to the HLD with either Profile based hotlining
or Rule based hotlining
- Upon receipt of the
RADIUS COA, if the HLD can honor the request, it responds with a
RADIUS COA Ack to the HAAA. If the HLD cannot honor the request,
it responds with a COA NAK message. Based on the local policy, HAAA
may either retry sending the hotlining request to the HLD or it
may send a RADIUS Disconnect Message (DM) to the HLD to terminate
the session. ASNGW/HA always sends COA ACK if the session
is present.
- The HLD sends a RADIUS
Accounting Request (Stop) indication for the active data session,
with Session Continue set to true.
- The HLD sends a RADIUS
Accounting Request (Start) for the hotlined session with Beginning
of Session set to False. If the Session-Timeout attribute was included
in step 3, the HLD initiates session teardown (i.e., tear down of
the service flows associated with the IP session) when the duration
specified in the Session-Timeout attribute has elapsed and the user's session
is still hotlined. After tearing down the service flow(s), the HLD
sends an Accounting Request (Stop) to the HAAA to inform that the
user's IP session has ended. If the Session-Timeout times out while
a session is hot-lined, the session is terminated.
- Since the user's data
session is hot-lined in mid session, the user's data traffic is affected.
Based on the hotlining rules set at the HAAA and indicated by it
in the RADIUS COA earlier, the uplink and/or downlink data
traffic of the user is either dropped, disconnected, or blocked,
and redirected to the HLA by the HLD.
- Once the hotline status
is applied to the user status, the HLA notifies the user of his/her hotlined
status and resolves the issue. If the condition that triggered the
hot-lining session is not cleared, the HLA may terminate the session.
In this case, the HAAA is notified by the HLA. Upon receipt of this
notification, the HAAA sends a RADIUS Disconnect Message to the
HLD. The accounting records are stopped and session termination
is initiated. This may happen automatically at the HLD if the user's
hotlined status does not change during the Session-Timeout value.
If the condition that triggered the hotlining session is cleared,
the HLA sends the Hotlinig Inactive Trigger to the HAAA to clear
the hotlined status of the user.
- Upon receipt of the
Hotlining Inactive Trigger, the HAAA sends a RADIUS COA message
to the HLD with appropriate attributes. Note that this may not be
the same HLD that initially handled the activation of the hotlining.
This may occur due to events such as handoff.
- Upon receipt of the
RADIUS COA, if the HLD can honor the request it will respond with
a RADIUS COA Ack to the HAAA. At that point the Hotline Session-Timeout
timer is turned off. If the HLD cannot honor the request, it responds
with a COA NAK message. Based on the local policy, the HAAA may
retry sending the hotlining signal to the HLD or it may send a RADIUS
Disconnect Message to the HLD to terminate the session. In this
case, the HLD sends a RADIUS Accounting Request (Stop) message to
the HAAA to indicate the end of the IP session for the user. This
occurs after the Disconnect Message is processed and the service
flow(s) associated with the IP session are torn down.
- The HLD generates
a RADIUS Accounting Request (Stop) with Session Continue set to
True message for the hotlined packet data session.
- The RADIUS Accounting
Request (Stop) message with Session Continue set to True is followed
by a RADIUS Accounting Request (Start) message with Beginning of
Session set to False. This indicates the start of the normal packet
data session.
- The user continues
the packet data session and the traffic is routed normally. During
the hotlined active status in the HLD, the byte, packet, and duration
counts for user's hotlined IP session is counted towards the overall
byte and packet counts.
Active Session
Hotlining for Prepaid Users
Active IP session
hotlining is invoked when the prepaid user is engaged in a packet
data session and the HAAA /PPS does not grant additional
quota to the user. The figure below shows the call flow between
HLD/PPC, HAAA/PPS and HLA.
- The prepaid user is
in an active IP session that is not hotlined.
- The threshold for
the prepaid quota(s) is reached.
- PPC requests additional
quota by sending an Authorize-Only Access-Request to the PPS containing
one or more PPAQ(s) indicating which quota(s) need to be replenished.
- PPS responds with
an Access-Accept packet. The balance on the user account is too low
for additional quota to be allocated. Hotlining is triggered for
the user to replenish his/her account. Access-Accept is
sent to the HLD with either Profile-based Hot-lining or Rule-based Hot-lining.
- From this point on
all steps are identical to “Active Session Hotlining for
Prepaid Users.”
Hotlining During
Initial Network Entry
During initial network
entry, hotlining is invoked. (Triggers for invoking hotlining are
not within the scope of this section.) Examples include limited
access to emergency services, empty prepaid accounts, or mobility
restriction applied to a fixed or nomadic subscription. This occurs
when H-AAA detects that initial network entry is being performed
at a BS that does not belong to the network entry zone of the MS.
I
- The MS performs EAP
authentication of initial network entry.
- The Authenticator
sends Access-Request as part of the authentication procedure. The H-AAA
server acquires the ASN hot-lining capabilities.
- If H-AAA activates
hotlining, it sends an Access-Accept to the Authenticator/HLD with
the appropriate attributes. The H-AAA may activate hotlining, depending
on application-specific conditions such as emergency network entry
(indicated by ES specific NAI), mobility restrictions applying to
fixed or nomadic subscribers, or an empty prepaid account.
- The anchor SFA located
with the authenticator establishes the initial service flow (ISF) for
the MS.
- The MS gets an IP
address from network side if an IP address is required for hotlining.
- The authenticator/HLD
sends a RADIUS Accounting Request (Start) for the hotlined session
to indicate the activation of hot-lining.
- Based on the hotlining
rules received from the H-AAA server, the uplink and/or downlink
data traffic of the user is either dropped or blocked, and redirected
to the HLA by the HLD.
- If the HAAA detects
that the condition that triggered the hot-lining of the session
is cleared, the HAAA sends a Radius COA message to the Authenticator/HLD
with the appropriate attributes.
- Upon receipt of the
Radius COA, the authenticator/HLD responds with a Radius
COA Ack to the HAAA.
- The authenticator/HLD
sends a Radius Accounting Request (Stop) to the HAAA to indicate
the inactivation of the Hotlining.
Tariff Switching
for Prepaid Accounting
The PPC and the PPS
may support the tariff switching mechanism described in this section.
This mechanism is useful if, for example, traffic before 18:00
is rated at rate r1 and traffic after 18:00 is rated at rate r2.
The mechanism requires the PPC to report usage before and after
the switch occurrs.
The PPC indicates
support for tariff switching by setting the appropriate bit in the
PPAC. If the PPS needs to signal a tariff switch time, it sends
a PTS attribute that indicates the point in time when the switch
will occur. This indication represents the number of seconds from
current time (TariffSwitchInterval TSI).
At some point after
the tariff switch, the PPC sends another Access-Request, as a result
of the user having logged off or the volume threshold being reached.
The PPC reports how much volume was used in total (in a PPAQ attribute)
and how much volume was used after the tariff switch (in a PTS VUATS
subtype attribute). In situations with multiple tariff switches,
the PPS must specify the length of the tariff switch period using
the TimeIntervalAfterTariffSwitchUpdate (TITSU) in the PTS attribute.
When a TITSU is specified
in the PTS, the PPC generates an Access-Request within the time
after TSI and before TITSU expires. Note that, typically, the PPC
is triggered by the Volume Threshold. However, it is possible that
during period r2, resources may not be entirely consumed and the
threshold not reached. The TITSU attribute ensures that, even in
this case, the PPC will generate the new Access-Request in good
time.
Note that it is not
efficient to use the tariff switching mechanism for services that
are metered based on time and uninterrupted consumption. Also note
that separate services flows may have individual tariff periods.
CSN Procedure Flows
This section
provides an overview of CSN procedure and working of ASN Gateway
in CSN procedure.
PMIP4 Connection
Setup and Call Flow with DHCP Proxy
This section
describes the CSN procedure of simple IP with DHCP proxy triggering
PMIPv4 for a WiMAX subscriber.
The following figure
and table provide a high-level view of the steps involved in PMIP4
connection and call flow of an SS/MS.
Figure 27. PMIP4 Connection
Setup Call Flow
Table 17. PMIP4 Connection
Setup Call Flow Description
Step |
Description |
1 |
Initial
network entry completed as described in ASN Procedures. |
2 |
MS
sends DHCP DISCOVER message to DHCP Proxy (co-located with ASN Gateway)
to discover a DHCP server for IP host configuration. |
3 |
Upon
receiving the DHCP DISCOVER message, the DHCP Proxy in the NAS triggers
the PMIP4 client to initiate 8 the Mobile IPv4 Registration procedure.The
PMIP4 client uses the HoA information and constructs a Mobile IPv4
Registration Request message and sends the Mobile IPv4 Registration
Request to the FA address. The FA forwards the registration request
to the CSN HA. |
4 |
CSN
HA processes the MIPv4 Registration Request.If a HoA is 0.0.0.0
in the Mobile IP Registration Request message, the HA assigns a
HoA. Otherwise, the HoA in the Mobile IP Registration Request message
is used. |
5 |
The
HA responds with the Mobile IP Registration Response message.The
source address for this Mobile IPv4 message over R3 is HA, and the
destination address is FA-CoA.The FA forwards the message to the
PMIP4 client. The PMIP4 client passes this information to the DHCP
proxy. |
6 |
The
DHCP proxy sends the DHCP OFFER message to the MS. |
7 |
MS
sends a DHCP REQUEST to the DHCP Proxy with the information received
in the DHCP OFFER. |
8 |
The
DHCP Proxy acknowledges the use of this IP address and other configuration
parameters by sending the DHCP ACK message. |
9 |
WiMAX
session established between MS and CSN HA. |
PMIP4 Session Release
This section
describes the CSN procedure of PMIPv4 session release during a WiMAX
subscriber session.
The following figure
and table provide a high-level view of the steps involved in PMIPv4
session release and termination of connection an SS/MS.
Figure 28. PMIP4 Session Release
Call Flow
Table 18. PMIP4 Session Release
Call Flow Description
Step |
Description |
1 |
The
session release trigger send by MS sending DHCP-Release message
to the ASN GS or DHCP proxy has expired on lease time or FA initiates
session release. |
2 |
ASN
Gateway initiates the session release with PMIPv4 client by sending
FA_Revoke_Req and sends PMIP De-Reg RRQ (Registration
Revocation) message to CSN HA. |
3 |
CSN
HA starts release of MIP binding. |
4 |
CSN
HA sends PMIP De-Reg RRQ (Registration Revocation) message to ASN
Gateway and PMIP client sends GA_Revoke_Rsp message
to ASN Gateway. |
9 |
WiMAX
session terminated between MS and CSN HA. |
WiMAX Deployment
with Legacy Core Networks
ASN Gateway
can inter-operate with a 3GPP overlay and 3GPP2 overlay and provide
continuity support for 3GPP2 and WiMAX handovers.
ASN Gateway Interoperability
with 3GPP Overlay
The following figure
shows a typical interoperability scenario between WiMAX and 3GPP
legacy networks with reference points and interfaces.
Figure 29. ASN Gateway with
3GPP Overlay
ASN Gateway Interoperability
with 3GPP2 Overlay
The following figure
shows a typical interoperability scenario between WiMAX and 3GPP2
legacy networks with reference points and interfaces.
Figure 30. ASN Gateway with
3GPP2 Overlay
Session Continuity
Support for 3GPP2 and WiMAX Handovers
This feature provides
seamless 3GPP2 session mobility for WiMAX subscribers and other
access technology subscribers. With the implementation of this feature,
the HA can be configured for:
- 3GPP2 HA service
- 3GPP HA service
- WiMAX HA service
- A combination of 3GPP2
and WiMAX HA services
The above configurations
provide the session continuity capability that enables a dual-mode device
(a multi-radio device) to continue its active data session as it
changes its active network attachment from 3GPP2 to Wimax and vice
versa, with no perceived impact from a user perspective. This capability
brings the following benefits:
- Common billing and
customer care
- Accessing home 3GPP2
service through Wimax network and vice versa
- Better user experience
with seamless session continuity
For more information
on this support, refer to the HA Administration Guide.
NSP-ID and NAP-ID
Functionality
NSP-ID and NAP-ID
functionality enable the MS to discover all accessible network service providers
(NSPs) in a WiMAX coverage area, and to indicate the NSP selection
during connectivity to the ASN. The actual NSP selection by the
MS may be based on various preference criteria, depending on the configuration
information.
Configuration information
includes:
- Information useful
in the MS discovery of the network access provider (NAP), including
channel center frequency and PHY profile,
- Information useful
in the MS decision mechanism to prioritize NSPs for automatic service
selection, including a list of authorized NAPs and NSPs,
- A list of authorized
share or roaming relationships between authorized NAPs and NSPs and
partner NAPs and NSPs,
- Identity credentials
provided by the NSPs to which the MS has a business relationship, and
- The mapping relation
table between 24-bit NSP identities and corresponding realms of the
NSPs.
Configuration information
may be provided on a pre-provisioned basis or at the time of MS dynamic
service subscription.
Manual Mode
The NSP Enumeration
List is presented to the user for selection. Each entry presents
only the verbose NSP name to the user. If more than one NAP can
be used to establish a direct connection with a NSP, the MS may
indicate each of the candidate NAPs along with the NSP or verbose
NSP name to the user in the following order:
- Home NSP.
- If the “User
Controlled RAPL” (Roaming Contractual Agreements Preference
List) is available, NSPs or their corresponding verbose NSP names
in the “User Controlled RAPL” in the MS (in priority
order),
- If the “Operator
Controlled RAPL” is available, NSPs or their corresponding
verbose NSP names in the “Operator Controlled RAPL” in
the MS (in priority order),
- Any other NSP or their
corresponding verbose NSP names in random order.
Upon selection and
successful authentication to the selected NSP, the MS indicates
the selected NSP. If no NSP is found, the MS behavior is implementation dependent.
Automatic Mode
For Automatic
Mode, without user intervention, the MS selects a NAP that has a
direct connection to the home NSP. If more than one NAP can be used
to establish a direct connection with an NSP, the MS selects a NAP
by using “User Controlled CAPL” (Contractual Agreements
Preference List) or “Operator Controlled CAPL”.
If a NAP that has direct
connection to the home NSP is not found, the MS attempts to select
a NAP that has connection to one of the NSPs in the Preferred NSPs
list. The order that the MS follows for selection from the NSP Enumeration
List is determined by the “User Controlled CAPL” and “Operator
Controlled CAPL”, if available in the configuration information.The
MS selects and tries to authenticate with an available and allowable
NSP, in the following precedence:
- Home NSP,
- If the “User
Controlled RAPL” is available, NSPs in the “User
Controlled RAPL” in the MS (in priority order),
- If the “Operator
Controlled RAPL” is available, NSPs in the “Operator
Controlled RAPL” in the MS (in priority order),
- Any other NSP in random
order.
Upon selection and
successful authentication to the selected NSP, the MS indicates
the selected NSP. If no NSP is found, the MS behavior is implementation dependent.
ASN GW and NAP-ID/NSP-ID
Process
Following is
an overview of NAP-ID and NSP-ID process from the ASN GW’s
perspective:
- NAP/NSP advertisement:
BS advertises the available NAP/NSP to MS. The MS chooses
one of the preferred NAP/NSPs and performs INE with that NAP/NSP.
The BS/MS supports this function; the ASN GW does not play
a role.
- Once the MS selects
an NSP, the MS performs INE with the selected NSP to authenticate
the MS at the selected NSP. The ASN GW enables the MS to get service
from that NSP. In short, the ASN GW routes the Authentication request
to the right AAA server, based on the NAI.
- The NSP-ID is included
in the access request from the ASN GW.
- The ASN GW and HA sends
the NSPID in authentication and accounting procedures to AAA server.
The ASNGW does not send NAPID in authentication and accounting procedures to
the AAA server, since the ASNGW sends the BSID to the AAA server.
Data Tunnel Endpoint
Support
ASNGW supports
forwarding downlink data to different endpoint tunnels other than
the control address on the BS. In addition, the ASNGW can process
uplink data and control traffic on different paths (VLANs) on the
ASNGW if the data and control traffic are hosted on a different
IP address.
The control and data
tunnel endpoint can be different for the BS or the ASNGW. If the
data tunnel endpoint is different from the control endpoint, it
applies for both downlink and uplink traffic destined to, or received
from, the peer (BS or ASNGW). This means that when downlink traffic
is sent to the peer, the data tunnel endpoint is the destination
IP address; when the uplink traffic is received from this peer,
the source IP address is the data tunnel endpoint. The GRE key is
unique for downlink and uplink data paths.
ASNGW with a Different
Tunnel Endpoint
The ASNGW supports
different data tunnel points on the BS for downlink traffic. The
BS conveys its data tunnel endpoint through the existing R6 TLVs
within MS Info.
If the uplink has a
different data tunnel point, the ASNGW adds this information in
the message that carries MS information, including the TLV or data
path TLV that describes uplink service flow. There is a unique GRE
key assigned to the uplink data path.
The ASNGW includes
the tunnel endpoint TLV in the data path messages to BS or from
the non-anchor GW to the anchor GW and vice-versa, to support the
handoff functionality. After receiving the tunnel endpoint TLV within
the data path messages, the BS forwards all the uplink data traffic
to the same address.
No Handoff (INE)
For the control
and data path setup for the INE, the BS/ASN specifies the
different IP addresses for control and data traffic. For example,
DT1 and BS1 are the data and control endpoints on the BS side. AT1
and AS1 are the data and control endpoints respectively on the ASNGW
side. If the ASNGW requires different data tunnel endpoints instead
of control addresses, the tunnel endpoint IP address has to be populated
in the MS information TLV if it is per BS for DP Reg Request/Response
message.
The ASNGW creates an
NPU flow using the tunnel IP address if received in the DP Reg Response
message for the uplink packet. From now on, all the data packets
received from the BS have the source address of DT1. For all the
downlink traffic, the ASNGW forms the data packet using the ASNGW
Data IP address as the source address; the AS1 and destination address
of the tunnel are the tunnel endpoint (that is, DT1). If no tunnel
end point attribute is received from BS/ASNGW, by default,
the control IP address is used for data traffic.
If the ASNGW requires
a different data tunnel endpoint instead of a control address, the tunnel
endpoint IP address is populated in the MS information TLV if it
is per BS for DP Reg Request/Response message.
Inter-ASNGW Handoff
For control
and data path setup for an inter-ASNGW handoff, the serving base
station (SBS) is connected to the anchor GW and the target base
station (TBS) is connected to the non-anchor GW. During INE, the
anchor GW specifies a different IP address for data traffic. For
example, if AT1 and DT1 are the data endpoints on the ASNGW and
SBS side, the ASNGW informs the SBS about a different address for data
by sending out a tunnel endpoint IP address in the MS information
TLV in the DP-Reg Request during INE.
Similarly, during inter-ASNGW
handoff, the non-anchor GW specifies the different data tunnel endpoint
for uplink traffic in the DP-Reg Rsp message. The same address on
the non-anchor GW receives the downlink data packets from the anchor
GW. AT2 and DT2 are the data tunnel endpoint for the non-anchor
GW and TBS, respectively. The tunnel endpoint IP address is populated
in the MS information TLV in DP Reg Rsp message from non-anchor
GW to the TBS.
Intra-ASNGW Handoff
For intra-ASNGW
handoff, during INE, the ASNGW specifies the different data tunnel
endpoint for receiving uplink traffic in the DP-Reg Req message
to the serving base station (SBS). After handoff, the ASNGW specifies
the different data tunnel endpoint to receive the Uplink traffic
in the DP-Reg Rsp message. For example, AT1 is the tunnel endpoint
on ASNGW for data traffic. DT1 and DT2 are the data tunnel endpoints
on the SBS and TBS, respectively. The ASNGW provides the tunnel
endpoint in the MS information TLV within the data path messages
AS1 is the control
address on the ASNGW to negotiate R6 control traffic. SB1 and TB1
are the control addresses on SBS and TBS, respectively. The ANCHOR
GW specifies the tunnel endpoint to receive the uplink traffic in
the DP-Reg Rsp message. AT1 and AT2 are the data tunnel endpoints
on the anchor and non-anchor GWs, respectively to negotiate R6 control
traffic. SB1 and TB1 is the control address on SBS and TBS, respectively.
Supported Standards
WiMAX/IEEE
References
- “WiMAX ASN
Profiles”, WiMAX Forum
- “Initial
Network Entry Stage 3”, Draft T33-001-R016v01-G Specification
WiMAX Forum
- “Procedures
and Messages for ASN Anchored Mobility with Profile C: Stage 3” draft, WiMAX
Forum
- “Procedures
for CSN Anchored Mobility Stage 3” draft, WiMAX Forum
- “WiMAX End-to-End
Network Systems Architecture: Stage 2 Draft Specification”, Release
1.0.0 Draft, March 28, 2007, WiMAX Forum
- “WiMAX End-to-End
Network Systems Architecture: Stage 3: Detailed Protocols and Procedures”,
Release 1.0.0 Draft, March 28, 2007, WiMAX Forum
- “WiMAX Forum
Network Architecture - Stage 3-Detailed Protocols and Procedures” - DRAFT-T33-001-R015v01-J
IEEE Standards
- IEEE 802.16e/D12
September 2005, Local and Metropolitan Area Networks – Part
16: Air Interface for Fixed Broadband Wireless Access Systems, Feb
2006.
- 802.1P QoS at MAC
Level
- 802.1Q VLAN Standard
- IEEE 802.16e/D12
September 2005, Local and Metropolitan Area Networks - Part 16: Air
Interface for Fixed Broadband Wireless Access Systems, March 2004.
IETF References
- RFC-1701, Generic
Routing Encapsulation (GRE), October 1994
- RFC-2131, Dynamic
Host Configuration Protocol (DHCP), March 1997
- RFC-2794, Mobile NAI
Extension
- RFC-2865, Remote Authentication
Dial In User Service (RADIUS), June 2000
- RFC-2866, RADIUS Accounting,
June 2000
- RFC-3012, Mobile Ipv4
Challenge/Response Extensions, November 2000
- RFC-3024, Reverse
Tunneling for Mobile IP, revised, January 2001
- RFC-3046, DHCP Relay
Agent Information Option, January 2001
- RFC-3344, Mobile IP
support for Ipv4, August 2002
- RFC-3579, RADIUS (Remote
Authentication Dial In User Service) Support For Extensible Authentication
Protocol (EAP), September 2003
- RFC-3588, Diameter
Base Protocol, September 2003
- RFC-3748, Extensible
Authentication Protocol, June 2004
- RFC 1918, NWG, Stage
2 Architecture, 121505
- RFC 3115, Mobile IP
Vendor/Organization-specific Extensions
Object Management
Group (OMG) Standards
- CORBA 2.6 Specification
01-09-35, Object Management Group