> 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 and requires an Access Service Network Gateway support license.
> ASN Gateway provides the following functionality, all of which is integrated into the chassis:

> • | ASN mobility

> • | Extensible Authentication Protocol (EAP) user authentication/Authentication, Authorization, Accounting (AAA) client

> • | DHCP proxy server

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

> ASN Mobility Management
> The Access Service Network Gateway (ASN Gateway) processes subscriber control and bearer data traffic, and 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.
> 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.
> 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 a 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.
> 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.
> 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 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 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.
> 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 are 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 Enhancements
> Lawful Intercept (LI) provides a mechanism for telecommunication service providers (TSPs) to assist Law Enforcement Agencies (LEAs) in monitoring suspicious individuals (referred to as targets) for potential criminal activity. LEAs provide one or more TSPs with court orders or warrants requesting the monitoring of a particular target. The target is identified by information such as their Mobile Station Identification (MSID) number, their name, or their assigned IP address.
> It is not possible to provision an LI trigger on the ASN Gateway (Simple IP) or home agent (Mobile IP) with pseudo-NAI identifiers, since the outer identity is concealed from the gateway. For this reason, if it is necessary to provision triggers with the pseudo-NAI, the basic LI license (with AAA event detection) must be used.
> Once the target has been identified the system, functioning as either an ASN Gateway (Simple IP) or home agent (Mobile IP), serves as an access function (AF) and monitors new data sessions or sessions already in progress. While monitoring, the system intercepts and duplicates session content and forwards it to a delivery function (DF) over an extensible, proprietary interface. The DF delivers the intercepted content to one or more collection functions.
> The WiMAX implementation of LI monitoring includes the following features:

> • | Active triggers (using AAA assist for control plane event detection)

> • | Event delivery (AF to DF) with ability to configure UDP/IP message acknowledgements

> 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, which 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.
> Currently, the ASN Gateway supports static pre-provisioned service flows. A total of up to three bi-directional or 6 unidirectional 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.
> 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.
> 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.
> 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
> 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.
> 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: PMIPv4, CMIPv4, CMIPv6 (this is IPv4 and IPv6 support for Proxy Mobile IP (PMIP)) and Client Mobile IP (CMIP).

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

> • | 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 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 if DHCP proxy is co-located in the ASN Gateway. and whether to process DHCP packet locally or not. 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.
> Initial Network Entry and Data Session Establishment without Authentication Call Flow
> Initial Network Entry and Data Session Establishment without Authentication Call Flow Description

> <X-Refs (online)>step <$paranum> | 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.
> Initial Network Entry and Data Session Establishment with Authentication Call Flow
> Initial Network Entry and Data Session Establishment with Authentication Call Flow Description

> <X-Refs (online)>step <$paranum> | 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 Cisco Systems 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.
> MS Triggered Network Exit Call Flow
> MS Triggered Network Exit Call Flow Description

> <X-Refs (online)>step <$paranum> | 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.
> Network Triggered Network Exit Call Flow
> Network Triggered Network Exit Call Flow Description

> <X-Refs (online)>step <$paranum> | 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 | ASN Gateway/FA and HA starts MIP release procedure.
> 7 | 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.
> 8 | ASN Gateway sends Accounting-Stop-Request (Release Indication) message to H-AAA.
> 9 | AAA replies with Accounting-Stop-Response message to ASN Gateway.
> 10 | ASN Gateway/FA replies with Path_Dereg_Response message to ASN BS.
> 11 | 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.
> Intra-ASN Gateway Uncontrolled Handover Call Flow
> Intra-ASN Gateway Uncontrolled Handover Call Flow Description

> <X-Refs (online)>step <$paranum> | 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 an uncontrolled intra-ASN Gateway handover preparation phase between two BSs.
> MS initiated Uncontrolled Intra-ASN Gateway Handover Preparation Phase
> MS initiated Uncontrolled Intra-ASN Gateway Handover Preparation Phase Description

> <X-Refs (online)>step <$paranum> | 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.
> MS initiated Uncontrolled Intra-ASN Gateway Handover Action Phase
> MS initiated Uncontrolled Intra-ASN GW Handover Phase

> <X-Refs (online)>step <$paranum> | 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.
> BS initiated Uncontrolled Intra-ASN Gateway Handover Preparation Phase
> BS initiated Uncontrolled Intra-ASN Gateway Handover Preparation Phase Description

> <X-Refs (online)>step <$paranum> | 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.
> BS initiated Uncontrolled Intra-ASN Gateway Handover Action Phase
> BS initiated Uncontrolled Intra-ASN Gateway Handover Action Phase Description

> <X-Refs (online)>step <$paranum> | 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 Gatewayx and the R6 Data Path Function in ASN Gatewayy. 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.
> 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.
> Controlled Inter-ASN Gateway Handover Procedure - Preparation Phase
> Controlled Inter-ASN Gateway Handover Procedure - Preparation Phase Description

> <X-Refs (online)>step <$paranum> | 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.
> Controlled Inter-ASN Gateway Handover Procedure - Action Phase
> Controlled Inter-ASN Gateway Handover Procedure - Action Phase Description

> <X-Refs (online)>step <$paranum> | 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.
> Uncontrolled Inter-ASN Gateway Handover Procedure
> Uncontrolled Inter-ASN Gateway Handover Procedure Description

> <X-Refs (online)>step <$paranum> | 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.
> Call Flow Showing How Additional Quota is Obtained
> Call Flow Showing How Additional Quota is Obtained

> <X-Refs (online)>step <$paranum> | 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.
> Call Flow for Applying HTTP Redirection Rule on Quota-Reach
> Call Flow for Applying HTTP Redirection Rule on Quota-Reach

> <X-Refs (online)>step <$paranum> | 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 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.
> Call Flow for Applying HTTP-Redirection Rule when CoA is Received
> Call Flow for Applying HTTP-Redirection Rule Received by CoA

> <X-Refs (online)>step <$paranum> | 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.
> Call Flow for Terminating the Call on Quota-Reach
> Call Flow for Terminating the Call on Quota-Reach

> <X-Refs (online)>step <$paranum> | 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.

> ‌
> CSN Procedure Flows
> This section provides an overview of CSN procedure and working of ASN Gateway in CSN procedure.
> Following procedures are discussed in this section:
> 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.
> PMIP4 Connection Setup Call Flow
> PMIP4 Connection Setup Call Flow Description

> <X-Refs (online)>step <$paranum> | 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.
> PMIP4 Session Release Call Flow
> PMIP4 Session Release Call Flow Description

> <X-Refs (online)>step <$paranum> | 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 Interoperability with 3GPP Overlay
> The following figure shows a typical interoperability scenario between WiMAX and 3GPP legacy networks with reference points and interfaces.
> 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.
> 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.
> Supported Standards
> WiMAX/IEEE References

> • | WiMAX ASN Profiles, WiMAX Forum

> • | Initial Network Entry Stage 3 Draft 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

> 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.1Q VLAN Standard

> 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

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883