MC-FiWiBAN: An Emergency-Aware Mission-Critical Fiber ...staff.aub.edu.lb/~ad57/documents/MC_FiWiBAN_COMMAG.pdf · thermore, the integration can help realize fixed mobile convergence

IEEE Communications Magazine • January 2011134 0163-6804/11/$25.00 © 2011 IEEE

INTRODUCTION

Mission-critical (MC) systems and organizations,such as healthcare, police, and firefighting, relyheavily on the underlying telecommunicationsinfrastructure to conduct their daily tactical andemergency operations. In recent years, the MCsector has witnessed the proliferation of diversemultimedia applications such as remote patientmonitoring, two-way video/audio conferencing,3D geographical mapping and positioning,enhanced telemetry, and live surveillance videobroadcasting. All these technological advance-ments are expected to force MC service pro-viders (SPs) to migrate from simple data servicesto triple-play (data, voice, and video) or evenquadruple-play (triple-play plus mobile) serviceson a single infrastructure in order to offer state-of-the-art MC service support.

Public safety and disaster relief (PSDR) net-works are particularly designed to guaranteereliable, continuous, secure, and flexible MC ser-vice. Since 1997 the terrestrial trunked radio(TETRA) standard [1] (predominant in Europe,Middle East and Africa, and Asia Pacific) andthe ASTRO-25 standard (equally predominantin the Americas) have become the de facto stan-

dards for PSDR communications, and have beenemployed by senior market players (e.g.,Motorola and Nokia) in their deployment of MCnetworks in rural and urban areas. More inter-estingly, TETRA networks have successfullypenetrated other large markets such as trans-portation, utilities, and oil/gas services (as recent-ly announced in Qatar) [2]. The current twomajor TETRA releases (TETRA-1 and TETRA-2) developed by the European Telecommunica-tions Standards Institute (ETSI), provide radiocapabilities endorsing network controlled ser-vices and direct mobile-to-mobile communica-tions, with a wide range of functionalities such asgroup calls, fast call setup, encryption/decryp-tion, real-time localization, and grade-of-service(GoS) connections [1]. However, the accesscapability offered by TETRA, which focuses onvoice plus data (V+D) services only, is not suffi-cient to satisfy the bandwidth requirements ofthe emerging multimedia PSDR applications.The transmission rates of these applications arepeculiarly higher than the 28.8 kb/s TETRAmaximum data bit rate.

In May 2000 Project MESA [3] was intro-duced to define a new platform and a set of MCrequirements that aim at forming an advancedPSDR telecommunication network with animproved bit rate of 2 Mb/s. In 2007, Motorolaannounced MOTOA4 [4], a suite of proprietarynetwork solutions leveraging the ubiquity of theIEEE 802.11n to form a wireless outdoor meshwide area network (MWAN). MOTOA4 oper-ates at high data bit rates of 300 Mb/s and offersfull ASTRO interoperability. However, itsdeployment has been restricted to urban areasonly.

In a similar timeline, public networks havebeen preceding the MC sector in terms of tech-nological evolution and market deployments.Recently, the integration of Ethernet passiveoptical network (EPON) and WiMAX has beenpresented as the evolutionary next step towardthe convergence to a high-speed wireless andcost-effective broadband access network [5–7].More attractively, EPON and WiMAX perfectlymatch in terms of capacity hierarchies and designpremises. EPON, for instance, supports a totalof 1 Gb/s bandwidth in both downstream andupstream directions, shared by typically N ≤ 32

ABSTRACT

The convergence of optical and wireless net-works has been envisioned recently as an attrac-tive economic broadband access solution; yet, itsusage has been restricted to public users only.To serve mission-critical services in public safetyand disaster relief communications using thefiber-wireless integration, key challenges such asfault recovery, security, and quality of serviceassurance must be addressed. This article intro-duces MC-FiWiBAN, a new emergency-awarearchitecture that leverages layer 2 virtual privatenetworks to support mission-critical services overthe integration. Each virtual private network cor-responds to a specific mission-critical systemrequirements bundle that is stipulated in the ser-vice level agreement and fulfilled via an effectiveresource management paradigm. Simulationresults show that MC-FiWiBAN can commitguaranteed quality of service for emergency andnon-emergency services.

TOPICS IN OPTICAL COMMUNICATIONS

Ahmad R. Dhaini and Pin-Han Ho, University of Waterloo

MC-FiWiBAN: An Emergency-AwareMission-Critical Fiber-WirelessBroadband Access Network

DHAINI LAYOUT 12/16/10 12:29 PM Page 134

IEEE Communications Magazine • January 2011 135

remote optical network units (ONUs). On aver-age, each ONU accesses ≈ 70 Mb/s bandwidth,which matches the total capacity offered by aWiMAX base station (BS) over a 20 MHz chan-nel. In addition, the integration enables integrat-ed resource allocation and packet schedulingparadigms that help to better support the emerg-ing quality of service (QoS) applications, as wellas improve the overall network throughput. Fur-thermore, the integration can help realize fixedmobile convergence (FMC) by supporting mobil-ity in the broadband network access, thereby sig-nificantly reducing network design andoperational costs [5].

The article aims at taking advantage of thepublic network evolution to support MC servicesover the fiber-wireless (FiWi) integration. In thiscontext, we propose MC-FiWiBAN (Fig. 1), anew emergency-aware architecture that can helpextend the MC multimedia service coverage torural areas, as well as improve the PSDR useraccess to the IP-based network core. PSDR andMC services require high security, custom net-work control, and fast network access, in addi-tion to a fine degree of QoS assurance andbandwidth guarantees. MC-FiWiBAN enforcesthese features via the construction of a layer 2virtual private network (VPN), which has beenwidely established in wired networks and is con-sidered a killer application in modern Internetcarriers [8, 9].

Figure 1 shows how MC-FiWiBAN can beeasily integrated with the TETRA infrastructure(i.e., TETRA switching and management infra-structure [SwMI]) using IP/Ethernet as the inter-face between the optical line terminal (OLT)and an Internet gateway (IGW) located at theTETRA SwMI. The main function of an IGW is

to hide from the SwMI the anomalies of MC-FiWiBAN, thereby achieving seamless integra-tion with almost no SwMI changes [10]. Asimpler strategy would be to directly embed theOLT as part of the SwiMI infrastructure; howev-er, a special interconnection agreement will thenbe required to preserve and/or lease the properTETRA authorizations to the access network. ATETRA radio user is envisioned to operate as adual-mode terminal capable of supporting bothTETRA and WiMAX radio/air interfaces inorder to provide full interoperability betweenMC units and systems across these heteroge-neous networks.

With MC-FiWiBAN, the article attempts toprovide an effective solution to the resourcemanagement problem — one of the key issuesthat arise in VPN construction over a sharednetwork infrastructure. A resource allocationframework is presented to achieve a guaranteedQoS level for MC services as defined in theVPN service level agreement (SLA). To the bestof our knowledge, this is the first work that con-siders the support of MC services over EPON-WiMAX.

The rest of the article is organized as follows.We first overview MC systems. We next presentMC-FiWiBAN by highlighting the main keyissues in the aspects of design and implementa-tion. An illustrative simulation example is thenpresented, and we finally conclude the article.

MISSION-CRITICAL SYSTEMSDifferent from public systems, an MC systemrequires a set of unique services and networkrequirements. In this section we brieflyoverview different types of multimedia services

Figure 1. MC-FiWiBAN supporting MC VPNs and integrating with TETRA networks. In safety-critical places (e.g., hospitals [H]), anetwork bridge may be used to connect ONU and BS, such that the BS is placed a small distance away from its designated safety-criti-cal site.

OLT

TETRASwiMI

(IP-based)

IP-basednetwork

c ore

IP/Ethernet

Internet/Gateway(IGW)

Fire intranet

PoliceIntranet

Hospitalintranet

Remote expert

Remote expert

Remoteexpert

Splitter1:N

20 Km

Remotedatabase

TETRAnetwork

TETRAnetwork

OLT: Optical line terminalONU: Optical network unitBS: WiMAX base stationSS: subscriber stationBridge: network bridge (optional)

Note: ONU and BS can be mounted in onebox (so-called ONU-BS).

TETRAuser/terminal

TETRA site

Remotedatabase

FireHQ

Firestation

ONU

Bridge

BS

SS

SS

SS

Remote database

SS

H

Clinic

ONU

BridgeBS

SS

SS

SS

SS

AMBULANCE

AMBULANCE

AMBULANCE

AMBULANCE

Policestation

PoliceHQ

ONU

Bridge

BS

SS

SS

Mobile MC units

SSSS


IEEE Communications Magazine • January 2011136

envisioned to extensively appear in such a sys-tem. We also highlight the main networkrequirements for ensuring robust MC servicesupport.

MISSION-CRITICAL SERVICESWith the emerging multimedia MC services,PSDR users can establish audio/video calls orshare images and other miscellaneous MC infor-mation. These services (Fig. 2a) possess strin-gent QoS and security requirements that need tobe fulfilled via an effective network solution.Typically, an MC service may belong to one ofthe following categories:• Emergency (asynchronous): A one-way mes-

sage (or flow of short length) is triggered byan emergency event (e.g., fire event, crimi-nal pursuit or an alarm by a health moni-toring system) and requires immediatedelivery/broadcast.

• Real-time (synchronous): It can be as simpleas telephone calls or as complex as sophisti-cated virtual-reality robotic surgery. It canalso be used for monitoring of long-termcare agents by establishing videoconferenc-ing. A particular example of a real-timeapplication is the live video surveillance sys-tem. The deployment of such a system overMC-FiWiBAN, as shown in Fig. 2b, canprovide a secure and robust wireless con-nection that eliminates the wiring/rewiringoverhead of conventional surveillance sys-tems.

• Store-and-forward (asynchronous): Itsupports delivery of non-emergency MCdata (images, bio-signals, etc.) to special-ists for e-consultation, evaluation, orother purposes. It does not require inter-active communications between involvedparties in real time; however, high dataintegrity and bandwidth guarantees arecrucial.

MISSION-CRITICAL NETWORK REQUIREMENTS

In addition to security and reliability, an MCnetwork must fulfill the following salient require-ments:1• Operability: The ability to establish and sus-

tain communications between different MCunits during an MC event

• Interoperability: The ability of all MC units(from all levels and disciplines) to commu-nicate among each other as authorized andas needed, regardless of their network capa-bilities

• Continuity of Communications: The abilityto maintain communications, even in theevent of a network failure

It is therefore essential that any designed oradopted network solution must sustain thesenetwork requirements to perpetuate the diverseQoS requirements of MC services.

MC-FIWIBANAs described, the deployment of MC systemscompels a set of features to be available in theunderlying network. In this section we discernthe building blocks of MC-FiWiBAN to embracethese distinctive attributes.

LAYER 2 VPNS OVER EPON-WIMAXAn MC system provisions a specific bundle ofservices with different QoS requirements to itsusers. To support these services over EPON-WiMAX, we propose to develop layer 2 VPNsover the EPON-WiMAX infrastructure; eachVPN corresponds to a specific service require-ment bundle issued by a registered system [9].Such VPNs are referred to as layer 2 VPNs inthe sense that they are built on the layer 2 pro-tocols.

Compared to layer 3 VPNs, layer 2 VPNs canbetter resolve complications due to network

Figure 2. a) Envisioned mission-critical applications and services; b) an illustration of a surveillance system over MC-FiWiBAN.

Bedroom Living Room

HeadquartersSSSS

ONU-BS

VPN EPON

Home patient monitoring

Heart

Remote consulting Event coverage and tracking

Robotic surgery Mobile medical units (MMUs)

(a) (b)

Electro-cardiogram

Living roomBedroom

1 In 2005 the U.S. Depart-ment of Homeland Secu-rity (DHS) activated acommunications pro-gram, Safecom(http://www.safecompro-gram.gov), which aims atimproving emergencyresponses through wirelesscommunications. Safe-com has also listed thesame features as emergen-cy requirements.



dynamics and fast wireless changing channel sta-tus [9]. In addition, layer 2 VPNs provide strongsupport for premium services with custom-designed control of layer 3 routing and IPaddressing, diverse QoS requirements, and secu-rity assurance, as well as the features intrinsicallyexhibited in the medium access control (MAC)layer [8]. These attributes are vital in the courseof MC service support over the EPON-WiMAXintegration.

With the initiation of layer 2 VPNs direct-ly on the integration, users of each registeredsystem can dynamically configure their ser-vice requirements and possibly issue call pre-emption requests through a suite of serviceaccess points (SAPs) and interfaces that aremanipulatively maintained in the correspond-ing VPN package. This property is essentialto an MC system where stringent bandwidthguarantees and call preemption requests arepresent [3]. Furthermore, such VPNs enableinteroperability between fixed and mobileplatforms.

The layer 2 VPN requests that are issuedby the users can be handled within the MCorganization without the need to involve fur-ther overlay and additional VPN agents [8]. Asa result, the classified nature of MC operationsis preserved; and the constantly changing MCunits’ locations, especially in mobile tacticalscenarios, are easily handled. Meanwhile, sur-vivabil i ty of the end-user services can beenhanced by multihoming,2 which can easilybe manipulated in the layer 2 VPNs [8]. TheVPN applications can determine if a usershould be associated with multiple ONU-BSsthrough separate air interfaces, so as to enablefast fault recovery, which is vital to the MCscenario.

VPN TUNNELING

As depicted in Fig. 3, we classify an MC-FiWiBAN VPN tunnel as either interdomain orintradomain:• Intra-domain: A tunnel is established

between customer edges (CEs) that belongto the same architectural domain (e.g.,between two WiMAX subscriber stations[SSs]).

• Inter-domain: A tunnel is establishedbetween CEs that belong to different archi-tectural domains (e.g., between the OLTand an SS).To achieve operability, a VPN tunnel is to be

established such that sufficient resources areallocated in MC-FiWiBAN (in both theuplink/upstream and downlink/downstreamdirections) and in the optical ring. The downlinkresource allocation is argued to be deterministic,due to being broadcast in nature under EPON-WiMAX [5, 7]. Hence, the article focuses on theuplink/upstream resource management problemin MC-FiWiBAN.

FAULT TOLERANCE AND ERROR RECOVERYTo maintain service continuity, a fast recoveryfrom any possible unexpected failure is required.In MC-FiWiBAN a VPN tunnel may fail due tothe following reasons:• A damage in the wireless link between the

ONU-BS and the wireless user (an intrado-main VPN error)

• A fiber cut between the ONU-BS and thesplitter (a hybrid inter-/intradomain VPNfault)

• A fiber cut between the splitter and theOLT (a hybrid inter-/intradomain VPNerror)

Figure 3. VPN tunneling in MC-FiWiBAN.

Point-to-multi-point(PMP)

Mesh

CO

Optical Ring

PE

PE ONU-BS Optical network unit-base station

Optical line terminal

Provider edge

CO Central office

CO

PE

COInter-domainVPN tunnel

PE

CE

CESS CE

SSSS

SS SS

CE

Intra-domainVPN tunnel

Inter-domainVPN tunnel

ONU-BS

ONU-BS

ONU-BS ONU-BS

ONU-BS

ONU-BS

ONU-BS

ONU-BS

ONU-BS

SS

SS

SS

SSCE

SS

SS SS

SS

SS

SS SS

SSCE

CE Customer edge Optical link

Wireless linkSS Subscriber station

SS

SS

SS

SS

SS

SS

CE

SS

OLT

Bidirectional

OLT

OLT

OLT

2 Multihoming refers to asingle host making use ofseveral connections asso-ciated with various inter-connected networks.



• A fiber cut on the metro ring, causing dam-age to the interdomain established VPNEnabled via multihoming, fast fault recovery

can be attained through the following strategies.If the wireless channel between the ONU-BSand the SS is deteriorated, the VPN tunnel canbe rerouted to another ONU-BS in range usinga direct connection (in the case of point-to-mul-tipoint [PMP] topology), or through a multihoproute (in the case of mesh topology with theONU-BS not in range) [11]. Similarly, if a fibercut occurs between an ONU-BS and the splitteror between the OLT and the splitter, the failurecan be averted by establishing communicationwith an alternative ONU-BS of a neighboringEPON-WiMAX network, to reach its networkboundary by means of the bidirectional metroring, which is also fault-tolerant by nature [12].Such a strategy cannot be performed in tradi-tional PONs and/or WiMAX networks [6].

These routing stratagems can easily be accom-modated in layer 2 through specialized routingagents (located at each network boundary) tomaintain service continuity of the VPNs.Nonetheless, other layer 3 FiWi routing proto-cols [11] may alternatively be adopted to servethe same purpose.

EMERGENCY-AWARE QOS SUPPORTAs mentioned, QoS requirements are specifiedin the SLA of each VPN. To support QoS in theMAC, the IEEE 802.16 standard defines fiveclasses of service (CoSs): unsolicited grant ser-vice (UGS), real-time polling service (rtPS),embedded real-time polling service (ertPS)(defined in IEEE 802.16e), non-real-time pollingservice (nrtPS), and best effort (BE) [13]. AnMC service plan typically comprises two types ofdata:• Regular periodic traffic (i.e., real-time or

store-and-forward) that is transmitted fre-quently

• Emergency messages that are highly erraticbut extremely delay-sensitiveAs shown in Table 1, QoS support for regular

MC traffic can be achieved by mapping each ser-vice to one of the WiMAX CoSs based on itstype and QoS requirements. On the other hand,emergency traffic requires QoS protection andimmediate transfer; therefore, it should not bemixed with other types of services. For this rea-son, we define a new IEEE 802.16 CoS, emer-gency grant service (EGS). EGS has the highestpriority, over all other services, and possessesstringent QoS requirements. Moreover, due toits erratic nature and sporadic occurrence (e.g,once in several weeks/months), EGS traffic isreported to the ONU-BS whenever an emergen-cy event occurs, and is placed in a separatebuffering queue.

EGS not only reduces the control overheadcaused by reporting the bandwidth needs in eachpolling interval (PI), but also eliminates thewaste of bandwidth caused by reservingresources for emergency services in each PI (incase the UGS approach is applied)3 [13]. With aseparate buffer, EGS also facilitates the imple-mentation of a service preemption mechanismrequired in emergency situations with congestednetworks.

SERVICE CLASSIFICATION AND COS MAPPINGThe design of a MAC protocol that arbitratesthe transmission of MC users over the sharedMC-FiWiBAN resources requires an MC serviceclassification at both the end user/SS and ONU-BS.

At the SS — Table 1 shows the mapping of theenvisaged MC users’ applications to the IEEE802.16 CoSs of each SS. This classification makesMC-FiWiBAN scalable in the sense that the sup-port of more users will then require no changes,especially to the adopted resource allocation

Table 1. Envisaged multimedia applications/service classification and CoS mapping.

Service type ApplicationQoS requirements

IEEE 802.16CoS

Data bit rate One-way end-to-end delay Jitter

Emergency call/event Device/human trigger 2–5 kb/s ≤10 ms N/A EGS

AudioDiagnostic (interactive) 4–25 kb/s ≤1 s ≤1 ms UGS

Conferencing (real-time) 5–70 kb/s ≤150 ms ≤1 ms UGS

VideoVideo streaming 1–6 Mb/s ≤10 s N/A nrtPS/rtPS

Conferencing (real-time) 20 kb/s–1 Mb/s ≤250 ms N/A rtPS

Monitoring services

Enhanced telemetry (real-time) 20–50 kb/s ≤250 ms N/A rtPS

MC data transfer 20–50 kb/s ≤250 ms N/A nrtPS

Bulk data transfer 50 kb/s–few Mb/s ≤10 s N/A nrtPS

Multimedia transfer Routine activities 100 kb/s–few Mb/s ≤10 s N/A nrtPS

Best effort (BE) Email/web browsing Minimum throughput BE

3 In WiMAX UGS trafficis not reported by the user.Instead, a fixed share ofbandwidth is allocated inevery PI for each admittedUGS flow.



schemes, since the VPN-to-MAC mapping, viathe predefined SAPs, will implicitly take care ofsatisfying its requirements without compromisingthe QoS level of existing services.

At the ONU-BS — According to the IEEE802.13ah standard, an ONU is allowed to sup-port and report up to eight queues [5]. To pre-serve the standard, we install a total of six queuesat the ONU-BS and then perform a simple one-to-one CoS mapping.

VPN RESOURCE MANAGEMENTOur previous work in [9] introduced the firstframework to address the resource managementproblem of layer 2 VPNs over EPON-WiMAX.The proposed framework, WiMAX-VPON, con-sists of a QoS-provisioning paradigm and a jointVPN-based access control (AC) and uplink/

upstream dynamic bandwidth allocation (DBA)mechanism. WiMAX-VPON ensures bandwidthguarantees for each VPN service and protects itsQoS. In this work we extend WiMAX-VPON tosupport MC services and requests.

VPN-Based QoS Provisioning — With the newframework, the effective upstream VPON cycleTeff

VPON, which is the upstream optical PI lengthminus the control overhead caused by the pollingand requesting signaling, is divided into two sub-cycles. As illustrated in Fig. 4, the first subcycleβTeff

VPON is shared among all K VPNs, whereasthe second subcycle (1 – β)Teff

VPON is sharedamong non-VPN services (to support legacyusers as well). Note that Teff

VPON can be obtainedeither via simulations by measuring the signalingoverhead rate or analytically [14].

Let Bkmin be the bandwidth reserved for VPN

Figure 4. MC-FiWiBAN QoS-provisioning paradigm with K = 4 VPNs; all supported by ONU-BSs 1, 5, 8,and 10. These ONU-BSs provision V4 services through SSs 3, 4, 6, and 9. In turn, SS3 accommodates V4requests. EGS4

3 means EGS bandwidth belongs to SS3 and V4.

Each SSaccomodatesmultiple VPN

service requests

Each ONU-BSprovisions multiple

VPNs

B1

βTVPONeff

(1 − β)TVPONeff

αkB1

VPN 1

BE43UGS4

3EGS43 . . . . . .

BE

ONU-BS1

Guard time

Real-time traffic

VPN 2 VPN 4 non-VPN

Control overhead

VPN 3

(1-αk)B1min

min

min

SS3

ONU-BS5 ONU-BS10

SS4 SS9SS4

ONU-BS8

EGS not only reduces

the control overhead

caused by reporting

the bandwidth needs

in each polling

interval (PI), but also

eliminates the

wastage of

bandwidth caused

by reserving

resources for

emergency services

in each PI (in case

the UGS approach

is applied).



k (denoted Vk) in each PI, and RN the transmis-sion speed of PON in megabits per second. Inaddition, let each Vk be given a weight wk todetermine its agreed upon bandwidth share. Bk

min(in bytes, thus divide by 8) is then computed asfollows:

To guarantee a minimum per-VPN SLA-based throughput for BE traffic and in order toeliminate starvation (in case of the admission ofa large number of EGS or real-time flows thathave higher priority), we reserve a portion ofαkBk

min. As a result, all the Vk real-time andemergency flows share the (1 – αk)Bk

min remain-ing bandwidth.

A Joint VPN-Based AC and DBA Mechanism— To guarantee a per-VPN QoS assurance inthe uplink/upstream direction, a joint VPN-based AC and DBA scheme is proposed comple-menting the proposed QoS provisioningframework [9].

With MC-FiWiBAN, VPN-AC admits allEGS and BE flows. Each admitted BE flowshares its reserved portion αkBk

min with all other

BE flows belonging to Vk, while an EGS flow isalways satisfied. Adversely, a constant bit rate(CBR, e.g., UGS) flow is admitted if its meanrate can be accommodated in both the wirelesstotal capacity and VPN bandwidth share. On theother hand, for variable bit rate traffic (VBR,e.g., rtPS and nrtPS), a guaranteed rate (with spe-cific delay requirements) is extracted from thearrival process passing through a dual-tokenleaky bucket (DTLB) situated at the MAC bufferentrance. Consequently, a VBR flow is admittedif its guaranteed rate can be accommodated inthe network.

The proposed VPN-DBA is installed at theOLT, and each ONU-BS and mainly divideseach upstream/uplink cycle/frame into two sub-cycles. The first subcycle is used to allocate guar-anteed bandwidth for admitted EGS andreal-time traffic, whereas the second subcycle isused to allocate BE traffic per VPN. Moreover,in addition to the MAC requests, VPN-DBAtakes into consideration the physical layer (PHY)burst profile associated with each wireless linksuch that a statistical QoS guarantee is achieved[9]. However unlike in [9] where EGS was notsupported, if the uplink channel is overloadedand an emergency event occurs, a call preemp-tion mechanism is designed to borrow enoughbandwidth from the BE quota to serve the

BT R w

wk effVPON

N kk

k

K

min , .=× × ⎛

⎝⎜

⎞

⎠⎟=

=∑

β

8 11

where

Figure 5. One-way end-to-end average packet delay with and without our AC framework (90 percent confidence interval): a) EGS flow;b) UGS flow; c) rtPS flow; d) nrtPS flow.

Number of VPN users

End-to-end (SS to OLT) average packet delay

(a)

160

> 10 ms

> 100 ms

< 10 ms< 10 ms

> 1 s

Systemsaturation

Systemsaturation

Systemsaturation

Systemsaturation

0

0.005

0

Ave

rage

pac

ket

dela

y (s

)

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045

0.05

176 192 208 224 240144128112968064483216

Number of VPN users


(c)

160010-4

Ave

rage

pac

ket

dela

y (s

)

100

101

176 192 208 224 240144128112968064483216Number of VPN users


(d)

160010-4

Ave

rage

pac

ket

dela

y (s

)

10-1

10-1

10-2

10-2

10-310-3

100

176 192 208 224 240144128112968064483216

Number of VPN users


(b)

1600

0.005

0

Ave

rage

pac

ket

dela

y (s

)

0.01

0.015

0.02

0.025

0.03

0.035

0.04

0.045

0.05

176 192 208 224 240144128112968064483216

AC-FTRAC-MTRNO-AC-FTRNO-AC-MTR





incoming EGS flow(s). The borrowed bandwidthis then re-allocated back to BE traffic once allemergency flows are served and satisfied.

SIMULATION RESULTSIn our illustrative simulation example we set theWiMAX-VPON parameters as follows: numberof ONU-BSs N = 16, ∀k, αk = 0.1, β = 1, K =4, and RN =1 Gb/s. The WiMAX total band-width is equal to 20 MHz. Vk is randomly gener-ated for each connecting SS. Without loss ofgenerality, we assume that all MC systems (i.e.,VPNs) have equal weights (wk). We also consid-er various adaptive modulation and coding(AMC) modes for different SSs (i.e., binaryphase shift keying [BPSK], quaternary phaseshift keying [QPSK], and M-quadrature ampli-tude modulation [QAM]).

To stress test our framework, we assume thateach SS has five flows (i.e., EGS, UGS, rtPS,nrtPS, and BE). We inject each EGS flow at arate of 5 kb/s. Every UGS flow is generated witha guaranteed rate of 64 kb/s [9]. Each rtPS flow isgenerated at a guaranteed rate of 5 Mb/s (whichis the average bit rate of a DVD-quality video[9]), and each nrtPS flow is generated with aguaranteed rate of 500 kb/s [9]. Each self-similarBE flow is generated at a mean rate of 1 Mb/s.

The number of VPN users increments by ⎪N⎪with time and reflects the attempt to connect anew MC unit to each ONU-BS simultaneously.Our framework is evaluated vs. the MC QoSrequirements listed in Table 1. We consider twosimulation scenarios: fixed transmission rate(FTR), where all SSs have the same fixed transmis-sion rate, and multiple transmission rates (MTR),where a random AMC is selected for every SS.

Figures 5 and 6 show the end-to-end averagepacket delay for EGS and real-time flows of atagged SS, and the total per-VPN BE trafficthroughput, respectively. As noticed, althoughable to meet the QoS requirements for someservices (e.g., UGS and nrtPS), typical resourcemanagement schemes (with no AC) are unableto maintain the QoS requirements for all MCVPN services, especially after system saturation.

On the other hand, the application ofWiMAX-VPON (with AC) is able to maintainthe QoS requirements for all types of services (interms of delay and throughput). This proves theeffectiveness of our framework in maintainingnetwork stability as well as ensuring and protect-ing the QoS level for all types of traffic. Figure 6also shows how the bandwidth borrowing mecha-nism may affect the overall BE throughput. How-ever, in our simulations flows never leave thenetwork; therefore, by giving up some of itsbandwidth quota, the total V3 BE traffic witness-es permanent throughput degradation.

CONCLUSION AND FUTURE WORK

CONCLUSIONThis article presents MC-FiWiBAN, a new emer-gency-aware fiber-wireless (FiWi) access net-work that leverages layer 2 VPNs over theEPON-WiMAX integrated network to providestate-of-the-art mission-critical service support.MC-FiWiBAN extends MC coverage to rural

areas and improves PSDR communications byendorsing the emerging MC multimedia services.A QoS provisioning framework was also present-ed to address the resource management problemarising from the establishment of VPNs. Oursimulation results proved the effectiveness ofMC-FiWiBAN in guaranteeing the QoS require-ments for different types of services.

FUTURE WORKWhile the presented simulation results provedthe effectiveness of MC-FiWiBAN, real deploy-ment scenarios and experiments can be of greatadded value to further highlight the advantagesof MC-FiWiBAN. Such experiments need toconsider large cities and areas where TETRA-based and MC-FiWiBAN-based systems withdual-mode users are deployed. These users willthen be configured to intercommunicate throughthe proposed architecture. Consequently, mobili-ty management will emerge as a theme thatneeds to be handled in the new architecture. Notonly will seamless handoff techniques berequired, but scenarios where PSDR users roambetween TETRA and MC-FiWiBAN coveragezones will require special handover protocolsthat consider the physical layer heterogeneity ofboth networks. Furthermore, other VPN relatedissues such as VPN gateway design and configu-ration, as well as advanced VPN resource man-agement paradigms may also be addressed.

As a final note, the key advantages of MC-FiWiBAN are summarized as follows:• Robustness: By constructing layer 2 VPNs

and performing the proper error recoveryand resource management strategies, MC-FiWiBAN can be more robust than legacywired and wireless networks (e.g., tradition-al PONs, WiMAX, and WiFi) that also pos-sess limited reaching abilities.

• Centralized operation and management: MC-FiWiBAN not only provides high-speedmobile access in rural areas, but alsoenables centralized control over the net-work resources (bandwidth and channel) atthe OLT using its operation, administra-tion, and management (OAM) unit.


Figure 6. Total per-VPN BE throughput.

VPN ID

Borrowed Bandwidth

α = 0.1 ⇒ BE quota ≈ 24.5 Mb/s

1

5

0

Tota

l BE

thro

ughp

ut (

Mb/

s)

10

15

20

25

30

35

2 3 4

No AC-MTRAC-MTRNo AC-FTRAC-FTR



• VPN interoperability: By deploying layer 2VPNs, MC-FiWiBAN provides an integrat-ed VPN service suite that enables interop-erability between fixed and mobileplatforms.

• Scalability: The installation of WiMAX net-works in rural areas enables seamless sup-port of more users and services, such thatno modifications are required to the alreadyinstalled equipment and layer 2 protocols.

• Improved TETRA services: Due to theincreased bit rates of MC-FiWiBAN,TETRA (V+D) services’ limitations (e.g.,call setup delays) can be considerablyimproved. Furthermore, the emerging MCmultimedia applications can be supportedseamlessly.

ACKNOWLEDGMENTSThe authors would like to thank Prof. AbdallahShami (UWO, Canada) and Dr. James She(Cambridge, United Kingdom) for their insight-ful feedback on this work.

REFERENCES[1] ETSI EN 300 392-2 V2.5.2, “Terrestrial Trunked Radio

(TETRA); Voice plus Data (V+D); Part 2: Air Interface(AI),” May 2006.

[2] TETRA; http://www.tetramou.com/.[3] Project MESA; http://www.projectmesa.org.[4] MOTOA4;

http://business.motorola.com/MOTOA4/index.html.[5] G. Shen, R. S. Tucker, and C.-J. Chae, “Fixed Mobile

Convergence Architectures for Broadband Access: Inte-gration of EPON and WiMAX,” IEEE Commun. Mag.,vol. 45, no. 8, Aug. 2007, pp. 44–50.

[6] S. Sarkar, S. Dixit, and B. Mukherjee, “Hybrid Wireless-Optical Broadband-Access Network (WOBAN): A Reviewof Relevant Challenges,” IEEE/OSA J. Lightwave Tech.,vol. 25, no. 11, Nov. 2007, pp. 3329–40.

[7] J. She and P.-H. Ho, “Cooperative Coded Video Multicastfor IPTV Services under EPON-WiMAX Integration,” IEEECommun. Mag., vol. 46, no. 8, Aug. 2008, pp. 104–10.

[8] W. Luo et al., Layer-2 VPN Architecture, CISCO Press,2005.

[9] A. R. Dhaini, P.-H. Ho, and X. Jiang, “WiMAX-VPON: AFramework of Layer-2 VPNs for Next-Generation AccessNetworks,” IEEE/OSA J. Optical Commun. Net., vol. 2,no. 7, July 2010, pp. 400–14.

[10] A. K. Salkintzis, “Evolving Public Safety Communica-tion Systems by Integrating WLAN and TETRA Net-works,” IEEE Commun. Mag., vol. 44, no. 1, Jan. 2006,pp. 38–46.

[11] S. Sarkar et al., “A Novel Delay-Aware Routing Algo-rithm (DARA) for a Hybrid Wireless-Optical BroadbandAccess Network (WOBAN),” IEEE Network, vol. 22, no.3, May 2008, pp. 20–28.

[12] S. Spadaro et al., “Positioning of the RPR Standard inContemporary Operator Environments,” IEEE Network,vol. 18, no. 2, Mar. 2004, pp. 35–40.

[13] IEEE, “IEEE Standard for Local and Metropolitan AreaNetworks Part 16: Air Interface for Fixed BroadbandWireless Access Systems,” 2004.

[14] A. R. Dhaini, P.-H. Ho, and X. Jiang, “PerformanceAnalysis of QoS-Aware Layer-2 VPNs over Fiber-Wireless(FiWi) Networks,” Proc. IEEE GLOBECOM ‘10, Miami, FL,Dec. 2010.

BIOGRAPHIESAHMAD R. DHAINI ([email protected]) received hisB.Sc. in computer science from the American Universityof Beirut (AUB) in 2004, and his M.App.Sc. in electricaland computer engineering from Concordia University,Montreal, Canada, with a best thesis award nominationin 2006. He worked as a software consultant at TEKSys-tems, Montreal, in 2006–2007; and as a software design-er at Ericsson, Montreal, in 2007–2008. He is currentlyworking toward his Ph.D. degree in electrical and com-puter engineering at the University of Waterloo. Hisresearch interests focus on optical/wireless broadbandaccess networks.

PIN-HAN HO ([email protected]) received his Ph.D.degree from Queens University, Kingston, Ontario, Canada,in 2002. He is now an associate professor in the Depart-ment of Electrical and Computer Engineering, University ofWaterloo, Canada. His current research interests cover awide range of topics in broadband wired and wirelesscommunication networks, including survivable networkdesign, wireless metropolitan area networks such as IEEE802.16 networks, fiber-wireless network integration, andnetwork security.

While the presented

simulation results

proved the

effectiveness of

MC-FiWiBAN, real

deployment

scenarios and

experiments can be

of great added value

to further highlight

the advantages of

MC-FiWiBAN.


Documents

MC-FiWiBAN: An Emergency-Aware Mission-Critical Fiber ...staff.aub.edu.lb/~ad57/documents/MC_FiWiBAN_COMMAG.pdf · thermore, the integration can help realize fixed mobile convergence