end-to-end qos in integrated wireless and sensor network ...donny/papers/endtoendqos.pdf ·...

End-to-End QoS in Integrated Wireless andSensor Network: System Implementation

Manikanden Balakrishnan, Dong Han, Driss Benhaddou and Xiaojing YuanUniversity of Houston, Houston, USA

{mbalakrishnan, dhan4, dbenhaddou, xyuan}@uh.edu

Abstract—Information prioritization would be crucial forseveral emerging applications of wireless and sensor net-works (WSNs) that require real-time event monitoring (dis-aster/intrusion monitoring, industrial automation, telemedi-cine). The current Quality-of-Service (QoS) literature forsensor applications is still premature, since most of the de-velopment efforts were focused on energy efficiency and sen-sor mote development. In this paper, we provide a systemconfiguration of end-to-end QoS in an environmental moni-toring network comprising local sensor and back-haul WiFinetwork technologies. We also demonstrate the performancegains achieved through rated bandwidth allocation for thesensor data flow across the integrated WSN. Key words:Wireless/Sensor Network, QoS

I. INTRODUCTION

Integrated sensor and wireless networks are envi-sioned to provide breakthrough benefits in real-time bor-der/intrusion monitoring and emergency (disaster) track-ing applications due to autonomous de-centralized andad-hoc network operation. These emerging applicationsare driving the need to focus on sensor network Quality-of-Service (QoS) support, since information prioritizationand service differentiation would be crucial in real-timeperformance monitoring wireless sensor applications. Thecurrent QoS literature for sensor networks is prematureas considerable focus and effort was on energy efficiencyand mote/interface development.

The QoS work for general wireless and mobile net-works [1, 2] provide tremendous leverage, since theycould be extended/optimized for use in sensor networks.The basic traffic definitions and service requirementsshould be re-formulated for sensor applications; for exam-ple, the traf-fic priorities would be classified as Routine,Alarm and Emergency in a performance monitoring sys-tem. Another fundamental difference is that an end-to-endsensor te-lemetry system is typically heterogeneous; localsensor networks are connected to gateways that are inter-faced to long-range back-haul wireless networks. Thus,an end-to-end QoS performance demands preservation ofthe traffic priorities across these heterogeneous wirelessinter-faces.

In this paper, we take these fundamental differencesinto consideration and implement a performance moni-toring sensor network with end-to-end QoS support. Webelieve that our work will be a demonstration of theessential components in designing QoS framework fornext-generation sensor applications.

A. Applications

The need for QoS in sensor networks is best describedby the emerging sensor applications (Fig.1).

Crew health and geo-station environment monitoringduring space exploration has long been one of NASA’sprimary tasks. There is a stronger emphasis on developingon-board wireless monitoring, data processing and localfeedback infrastructure for emergency mitigation, whichis specifically crucial for healthcare applications. TheInternational Space Station requires continual atmospheremonitoring for gas and water vapor levels [3], and thedistributed sensor systems could benefit significantly fromwireless networks.

Industrial sensor network [4] for continuous andautono-mous monitoring of critical equipments in pro-cess plants for alarming/predictive maintenance is anothermajor commercial application requiring network QoSsupport. Distributed sensor networks find most of therecent appli-cations in disaster/threat monitoring [5] andthe network ability to report emergency events withincertain time bound is important for such applications.

B. Related Work and Novelty

Testbed development for sensor networks are plenty,but works that address differentiated traffic servicesin heter-ogeneous architectures across diverse wireless

Real time Oxygen-level monitoring in space station/

Continuous equipment monitoring in process plants

Control room

Mesh sensor network

Centrally controlled sensor network

Room 1 Room 2

�

Hospital

Doctor location: physiological

condition estimation, response

advisory

Medical sensors form a

1-hop body network to

the head node.

Head node: Performs

local processing, external

communication Mesh wireless network

interface between patients and

doctor devices.

Wireless Health Monitoring

Fig. 1. Sensor Applications Requiring End-to-End QoS

WSN-1

978-1-86135-369-6/10/$25.00 ©2010 IEEE

886 CSNDSP 2010

technolo-gies are scarce. The work presented in [6] pro-posed a one-hop WSN architecture for health monitor-ing, in which sensors are directly connected to a PDA(sink), which provides the connectivity to a central server.Codeblue [7] and Alarmnet [8] are practical sensor meshnetwork platforms for enabling autonomous and remotehealth monitoring.

The WirelessHART [9] and ISA 100.11a [10] specifica-tions are new wireless/sensor network standards for in-dustrial process automation applications, developed forreliable wireless monitoring and alerting within industrialenvironments. From QoS perspective, the standards de-fine multiple levels of message priority based on the tar-get applications. In all the work discussed above there isno notion of gateway software translation of sensor QoSrequirements across the back-haul wireless network.

The uniqueness of our testbed is the firmware enhance-ment at the wireless and sensor gateway entities to trans-late the sensor QoS requirements across the back-haulnetwork. Addressing end-to-end QoS and preservation oftraffic priorities across heterogeneous wireless domains isnot addressed much in the literature, and this paper pro-vides an operational demonstration of such capabilities.Our demonstration is crucial in the context that sensordeployments for large-scale applications would inherentlyinvolve long-range wireless technologies for back-haulsupport, and relevant testbeds are crucial for QoS re-search.

II. NETWORK AND SOFTWAREARCHITECTURE

This section briefly describes the hardware and soft-ware components of our integrated wireless and sensornet-work.

The MicaZ [11] sensor motes are programmed withti-nyOS for sensing variety of environmental and systeminformation (light, temperature, battery-level) and com-municating to the sensor gateway over an 802.15.4 [12]network. The sensor gateway node is serially connectedto the WiFi gateway (Linux-PC), which is installed with3com wireless card driven by the open source Linux Mad-wifi driver [13]. The Madwifi driver provides a full im-plementation of the IEEE 802.11e Enhanced DistributedChannel Access standard [1], which is a QoS supportedchannel access protocol. The Madwifi EDCA driver en-ables traffic prioritization and differentiated bandwidthallocation in our end-to-end network.

The sensor motes and WiFi gateway form a local sensornetwork resource for monitoring a target area (labs/roomsin this prototype) and disseminating the information tothe central client. We need application level networkabstraction for sensor data flow across heterogeneouswireless communication interfaces i.e irrespective of theunderlying network standard, the sensor data has to flowseamlessly end-to-end. In our prototype, we leveragethe Bionet middleware [14] for network abstraction andenabling sensor data flow (client-server style) across thesensor-WiFi network.

We also use eBox-2300 [15], a compact PC with Win-dows Mobile software development environment, as aPDA/smart-phone based WiFi gateway. The purpose isto experiment with mobile back-haul gateways, whichwill eliminate the dependence on fixed infrastructure fordata routing from local sensor networks. The field sensorscommunicate to a base-station sensor (USB-connected toeBox) and a serial forwarder application extracts the rawinformation from the 802.15.4 frames, after which theexisting WiFi interface is used for back-haul distri-bution.

A background (BK) traffic source generates randomtraf-fic in the back-haul network to mimic realistic scenar-ios. Fig.3 summarizes the open-source software architec-ture of our network.

The Bionet [14] middleware provides an extensivehard-ware abstraction (hab) for MicaZ motes and var-ious net-work interfaces. Irrespective of the underlyingcommuni-cation network (WiFi, Ethernet, sensor), theBionet repre-sents a common application-network, seam-lessly ex-changing Bionet data. We employ this middle-ware to en-able data translation and transmission betweenthe sensor-WiFi interfaces.

Sensor-net resource

BK traffic

Client/End-User

Zigbee/802.15.4

WiFi with QoS(IEEE 802.11e EDCA)

Zigbee/802.15.4

Sensor-net resource

eBox 2300 compact PCSmart phone

emulator

��

��

��

��

��

��

��

��

��

��

�!��

��

��!�"

#��!��

��

� ��$�#%%

�!�&��

��

��

��

��

Sensor Gateway serially connected to PC (WiFi

Gateway)

Fig. 2. Wireless Sensor Network Architecture.

Fig. 3. Software architecture.

WSN-1 887 CSNDSP 2010

III. EXPERIMENT SETUP

This section details the network and traffic configura-tion used for our sensor QoS evaluation experiment.

A. Network Configuration

The first step is to set up the back-haul wireless networkfor end-to-end communication. The wireless network isenabled in managed mode (access point controlled), butthe channel allocation process is distributed (contention-based). The access-point (AP) is configured with a localIP address, ESSID, and 802.11g-protocol mode using theMadwifi commands

>> w l a n c o n f i g a t h 0 c r e a t e wlandev w i f i 0wlanmode ap

>> i w p r i v a t h 0 mode 3>> i w c o n f i g a t h 0 e s s i d ” Local−W i r e l e s s ”>> i f c o n f i g a t h 0 up 1 0 . 3 . 0 . 1

The AP machine will start sending periodic beacons to an-nounce the network. The other gateway machines are configuredas stations with the same network ESSID, mode and frequency-channel set by the AP. At this point, the stations received theAP beacons and established a WiFi network (the connectivitywas verified using ping).

The next step is to integrate the local sensor networks to theWiFi network, for which the Bionet middleware is in-stalled inall the machines. The Bionet-node application is installed in thefield sensor motes and gateway applica-tion is installed in thesink-mote, which is USB-connected to WiFi gateway. The fieldsensor motes send environ-mental data to the sink/WiFi-gateway,where the Bionet-hab extracts the information data and wraps itas Bionet application data for dissemination to all Bionet clientsacross the WiFi network.

Fig.4 shows a sample display, at the end-client machine, ofthe sensor information sourced from a local sensor network.Variety of environmental and system infor-mation (temperature,light-intensity, battery-level) from a field sensor node (0002) ispublished through the WiFi gateway (isso-desktop) to the centralclient, which is de-picted by the Bionet monitor application.Also, any spe-cific sensor information can be plotted in real-time for monitoring the trend.

The background traffic source is configured using the D-ITG traffic emulator [16]. The D-ITG application allows forthe explicit specification of traffic priority (IP TOS = 0x08 forBK), source/destination IP and port addresses, packet size, flowduration and other advance protocol parameters. The final stepis to setup the end receiver. In our experiments, one of themachines in the WiFi network is configured as the end-user ofall the local sensor data and the BK traffic. Sensor informationfrom variety of locations, wrapped as bionet data, flows into theend-user where the Bionet client application decodes them forprocessing, storage, and display.

B. Configuring Quality of Service (QoS)The MadWifi driver provides command-line control to dis-

able/enable the rated bandwidth allocation on every machinedynamically. If QoS is switched off, the priority queueing andcontention process of the IEEE 802.11e EDCA protocol isdisabled and all the packets are queued in the best-effort queue.In our specific case, the traffic priorities of sensor data and D-ITG background traffic are the same and there is no preferentialresource allocation for sensor data.

Enabling the QoS will activate the multiple priority queueingof Madwifi implementation. The queues are numbered 0-3 (0being the lowest priority) and the con-tention (back-ff) param-eters for each queue are defined as per the 802.11e standard[1].The sensor data is marked with highest priority (level 3)and the network background (BK) traffic is at level 1.

We modified the Madwifi driver to buffer the sensor datain level-3 queue. With this setup, the sensor data has higherprobability of winning channel transmission opportunity ascompared to BK traffic. Fig.5 depicts the firmware design, withand without QoS, in the gateway nodes.

IV. PERFORMANCE EVALUATIONAfter the network is configured, the field sensor nodes and

back-ground traffic sources are switched on to initiate the trafficflow. The sensor sources publish data every second and theBK traffic rate is varied from low to heavy. The backgroundtraffic flow sta-tistics was automatically generated by the D-ITG software [16]. For the estimation of sensor-flow statistics,we programmed the sensor client to log the sensor data andpost-process the traffic traces.

Fig.6 and 7 show the experimental results without and withQoS respectively. For BK traffic, we measure the Round TripDelay (RTD), which is a direct measure of channel accesslatencies.

For the sensor data, Inter-Message-Time (IMT) at the endreceiver is measured, which specifies the interval between suc-cessive sensor message arrivals from a specific source. Thepurpose is to measure the jitter in sensor message delivery,which is a reflection of the preferential network treatmentprovided to the sensor data in presence of BK traffic. TheBK traffic rate is progressively increased from 2.4 Mbit/s to6.4 Mbit/s by introducing new BK traffic flows during theexperiment process. Both RTD and IMT are measured end-to-end.

With sourcing rate of 1 message/s, IMT should ideally beclose to 1s at the receiver (with zero WiFi network delay). Theamount of deviation from the reference 1s line indicates thedegree of jitter in sensor data arrival, and we can clearly see asignificant reduction in sensor data jitter after QoS is enabled(fig.6). Consequently, with QoS, RTD of BK traffic increases10 fold due to bandwidth throttling of lower-class traffic andpreferential treatment to the sensor traffic. In capacity-limited

�

Fig. 4. Sensor Information at End-Client.

��

��

� ��

��

��

Priority 1 queuePriority 3 queue

With QoS

��

� ��

��

Without QoS

Fig. 5. Driver Configuration for QoS.


�

�

Fig. 6. Performance without QoS.

wireless networks, prioritized services have to be achieved usingsimilar methodologies.

V. CONCLUSIONSThis paper provides a practical system implementation of

end-to-end QoS in integrated sensor-WiFi network using off-the-shelf hardware/software solutions. With emerging applicationsof wireless and sensor networks in emergency tracking (disaster)and real-time monitoring (intrusion), there is a significant needto demonstrate QoS capabilities in sensor networks. Also, pre-serving the information priority across heterogeneous wirelessinterfaces to achieve true end-to-end QoS will be essential,since sensor deployments would inherently involve long-rangewireless technologies for back-haul support.

In future, the real time sensor applications and our QoSwork will drive the need for practical sensor systems withemergency traffic support (not just high, but exclusive priority)and enhanced higher-layer protocols (routing) for QoS basednetwork topology organization. We also believe that our net-work infrastructure will be a perfect platform for sensor QoSprotocol/algorithm research and development.

ACKNOWLEDGMENT

This work was enabled by the financial support from ISSO(www.isso.uh.edu) post-doctoral fellowship.

REFERENCES

[1] IEEE 802.11e Standards, MAC Quality of Service Enhancements,2005, http://standards.ieee.org/getieee802/download/802.11e-2005.pdf

[2] IEEE 802.16e Standards, Physical and MAC Layers for Com-bined Fixed and Mobile Operation in Licensed Bands, 2005,http://standards.ieee.org/getieee802/download/802.16e-2005.pdf

[3] http://www.nasa.gov/mission-pages/station/science/experiments/Environmental Monitoring.html

[4] http://millennial.net/industries/industrialautomation.php

�

Fig. 7. Performance with QoS.

[5] K. Casey, A. Lim and G. Dozier, ”A Sensor Network Architecturefor Tsunami Detection and Response,” International Journal ofDistributed Sensor Networks, vol.4, issue 1, pp. 28-43, Jan. 2008].

[6] A. Milenkovi?, C. Otto and E. Jovanov, ”Wireless Sensor Networksfor Personal Health Monitoring: Issues and an Implementation,”Computer Communications, vol. 29, issue 13-14, pp. 2521-2533,Aug. 2006

[7] http://fiji.eecs.harvard.edu/CodeBlue[8] http://www.cs.virginia.edu/wsn/medical/[9] http://www.hartcomm.org[10] http://www.hartcomm.org[11] Crossbow Technology Inc. http://www.xbow.com[12] IEEE 802.15.4 standards MAC and PHY layer specifications

for low-rate WPANs http://standards.ieee.org/getieee802/download/802.15.4d-2009.pdf

[13] http://madwifi-project.org/[14] http://bioserve.colorado.edu/bionet/[15] http://www.embeddedpc.net[16] http://www.grid.unina.it/software/ITG/index.php


end-to-end qos in integrated wireless and sensor network ...donny/papers/endtoendqos.pdf ·...

Documents