Download pdf - WiMAX-VPON: A Framework of Layer-2 VPNs for Next ...ad57/documents/WiMAX... · Layer-2 VPNs for Next-Generation Access Networks ... Abstract—This paper proposes WiMAX-VPON, a

400 J. OPT. COMMUN. NETW./VOL. 2, NO. 7 /JULY 2010 Dhaini et al.

This article has been accepted for inclusion in a future issue of this journal. Content is final as presented.

WiMAX-VPON: A Framework ofLayer-2 VPNs for

Next-Generation Access NetworksAhmad R. Dhaini, Pin-Han Ho, and Xiaohong Jiang

bsWcbtwccnttmstsahpn

piitstflt(t

A

aicp

pg

Abstract—This paper proposes WiMAX-VPON, anovel framework for establishing layer-2 virtual pri-vate networks (VPNs) over the integration of WiMAXand Ethernet passive optical networks, which haslately been considered as a promising candidate fornext-generation fiber-wireless backhaul-access net-works. With WiMAX-VPON, layer-2 VPNs support abundle of service requirements to the respective reg-istered wirelessÕwired users. These requirements arestipulated in the service level agreement and shouldbe fulfilled by a suite of effective bandwidth manage-ment solutions. To achieve this, we propose a novelVPN-based admission control and bandwidth alloca-tion scheme that provides per-stream quality-of-service protection and bandwidth guarantee for real-time flows. The bandwidth allocation is performedvia a common medium access control protocol work-ing in both the optical and wireless domains. Anevent-driven simulation model is implemented tostudy the effectiveness of the proposed framework.

Index Terms—Ethernet PON (EPON); IEEE 802.16(WiMAX); QoS; Virtual private network (VPN).

I. INTRODUCTION

T he massive increase of broadband access applica-tions with varying QoS requirements, such as In-

ternet Protocol television (IPTV) and video on demand(VoD), has significantly contributed to the evolution ofnext-generation wired and wireless networks.

Lately, the integration of Ethernet passive opticalnetworks (EPONs) and WiMAX has been presented asan attractive broadband access network (BAN) solu-tion [1–3]. The complementary features of these net-works has motivated interest in using EPON as a

Manuscript received January 19, 2010; revised May 10, 2010; ac-cepted May 18, 2010; published June 9, 2010 �Doc. ID 122862�.

A. R. Dhaini (e-mail: [email protected]) and P.-H. Ho (e-mail:[email protected]) are with the Department of Electricaland Computer Engineering, University of Waterloo, Canada.

X. Jiang (e-mail: [email protected]) is with the School of SystemsInformation Science, Future University-Hakodate, Japan.

Digital Object Identifier 10.1364/JOCN.2.000400

1943-0620/10/070400-15/$15.00 ©

Authorized licensed use limited to: University of Waterloo. Downloaded on

ackhaul to connect multiple dispersed WiMAX basetations (BSs) [1,4]. More specifically, EPON andiMAX perfectly match in terms of capacity hierar-

hies. EPON, for instance, supports a total of 1 Gbpsandwidth in both downstream and upstream direc-ions, shared by typically N�32 remote optical net-ork units (ONUs) [5]. On average, each ONU ac-

esses �70 Mbps bandwidth, which matches the totalapacity offered by a WiMAX BS over a 20 MHz chan-el as well [6]. The integration can take advantage ofhe bandwidth benefit of fiber communications andhe non-line-of-sight (NLOS) features of wireless com-unications. In addition, it enables integrated re-

ource allocation and packet scheduling paradigmshat help better support the emerging quality-of-ervice (QoS) services, as well as to improve the over-ll network throughput. Finally, the integration canelp realize fixed-mobile convergence (FMC) by sup-orting mobility in the broadband access, thereby sig-ificantly reducing network operational costs [1].

The EPON-WiMAX integration has been well re-orted in the past few years [1,2]. Nonetheless, build-ng up virtual private networks (VPNs) directly on thentegration has never been investigated in the litera-ure to our knowledge. In addition, the already pre-ented upstream bandwidth allocation schemes areoo trivial [2,7–9] and are neither able to provide per-ow QoS protection nor able to offer end-to-end [fromhe subscriber station (SS) to the optical line terminalOLT)] bandwidth guarantee, features that are essen-ial for establishing VPN tunnels over EPON-WiMAX.

. Supporting VPNs Over EPON-WiMAX

VPNs have been known as a superb technology thatre provisioned over a public or third-party networknfrastructure and are positioned to provide dedicatedonnectivity to a closed group of users with a stronger-flow QoS guarantee [10].

VPNs over EPON-WiMAX could be deployed to sup-ort mission-critical (police, health care, fire-fighting)overnmental or corporate systems in order to achieve

2010 Optical Society of America

June 17,2010 at 21:47:06 UTC from IEEE Xplore. Restrictions apply.

TtmmaVvsmbSa

Esb

Dhaini et al. VOL. 2, NO. 7 /JULY 2010/J. OPT. COMMUN. NETW. 401


a secure high-speed and efficient wireless connectivityamong registered users in rural and urban areas.

Building up layer-2 VPNs is most suitable when anEPON-WiMAX integrated network is installed. This isdue to their support for premium services withcustom-designed control, diverse QoS requirements,and security assurance, features that can be intrinsi-cally provided by the layer-2 medium access control(MAC) protocols [11]. Such VPNs are referred to aslayer-2 VPNs in the sense that they are built upon thelayer-2 protocols. Compared with layer-3 [12], layer-2VPNs can do a better job in resolving the complica-tions due to network dynamics, communication mediaheterogeneity, and fast-changing channel status. Thiscan be at the expense of a more complicated designthat considers any possible layer-2 issue. In otherwords, when a layer-3 VPN is installed, a specializedsoftware that forms a control plane [e.g., multiprotocollabel switching (MPLS)] has to be in place instead ofsimply deploying standard IP protocol stacks on top oflayer-2. Alternatively, deploying layer-1 VPNs overthe integration cannot be achieved due the physicalmedia heterogeneity of both networks and because itrequires complex hardware-dependant VPN solutionsthat can operate over both networks simultaneously[13].

For these reasons in this paper, we investigate therealization of layer-2 VPNs over the EPON-WiMAXintegration. To achieve the latter, we propose a novelframework for establishing IEEE 802.16 virtual pri-vate passive optical networks, namely, WiMAX-VPON.

To the best of our knowledge, this is the first workthat considers the support of layer-2 VPNs over EPONor WiMAX networks or over their integration as well.

B. Contributions of This Work

Supporting layer-2 VPNs gives rise to the followingmain resource management challenges that will bethe focus of our study:

• Meeting the QoS requirements of the supportedVPN services.

• Providing guaranteed resources for each service.To resolve these issues, we propose a new VPN-basedadmission control (AC) and upstream/uplink dynamicbandwidth allocation (DBA) paradigm that will pro-vide guaranteed bandwidth for each VPN service.This paradigm will ensure and protect end-to-end per-flow QoS (in both the wireless and optical planes) fornew and existing traffic, respectively, while maintain-ing their expected performance as defined in the ser-vice level agreement (SLA).

More specifically, the contributions of this paper canbe summarized as follows:

1) This paper proposes, to the best of our knowl-


edge, the first framework for supporting layer-2VPNs over the EPON-WiMAX integration.Layer-2 VPNs act as a cost-effective, secure, andflexible link between the underlying fiber–wireless infrastructure and higher-level mission-and business-critical services.

2) This paper presents a new VPN-based QoS pro-visioning framework that enables a robust band-width and QoS assurance for each wireless reg-istered VPN user in the uplink/upstream sharedmedia. From a user perspective, once a VPN tun-nel is established, it is definite that the properresources are reserved for this tunnel and thatits bandwidth is allocated by means of the DBA.

3) Our work differs from previous related work[2,7–9] in that we offer a novel joint VPN-basedAC and DBA scheme that enables an end-to-end(from SS to OLT) QoS guarantee while takinginto consideration the different wireless channelconditions. In other words, our scheme offers arobust bandwidth allocation with a MAC-PHYcross-layer consideration so that the physicallayer (PHY) burst profile is taken into accountrather than relying solely on MAC requests [14].

4) The proposed AC scheme is implemented on athree-stage system, which is involved in the col-laboration among the SS, ONU-BS, and OLT.Such a decentralized AC design reduces the com-plexity and “decision time” of the AC scheme, asopposed to installing it at one end (e.g., theOLT).

5) WiMAX-VPON provides a per-flow QoS protec-tion and bandwidth guarantee for admitted traf-fic. Our simulation results show that in the casewhere no AC is applied, a drastic performancedegradation is witnessed for already admittedand newly admitted VPN services.

he rest of the paper is organized as follows. In Sec-ion II, the different EPON-WiMAX architectures thatay be used for supporting our framework are sum-arized, and the research challenges related to QoS

nd resource management are highlighted. WiMAX-PON is presented in Section III, and its potential ad-antages and the related design issues are demon-trated. The proposed three-stage admission controlechanism is described in Section IV, and the VPN-

ased bandwidth allocation scheme is presented inection V. Section VI presents the performance evalu-tion, and Section VII concludes the paper.

II. EPON-WiMAX-RELATED CHALLENGES

This section briefly overviews the different possiblePON-WiMAX architectures that can be installed toupport our framework. Related challenges such asandwidth allocation and admission control are also


lSbhWtofu

Wssipottticteppms

ditgpIllofioft

A

wlaoldl



discussed while demonstrating how existing schemesare not able to provide any QoS guarantees and henceare not suitable for the support of layer-2 VPNs.

A. EPON-WiMAX Architectures

Several architectures were proposed for the EPON-WiMAX integration [1,2], with a point-to-multipoint(PMP) topology. The disparity between these architec-tures is in the mounting procedure of the EPON’sONU and the WiMAX’s BS.

1) Independent: In this architecture, EPON andWiMAX work independently. As a result, each ONUwould consider a WiMAX BS as an end-user and caninterconnect it through Ethernet (a common sup-ported standard interface).

2) Hybrid: In this architecture, the ONU and BS aremounted in one box, a so-called ONU-BS.

3) Unified Connection-Oriented: The purpose of thisarchitecture is to handle the connection-orientedbandwidth allocation paradigm offered by the IEEE802.16 MAC rather than the queue-oriented one of-fered by the IEEE 802.3ah MAC. This architecturealso recommends the installation of an ONU-BS asone box.

4) Microwave-Over-Fiber (MOF): In this architecture,a “dumb” antenna is connected to the EPON’s ONU,responsible for relaying WiMAX radio signals to andfrom its associated microcell. Here, an optical subcar-rier and another wireless subcarrier are used to trans-fer signals from the wireless to the optical domain.

5) Virtual: Here, a different approach is proposed fordesigning the ONU-BS communication while preserv-ing the current EPON and WiMAX standards [2].Namely, a VOB (i.e., a virtual ONU-BS) is built by in-stalling a network bridge between the ONU and theBS.

Note that a mesh-based EPON-WiMAX architecturemay alternatively be installed to take advantage ofthe multihop routing and relaying capabilities of wire-less mesh networks. Nonetheless, routing and the re-lated challenges are far from the scope of this study.More details on how to perform routing in fiber–wireless mesh-based networks can be found in [15].

One of the powerful advantages of WiMAX-VPON(as we will see later) is that it is designed to be archi-tecture independent. Hence, the decision of selectingany of the described architectures is left to the net-work designer’s preferences. Such a decision could bemade based on the pros and cons of each architectureas detailed in [1–3].

B. Bandwidth Allocation and Admission Control

The integration of EPON and WiMAX networks isexpected to deliver common services with the same


evel of quality and matching performance behavior.uch features can be achieved by manipulating theandwidth allocation and AC schemes. This propertyas been widely investigated in EPON [5,16,17] andiMAX [18] separately, but little work that considers

heir integration has been done. In general, the effortsf bandwidth allocation and admission control mayall in either one of the following categories: (1)pstream/uplink and (2) downstream/downlink.

In the downstream direction, both EPON andiMAX simply broadcast data packets over the

hared media. Previous research efforts on WiMAXcheduling, resource allocation, and admission controln the downstream direction have been extensively re-orted [18], and the additional consideration of EPONn top of WiMAX has not brought up more issues dueo the broadcast-in-nature transmission in both sys-ems. On the other hand, in the upstream direction,he EPON’s ONUs and WiMAX’s SSs launch packetsn the shared media, respectively, and have to be syn-hronized such that the packets can be successfullyransmitted to the corresponding OLT and BS. This isxpected to fundamentally change the nature of theroblem. Therefore, the paper focuses on solutionsertaining to dynamic bandwidth allocation and ad-ission control for EPON-WiMAX networks in the up-

tream direction.

In the past couple of years, some related works ad-ressed the upstream resource management problemn EPON-WiMAX (e.g., [2,7–9]). Nevertheless, none ofhe proposed schemes were able to provide bandwidthuarantees or QoS protection for the incoming flows,roperties that are required for the support of VPNs.n addition, these schemes did not consider the under-ying PHY burst profiling applied on each wirelessink, and so the allocation was based on MAC requestsnly, which makes such an arbitration less meaning-ul [14]. Therefore adopting any of these mechanismss not a viable solution in the context of layer-2 VPNsver the integrated network. Conversely, our proposedramework addresses these issues and provides effec-ive resource allocation solutions.

III. WiMAX-VPON: LAYER-2 VPNS OVER EPON-WiMAX

. Network Model

To support VPN services on EPON-WiMAX net-orks, one approach is to deploy VPNs in the network

ayer (i.e., IP layer) in the ONU-BSs. This is certainlyt the expense of higher control and managementverhead due to the protocol overlay and potentiallyonger delay. A layer-2 VPN over the EPON-WiMAXomain is expected to achieve much more efficient andightweight network management, which is necessary


tflptofcost

B

ttpW

1atgEEdpTtfpcO8tebsupcft

2masqs

wbnpFu



to support a multiservice and multicustomer environ-ment. In the proposed framework, each VPN serves asa shim layer that maps those service requirementsand commands to the MAC layer routing, resource al-location, and AC mechanisms, via a suite of service ac-cess points (SAPs) and primitives. Thus, each VPNcorresponds to a specific service requirement bundlesuch that the users can dynamically configure theirservice requirements. This feature is essential to sup-port stringent bandwidth guarantee and possible ser-vice preemption requests.

Typically, a VPN consists of three planes: 1) control,2) data, and 3) physical. The control plane handles op-erations such as connection establishment, routing,and AC. The data plane is concerned with the band-width management for VPN services and meetingtheir SLA-based QoS requirements. The physicalplane is basically the underlying network infrastruc-ture (here, EPON-WiMAX). The realization of multi-planed VPNs over EPON-WiMAX is illustrated inFig. 1.

With the current heterogeneous Internet and accessnetwork deployment, it is possible that a connectiongoes through multiple VPNs supported by differenttechnologies at different network layers or even anydata path without any QoS protection and class-of-service (CoS) control; however, this paper emphasizes

Fig. 1. Layer-2 VPNs over EPON-WiMAX.


he implementation of layer-2 VPNs in terms of per-ow QoS protection, custom-design network control,erformance parameter selection, and tunneling be-ween nodes at the network boundary. In the contextf EPON-WiMAX networks, the network boundary isormed by the end users and the OLT. A VPN gatewayould be deployed at the OLT so as to interface withther VPNs under some agreements/policies. The de-ign of the VPN gateway and related issues are none-heless out of the scope of this paper.

. System Model

The integration of EPON-WiMAX requires the iden-ification of multiple design and operation themes. Inhis section, we discern these matters in order to com-lete the support of layer-2 VPNs over EPON-iMAX.

) Principle of Operation: EPON supports differenti-ted services (DiffServ), whereas WiMAX supports in-egrated services (IntServ), especially in the case ofrant-per-connection (GPC) mode [6]. Furthermore inPON, incoming IP datagrams are encapsulated inthernet frames according to the IEEE 802.3 stan-ard [19], whereas they are launched as IEEE 802.16rotocol data units (PDUs) in the case of WiMAX [6].herefore to enable a unified connection-oriented con-

rol from the SS to the OLT, and since WiMAX allowsor a finer bandwidth allocation than EPON, we pro-ose to modify the MAC protocol in EPON to supportonnection-oriented requests from the ONU-BS to theLT. This can be implemented by launching IEEE02.16 MAC PDUs encapsulating Ethernet frames inhe optical domain, rather than directly carrying Eth-rnet frames in upstream and downstream frames/ursts of EPON [1]. As a result, the whole integratedystem will support IntServ and can be controlled bynified connection-oriented bandwidth managementrotocols, launching WiMAX PDUs. In addition, noontrol frames will then be required in the Ethernetrame for the bandwidth allocation and network con-rol in the optical domain.

) Wireless Channel Model: The wireless channel isodeled as a Rayleigh fading channel [20] that is suit-

ble for flat-fading channels as well as frequency-elective fading channels encountered with optical fre-uency division multiplexing (OFDM). The receivedignal of an SS n is computed as follows:

rsn = hn�t� � ts�t� + bnn�t�, �1�

here ts�t� is the transmitted signal and bnn�t� is theackground noise at time t. hn�t� is the total instanta-eous channel gain that jointly considers the multi-ath effect, shadowing effect, and path loss exponent.or fixed users, the average channel gain hn can besed and is described as follows [21]:


Sbsxp

3fivrn(i[icfawmoqsisctc“bbs

4aEbltafep



hn = mn� c

Dn�

� Sn, �2�

where Dn is the distance between SS n and the con-nected ONU-BS, c is a constant including the trans-mission and receiving multi-input–multi-output(MIMO) antenna gain [21], and � is the path loss ex-ponent. Sn is a random variable for the shadow fadingeffect and mn is the multipath fading effect that rep-resents the Rayleigh fading channel. The averagesignal-to-noise ratio (SNR) for SS n is given bySNRn=Pn /Vbn, where Vbn is the background noisevariance. Pn is the receiving power and is given byPn= �hn�2 Pt, where Pt is the total transmitter power ofthe ONU-BS. Assuming that Pt is fixed, Pn can be al-located by the ONU-BS such that the maximum SNR�SNRn

max� is achieved.

We assume that multiple transmission modes areavailable, with each mode representing a pair of a spe-cific modulation format and a forward error correcting(FEC) code. Based on the channel state information(CSI) estimated at the receiver, the adaptive modula-tion and coding (AMC) controller determines themodulation-coding pair/mode, which is sent back tothe transmitter through a feedback channel for theAMC controller to update the transmission mode. Inour framework we consider the transmission modes inTable I.

The target of our study is the VPN setup by takingWiMAX networks as an extension to EPON networksin order to offer high-speed wireless access in the lastmile [1]. Since EPON is based on time division mul-tiple access (TDMA) and for simplicity, we adopt theOFDM-TDMA air interface for the wireless channelaccess. OFDM-TDMA is supported by the IEEE802.16 standard and is very suitable for fixed wirelessusers (i.e., using the IEEE 802.16d standard that iswidely deployed in both Europe and Asia) [2]. As a re-sult, each user/SS will be allocated all the OFDM sub-carriers and a time division duplexing (TDD) time slot(or TDD frame physical slots) for uplink transmission.

Given a bit error rate (BER) less than 10−6, Table Ilists the convolutionally coded M-ary rectangular orsquare QAM modes, adopted from the HIPERLAN/2or the IEEE 802.11a standards [22] with specific

TABADAPTIVE MODULATI

Modulation BPSK QPSK

Transmission mode �X� 1 2Coding rate �CR� 1 / 2 1 / 2

Receiver SNR (db) 6.4 9.4Bits/symbol �� 0.5 1

Coded bits/subcarrier �Wsc� 1 2


NRnmax and bits/symbol [23]. Let Nd be the total num-

er of OFDM data subcarriers and Tsym be the OFDMymbol duration in seconds. For a transmission mode(Table I), SS n’s transmission rate Rn

x (bps) is com-uted as follows:

Rnx =

Nd � Wscx � CRx

Tsym. �3�

) QoS Mapping: The IEEE 802.16 standard definesve classes of services, namely, unsolicited grant ser-ice (UGS), real-time polling service (rtPS), extendedeal-time polling service (ertPS, defined in 802.16e),on-real-time polling service (nrtPS) and best effort

BE) [6]. On the other hand, an IEEE 802.13ah ONUs allowed to support and report up to eight queues19]. Typically, three classes of services are supportedn an EPON: (1) expedited forwarding (EF) foronstant-bit-rate (CBR) traffic, (2) assured forwardingor variable-bit-rate (VBR) traffic, and (3) BE [5], eachssigned one buffering queue. To simplify the band-idth allocation operation, we perform a one-to-oneapping between the CoS queues in the BS and the

nes in the ONU [2]. Hence we will have a total of fiveueues for UGS, rtPS, nrtPS, ertPS, and BE classes ofervice. Consequently, the users’ incoming flows arenitially classified at the SS side using the packet clas-ifier and mapped to the corresponding CoS queue. Inase a VOB is installed, each transmitted packet ishen classified at the BS side and then mapped to theorresponding ONU CoS queue. Alternatively if aone-box” ONU-BS is mounted, incoming packets cane directly mapped to one of the five correspondinguffering queues. Before being buffered, flows can beubject to traffic policing and admission control.

) Requesting and Granting: Requesting and grantingre two fundamental operations standardized inPON and WiMAX [6,19] and are used to exchangeandwidth allocation control messages. In the wire-ess plane, the polling mode is adopted to achieve bet-er sensitivity in QoS guarantee. The polling mode en-bles every ONU-BS to poll its SSs in each OFDMrame so as to gather the bandwidth requirement ofach SS. Once available, each ONU-BS performs theroper bandwidth allocation and granting in a GPC

IAND CODING MODES

16 QAM 64 QAM

3 4 5 6 73 / 4 1 / 2 3 / 4 2 / 3 3 / 411.2 16.4 18.2 22.7 24.41.5 2 3 4 4.52 4 4 6 6

LEON


wg

wptsasHlatpnQ

tosSOnn

D

sOnf



fashion [6]. Each grant specifies the number of physi-cal slots used for upstream transmission in the nextOFDM frame. Typically, each SS reports its require-ments using the BW_Request message. Nonetheless,the UGS traffic does not need to request because itsrate is constant. Thus, the ONU-BS should reservethe bandwidth for the admitted UGS flows.

In the optical plane and according to the multipointcontrol protocol (MPCP) [19], each ONU is allowed torequest bandwidth for up to eight queues in each RE-PORT message. To preserve the REPORT structure,each ONU-BS will report the buffering queue occu-pancies for real-time flows (i.e., UGS, rtPS, ertPS, andnrtPS queues) and will use the remaining four fieldsto report up to four BE VPN bandwidth needs. If anONU-BS provisions more than four VPNs, multipleREPORT messages may be used to report the rest ofthe VPNs. The latter can be implemented by having acounter that keeps track of each BE packet buffered inthe BE queue. On the other hand, a GATE messageincludes a grant for each real-time buffer request andan aggregate grant for all the VPN BE traffic re-quests.

C. VPN-Based QoS Provisioning

With our QoS provisioning framework, each up-stream VPON cycle Tcycle

VPON is divided into two sub-cycles. The first subcycle �Tcycle

VPON is shared among allthe K VPNs. The second subcycle �1−��Tcycle

VPON isshared among non-VPN services. Let Bmin

k be thebandwidth reserved for VPN k (denoted as Vk) in eachtransmission cycle. Tg denotes the guard time thatseparates the transmission windows of two consecu-tive ONU-BSs, and RN is the transmission speed ofthe PON in Mbps. In addition, let each Vk be given aweight wk to determine its paid/committed band-

Fig. 2. (Color online) Proposed V


idth. Therefore, Bmink (in bytes, thus divide by 8) is

iven as follows:

Bmink =

��TcycleVPON − K � Tg� � RN � wk

8, �4�

here �k=1K wk=1. An important parameter in the pro-

osed cycle framework is the minimum per-VPNhroughput that allows the BE traffic to be free fromtarvation. Such a reserved quota for BE traffic takes

portion of �kBmink , while the real-time flows will

hare the remaining bandwidth, that is, �1−�k�Bmink .

ere, a packet preemption mechanism may be al-owed such that the BE traffic is preempted in order toccommodate more real-time flows and/or to maintainhe bandwidth requirement for the existing higher-rioritized flows that are possibly subject to bad chan-el conditions. A graphical illustration of the proposedoS-provisioning framework is given in Fig. 2.

As noted, our framework is designed to be architec-ure independent. Namely, it can operate on top of anyf the EPON-WiMAX architectures that were de-cribed earlier. In addition, it is designed to allow eachS to access its VPN reserved bandwidth through anyNU-BS, which will allow it to operate over mobileetworks [e.g., IEEE 802.11 (WiFi) and IEEE 802.16eetworks] as well.

. Traffic Characteristics and QoS Requirements

CBR traffic (such as UGS) is nonbursty and can beimply characterized by its mean data rate �� in bps.n the other hand, VBR traffic (such as rtPS andrtPS) is bursty in nature and is characterized by the

ollowing parameters:• Peak arrival data rate �� in bps.• Maximum burst size �� in bits.

N QoS provisionning framework.
PO

pscserpi

ts

gt

sGa

wVtEtbBVtonatBt

mfiwbv



• Delay bound ��, which is the maximum amountof time in units of seconds allowed to transport atraffic stream measured between the arrival ofthe flow to the MAC layer and the start of trans-mission in the network.

• MAC service data unit (MSDU) maximum andminimum sizes (Lmax and Lmin). For fixed framesize streams of size L, the mean frame size L̄=L.

Finally, BE traffic is bursty and requires neither delayrequirements nor bandwidth guarantee.

Once all these parameters are specified by the enduser, the problem left for the admission control unit(ACU) is simply to determine whether a new streamshould be admitted and whether its QoS requirementscan be guaranteed while the QoS requirements for al-ready admitted streams can be protected. For CBRtraffic, a flow is admitted in case its mean data ratecan be supported by the current system. For VBR traf-fic, the AC may admit a VBR stream according to ei-ther its peak rate or its mean data rate [24], which ob-viously causes a dilemma between the boost ofnetwork utilization and a more secured service guar-antee, respectively. With the proposed framework, ourapproach defines a suite of new traffic parameters viaa dual-token leaky bucket (DTLB) model for trafficregulation. The DTLB is situated at the entrance ofthe MAC buffer and is associated with each stream.The bucket size is calculated as follows:

S = � �1 − �/��. �5�

Accordingly, the arrival process of the stream pass-ing through the filter is computed as follows [24]:

A�t,t + �� = min��,S + ��, �6�

where A�t , t+�� is the number of cumulative arrivalsduring �t , t+��. The arrival rate curve could be con-structed from the above equation and is shown in Fig.3. Therefore, the guaranteed rate for every real-timeflow i belonging to Vk can be easily derived from Fig. 3using the distance formula [17,24]:

gik =

i

ik +

i

�i

. �7�

Fig. 3. (Color online) Guarantee bandwidth derivation graph.


In the wireless domain, transmissions are errorrone due to fluctuating channel conditions. Thus, theense of per-flow-based bandwidth guarantees be-omes tricky. A common method is to pursue a statisticense of bandwidth guarantees. By assuming a framerror probability Perror,i for stream i, the transmissionate in the wireless domain, such that a VBR streamerceived bandwidth can be statistically guaranteed,s obtained as follows:

gik =

i

�ik +

i

�i��1 − Perror,i�

. �8�

Note that Perror,i is a function of the channel condi-ion (i.e., the SNR), which is random in nature as de-cribed in Subsection III.B.

Similarly, the transmission rate for a statisticaluarantee of a CBR stream perceived bandwidth, per-aining to Perror,i, can be obtained as follows:

gik =

�i

1 − Perror,i. �9�

With the above computations, a rate-based admis-ion control [17] can be designed as simple as follows:iven the allocated bandwidth for Vk (denoted as Bk

G),new flow i+1 can be admitted if

gi+1k + �

i=1

hk

gik � Bk

G, �10�

here hk is the number of real-time streams (CBR orBR) of VPN k. However, there are other restrictions

hat need to be taken into consideration in VPN-basedPON-WiMAX networks, rather than simply admit-

ing based on such a rule. Due to the fact that Vk coulde simultaneously provisioned at multiple ONU-BSs,kG is shared among all the ONU-BSs that provisionk at a first stage and meanwhile shared among all

he SSs with the same provisioning capability at a sec-nd stage. In this case, the AC’s decision makingeeds to further consider the network architecturend SSs’ distribution. For this reason, we propose ahree-stage AC mechanism, where all the SSs, ONU-Ss and the OLT collaboratively perform AC in order

o satisfy the conditions defined in Eqs. (8) and (9).

IV. VPN-BASED ADMISSION CONTROL

This section describes the proposed three-stage ACechanism for real-time flows. Note that the BE traf-

c requests are always admitted. The admitted flowsill be further distinguished according to a dynamicandwidth allocation algorithm (which will be pro-ided in Section V).


rttIts

C

aal

I(mundSoootl

adtdumsiSsi

A

Omtt

w



A. SS-Based Admission Control

Let Mk be the number of ONU-BSs that provisionVk and share the total allocated bandwidth �kBmin

k formaintaining the minimum BE bandwidth. EachONU-BS is allocated an equal portion of the currentlyavailable bandwidth at the OLT for the BE traffic ofVk, namely, �kBmin

k / �Mk�. This information is broadcastby the OLT to all the ONU-BSs in the registrationphase. Let Rj,BE

k denote the rate reserved for BE trafficof Vk at each ONU-BS j, which can be expressed as

Rj,BEk =

�kBmink � 8

�Mk� � �TcycleVPON. �11�

Let Nk denote the number of SSs using the services ofVk via ONU-BS j. Thus, the reserved BE rate for eachuser/SS n of Vk at ONU-BS j, which is denoted asRj,BE

n,k , can be expressed as

Rj,BEn,k =

�kBmink � 8

�Nk� � �Mk� � �TcycleVPON. �12�

According to Eq. (10), a new real-time (RT) flow i+1by SS n could be admitted to Vk at ONU-BS j if thefollowing condition is satisfied:

gn,i+1k + �

k�

i�gn,i

k + Rj,BEn,k � � Rn

x , �13�

where gn,i+1k is the guaranteed rate (bps) for the flow

computed according to either Eq. (8) or Eq. (9).

Using SS-based AC, a new flow is admitted at theSS side if its guaranteed bandwidth plus the alreadyexisting traffic (real time and best effort) is less thanor equal to the SS PHY transmission rate. This condi-tion also implies that SS n’s PHY rate (or the adaptedAMC) cannot go lower than Rn

x ; otherwise, the band-width will no longer be guaranteed. Thus, our systemensures guaranteed bandwidth for admitted flows un-der the condition that its respective SS maintains aminimum PHY rate that will obey the specified rule.

B. ONU-BS-Based Admission Control

Once a flow is conditionally admitted at the SSlevel, it is reported to its connected ONU-BS j. TheONU-BS then locally performs rate-based AC accord-ing to the bandwidth requirement of the arriving flowalong with the overall wireless bandwidth availability.The condition for flow i+1 of Vk from SS n to be ad-mitted at ONU-BS j is defined as follows:

gn,i+1k

Rnx + �

k�n

�i

gn,ik

Rnx � NBR − �

k�n

Rn,BEk

Rnx . �14�

Here, the nominal bandwidth ratio is defined asNBR= �1−Co�, where Co represents the control over-head ratio caused by the signaling required to perform


esource allocation and will be evaluated via simula-ions. gn,i

k /Rnx is the ratio of the channel rate required

o transmit flow i of Vk in a 1 s time interval at SS n.f sufficient bandwidth is available to accommodatehe flow, it will be reported to the OLT for the finaltage of AC in the VPN level.

. OLT-Based Admission Control

After passing the first and second stages, flow i+1 isdmitted by the OLT if sufficient bandwidth is avail-ble in Vk. The condition of admission is defined as fol-ows:

gi+1k + �

igi

k ��1 − �k�Bmin

k � 8

�TcycleVPON . �15�

n summary, VPN-AC is used to achieve an end-to-endfrom SS to OLT) bandwidth guarantee for each ad-itted flow. It is designed for the scenario where the

sers of a VPN may connect to any ONU-BS, but areot allowed to utilize more bandwidth than their pre-efined bandwidth share in the upstream channel.uch a feature is critical to building up layer-2 VPNsver EPON-WiMAX integration while at the expensef longer decision making delay at each SS on an orderf milliseconds during the next polling interval. None-heless, a delay within the maximum OFDM frameength (i.e., 20 ms [6]) is considered tolerable.

V. VPN-BASED DYNAMIC BANDWIDTH ALLOCATION

As a complement to the AC scheme in the course ofper-flow QoS guarantee, we provide a VPN-based

ynamic bandwidth allocation (VPN-DBA) schemehat is installed at both the OLT and ONU-BSs in or-er to arbitrate the transmission of ONU-BSs over thepstream optical channel and to arbitrate the trans-ission of SSs over the uplink wireless channel, re-

pectively. Moreover at the ONU-BS, VPN-DBA takesnto consideration different channel conditions of eachS reported through the CSI, where the allocated timehare is adaptive to the fluctuating channel conditionn order to achieve the desired bandwidth guarantee.

. VPN-DBA at the ONU-BS

To determine the time share for a flow, eachNU-BS j calculates the aggregated rates of the ad-itted real-time flows (denoted as Gj=�k�igi

k) and theotal reserved VPN BE rates (denoted as Rj,BE) usinghe following equation:

Rj,BE = �k

Rj,BEk � �k, �16�

here


apa

wsi

wflenc

eceaii

t

wi

W



�k = 1 if ∀ i, ∃ SSi, and �SSi� has Vk requests

0 otherwise ..

�17�

To protect RT traffic from being shared with BE traf-fic, in our scheme, each cycle/frame is divided into K+1 subcycles, where subcycle 1 is for real-time flows,while the remaining K subcycles are for all the VPNs’BE traffic. The size of each subcycle should be deter-mined in each polling interval so as to adapt to thebandwidth request fluctuation of each flow. Thus,TRT

802.16 (i.e., the subcycle assigned to real-time flows)and Tk

802.16 (i.e., the subcycle assigned to Vk’s BE traf-fic) can be computed as follows:

TRT802.16 =

Gj � Tcycle802.16

Gj + Rj,BE, �18a�

Tk802.16 =

Rj,BEk � Tcycle

802.16

Gj + Rj,BE, �18b�

where Tcycle802.16 is the total wireless frame length.

In addition, the proposed AC scheme differentiatesthe SSs with real-time flows from those that only haveBE flows. For a real-time SS n, the time share in thereal-time subcycle Tn,RT

802.16 is expressed by

Tn,RT802.16 =

�1/Rnx� � TRT

802.16

�1� ��n

Rn,RTx � , �19�

where Rnx is the computed transmission rate for SS n,

and �nRn,RTx is the sum of transmission rates for all

real-time SSs. The inverse of the transmission rate isused because an SS with a lower transmission rate re-quires more time share to transmit an admitted flowrate. Similarly, the time share allocated to SS n forthe Vk BE subcycle, Tn,k

802.16, is expressed by the follow-ing:

Tn,k802.16 =

�1/Rnx� � Tk

802.16

�1� ��n

Rn,kx � , �20�

where �nRn,kx is the sum of transmission rates for all

Vk SSs. Next and based on the admitted flow rate andreported frame size, our scheme estimates the amountof bandwidth required to satisfy each admitted flow ineach frame. Thus, the estimated guaranteed band-width Bi,n

g for real-time flow i launched by SS n ineach polling interval is determined as

Bi,ng =

gik � Rn

x � Tn,RT802.16

G � 8. �21�

j


To explore the bandwidth usage of each frame andvoid any possible resource waste, the number ofackets per polling cycle estimated for flow i, denoteds npi,n, is first obtained:

npi,n = �Bi,ng

L̄i�, �22�

here L̄i is the average packet size as defined in Sub-ection III.D. Thus, the allocated bandwidth for flow in the next cycle/frame, Bi,n

alloc, is then given by

Bi,nalloc = min�npi,n � L̄i,ri,n�, �23�

here ri,n is the requested bandwidth for real-timeow i (i.e., the buffering queue occupancy) by SS n inach polling interval. As mentioned, UGS traffic needsot to be requested. Hence, the ONU-BS may periodi-ally grant it the desired bandwidth.

With OFDM, one physical symbol may carry differ-nt bits of MAC layer data according to the channelondition that in turn affects the modulation schememployed. Therefore, each ONU-BS has to convert thellocated bandwidth into a number of symbols accord-ngly. The number of OFDM symbols required for flowby SS n, denoted as Fi,n, is computed as follows [2]:

Fi,n =Bi,n

alloc � 8

�x. �24�

For BE traffic, the allocated bandwidth Bn,BEalloc is de-

ermined with the same approach as follows:

Bn,BEalloc = min�Rn

x � Tn,k802.16

8,rn,BE� , �25�

here rn,BE is the requested bandwidth for BE trafficn each polling interval.

TABLE IISIMULATION PARAMETERS

EPON Number of ONU-BSs �M� 16Channel Speed �RN� 1 Gbps

Distance (OLT to ONU-BS) 25 kmTcycle

VPON 2 msTg 1 �s

ONU-BS queue size 10 MbytesiMAX Channel bandwidth 20 MHz

Nd 1440Tsym 0.1 ms

Distance (SS to ONU-BS) 5 kmTcycle

802.16 5, 10, 20 msSS queue size 10 Mbytes

VPN Number of VPNs �K� 4� 1

∀k ,�k 0.1SS Vk random(1, 4)


oaptspa

ftoehU6ardrD[t[srgumaurinna

NT

F

ms



B. VPN-DBA at the OLT

The OLT receives reports from ONU-BS j on thelength of its real-time queue m, (i.e., rm,j) and a BEVPN counter of Vk (i.e., rk,j). Moreover, we have therate of BE traffic as

RBE = �k

�j

Rj,BEk . �26�

Same as in the case of VPN-DBA at the ONU-BS,the OLT divides each transmission cycle into two sub-cycles (real-time and BE), and each BE subcycle is fur-ther subdivided into K subcycles. Consequently, theVPON’s upstream real-time flow subcycle TRT

VPON and aVk subcycle Tk

VPON are computed as follows:

TRTVPON =

G � �TcycleVPON

G + RBE, �27a�

TkVPON =

�j

Rj,BEk � �Tcycle

VPON

G + RBE, �27b�

where G=�j=1M Gj, and �jRj,BE

k is the total requestedbandwidth for Vk. Note that for a non-VPN flow, thecomputation is done with �1−��Tcycle

VPON instead of�Tcycle

VPON. As mentioned, in the optical plane all ONU-BSs transmit at the same speed. Thus with a real-time subcycle TRT

VPON, the time share for each ONU-BSj in the real-time subcycle Tj,RT

VPON is computed as fol-lows:

Tj,RTVPON =

TRTVPON � RN

�M� � 8. �28�

Finally, the OLT calculates the allocated bandwidthfor queue m of ONU-BS j, Bj,m

alloc in the same manner asthe computation done by the ONU-BS. The same logicalso applies for the BE computation.

VI. PERFORMANCE EVALUATION

To evaluate the effectiveness of the proposed ACand DBA algorithms, we have developed a simulatorusing OMNET . The simulation parameters areshown in Table II. Here, the case of �=1 implies that“non-VPN” traffic is NOT considered, and thereforethe available VPON bandwidth is divided among K=4 VPNs. Without loss of generality, we assume thatall VPNs have equal weights. Thus, wk=w=1/K∀k,and �k=1

K wk=1. As a result, each VPN is reserved a to-tal of 249.5 Mbps, out of which 24.95 Mbps are re-served for BE traffic (since ∀k ,�k=0.1).

To test the resilience of our proposed algorithms inhandling fluctuating channel conditions, the followingtwo simulation scenarios are investigated:


• Scenario A: The highest transmission rate isadopted for every SS n of each ONU-BS; i.e., Rn

x

=Rn7.

• Scenario B: Here, various channel conditions areconsidered for different SSs. The transmissionmode of each SS is randomly generated �x=random�1,7��.

We realize that scenario A (which is applied in mostf the related work in the literature [2,7–9]) is not re-listic in the presence of the powerful AMC functionrovided by the IEEE 802.16 standard; nonetheless,he result of scenario A is explored and positioned toerve as a benchmark for scenario B and is expected torovide some insights in case other types of wirelessir interfaces are employed, such as IEEE 802.11.

In each scenario, we simulate with multiple OFDMrame lengths (5, 10, and 20 ms) in order to show howhis affects the overall network performance in termsf end-to-end (from SS to OLT) flow throughput andnd-to-end average packet delay. Each incoming SSas four flows (UGS, rtPS, nrtPS, and BE). EveryGS flow is generated with a mean/guaranteed rate of4 Kbps (modeled using the constant distribution)nd a packet size equal to 70 bytes [20]. Alternatively,tPS and nrtPS flows are modeled using the Poissonistribution. We generate rtPS traffic at a guaranteedate of 5 Mbps (which is the average bit rate of aVD-quality video) and a packet size of 800 bytes

24]. Similarly, nrtPS traffic is generated at a guaran-eed rate of 500 Kbps and a packet size of 600 bytes20]. BE traffic is highly bursty, and we use self-imilar traffic (Pareto distribution with a Hurst pa-ameter H=0.8) for modeling it [5]. Each BE flow isenerated at a mean rate of 2 Mbps with packet sizesniformly distributed between 64 and 1518 bytes. Theaximum allowable latency for voice traffic is 100 ms

nd for video traffic is 150 ms [20]. The number of SSssed in the figures increments by �M� with time andeflects the arrival (or request for joining) of a new SSn time (with its CoS flows) to each ONU-BS simulta-eously. Hence, every time a new SS wants to join theetwork, it will be subject to the VPN-AC frameworks well as the VPN-DBA computation.

We first start by running scenario A to extract theBR that is needed to apply the AC rules [Eq. (14)].he NBR is computed as follows:

NBR =Total Throughput

Transmission Rate=

59.0976 Mbps

64.8 Mbps= 0.912.

�29�

or a more conservative AC, we set NBR=0.9.

To study the performance of real-time traffic, weeasure the instantaneous average packet delays of a

elected SS’s real-time flows. Figures 4–6 show these


Op

tlSfthitpiststwftirOflUo

smo

F



measurements with AC (i.e., VPN-DBA) and withoutAC (i.e., NO-AC) under both scenarios. Note that withVPN-DBA, there is no intra-ONU/intra-SS schedulingrequired since the OLT/ONU-BS allocates bandwidthfor each CoS, per each ONU-BS/SS, every cycle/

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 28830010

−4

10−3

10−2

10−1

Number of SSs

Ave

rage

Pac

ketD

elay

(sec

onds

)

5 ms − A10 ms − A20 ms − ANO−AC

(a)

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 28830010

−4

10−3

10−2

10−1

Number of SSs

Ave

rage

Pac

ketD

elay

(sec

onds

)

5 ms − B10 ms − B20 ms − BNO−AC

(b)

Fig. 4. (Color online) UGS flow average end-to-end packet delay.

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 28830010

−4

10−3

10−2

10−1

100

Number of SSs

Ave

rage

Pac

ketD

elay

(sec

onds

)


(a)

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 28830010

−4

10−3

10−2

10−1

100

Number of SSs

Ave

rage

Pac

ketD

elay

(sec

onds

)


(b)

Fig. 5. (Color online) rtPS flow average end-to-end packet delay.


FDM frame. On the other hand, with NO-AC, we ap-ly strict priority (SP) scheduling [2].

Clearly, using the SP scheduler, UGS traffic showshe optimal performance where its average packet de-ay remains under 2–10 ms even when the number ofSs continuously increases, regardless of the OFDM

rame length. This is a direct result of the SP policyhat always selects packets from a queue with aigher priority. As for VPN-DBA, it makes sure to sat-

sfy the QoS requirements in terms of delay andhroughput by reserving all real-time traffic with ap-ropriate bandwidth in every cycle. Since a UGS flows admitted only if its guaranteed bandwidth is as-ured in every cycle, we can see that VPN-DBA main-ains a UGS average packet delay of 5–20 ms undercenario A. However, the delay variation is affected byhe OFDM frame length, especially in scenario B,here the delay might reach �90 ms with a 20 ms

rame size. This is due to the fact that in this scenario,he bandwidth is allocated to each SS with respect tots transmission rate, and hence the cycle might satu-ate because some SSs have requested for moreFDM symbols than others to support the admittedow rate. Nonetheless, VPN-DBA still maintains aGS packet latency less than the maximum allowable

ne (i.e., �100 ms).

As for rtPS and nrtPS traffic, Figs. 5 and 6 demon-trate that VPN-DBA maintains their delay perfor-ance to meet the specified target QoS requirements

f the stream (i.e., �150 ms) while the delay wit-

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 28830010

−4

10−3

10−2

10−1

100

Number of SSs

Ave

rage

Pac

ketD

elay

(sec

onds

)


(a)

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 28830010

−4

10−3

10−2

10−1

100

Number of SSs

Ave

rage

Pac

ketD

elay

(sec

onds

)


(b)

ig. 6. (Color online) nrtPS flow average end-to-end packet delay.


tasatn



nesses an exponential increase with NO-AC, espe-cially after system saturation (number of SSs=192).This behavior highlights the need for the applicationof AC in WiMAX-VPON, because when the systemreaches saturation and all the arriving streams areadmitted, the performance is no longer maintained.More specifically, no bandwidth is guaranteed for eachtype of traffic, and the QoS requirements can nolonger be met not only for new flows but also for theexisting ones. On the other hand, the deployment ofAC allows for a bandwidth guaranteed service withprotected and guaranteed QoS that will meet the VPNSLA and maintain it.

We further evaluate the proposed VPN-AC frame-work by measuring the throughput of one flow fromeach CoS of a common SS with AC (i.e., VPN-DBA)and with NO-AC. It is demonstrated in Fig. 7 that theselected UGS flow exhibits similar performance be-havior to that with NO-AC, whereas the selected rtPSand nrtPS flows show different behaviors. Here, rtPSand nrtPS flows (see Figs. 8 and 9) with AC maintaintheir derived 5 Mbps and 500 Kbps throughputs, re-spectively, throughout the simulation, even after thesystem saturation. On the other hand, when NO-AC isapplied, these flows do not show a stable throughputbehavior. Moreover, when the system reaches satura-tion, their throughput starts decreasing. This is due tothe fact that when more real-time flows are admittedand no AC is applied, the bandwidth that was guaran-teed for the already admitted flows (before saturation)is now shared among more flows. Hence, the band-width is no longer guaranteed for the already admit-

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 2883000.0635

0.0636

0.0636

0.0637

0.0638

0.0638

0.0638

0.0639

0.0639

0.064

0.064

Number of SSs

Ave

rage

Thr

ough

put(

Mbp

s)


(a)

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 2883000.0634

0.0635

0.0636

0.0637

0.0638

0.0639

0.064

0.0641

Number of SSs

Ave

rage

Thr

ough

put(

Mbp

s)


(b)

Fig. 7. (Color online) UGS flow average end-to-end throughput.


ed flows as well as for the newly admitted ones. This,gain, shows the effectiveness of our AC framework intabilizing and guaranteeing the throughput for alldmitted flows by rejecting the flows that will breakhis theme. Furthermore, our framework proves thato matter what channel condition each user pos-

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 2883004.75

4.8

4.85

4.9

4.95

5

5.05

5.1

Number of SSs

Ave

rage

Thr

ough

put(

Mbp

s)


(a)

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 2883004.75

4.8

4.85

4.9

4.95

5

5.05

5.1

Number of SSsA

vera

geT

hrou

ghpu

t(M

bps)


(b)

Fig. 8. (Color online) rtPS flow average end-to-end throughput.

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 2883000.35

0.4

0.45

0.5

0.55

0.6

Number of SSs

Ave

rage

Thr

ough

put(

Mbp

s)


(a)

0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 2883000.35

0.4

0.45

0.5

0.55

0.6

Number of SSs

Ave

rage

Thr

ough

put(

Mbp

s)


(b)

Fig. 9. (Color online) nrtPS flow average end-to-end throughput.


sha3iiiaoppcfhcprNanrao

viwif(fiapwchqtFfVgo



sesses, it can still provide its flows with the guaran-teed bandwidth, which are well demonstrated by theresults under scenario B. This is achieved by allocat-ing more OFDM frames to transmit the same flowrate, as described before. In real and practical set-tings, this will deny all malicious users from monopo-lizing the bandwidth provided, and at the same time,it will allow for protection to the bandwidth assignedfor other well-behaved users, while meeting the QoSrequirements for each VPN service as specified in theSLA.

We now study the performance of BE traffic in bothscenarios under different OFDM frame lengths. SinceBE has no QoS requirement in terms of delay [20], we

TABVPN 4 TRAF

CoS UGS

Scenario A B

Number of generated flows 59 50Number of admitted flows 59 26Number of rejected flows 0 24

Admission rate (%) 100% 52%Expected throughput (Mbps) 3.776 1.664Monitored throughput (Mbps) 3.76376 1.66151

1 2 3 41

26

51

76100

VPN

BE

Thr

ough

put(

Mbp

s)20ms−B 20ms−A 10ms−A 10ms−B 5ms−B 5ms−A

Fig. 10. (Color online) Per-VPN BE end-to-end throughput.

0.05 0.1 0.15 0.2 0.2510

−3

10−2

10−1

100

α

Ave

rage

Pac

ketD

elay

(sec

onds

)

UGSrtPSnrtPSBE

Fig. 11. (Color online) Average end-to-end packet delay versus �.


how the total BE throughput in Fig. 10, which isighly affected by the OFDM frame length. For ex-mple, with 5 ms frame length under scenario A, VPNyields a total throughput of 10 Mbps, knowing that

ts reserved one is 24.95 Mbps. The total throughputncreases to reach �25.5 Mbps when the frame lengths increased to 20 ms. This is due to the fact that withsmaller frame size, the VPN BE subcycles portion of

ne SS might be smaller than the head-of-line (HOL)acket in its BE queue. As a result, not only can thoseackets not be transmitted, but they could also be suc-essively blocked from being transmitted, and there-ore, the throughput is suppressed. On the otherand, with a larger frame length, each VPN BE sub-ycle will be large enough to accommodate mostacket sizes for all SSs, and hence the throughput caneach as high as �24.95 Mbps (i.e., the reserved one).onetheless, using an OFDM frame length of 10 mslso meets the expected throughput under both sce-arios and produces a throughput equivalent to theeserved one. This shows that WiMAX-VPON canchieve the desired/expected performance for all typesf traffic, if the network parameters are set properly.

As mentioned before, our proposed VPN-DBA di-ides each transmission cycle into multiple subcyclesn order to protect real-time traffic from being sharedith BE traffic. To highlight this advantage, we plot

n Fig. 11 the overall average end-to-end packet delayor all CoS, with multiple BE traffic VPN portionsi.e., with multiple � values). As noted, real-time traf-c (i.e., UGS, rtPS, and nrtPS) maintain an overallverage delay �10 ms regardless of the assigned BEortion for each VPN. On the other hand, BE trafficitnesses a delay decrease as its reserved portion in-

reases, which is under our expectations. This showsow VPN-DBA can efficiently preserve the QoS re-uirements for real-time flows while satisfying BEraffic with the throughput agreed upon in the SLA.inally, Table III summarizes the statistics collected

rom our simulations about a particular VPN (here,PN 4). These results show that 100% and 52% of theenerated VPN 4 UGS traffic is admitted, while itsverall QoS and bandwidth requirements are guaran-

IIISTATISTICS

rtPS nrtPS

A B A B

59 50 59 5038 12 48 1921 38 11 31

�64% 24% �82% 38%190 60 24 9.5

189.815 58.6636 23.7408 9.51106

LEFIC




teed, under scenarios A and B, respectively. Approxi-mately 64% and 24% of its rtPS flows are also admit-ted under both scenarios, and approximately 82% and38% of its nrtPS flows are admitted as well, whereasall BE flows are admitted. The difference of admissionrates between scenarios A and B is caused by ONU-BS-based AC [i.e., Eq. (14)], where the overall wirelesssystem capacity is proportional to each SS’s transmis-sion rate. Thus, the admission rule becomes more con-servative if more SSs have lower transmission rates.The table also shows that the monitored/measuredthroughput for each CoS traffic meets the expected/calculated one. This again demonstrates the effective-ness of our proposed framework in providing the ex-pected performance under various channel conditions.Note that with no AC, all traffic is admitted; however,their QoS requirements are not guaranteed (except forUGS traffic). Note also that these collected results aretraffic model dependent. In other words, more flowscan be admitted or rejected, depending on all of the re-quired guaranteed throughput for real-time and BEtraffic, the generated flows’ mean rates, and the num-ber of flows/SSs generated.

VII. CONCLUSIONS

This paper has presented the first work to ourknowledge to establish layer-2 VPNs over the EPON-WiMAX integration. A novel framework, namely,WiMAX-VPON, was proposed for providing per-service QoS protection and assurance. This work firstdefined layer-2 VPNs over EPON-WiMAX networksand then highlighted a number of important issuessuch as QoS mapping and traffic characteristics. Theproposed framework implements a new joint VPN-based three-stage AC and DBA paradigm to achievean end-to-end bandwidth guarantee. To validate theeffectiveness and the robustness of our framework, ex-tensive simulations were conducted, which demon-strated that the lack of an efficient AC or DBA mecha-nism could not preserve the QoS requirements ofvarious types of flows. On the other hand, WiMAX-VPON has shown much improved performance interms of maintaining the QoS requirements of the ex-isting flows while providing an overall per-VPN ac-ceptable minimal throughput for BE traffic. We con-clude that the proposed framework is a promisingcandidate for the operation of future EPON-WiMAXbackhaul-access networks.

ACKNOWLEDGMENT

Preliminary results of this work appeared in ICC’10[25].


REFERENCES

[1] G. Shen, R. S. Tucker, and C.-J. Chae, “Fixed mobile conver-gence architectures for broadband access: integration of EPONand WiMAX,” IEEE Commun. Mag., vol. 45, no. 8, pp. 44–50,Aug. 2007.

[2] K. Yang, S. Ou, G. Ken, and H.-H. Chen, “Convergence of Eth-ernet PON and IEEE 802.16 broadband access networks andits QoS-aware dynamic bandwidth allocation scheme,” IEEE J.Sel. Areas Commun., vol. 27, no. 2, pp. 101–116, Feb. 2009.

[3] N. Ghazisaidi, M. Maier, and C. M. Assi, “Fiber-wireless (FiWi)access networks: a survey,” IEEE Commun. Mag., vol. 47, no.2, pp. 160–167, Feb. 2009.

[4] S. Sarkar, S. Dixit, and B. Mukherjee, “Hybrid wireless-opticalbroadband-access network (WOBAN): a review of releventchallenges,” J. Lightwave Technol., vol. 25, no. 11, pp. 3329–3340, Nov. 2007.

[5] G. Kramer, B. Mukherjee, and G. Pesavento, “IPACT a dy-namic protocol for an ethernet PON (EPON),” IEEE Commun.Mag., vol. 40, no. 2, pp. 74–80, Feb. 2002.

[6] “IEEE standard for local and metropolitan area networks part16: air interface for fixed broadband wireless access systems,”2004.

[7] M. Luo, H. Li, Y. Lu, and Y. Ji, “QoS-aware scheduling inemerging novel optical wireless integrated networks,” in Chal-lenges for Next Generation Network Operations and ServiceManagement. Springer, 2008, pp. 445–448.

[8] Y. Yan, H. Yu, H. Wang, and L. Dittmann, “Integration ofEPON and WiMAX networks: uplink scheduler design,” inProc. of Asia-Pacific Optical Communications (APOC 2008),Hangzhou, China, 2008.

[9] Y. Luo, S. Yin, T. Wang, Y. Suemura, S. Nakamura, N. Ansari,and M. Cvijetic, “QoS-aware scheduling over hybrid opticalwireless networks,” in Nat. Fiber Optic Engineers Conf., 2007,paper NThB1.

[10] R. Venkateswaran, “Virtual private networks,” IEEE Poten-tials, vol. 20, no. 1, pp. 11–15, Feb. 2001.

[11] W. Luo, C. Pignataro, A. Y. H. Chan, and D. Bokotey, Layer-2VPN Architectures. CISCO Press, 2005.

[12] W. Wei, J. Hu, D. Qian, P. N. Ji, T. Wang, X. Liu, and C. Qiao,“PONIARD: a programmable optical networking infrastruc-ture for advanced research and development of future Inter-net,” J. Lightwave Technol., vol. 27, no. 3, pp. 233–242, Feb.2009.

[13] N. Nadarajah, E. Wong, and A. Nirmalathas, “Implementationof multiple secure virtual private networks over passive opticalnetworks using electronic CDMA,” IEEE Photon. Technol.Lett., vol. 18, no. 3, pp. 484–486, Feb. 2006.

[14] X. Bai, A. Shami, and Y. Ye, “Robust QoS control for single car-rier PMP mode IEEE 802.16 system,” IEEE Trans. MobileComput., vol. 7, no. 4, pp. 416–429, Apr. 2008.

[15] A. S. Reaz, V. Ramamurthi, S. Sarkar, D. Ghosal, S. Dixit, andB. Mukherjee, “CaDAR: an efficient routing algorithm for awireless-optical broadband access network (WOBAN),” J. Opt.Commun. Netw., vol. 1, no. 5, pp. 392–403, Oct. 2009.

[16] M. P. McGarry, M. Maier, and M. Reisslein, “Ethernet PONs: asurvey of dynamic bandwidth allocation (DBA) algorithms,”IEEE Commun. Mag., vol. 42, no. 8, pp. S8–S15, Aug. 2004.

[17] A. R. Dhaini, C. M. Assi, M. Maier, and A. Shami, “Per-streamQoS and admission control in Ethernet passive optical net-works (EPONs),” J. Lightwave Technol., vol. 25, no. 7, pp.1659–1669, July 2007.

[18] C. So-In, R. Jain, and A.-K. Tamimi, “Scheduling in IEEE802.16e mobile WiMAX networks: key issues and a survey,”IEEE J. Sel. Areas Commun., vol. 27, no. 2, pp. 156–171, Feb.2009.

[19] IEEE 802.3ah Task Force Home Page. Available: http://www.ieee802.org/3/efm.

[20] J. G. Andrews, A. Ghosh, and R. Muhamad, Fundamentals of


http://www.ieee802.org/3/efm

http://www.ieee802.org/3/efm

AoRSSs

nSFsoJewdps



WIMAX: Understanding Broadband Wireless Networking.Prentice Hall, 2007.

[21] S. Catreux, P. F. Driessen, and L. J. Greenstein, “Datathroughputs using multiple-input multiple-output (MIMO)techniques in a noise-limited cellular environment,” IEEETrans. Wireless Commun., vol. 1, no. 2, pp. 226–234, Apr. 2002.

[22] A. Doufexi, S. Armour, M. Butler, A. Nix, D. Bull, and J. Mc-Geehan, “A comparison of the HIPERLAN/2 and IEEE 802.11awireless LAN standards,” IEEE Commun. Mag., vol. 37, no. 12,pp. 172–180, May 2002.

[23] Q. Liu, S. Zhou, and G. B. Giannakis, “Queuing with adaptivemodulation and coding over wireless links: cross-layer analysisand design,” IEEE Trans. Wireless Commun., vol. 4, no. 3, pp.1142–1153, May 2005.

[24] C.-T. Chou, S. S. N. Shankar, and K. G. Shin, “Achieving per-stream QoS with distributed airtime allocation and admissioncontrol in IEEE 802.11e wireless LANs,” in Proc. of IEEE IN-FOCOM’05, Apr. 2005, pp. 1584–1595.

[25] A. R. Dhaini, P.-H. Ho, and X. Jiang, “QoS-aware layer-2 VPNsover EPON-WIMAX,” in Proc. of IEEE Int. Conf. on Commu-nications (ICC’10), Cape Town, South Africa, 2010.

Ahmad R. Dhaini received his B.Sc. incomputer science from the American Uni-versity of Beirut (AUB) in 2004 and hisM.App.Sc. in electrical and computer engi-neering from Concordia University, Mont-real, with a best thesis award nomination in2006. He worked as a software consultantat TEKSystems, Montreal, in 2006–2007,and as a software designer at Ericsson,Montreal, in 2007–2008. He is currentlyworking toward his Ph.D. degree in electri-

cal and computer engineering at the University of Waterloo. He hasauthored a book and published several papers in major journals andconferences related to his area of expertise. He has also been as-signed as a technical program committee member, technical re-viewer, and member of the editorial board in major conferences andjournals. His research interests focus on access networks, more spe-cifically on optical/wireless broadband access networks.

Pin-Han Ho received his B.Sc. and M.Sc.degrees from the Electrical Engineering De-partment of the National Taiwan Univer-sity in 1993 and 1995, respectively, and hisPh.D. degree from Queens University atKingston in 2002. He is now an associateprofessor in the Department of Electricaland Computer Engineering, University ofWaterloo, Canada. Professor Ho is theauthor/co-author of more than 150 refereedtechnical papers, several book chapters, and

a book on optical networking and survivability. His current researchinterests cover a wide range of topics in broadband wired and wire-less communication networks, including survivable network design,wireless metropolitan area networks such as IEEE 802.16 net-works, fiber–wireless (FiWi) network integration, and network se-
curity. He is the recipient of the Distinguished Research Excellent

ward in the Department of Electrical and Computer Engineeringf the University of Waterloo; the Early Researcher Award (Premieresearch Excellence Award) in 2005; the Best Paper Award inPECTS’02, ICC’05 Optical Networking Symposium, and ICC’07ecurity and Wireless Communications Symposium; and the Out-tanding Paper Award in HPSR’02.

Xiaohong Jiang received his B.S., M.S.,and Ph.D degrees in 1989, 1992, and 1999,respectively, all from Xidian University,Xian, China. He is currently a Full Profes-sor at the Future University-Hakodate, Ja-pan. Before joining the Future University,Dr. Jiang was an Associate Professor at To-hoku University from Feb. 2005 to Mar.2010. He was an Assistant Professor in theGraduate School of Information Science, Ja-pan Advanced Institute of Science and Tech-

ology (JAIST), from Oct. 2001 to Jan. 2005. Dr. Jiang was a Japanociety for the Promotion of Science (JSPS) Postdoctoral Researchellow at JAIST from Oct. 1999 to Oct. 2001. He was a research as-ociate in the Department of Electronics and Electrical Engineeringf the University of Edinburgh from Mar. 1999 to Oct. 1999. Dr.iang’s research interests include optical switching networks, rout-rs, network coding, WDM networks, VoIP, interconnection net-orks, IC yield modeling, timing analysis of digital circuits, clockistribution, and fault-tolerant technologies for VLSI/WSI. He hasublished over 150 referred technical papers in these areas. He is aenior member of IEEE.
