13
Digital Object Identifier 10.1109/MVT.2009.932549 JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE 1556-6072/09/$25.00©2009IEEE ||| 1 WiMAX NETWORK W orldwide interoperability for microwave access (WiMAX) tends to be one of the most controversial technologies in telecommunications history. WiMAX can be seen either as a prominent technology in the mobile Internet access revolution or as an unjustifiably hyped technology that remained just an expectation and never lived up to its potential. Advocates of the former statement include the major, leading industries. There are also significant supporters of the latter one, and thus doubters of WiMAX, which bank on their experience in deploying legacy, cellular networks, and shift the attention to HSxPA and third-generation (3G) long-term evolution (LTE) [1]. Overview and Challenges Beyond the Air Interface Kostas Tsagkaris and Panagiotis Demestichas IEEE Proof

WiMAX NETWORK - unipi.grtns.ted.unipi.gr/ktsagkaris/img/papers/ieee/J20_IEEEVTM_WiMAX... · WiMAX Forum, and more specifically the Networking ... “WiMAX Network Architecture”

Embed Size (px)

Citation preview

Digital Object Identifier 10.1109/MVT.2009.932549

JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE 1556-6072/09/$25.00©2009IEEE ||| 1

WiMAX NETWORK

Worldwide interoperability for microwave access (WiMAX) tends to be one of the most controversial technologies in telecommunications history. WiMAX can be seen either as a prominent technology in the mobile Internet access revolution or as an unjustifiably hyped technology that remained just an

expectation and never lived up to its potential. Advocates of the former statement include the major, leading industries. There are also significant supporters of the latter one, and thus doubters of WiMAX, which bank on their experience in deploying legacy, cellular networks, and shift the attention to HSxPA and third-generation (3G) long-term evolution (LTE) [1].

Overview and Challenges Beyond the Air Interface

Kostas Tsagkaris and Panagiotis Demestichas

IEEE

Proof

2 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | JUNE 2009

Although related technologies like WiBro in South Ko-rea already have live deployments in action, it is expect-ed that 2008 will be the year of the commercial debut of WiMAX arriving as a new option for Internet access. Apart from the United States, where WiMAX will be avail-able to more than 4 million people by the end of 2008, there are also significant international WiMAX deploy-ments in Asia, Europe, Australia, the Middle East, and South America [2]. <AU: Please note that the references (both in text and list) have been renumbered to make them sequential per magazine style.>

The fixed version of WiMAX, corresponding to and also overriding the IEEE standard 802.16d or 802.16-2004 [3], acts as a simple, quick, and cost-effective way of bringing the Internet access to many new places (by setting up WiMAX base stations), instead of laying digi-tal subscriber line (DSL) <AU: Please check whether the definition of DSL is ok as given.> or cable wires. On the other hand, the latest version of the IEEE 802.16 standard, i.e., 802.16e or 802.16e-2005 [4] or simply Mo-bile WiMAX, can also provide fixed access with carrier-grade performance, but at the same time promises a real mobile Internet experience to the users by efficiently handling various manifestations of handoffs during user movement. While the fixed WiMAX market seems to be a niche market, with the operators aiming at covering areas that are not served by fixed broadband infrastruc-ture, mobile WiMAX operators are targeting a much bigger market, because they are looking to major metro-politan areas deployments, cohabiting with cellular ser-vices either in a complementary or competing manner.

The IEEE standards, 802.16d and 802.16e, as well as the more recent amendments like 802.16j (enhancement of coverage, throughput, and system capacity by introduc-ing multihop relay capabilities) [5] and 802.16m (amend-ment of 802.16 WMAN-OFDMA specification for providing advanced air interface) [6] <AU: Please spell out WMAN-OFDMA.> are mainly dealing with specifications for the physical (PHY) and medium access control (MAC) layers. We strongly believe that, to exploit the full potential of WiMAX, operators should dedicate a significant propor-tion of their attention beyond the air interface, where the access service network (ASN) and the connectivity service network (CSN) exist. In general, the ASN is responsible for managing mobile station (MS) access, radio resources, mobility, quality-of-service (QoS), and security and also for interfacing the BS and the all-Internet protocol (IP) core network, the CSN. <Au:Please spell out BS.> The CSN performs core network functions such as policy and admission control, IP address allocation and billing and is also responsible for internetworking with non-WiMAX networks and for roaming through links to other CSNs.

Here is exactly where WiMAX Forum comes in. The WiMAX Forum, and more specifically the Networking Working Group (NWG), aims at producing specifications

[7], [8] that will assist vendors to provide architectures or platforms that will be open, interoperable, and ca-pable of interworking with other networks. This can be, of course, facilitated by the fact that the core of WiMAX will be an IP-based architecture, which traditionally sup-ports openness, in addition to other well-known benefits such as low cost and development flexibility. Operators then need to carefully select their solutions (vendors) while equipping their ASN and CSNs with the appropri-ate hardware (various network elements) and software. In particular and to address the strong requirement for mobility, the WiMAX Forum specifies a mobility support node that resides in the heart of the ASN and is referred as ASN gateway (ASN-GW). The ASN-GW lies in the most salient and opportune spot of the network, where traffic is moving from the radio to the core (information serv-ers) part and vice versa.

The embodiment of such a GW is judged as extremely crucial requirement for supporting and provisioning com-petitive WiMAX system deployments. That is because mainstream functionality such as QoS, mobility, and se-curity, and subscriber service management and control, as well as more intelligent features, such as cost-effective provisioning, network, traffic, and spectrum optimization, differentiated content management, and support for multi-cast–broadcast and location-based services could not be supported without the existence of a powerful ASN-GW [9].

Framed within this statement and the preceding anal-ysis, this article focuses beyond the air interface on the core part of a WiMAX network and aims at presenting an overview and challenges pertinent to the successful deployment of WiMAX solutions, as per the current re-lease of NWG specifications. Special focus is placed on the ASN functional architecture, wherein the ASN-GW is the most strategic asset.

The rest of this article is organized as follows: the “WiMAX Network Architecture” section presents the WiMAX network reference model (NRM) and architec-ture. The “ASN Functionality” section focuses on the ASN and describes the set of functional protocol that it provides, and the requirements and challenges for a possible ASN-GW deployment are discussed in the next section. The “What is Next? The Way Forward” section describes what is to be improved in the next release of the WiMAX Forum NWG specifications, and finally, the last section discusses and concludes the article.

WiMAX Network Architecture

The logic and design principles behind the WiMAX net-work architecture are based on the fulfilment of certain requirements [10] that can be briefly stated as follows.1) The architecture shall be based on decomposing into

functions and specifying open, well-defined reference points (interfaces) in a way that multivendor interop-erability is ensured.

IEEE

Proof

JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 3

2) Multiple deployment schemes including centralized, fully, and semidistributed (hybrid) implementations shall be supported.

3) The architecture shall support various usage models including fixed, nomadic, portable, and mobile usage models.

4) The architecture shall decouple the access network from the connectivity network, which is radio agnostic and offers IP services.

5) The architecture shall support a variety of business models arising from various types of dividing roles among the main business entities, namely the network access provider (NAP), the network service provider (NSP), and the application service providers (ASP).

6) The architecture shall support interworking with 3GPP/3GPP2, Wi-Fi, and wired networks, such as DSL, with the use of IETF protocols. <AU: Please spell out IETF>The NAP is the entity that owns and operates the ac-

cess network providing the radio access infrastructure to one or more NSPs. Correspondingly, the NSP is the entity that owns the subscriber and provides his or her with IP connectivity and WiMAX services by using the ASN infrastructure provided by one or more NAPs. A NSP can be attributed as home or visited from the sub-scriber’s point of view. A home NSP maintains service-level agreements (SLAs), authenticates, authorizes, and charges WiMAX subscribers. A home NSP may settle roaming agreements with other NSPs, which are called visited NSPs and are responsible to provide some or all subscribed services to roaming WiMAX users. Figure 1 depicts the possible business relationships among NAP and NSP entities, as well as with the WiMAX subscriber.

As a result, a network architecture, which is believed to fulfil the above-stated requirements, has been developed by the WiMAX NWG. Figure 2 depicts the foreseen WiMAX network architecture. The NRM, which is a logical representation of the network architecture, is also shown in Figure 3. Apart from the MS/subscriber stations (SS) used by the subscriber to access the network, the WiMAX core network also comprises the ASN and the CSN.

The ASN, owned by a NAP, con-sists of one or more BSs and one or more ASN-GWs. The ASN functional-ity is presented in more detail in the next section. The CSN, located at the core of the WiMAX network architec-ture and typically owned by an NSP, controls and manages both the ASN and users by providing functional-ities such as

connectivity to Internet and ASP(s) and interworking ■

with other public land mobile networks (PLMNs) and networksIP address management ■

provision of authentication, authorization, and account- ■

ing (AAA) to users, devices, and servicesASN-CSN tunneling support ■

roaming between NSPs ■

location management, mobility, and roaming between ■

ASNspolicy and QoS control based on the contract or SLA ■

with the user.To do so, a set of network elements are mobilized, in-

cluding home agents (HAs), dynamic host-configuration protocol (DHCP), and domain name system (DNS) servers,

Service Level Agreement (SLA)HomeNSP

WiMAXSubscriber

Contract

Contract

VisitedNSP

CSN

RoamingAgreement

CSN

NAP #1

NAP #2

ASN

ASN#1

ASN#2

FIGURE 1 Relationships among key WiMAX business entities [8].

FIGURE 2 WiMAX network architecture.

ASN CSN

CSNASN

BS

BS

BS

ASN GW(Foreign Agent)

IPBackbone

InterworkingGW

GW

GW

ASP Internet IMS

HomeAgent

AAAServer/Proxy

DHCP/DNSBillingServer

PolicyServer User

DatabaseNMS

GWGW

IEEE

Proof

4 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | JUNE 2009

AAA proxies and servers (home or visited, e.g., when in roaming situations), billing servers, policy servers, voice over Internet protocol (VoIP), interworking GWs, and IMS-support nodes. <AU: Please spell out IMS.>

Some key issues about the proposed NWG’s NRM need to be pointed out here. 1) The reference points do not dictate how vendors implement their edges, 2) the notion of functional entities, which can be combined or

decomposed by the vendor or operator, is introduced, 3) no specific physical entities are introduced, and 4) no single physical ASN or CSN topology is mandated, thus al-lowing room for the vendor or operator differentiation.

As said, one of the key requirements that drove the network design is the openness of the reference points, which the NWG specifications define as conceptual links that connect two groups of functions that reside in dif-ferent functional entities of the ASN, CSN, or MS. Those reference points, also depicted in Figure 3, are summa-rized in Table 1.

Finally, interworking is supported for providing com-mon billing or accounting and intertechnology handovers that guarantee service continuity among WiMAX and incumbent mobile network operators, given that multi-mode subscriber devices exist. By the current release of NWG Stages 2 and 3 [7], [8], WiMAX interworking with 3GPP (UMTS) networks is proposed in accordance to the 3GPP-WLAN interworking paradigm [11], [12]. <AU: Please spell out UMTS.> More recently, 3GPP has facili-tated the interworking with WiMAX by standardizing the evolved packet core (EPC) network architecture [13]. In-terworking with 3GPP2 (CDMA 2000) network is facilitat-ed by the fact that both ASN-GW and packet data serving node (PDSN) supports the foreign agent (FA) function-ality as per mobile IP (MIP) [14]. As for the Wi-Fi case, the interoperation is simplified by the fact that both net-works employ common IETF-based protocols for trans-port, mobility, security, and connectivity. Finally, for the wired case, e.g., DSL, the interworking can be achieved at various stages of the DSL end-to-end network (e.g., T, A10, and V interfaces [15]) since NAP, NSP, and ASP have

almost the same role to the DSL architecture as in WiMAX. In all the above-mentioned sce-narios, the ASN-GW plays a remarkable role in controlling the interconnections.

ASN Functionality

The ASN provides means to connect mobile subscribers using an OFDMA-based air link to an IP-based backbone. ASN comprises BSs and ASN-GWs. The WiMAX BS is defined as a logical entity that embodies a full instance of the WiMAX MAC and PHY in compliance with the IEEE 802.16 standards suite and may host one or more ASN functions, includ-ing handoff triggering and tunnel establish-ment, radio resource management (RRM), QoS policy enforcement, traffic classifica-tion, DHCP proxy, key and session manage-ment, and multicast group management. A BS may be connected to more than one ASN-GW if required for load balancing or redun-dancy reasons. On the one hand, the ASN-GW connects to and manages a number of BSs

SS/MS

ASN #1

ASN #2

CSN

CSN

Visited NSP

NSPHome

NAP

BS

BS

BS

BS

ASN-G/W

DecisionPoint

EnforcementPoint

R1

R2

R5

R6

R6

R6

R6

R6

R4

R4

R7

R8

R8

R8

R8

R3

FIGURE 3 WiMAX network reference model.

TABLE 1 WiMAX reference points.

Reference Point

Description End Points

R1 Implements IEEE 802.16e-2005 MS<->BS

R2 Logical interface used for authenti-cation, authorization, IP host con-figuration, and mobility management

MS<-> CSN

R3 Supports AAA, policy enforce-ment, and mobility-management capabilities. Implements tunneling between ASN and CSN

ASN<->CSN

R4 Used for MS mobility across ASNs ASN<->ASN

R5 Used for internetworking between home and visited network

CSN<->CSN

R6 Implements intra-ASN tunnels and used for control plane signalling.

BS<->ASN-GW

R7 Used for coordination between data and control plane in ASN-GW (optional)

ASN-GW (decision) <-> ASN-GW (enforcement)

R8 Used for fast and seamless handover

BS<->BS

IEEE

Proof

JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 5

and coordinate traffic and handoffs among them. On the other hand, it interfaces with other network elements in CSN as described before, i.e., HA, DHCP proxies and servers, AAA proxies and servers, etc., to provide seam-less mobility to the users.

According to WiMAX forum specifications, the ASN will provide a large set of network functions, which are destined to the provision of optimized access to a WiMAX subscriber, and can be summarized as follows.

Network Discovery and SelectionAs the MS will operate in a diverse environment, where multiple network and service providers are available and candidate of being selected, the WiMAX standard defines a four-step procedure to facilitate the operations. The procedure is applicable to the first time use, initial net-work entry, network reentry, or when an MS transitions across NAP coverage areas. The MS first discovers all the NAPs in the coverage area. The MS then discovers all NSPs that advertising their service offering via the avail-able networks. In the sequel, the MS enumerates and selects either automatically (by means of stored configu-ration information) or manually (by user assistance) an NSP. Finally, the MS indicates its selection by attaching to an ASN associated with the selected NSP and by provid-ing its identity.

IP Address AssignmentBoth static and dynamic IP addresses may be assigned also depending on the usage type (fixed, nomadic, por-table, or mobile). Static IP addresses may be assigned by manual provisioning in the MS or via DHCP, while dynam-ic IP addresses are based on DHCP. The related function-al entity residing in ASN may be either a DCHP relay or a DCHP proxy. DHCP relay is used when MS initiates DHCP and address need to be retrieved from DHCP server in CSN. DHCP proxy is used when MS initiates the DHCP and address is available during authentication from AAA server. In mobile situations and in cooperation with mobility management functions, IP addressing is based either in DHCP or on MIP procedures defined in IETF’s RFC 3344 [14].

Authentication and Security ArchitectureThe authentication and security architecture supports the IEEE 802.16e security services [16], with an extensible authentication protocol (EAP)-based [17] AAA framework [18]. WiMAX uses EAP for authentication and key distri-bution. Both device and user authentication are support-ed with various EAP types like password, certificate or SIM-card based, and by using various credentials, such as preprovisioned secret keys, SIM/USIM cards, or X.509 cer-tificates. <AU: Please spell out SIM and USIM.>

In brief, MS initiates EAP exchange to establish au-thenticated session and associated key material, the

ASN forwards the request from the MS to AAA serv-er, and, after receiving the AAA server’s response, it establishes the service and informs the MS. Privacy key management version 2 (PKMv2) is used to transfer EAP messages in the air link between MS and BS. The authentication relay in BS acts as an EAP proxy that relays this EAP messages to the authenticator via an authentication relay protocol. Authenticator is in ac-cordance to EAP specifications. AAA client, being part of the authenticator, forwards EAP messages to AAA server in the CSN over Radius [19] (or Diameter [20]) protocol. After successful EAP exchange, security keys, including the authentication key, are either fetched or locally derived in MS, ASN entities, and AAA server. Key distributor is responsible for holding those keys, and the key receiver holds the authentication key and generates appropriate 802.16e keys. Figure 4 shows the authentication relay procedure.

AccountingAccounting function is used to observe and collect net-work resource usage information and assist in proper charging. In case of offline accounting, the user will not be charged while being served, but duration-based charging information is generated based on resource usage and stored. In online accounting, the user is continuously monitored against its remaining credits provided by an AAA server. Once his or her prepaid balance expires, permission of service must be withdrawn. An accounting client is the responsible functional entity in the ASN.

QoS ArchitectureThe IEEE 802.16e-2005 [4] focuses on the radiolink con-nection and defines a QoS framework providing connec-tion-oriented service, data delivery service classes for real, nonreal, and best-effort traffic, provisioned QoS parameters for each subscriber, and a policy requirement for admitting new service flow requests. Each subscrip-tion is associated with a number of service flows with specified QoS parameters, e.g., max/min/average traffic rate, which are provided in a policy database and may be both static and dynamic, i.e., with the capability to be dynamically created, modified, or deleted (not included in current release).

SS/MS

BS

ASN

ASN G/W

AuthenticationRelay (EAP Relay)

AuthenticationServer (AAA)

Authenticator(AAA Client)

EAP/PKMv2

EAP/AuthenticationRelay Protocol

EAP/Radius

FIGURE 4 Authentication relay procedure.

IEEE

Proof

6 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | JUNE 2009

The WiMAX QoS architecture in NWG specifica-tion expands the QoS framework defined in [4], [21]. In particular, it provides the functionality to support both per user (coarse-grained) and per service flow ( fine-grained) QoS levels, admission control and band-width management. It also supports a policy-based QoS framework for provisioning QoS policies and managing policy decision and enforcement operations according to SLAs and by using IETF protocols.

The main ASN functional entities of this QoS architec-ture, also shown in Figure 5, include 1) the service flow management (SFM), which is located in the BS and is re-sponsible for performing the admission control function and managing the creation, admission, activation, modifi-cation, and deletion of 802.16e service flows and 2) the ser-vice flow authorization (SFA) entity, the role of which is to evaluate incoming service requests against the user QoS profile and decides upon admittance of the flow. The SFA acts by interacting with synergetic functions that reside in the CSN and include among other the policy function (PF) containing the NSP’s application-dependent policy rules and the AAA server that stores user QoS information. It communicates with PF in CSN using AAA infrastructure, e.g., for receiving service flow establishment requests and for mapping to 802.16e format. The SFA may in turn act by its own using a local policy database and local PF.

Obviously, the scope of the above-mentioned WiMAX QoS procedures focuses on the radio link. To be able to guarantee end-to-end QoS, WiMAX QoS architecture must be studied in concurrence with the evolution of QoS mechanisms and technologies in IP networks. This state-ment can be justified by the fact that WiMAX is expected to use an IP core network for the conveyance of end-to-end IP services. Therefore, to optimize the end-to-end QoS in terms of availability, throughput, packet loss, de-lay, and jitter, and thereupon increase the performance perceived by a user, efficient QoS mechanisms should

be mobilized. As an example, we dis-tinguish and just mention the three most prominent IP QoS mechanisms ascribed to IETF: integrated services (IntServ) [22] is a mechanism that as-sumes prereservation of resources, whereas mechanisms like differen-tiated services (DiffServ) [23] and multiprotocol label switching (MPLS) are based on prioritization of cer-tain services or users. All in all, QoS treatment in the fixed part of the ac-cess and core networks may require specific layer-2 and layer-3 interfaces with ASN elements, thus calling for various implementation choices.

Mobility ManagementThe deployment of mobile WiMAX is

unbrokenly related to the efficiency of the defined mobili-ty-management mechanisms. WiMAX mobility manage-ment is actually a hard optimization task that aims at the minimization of several parameters like, signaling, packet loss, and handoff latency, in parallel with providing advanced mechanisms like buffering or bicasting, for ensuring in-order packet delivery even at vehicular speeds and in compliance with the EAP-based security architecture. Figure 6 highlights the various handover scenarios supported by WiMAX network.

Two types of mobility are defined: 1) ASN-anchored mobility and 2) CSN-anchored mobility. ASN-anchored mobility covers the handoff of an MS between a serving BS and a target BS (in the same or different ASN), without changing the traffic anchor point, i.e., the FA of the MS in the serving (also anchor) ASN. This case is illustrated by moves 1−>2 and 1−>3 in Figure 6. In 1−>2, the MS is handed over from BS#1 to BS#2 by migrating R6 reference point as it moves to the right, whereas R8 may be used for convey-ing undelivered packets after handover. Similarly, while moving from 1 to 3, MS is handed over to BS#5 with no change in the anchor FA but with the use of tunneling over R4 for the packet data delivery. In both cases, the han-dover may be initiated either by the MS or the network.

Three basic functions need to cooperate to accom-plish the task of ASN-anchored mobility according to WiMAX forum: data path function (DP function), hand-off function (HO function), and context function. The DP function is responsible for managing the establishment of bearer paths needed for data packet transmission between entities involved in a handover. This may also include tunneling support for packet forwarding and special procedures like buffering or bicasting. The HO function is responsible for making the HO decisions and performing the signaling procedures related to the han-dover. Last but definitely not least, the context function

FIGURE 5 QoS functional architecture.

SS/MS

R1 R6

R3

Service FlowManagement(Admission

Control)

ServiceFlow

Authorization

Resource InfoDatabase

LocalPolicy

Database

PolicyDatabase

AAA/QoS

ProfileCSNASN

PolicyFunction

802.16eQoS

IP QoS Domain(e.g., Diffserv)

IEEE

Proof

JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 7

is responsible for the exchange of state information among the network elements impacted by a handover, i.e., MS, old and new BS, while guaranteeing minimum data loss and delays.

CSN-anchored mobility refers to a set of procedures for changing the MS’s traffic anchor point in the ASN, i.e., the FA, without changing the CSN anchor point. This is covered by move 1−>4 in Figure 6. The handover actu-ally takes place through the R3 reference point through which the new FA and CSN exchange signaling messages for DP establishment. CSN-anchored mobility uses the MIP protocol for IP-layer mobility management [14]. Two different, mandatory MIP implementations are defined for supporting CSN-anchored mobility: 1) Client MIP re-quires the MS to have a MIP client implemented in its stack and 2) a proxy MIP [24] in the ASN undertakes the responsibility of performing MIP operations on behalf of the MS. In the second case, a proxy-MIP client is required to be located in the ASN along with the FA.

Last, mobility-management functions should be also able to handle intertechnology handover situations. This is illustrated in Figure 6, move 1−>5 where the procedure involves interactions with system entities defined in other technology systems.

Radio Resource ManagementThe objective of RRM functionality in the ASN is to maxi-mize the efficiency of radio resource utilization be means of measuring and estimating, exchanging and controlling the appropriate, standardized radio resource-related indicators (e.g., measuring and report-ing the BS’s spare capacity for adjusting the handover or load-balancing decisions).

It is important to state that the implementation of RRM functions in WiMAX ASN is optional for two reasons: 1) each BS executes by its own many RRM tasks without the need to interact with other RRM functional entities in the ASN and 2) RRM signaling can be incorporated in control messages exchanged by other related QoS and handover management functions.

RRM function is decomposed into two functional enti-ties in the WiMAX architecture: the radio resource agent (RRA) and the radio resource controller (RRC). In brief, the RRA is located in BS and is responsible for collecting and measuring radio resource indicators, for local radio resource control and for communicating, when needed, with the RRC. The RRC residing in each BS, ASN-GW, or as a stand-alone server in the ASN is responsible for collect-ing the radio resource indicators from the various RRAs attached to it and communicating with other RRC(s).

Paging and Idle-Mode OperationFor power saving and resource conservation reasons, the MS in mobile WiMAX may go to idle mode, during which it is able to receive broadcast transmissions from

BS, without being involved in an active session. For idle-mode operation, BSs are assigned to paging groups. Each MS belongs to a paging group [4] depending on its location. Efficient location management, including loca-tion registration and location update procedures, and wise division of coverage area into paging areas and groups ensures that a MS will be always correctly paged, assists in the avoidance of flooding of certain BSs with overhead paging messages, and also facilitates the deliv-ery of location-based services. Support for paging and idle-mode operation are optional for nomadic and porta-ble but mandatory for mobile usage models.

Paging comprises the following functional enti-ties: 1) the paging controller (PC) is a functional en-tity that administers the activity of idle-mode MS in the network. Each idle-mode MS requires a so-called anchor-PC, which always contains updated location information. Additional relay PCs may be used for relaying paging and location management messages between the paging agent (PA) and the anchor PC; 2) the PA is a BS functional entity that handles the inter-action between the PC and paging-related functions specified in IEEE 802.16e; and 3) the location register (LR) is a distributed database that contains informa-tion about the idle-mode MSs and with one-to-one association to an anchor PC. Figure 7 highlights the paging operation when the PA is located across R6 ref-erence point from the PC.

CSN

ASN Anchored Mobility–Unchanged Anchored FA (R6/R8)

ASN Anchored Mobility–Unchanged Anchored FA (R4)

CSN Anchored Mobility–Changed FA (R3)

Intertechnology Handover

GWGWR3 R3

R4

R6

R1

BSC/RNC/aGW

ASN

R8

R1 R1

MS MS MS MS

BS #1 BS #3 BS #4

ASNGW #1

(FA)

ASNGW #2

(FA)

1

1

1

1

1

2

2

3

3

4

4

5

5

Home Agent (HA)

OtherTechnology

NSP

IP IP

BS #2 BS #5 BS/NodeB/eNB

FIGURE 6 Mobility handover scenarios.

IEEE

Proof

8 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | JUNE 2009

ASN ProfilesThe described ASN functionality is distributed between BS(s) and ASN-GW(s) according to certain profiles. Three different profiles (A, B, and C) are defined in the specifications [7] depending on the way they divide the functionality of the ASN between BSs and the ASN-GWs. In Profile B, ASN functions are crowded within the same system entity, the BS No ASN-GW and R6 interface exist and thus, it reflects the flat and distributed solution model. <AU: Can the “No” in the sentence beginning with “In profile B, ASN...” be changed to “number”?> In Profiles A and C, ASN functions are split among ASN-GW and BS. Their main difference lies within the way that the mobility and radio resource-related manage-ment functions are distributed between ASN-GW and BS. In Profile A, the ASN-GW is the entity that controls the radio resource management and handover procedures, whereas this task shifts to the BS in Profile C.

ASN-GW Functional Decomposition

and Implementation Issues

This section discusses on requirements and challenges for developing a competitive, standards’ compliant ASN G/W. The ASN G/W can be seen as the natural evo-lution of other legacy, access GWs, usually met in both wired and wireless communication systems (e.g., BSC, RNC, BRAS, etc.) and is the main new component that is introduced for making WiMAX, a complete system capable of global roaming and interworking with the wireless world. In the analysis, distinction among data, control, and management planes is used as a familiar way in telecommunication standards for encapsulating functionality.

Data PlaneThe appropriate functions of the data plane subsystem can be summarized as follows.

Tunneling includes 1) generic routing encapsulation ■

(GRE) encapsulation-decapsulation [25], which is used for tunneling the data traffic in the R6 and the R4 reference points and 2) IP over IP encapsulation–decapsulation, which is the proposed tunneling meth-od for data traffic over the R3 reference point, with GRE being also an option.Packet classification can be performed in different ■

stages, e.g., first distinguish the control from data traf-fic, second to perform GRE (or IPoverIP) classification, and third to perform inner packet classification.QoS marking ■ of data packets is needed after classifica-tion to allow per flow QoS discrimination for the assignment of the appropriate traffic handling policies including, i.e., congestion management and bandwidth allocation.Traffic management ■ is needed for switching or rout-ing traffic between MS (R6), CSN (R3), and other ASN-GWs (R4).Accounting support needs to be supported for user ■

data packet or octet counting.Handover support ■ can assist handover optimizations, such as bicasting and buffering.Security, e.g., with IPsec or SSL, VPNs, etc., is needed ■

for end-to-end security and privacy in R6 and R4.

Control PlaneWhile the data plane seems more like an artistic stoke of the brush, which is more or less based on inherited knowledge and experience from past pack-

et processing implementations, the control plane needs to adhere more on the WiMAX speci f icat ions. Accordingly, in Figure 8, a generic block diagram for the ASN-GW con-trol plane is shown. The block dia-g r a m p ro p o s e s a p ro p o s e d , possible decomposition of the main ASN-GW control plane functionality into various software modules par-ticipating in one or more WiMAX functions presented in the previous section. This block diagram has been constructed having in mind profiles A and C. Functional enti-ties in the BS are also depicted for clarity reasons.

The ASN-GW control plane (sig-naling) protocols may be classified into those that can be referred to as “WiMAX specific,” and those that are mainly based on IETF protocols.

R3

R6R6 R6 R6 R6

R4

LocationRegister

LocationRegister

Relay PagingController

PagingAgent(PA)

PAPA

PAPA

BS #5BS #4

BS #3BS #2

BS #1

Paging Group A Paging Group B

Paging Data

Incoming Data for MS

Paging Group CMS

Anchor PagingController

ASN GW #2ASN GW #1

HA

FIGURE 7 Paging operation.

IEEE

Proof

JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 9

WiMAX Specific ModulesThe DP module is needed for setting up user data bearer in the user DP and track session information on this path. It will be responsible for managing the creation and deletion of GRE tunnels in the respective R6/R4 reference points and for switching traffic from GRE tunnels to IP-in-IP (MIP) tunnels (R3). It may support both IP and Ethernet payloads bearer [7]. It will be also used to support handover functionality in terms of relaying paths to other ASN-GWs (R4) and might be also used to assist handover optimization by offering bicast-ing and buffering capabilities.

The session management module holds the context function for creating, deleting, modifying, and reading the MS context. It will be also responsible for transferring con-texts to and from ASN GWs/BS. MS context must be kept in failure safe memory areas. It also holds the HO function that controls handovers in both ASN- and CSN-anchored mobility cases. In the former case, it will be responsible for selecting the target BSs from a candidate list, propa-gated via HO messages, negotiate the HO, and finally se-lect the target BS. In the latter case, it will handle probable FA change. It also collaborates with DP function for config-uring the user DP, in case bicasting and buffering capabili-ties are offered to optimize the HO procedure.

The authentication and security module implements functionality pertinent to authentication and security. It contains authenticator or AAA client and key distributor as described earlier.

The accounting module is responsible for the account-ing procedures based on AAA protocol. (Interface with AAA client is needed.) It will offer both offline (postpaid), where accounting user is charged based on generated and stored duration information, and online (prepaid) ac-counting, where user is continuously monitored against its remaining credits and he or she is denied to be served once he or she consumes its prepaid balance.

The main part of the QoS module is the SFA, of which mainly responsibility is the admission control based on local policies and resource availability. It is also respon-sible for handling (creating/modifying/deleting) static and dynamic service flows, acquiring (through AAA cli-ent) policies stored in the HAAA, performing local policy enforcement (using a local-policy database and an asso-ciated local-PF), and DP preregistration and prederegis-tration in association with HO function.

The RRM module is represented by the RRC when in Profile A or by the RRC relay when in C and is needed to as-sist WiMAX functions, which impact radio resources. This

FIGURE 8 Control plane functional blocks and modules (A or C profile).

BS

R6

ASN GW

QoS Module RRM Module

Service FlowAuthorization

RRC orRRC Relay

Location Update/Paging Module

Routing Module

Accounting Module

AccountingClient

LocationRegister

PagingController

Authentication and Security Module

Session Management Module Data Path Module

Data PathFunction

HandoverFunction or

Relay

ContextFunction

IP Addressing Module

DHCPProxy/Relay

Proxy-MIP Client Proxy/Relay ARPModule

DNS

R4

R3

Foreign Agent

MIP

KeyDistributor

Authenticator

AAA Client(RADIUS/DIAMETER)

Multicast/BroadcastControl Module

AuthenticationRelay

KeyReceiver

RRA

RRC orRRC Relay

Data PathFunction

ContextFunction

HandoverFunction or

Relay

Service FlowManagement

IEEE

Proof

10 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | JUNE 2009

module will be responsible for collecting radio resource indicators from the controlled BSs, to maintain a local ra-dio resource database and, accordingly, to assist WiMAX functions which impact radio resources, e.g., QoS, service flow admission control, mobility management, etc.

The location update or paging module is needed for paging and idle-mode operation of MS. It will implement the PC entity that handles one or more paging groups, connects to other PCs in the network, triggers the PAs in BS(s), and updates LR whenever MS moves in and out of IDLE mode or when MS updates its own location. The LR will be a distributed database containing information about the idle-mode MSs.

IETF Based and Other Communications ModulesThe IP addressing module is needed for managing the IP address configuration for MS. For that reason, the module implements DHCP relay or a DHCP proxy functionality. It also hosts MIP submodule exhibiting proxy-MIP and FA functionality for mobility support.

Additional modules, depicted in Figure 8, are required for providing DNS support, routing and packet forward-ing support, MS identity hiding by means of proxy and relay ARP or multicast–broadcast control.

Management PlaneAs in any network deployment, an operations, administra-tion, maintenance, and provisioning (OAM&P) is needed to enable the automation of network operations and busi-ness processes that are critical to WiMAX deployment. Being interested here for the management and configura-tion of the ASN-GW node per se, the ASN-GW management plane has to take care of both management functions related to the system as a whole and functions related to resources and parameters residing in the control and user data planes. What is described herewith actually com-prises a vendor-specific element management system (EMS) for managing the ASN-GW network element. It will allocate functionalities falling into fault, configuration, performance, and security management functional areas as per ITU-T recommendation in [26], while also interfac-ing with a service provider’s network management sys-tem (NMS). <AU: Please spell out ITU-T.>

Fault management is needed for alarm surveillance, cor-relation and filtering, with causal reports and definitions of different levels of alarms’ severity, fault detection, isola-tion and testing, and for forwarding the alarms to NMS.

Configuration management will be responsible for the starting up and configuration of the ASN-GW. It is impor-tant for managing resources and services availability, for properly configuring thresholds and system-specific pa-rameters, e.g., DHCP server, AAA server, etc., and to per-form software upgrades and system backup/restores.

Performance management is needed for monitoring traffic load, delays, errors, etc. and for deriving data

statistics for obtaining insight to the behavior and effec-tiveness of the ASN-GW.

Security management will address issues concern-ing the controlled access to system resources, facilities and information, the logging of security events and the protection of the managed system against intentional or accidental abuse, unauthorized access, and communica-tion loss. Note that this is independent of the subscriber authentication described previously in the “Authentica-tion and Security Architecture” section.

Deployment ChallengesApart from satisfying the major requirements of the ASN functionality that the specifications define, the strategic location, which the ASN-GW holds within the WiMAX net-work, calls for addressing some raising challenges with the list not being exhaustive: the increased traffic that WiMAX has to convey calls for ensured capacity to sup-port subscribers and target system throughput and might be realizable in terms of anticipated high-speed proces-sors with certain amount of memory and several data plane hardware components. Specialized traffic control mechanisms such as load balancing are also required for optimizing capacity and spectrum allocation and can be easily provided by the ASN-GW, which has the whole pic-ture of network resource consumption. Scalability is also needed to care for possible network growth.

Fault tolerance and reliability, in “five nines” if pos-sible, should also be taken into account seriously and could be achieved by redundant hardware for both data and control planes (redundancy of management plane is a side issue). Alternatively, in case of some hardware fail-ures, traffic and context redistribution among the rest healthy hardware elements could also be an option.

In addition, a great challenge when envisioning the design and development of an ASN-GW is the ability of high-speed packet handling. Obviously, functions such as classification, filtering, tunneling, routing, encryption, etc. call for highly intensive packet processing that needs to be implemented on hardware, e.g., network proces-sors (NPs) or field-programmable gate arrays (FPGAs).The control plane, on the other hand, is more about an issue of developing well-designed and robust software to efficiently control data plane behavior. Anyway, perfor-mance efficiency requires that data and control planes should be in tight coordination.

What Is Next? The Way Forward

It must be noted that even though the above-mentioned analysis corresponds to the current release of WiMAX Forum NWG specifications [7], [8], the next release of the standard, namely Rel 1.5, is expected by the end of 2008 or early 2009 and will provide amendments to the ASN network architecture and baseline functionality described in this article. More specifically, the next release of NWG

IEEE

Proof

JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 11

Stages 2 and 3 specifications, also according to [27], will place focus on

1) specifying the requirements for the WiMAX network to support multicast–broadcast services (MCBCS)

2) extending handover data integrity including, among others, techniques such as buffering and bicasting that were mentioned earlier

3) preparing the WiMAX network for lawful interception purposes, thus capturing the need to intercept traffic and related information, while being in compliance with national or regional laws and regulations

4) providing emergency calls or services by incorporat-ing location information, e.g., global positioning sys-tem (GPS) assisted

5) amendments to the WiMAX network for exploiting location capabilities and information to be used to enable location based services, support for emergen-cy calls, lawful interception mechanisms, and assist location-based handovers, and traffic and coverage measurements

6) amendments to support simple IP networks, i.e., referring to a service in which no MIP-based network elements and thus no HAs are required (fixed WiMAX)

7) specifications for over-the-air (OTA) provisioning based on TR-069 protocol [28] for configuring, acti-vating, enabling subscription for, and managing a great variety of device types

8) amendments pertinent to architecture and proce-dures regarding robust header compression (ROHC) function of WiMAX network, which is located in the ASN-GW and aims at compressing and decompress-ing the IP headers

9) specifications for the policy and charging control (PCC) framework for WiMAX with the aim to allow applications to dynamically request QoS and charg-ing attributes for a specified IP flow, in accordance to the respective PCC solution of 3GPP Rel. 7

10) interworking issues and especially on dual-mode devices able at operating in both WiMAX and cdma2000 technologies

11) specifications for a universal services interface (USI), which is a framework for defining required WiMAX network interfaces toward trusted third party ASPs and Internet-ASPs and is intended to propose a solu-tion for service providers to generate additional rev-enue, to enable Internet-ASP for dynamic service creation and to reuse WiMAX network intelligence provided, e.g., by LBS, MCBCS, PCC.

Discussion and Conclusions

WiMAX is a revolutionary technology that aims at fill-ing the gaps of the Internet. To achieve this goal, signif-icant proportion of attention must also be dedicated to network beyond the radio link. What WiMAX can be

certainly proud of, within a fiercely competitive busi-ness environment, is a well-defined, open, and intoper-able network architecture beyond the radio link, in particular in the ASN. A key element of the ASN is the ASN-GW that is expected to play a crucial role in accommodation of the increased number of mobile Internet users in the future.

In this article, we presented an overview of the WiMAX network architecture. We also exemplified the important role of the ASN functionality and the way it is decomposed to support IP-based intensive applications with adequate QoS and at increased speeds. Finally, we discussed on issues regarding the ASN-GW’s critical role within the WiMAX network.

We conclude by discussing a little bit on the no-torious battle toward the wireless broadband prize. Even if current cellular 3G operators will need to de-vote less effort at convincing their customers about the advent of next-generation wireless services via their mobile phone, a revolting experience of WiMAX users relishing high-speed Internet connections at home or office using a fixed device, while roaming to mobile Internet when away from home or office us-ing a mobile device, is expected to show up earlier. This is ascribed to a well-placed combination of fixed and mobile WiMAX with the presence of the ASN-GW. Specifically, WiMAX networks exhibit much less hier-archy than 3G networks do, because of the concen-tration of a far greater functionality at ASN-GW. This also results in minimized need for new software and hardware and, thus, reduced CAPEX/OPEX. Further-more, the ASN-GW’s flexibility at performing easier and quicker upgrades will help WiMAX networks to follow the changing business goals. Finally, the ex-istence of ASN-GW will support the need for hetero-geneous WiMAX implementations with various cell sizes, types, and radio nodes. In conclusion, the pres-ence of an adaptable, flexible, and full-featured ASN-GW comprises at the moment the basic advantage of WiMAX in the fourth-generation (4G) race with other high-speed alternative technologies.

AUTHOR INFORMATION

<AU: Please provide short biographies of each author.>

References[1] “Evolved universal terrestrial radio access (UTRA) and universal

terrestrial radio access network (UTRAN) radio interface protocol aspects,” 3GPP TR25.813, Nov. 2005.<AU: Please provide the author names and publisher and the location.>

[2] WiMAX Forum WiMAX Technology Forecast (2007–2012) [Online]. (Aug./Sept. 2008). Available: http://www.wimaxforum.org/docu-ments/downloads/wimax_forum_wimax_forecasts_6_1_08.pdf<AU: Please provide the complete list of author names.>

[3] IEEE Standard for Local and Metropolitan Area Networks – Part 16: Air Interface for Fixed Broadband Wireless Access Systems, Oct. 1, 2004.<AU: Please provide the Standard number, if possible.>

[4] Amendment to IEEE Standard for Local and Metropolitan Area Net-works – Part 16: Air Interface for Fixed Broadband Wireless Access Sys-tems – Physical and Medium Access Control Layers for Combined Fixed

IEEE

Proof

12 ||| IEEE VEHICULAR TECHNOLOGY MAGAZINE | JUNE 2009

and Mobile Operation in Licensed Bands, IEEE Standard 802.16e–2005, Dec. 7, 2005.

[5] IEEE 802.16 Relay Task Group. (2007 May). “Draft standard for lo-cal and metropolitan area networks – Part 16: Air interface for fi xed and mobilebroadband wireless access systems, multihop relay speci-fi cation [Online].” IEEE 802.16j-06/026r4. Available: http://ieee802.org/16/relay/docs/80216j-06_026r4.zip

[6] (2006 Nov.). “Draft IEEE standard for local and metropolitan area networks – Part 16: Air interface for fi xed and mobile broadband wire-less access systems – Advanced air interface [Online].” IEEE 802.16m. Available: http://standards.ieee.org/board/nes/projects/802-16m.pdf<AU: Please provide the author names.>

[7] WiMAX Forum, “WiMAX end-to-end network systems architecture – Stage 2: Architecture tenets, reference model and reference points,” Release 1, Version 1.2, Jan. 2008.

[8] WiMAX Forum, “WiMAX end-to-end network systems architecture – Stage 3: Detailed protocols and procedures,” Release 1, Version 1.2, Jan. 2008.

[9] A Farpoint Group White Paper, “Completing the 4G vision: Gateways for mobile WiMAX,” Sept. 2007.<AU: Please provide the publisher and location. Also, check whether the reference is OK as edited.>

[10] J. G. Andrews, A. Ghosh, and R. Muhamed, Fundamentals of WiMAX: Understanding Broadband Wireless Networking — The Definitive Guide to WiMAX Technology. Englewood Cliffs, NJ: Prentice-Hall, Feb. 2007

[11] 3GPP TS 23.234 V6.5.0 (2005–06). “3GPP system to wireless local area network (WLAN) interworking; system description (Release 6).”<AU: Please provide the author names, and the publisher or url details.>

[12] 3GPP TS 33.234 V6.5.1 (2005–06). “Wireless local area network (WLAN) interworking security (Release 6).”<AU: Please provide the author names, and the publisher or url details.>

[13] 3GPP TS 23.402 V8.3.0 (2008–09). “Architecture enhancements for non-3GPP accesses (Release 8).”<AU: Please provide the author names, and the publisher or url details.>

[14] C. Perkins, “IP mobility support for IPv4,” RFC 3344, IETF, Aug. 2002.<AU: Please provide the location.>

[15] Broadband Forum. “DSL evolution – Architecture require-ments for the support of QoS-enabled IP services,” TR-059, Sept. 2003.<AU: Please provide the publisher bringing out this Forum and its location.>

[16] K. Lu, Y. Qian, and H.-H. Chen, “Wireless broadband access: WiMAX and beyond – A secure and service-oriented network control frame-work for WiMAX networks,” Commun. Mag., vol. 45, no. 5, pp.124–130, May 2007.

[17] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz, “Extensible authentication protocol (EAP),” RFC 3748, IETF, June 2004.<AU: Please provide the location.>

[18] J. Vollbrecht, et al., “AAA authorization framework,” RFC 2904, IETF, Aug. 2000.<AU: Please replace et al. with the complete list of author names. Also provide the location.>

[19] B. Aboba and P. Calhoun, “RADIUS (Remote Authentication Dial In User Service) support for extensible authentication protocol (EAP),” RFC 3579, IETF, Sept. 2003.<AU: Please provide the location.>

[20] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko, “Diam-eter base protocol,” RFC 3588, IETF, Sept. 2003.<AU: Please provide the location.>

[21] C. Cicconetti, L. Lenzini, E. Mingozzi, and C. Eklund, “Quality of ser-vice support in IEEE 802.16 networks,” IEEE Networks, vol. 20, no. 2, pp.50–55, Mar.–Apr. 2006.<AU: Please check whether the reference is OK as edited.>

[22] R. Braden, D. Clark, and S. Shenker, “Integrated services in the In-ternet architecture: An overview Internet architecture: An overview,” RFC 1633, IETF, June 1994.<AU: Please provide the location.>

[23] K. Nichols and B. Carpenter, “Defi nition of differentiated services per domain behaviors and rules for their specifi cation,” RFC 3086, IETF, Apr. 2001.<AU: Please provide the location.>

[24] K. Leung, G. Dommety, P. Yegani, and K. Chowdhury, “Mobility management using proxy mobile IPv4,” IETF draft: draft-leung-mip4-proxy-mode-02.txt, Jan. 2007.<AU: Please provide the location. Also check whether the reference is OK as edited.>

[25] D. Farinacci, et al., “Generic routing encapsulation (GRE),” RFC 2784, IETF, Mar. 2000.<AU: Please provide the location and also pro-vide the complete list of author names.>

[26] (2000 Feb.). “TMN management functions.” ITU-T M-3400.<AU: Please provide the author names and further details (publisher and location or url) regarding this reference.>

[27] WiMAX Forum, “Recommendations and requirements for networks based on WiMAX Forum certifi ed™ products,” Release 1.5, July 10, 2008.

[28] DSL Forum. (2007 Dec.). “CPE WAN management protocol v1.1,” TR-069 Amendment 2. [Online]. Available: http://www.dslforum.org

IEEE

Proof

JUNE 2009 | IEEE VEHICULAR TECHNOLOGY MAGAZINE ||| 13

THE NAP IS THE ENTITY THAT OWNS AND OPERATES THE ACCESS NETWORK PROVIDING THE RADIO ACCESS INFRASTRUCTURE TO ONE OR MORE NSPS.

A HOME NSP MAINTAINS SERVICE-LEVEL AGREEMENTS, AUTHENTICATES, AUTHORIZES, AND CHARGES WIMAX SUBSCRIBERS.

3GPP HAS FACILITATED THE INTERWORKING WITH WIMAX BY STANDARDIZING THE EVOLVED PACKET CORE NETWORK ARCHITECTURE.

DHCP RELAY IS USED WHEN MS INITIATES DHCP AND ADDRESS NEED TO BE RETRIEVED FROM DHCP SERVER IN CSN.

DHCP PROXY IS USED WHEN MS INITIATES THE DHCP AND ADDRESS IS AVAILABLE DURING AUTHENTICATION FROM AAA SERVER.

ACCOUNTING FUNCTION IS USED TO OBSERVE AND COLLECT NETWORK RESOURCE USAGE INFORMATION AND ASSIST IN PROPER CHARGING.

THE DP FUNCTION IS RESPONSIBLE FOR MANAGING THE ESTABLISHMENT OF BEARER PATHS NEEDED FOR DATA PACKET TRANSMISSION BETWEEN ENTITIES INVOLVED IN A HANDOVER.

IEEE

Proof