IEEE Communications Magazine • December 2013 1370163-6804/13/$25.00 © 2013 IEEE

INTRODUCTION

One of the key enablers of smart homes andenvironments is low power wireless networks.Smart environments such as smart homes,offices, and factories envision that every objectthat makes the place functional or objects withwhich we interact might consist of sensing, actu-ation, processing, and networking capability.Smart environments may have hundreds or thou-sands of such nodes that work together to makeour lives more efficient, comfortable, and safe. Asmart home, for instance, could monitor occu-pancy and weather to control climate systems,schedule appliances at the most economical timeof the day, make entertainment available inappropriate devices, and allow monitoring ofenergy use, security systems, appliance status,

and even occupant activities securely throughthe Internet. Most of the nodes or objects insuch environments use wireless network forrelaying sensor readings to the controllers, relay-ing commands from the controllers to the actua-tors, and for nodes to communicate with eachother depending on the application. One smarthome can easily have several hundred wirelessnodes.

As this vision gets ever closer to becoming areality, it is time to do a reality check to under-stand if the wireless technologies proposed forsuch environments are up to the task. IEEE,IETF, and various industry alliances (e.g., Zig-Bee) have proposed and adopted standards forthese networks keeping in mind constraints andproperties relevant to these networks. Often-times, the nodes in these networks have limitedpower (energy harvesting, long intervals be-tween battery change, or long operation of dis-posable smart objects). Thus, energy efficiency isone of the primary design objectives of suchstandards. IEEE standards such as various fla-vors of 802.15.4, IETF protocols such as RPL,and ZigBee all try to enable energy-efficientwireless communication between the nodes. Onecould power some of these wireless devices for ayear or more with a single AA battery. The goodnews is these nodes are available for purchasetoday. While the progress in energy efficientcommunication in these networks has been noth-ing short of phenomenal, what is relativelyunknown is how these networks might performwhen they are deployed in massive numbers inthe real world. There are two main networkingchallenges in such scenarios. The first challengeis inter-operation between the devices from dif-ferent manufacturers that have products in dif-ferent segments of the ecosystem that comprisesthe Internet of Things (IoT). The devices musthave inter- operating MAC, networking, andapplication layers for them to work with eachother. There is an emerging consensus that802.15.4 type MAC, 6LoWPAN, and RPL willprovide inter-operation at the MAC and net-work layer for the low- power devices, and stan-dards such as ZigBee will build ontop.

The second challenge is to make sure thesedevices can co-exist with a large number of otherdevices. Is there enough bandwidth for all ofthem? Can they work despite interference from

ABSTRACT

Smart homes and environments will consist ofa large number of low power wireless devicessuch as sensors and actuators. Recently IETFstandardized a network protocol called RPL thatis designed to run on these nodes. In this article,we study the performance of RPL on a variety ofscenarios that these nodes will encounter whenthey are deployed in practice. We deploy a net-work of 23 sensor nodes in a computer lab tomonitor energy used by each computer acrossthe applications and users. We subject the net-work to four different levels of interference thatare representative of the types and levels ofinterference that these networks might encounterin deployment. Our study finds that RPL’s relia-bility degrades even with an access point in over-lapping channel under normal network traffic.With high interference, the packet delivery relia-bility goes down to 10 percent. The scenario thatresulted in this performance is not unimaginablein smart home or environment. This perfor-mance degradation is partly due to lack of coor-dination across the layers of the protocol stack:RPL is unaware of the changes in the wirelessenvironment underneath and proceeds as usual.As other research has shown, coordination acrossthe network stack is essential for network proto-cols to work reliably in the presence of interfer-ence. This will require a more coordinatedapproach to standards across the bodies.

ACCEPTED FROM OPEN CALL

Dong Han and Omprakash Gnawali, University of Houston

Performance of RPL Under Wireless Interference

HAN_LAYOUT_Layout 12/3/13 2:59 PM Page 137

IEEE Communications Magazine • December 2013138

devices of similar type or different types?Researchers and practitioners have studied theseissues for a long time most often coming up witha recommendation to run the devices in non-overlapping channels just to be on the safe side.This recommendation is a good common sensewhen we manually deploy a few access points inour offices or a few wireless nodes at our homes.When we deploy a massive number of nodes insmart homes or offices, we do not have that lux-ury.

In this article, we study the challenge facedby current standards in low-power wireless net-works when they are deployed in a real worldapplication. While there are prior studies thatshow how interference impacts various researchprotocols, this is a first look at the newly stan-dardized RPL’s performance under wirelessinterference in a realistic environment. Wedeploy a wireless sensor network that measuresenergy consumption of computers in a computerlab. The nodes use state-of-the-art standards forlow cost wireless devices. The nodes have802.15.4 compliant radios and run IETF RPL [1]protocol, with which they report sensor readingsto a server. We subject the network to realisticinterference from other similar devices and WiFidevices to understand the resulting performanceof the network. We find alarming degradation innetwork reliability. This degradation is harmlessin our application but in critical applications(such as security and occupant monitoring)would be unacceptable. With a detailed analysisof the network performance, we bring insightsinto the cause of this degradation. Thus we bringreal world evidence to motivate future researchand standards to address co-existence of devicesin an increasingly wireless world.

INTERFERENCE AND COEXISTENCEA large number of smart devices for Internet ofThings (IoT) operate on 2.4GHz ISM band.Most research on wireless co-existence naturallyfocuses on protocols and systems that operate inthis band.

All networking professionals know to avoidoverlapping channels to maximize the perfor-mance of a network. Unfortunately, we do nothave this luxury as we deploy larger and largernetworks. Many devices inevitably will operateon the same channel and cause interference toother devices in the same channel. In such acase, it becomes important to coexist with otherdevices. There are two types of interference anode must deal with: from the same type ofdevice and from different types of device.

The same type of device employ the sameprotocol stack so it is easier to coordinate andaccommodate transmissions across the nodes.However, if the devices using the same technolo-gy is sold by different vendors, it is possible thatthe devices use different configuration in theirnetwork stack making some devices more aggres-sive than others. One of the scenarios we studyhas a sensor node that aggressively sends a largenumber of packets drowning the rest of thenodes.

In a smart environment, most likely the wire-less nodes encounter interference from many

different types of devices. Bluetooth, ZigBee,and WiFi are three most common wireless tech-nologies at homes. In this article, we study howdevices running the latest IETF standard calledRPL perform when they are deployed in such anenvironment.

Research in co-existence of devices runningZigBee or 802.15.4 compatible protocols andWiFi has been especially active in the last sever-al years. In [2], the authors jointly consider theintensity and density of WiFi interference, thenlet the ZigBee nodes access the level of the localinterference, and if necessary switch to a newchannel.

It has been shown that existing CSMA mech-anisms are inadequate to enable Zigbee to coex-ist with WiFi [3]. The authors show thatmodeling and predicting the length of space inWiFi traffic allows setting the right frame size inZigBee to maximize throughput. The experi-ments on real hardware using testbed demon-strated the proposed control protocol enabledZigBee nodes to communicate reliably evenunder heave WiFi interference. Otherresearchers have shown that it is possible tomake communication reliable despite ZigBee-WiFi interference using header and payloadredundancy [4].

These and many other research projectsexplore techniques for coexistence between sameand different devices. They are slowly being dis-cussed at the standard bodies and none of thedevices available in the market today employsuch technologies. In this article, we use the lat-est IETF routing protocol called RPL, which isdesigned for low power wireless networks, andunderstand how it works when it is run on top of802.5.4 compliant radio in presence of differentlevels and types of interference.

ROUTING IN LOW-POWERNETWORKS USING RPL

RPL is an IPv6 routing protocol for low powerand lossy networks recently standardized by theIETF in RFC 6550 [1]. RPL is designed forwireless networks such as sensor networks andnetworks in smart homes and offices that uselow power devices. The predominant traffic pat-tern in these networks is multipoint-to-point, i.e.,a large number of devices reporting their statusand sensor readings to a server. Such routes areestablished by forming a directed ascyclic graph(DAG), an implementation of a distance vectorprotocol. The packets are forwarded along theDAGs which span the whole network. Each non-leaf nodes in the DAG will act as a router,potentially be a parent node on a path towardsthe root of DAG. The nodes use Objective Func-tions (OFs) to select parents within an RPLinstance. We choose OF0 in our experiment,which uses hop-count as the metric to select par-ent and path. RPL also supports sending mes-sages from the root to individual nodes. Suchmessages are used to control the devices such aslights, appliances, and power strips.

RPL could potentially be deployed in homes,offices, factories, and even at the edges of smart-grids as part of advanced metering infrastructure

RPL is designed for

wireless networks

such as sensor net-

works and networks

in smart homes and

offices that use low

power devices. The

predominant traffic

pattern in these net-

works is multipoint-

to-point, i.e., a large

number of devices

reporting their status

and sensor readings

to a server.

HAN_LAYOUT_Layout 12/3/13 2:59 PM Page 138

IEEE Communications Magazine • December 2013 139

on devices like smart meters and electrical appli-ances. Although this standard is less than oneyear old, there is a huge interest in understand-ing how RPL works because the scope for itsapplication is so wide.

Researchers have used simulations and real-world experiments to understand the perfor-mance of RPL. Simulation studies of RPL haveshown how quickly RPL can establish routes inthe network however has large control overhead[5]. Other studies have shown RPL to have per-formance comparable to ideal shortest pathrouting [6]. A different study in simulationshowed that RPL lives up to its promise of effi-ciency in energy, storage, and communicationoverhead [7]. A study of point-to-point routingin RPL found inefficiencies [8]. The IETF hasaddressed these issues by defining a more effi-cient point-to-point routing mechanism for RPL.RPL has also been studied as a part of a stackwith CoAP, an HTTP-like protocol for con-strained environments. The study found RPL towork well as a networking substrate [9].

EXPERIMENT SETUPOur goal is to study the performance of a net-work running RPL under various levels of inter-ference such networks could encounter whenthey are deployed in the real world. We nowdescribe experiment setup that we used for thisstudy.

APPLICATIONWe deployed an application to monitor thepower use of computers in a computer lab. Thelab has 23 computers arranged in four rows. Thestudents can log in to these computers to checkemails and do their homework. The goal of theapplication is to closely monitor the energy usedin a time scale that helps us uncover the trendsused by different computers, applications, andstudents. This application has been running con-tinuously for five months.

NETWORKFigure 1 shows the network architecture. We usePowerNet [10] nodes as the energy sensor nodes,which are attached to the computers in seriesbetween the power cable and power outlet. ThePowerNet node has energy metering IC torecord energy being supplied to the computerand report it to the server. It has CC2420 radio,which provides the IEEE 802.15.4 PHY layer. Atthe MAC layer, we use TKN15.4 [11], which isan implementation of IEEE 802.15.4-2006 MAClayer but without the support for security ser-vices, PAN ID conflict notification and resolu-tion, and frame buffering in transaction queueafter CSMA-CA algorithm fails. We use theTinyOS RPL implementation which consists ofBlip, the TinyOS 6LoWPAN stack, and TinyR-PL, an implementation of the RPL standard[12]. Blip implements 6LoWPAN header com-pression, 6LoWPAN neighbor discovery andDHCPv6. Hop-by-hop retransmissions are usedto improve packet delivery reliability. We use aTmote node as the gateway, which also runsRPL. We attach the gateway to a Unix serverthrough a USB port. The gateway receives and

forwards all of the incoming packets to databasefor further analysis.

INSTRUMENTATIONThe nodes sample power at 10Hz, pack 20 read-ings to a single packet and send it to the basestation. In addition to the application payload,the packets contain other metadata that we lateruse to analyze RPL information. Every minute,the nodes also send summary of data and con-trol plane counters for further analysis. With thisset of information, we can study RPL’s perfor-mance at the network layer and also able to drilldown to MAC layer mechanisms to explain theperformance (number of retransmissions, num-ber of times route changes, received signalstrength, etc.) at different time scales.

SCENARIOSWe designed four experiment scenarios with dif-ferent levels of interference:• Low Interference: We set the PowerNet

nodes to run on 802.15.4 channel 25, whichdoes not overlap with any WiFi channels inthe United States. We verified that thischannel was free of interference. The onlyinterference is due to other PowerNetnodes.

• Normal Interference: In this scenario, thePowerNet nodes run on 802.15.4 channel12. This channel overlaps with WiFi chan-nel 1. In the department, there are severalAPs that use this channel. This scenariorepresents the most common case of inter-ference due to the normal use of WirelessAP on overlapping channels.

• Mixed Interference: In this scenario, in addi-tion to running PowerNet nodes on channel12, we put two low power nodes on 802.15.4channel 12. These two nodes were pro-grammed to send packets to each other asquickly as they can with maximum power.Thus the PowerNet nodes experience inter-ference not only from WiFi AP but also thetraffic bouncing between these two nodes.

• High Interference: In this scenario, wedeployed an additional WiFi AP in the laband configured it to run on channel 1, thusoverlapping with the channels of public APsand PowerNet. Then we connected to this

Figure 1. Architecture of a sensor network deployed to monitor energy used bycomputers.

Database serverBase stationComputer

Computer

Power readingsent over wireless

using RPL

User activity data sentover wired network

Switch

HAN_LAYOUT_Layout 12/3/13 2:59 PM Page 139

IEEE Communications Magazine • December 2013140

AP using a laptop and generated continu-ous traffic at 20 Mbps using Iperf. Thus,the PowerNet nodes are subjected to highinterference from WiFi as well as 15.4 inthis scenario.We ran the network for 10 hours in each sce-

nario in the same time of day to get repeatableresults.

RPL’S PERFORMANCE UNDERINTERFERENCE

We subject the energy monitoring network run-ning RPL to various levels of interference tostudy RPL’s performance. In this section we pre-sent our findings.

RELIABILITY

We want our network to deliver packets reliably.While some applications might tolerate somelosses, critical home monitoring applicationscannot. Packet Reception Rate (PRR) is themost common metric used to quantify how reli-ably a protocol can deliver packets to the desti-nation. We expect each link chosen by a goodrouting protocol to be reliable but that is insuffi-cient for successful multi-hop forwarding: theentire path needs to be of high quality. So, weuse the end-to-end version of the PRR metric,i.e., what fraction of the packet that was sentarrived at the destination which is multiple hopsaway.

Figure 2 shows the average PRR for eachscenario. The PRR stays at almost 100% withlow interference and about 92% with normalinterference. When there are WiFi and 15.4nodes interfering with PowerNet, the PRRdrops to an average of 75%. In the last sce-nario, i.e., high interference, the average PRRof the nodes drop to below 10%. The figureshows that under normal interference, the per-formance of RPL might be acceptable but whenthere is high interference very few packets arereliably delivered.

To explain this trend in reliability in moredetail, we analyze the quality of paths selectedby RPL for forwarding the packets in each case.We use the metric called Path ETX to quantifythe quality of path. Path ETX is the expectednumber of transmissions and retransmissionsrequired to deliver a packet from a source to thedestination over multiple hops.

Figure 3 plots the distribution of path ETXin each scenario. In low interference scenario,almost half the paths have ETX of 2, and mostdistributed in the 2-3 range. The Path ETXincreases, but only slightly with normal andmixed interference. There is a larger increasein Path ETX with high interference. Almosthalf of the paths have ETX of 3 or larger and10% of the paths have an ETX of 4 or larger.Thus, worse paths become more common withhigher interference and cause lower packetdelivery.

CONTROL OVERHEADControl traffic is used to discover, setup, andmaintain the routes in the network. RPL usesadaptive timers to adjust the rate at which thecontrol messages are sent. The efficiency isachieved in a long-running stable network wherethe control traffic might be sent once every sev-eral hours. We normalize the number of controlpackets sent by the number of data packets toobtain control overhead ratio, i.e., how manycontrol packets are sent for each data packet inthe network. RPL is designed for low power net-works to provide efficient communication so weexpect its control overhead ratio to be low.

Figure 4 shows the control overhead ratiosacross the four scenarios. With low interference,the control overhead ratio is distributed in therange of 15% to 20%, i.e., RPL sends 0.15 to0.2 control packet for each data packet. Withnormal and mixed interference the control over-head ratio increases to about 30% and 50%

Figure 2. Packet reception rate under various interference scenarios.

ScenariosLow

20

0

PRR

(%)

Normal Mixed High

40

60

80

100

Figure 3. Path ETX under various interference scenarios.

ScenariosLow

2

0

Path

ETX

Normal Mixed High

4

6

8

10

HAN_LAYOUT_Layout 12/3/13 2:59 PM Page 140

IEEE Communications Magazine • December 2013 141

respectively. This shows that with increasinginterference, RPL needs to work harder to dis-cover and maintain viable routes for data deliv-ery. With high interference, the ratio increasesto almost 100%. This is most troubling becauseRPL is sending almost one control packet foreach data packet delivery. The high controloverhead ratio is due to the larger number ofcontrol packets being sent and much lowernumber of data being sent successfully whenthere is high interference.

NETWORK CHURNAs RPL discovers better paths or discontinuesusing a bad link, it switches to a different pre-ferred next hop (or parent) for a given destina-tion. This process not only changes the next hopbut could also change the Rank. RPL use Rankto approximately (depends on the routing met-ric) indicate the hop distance of a node from theroot of network. The larger the rank value of anode, the longer the path from the root to thenode. An unstable network changes the routesmany times. When RPL selects a new route, itdoes not necessarily change the node’s Rankbecause the new route might also be of approxi-mately the same length.

Figure 5 shows the number of parent changesfor the four scenarios. With low interference, thenetwork is stable: each node changed the parent1.7 times per hour in average. We see more fre-quent parent changes with normal and mixedinterference. With high interference, each nodechanged parent 1400 times per hour in average.This suggests that when there is interference, theadaptive Trickle timer was reset many timeswhich causing the node to send a large numberof control packets. These numbers tell us thenodes change parents more often when there isinterference but does not tell us if these changesresult in finding substantially different paths. Tostudy the network churn in more detail, wedefine a new metric called Excess Parent Change(EPC) defined as Eq. 1:

(1)

The EPC metric helps us discern between thetwo cases — a node changes parents when it dis-covers a better or worse path (according toRank) or when it changes between multiple par-ents without any significant change in Rank. Thelatter could occur when a node switches betweenmany parents without improving the Rank, e.g.,when it is subjected to interference.

Figure 6 plots the Excess Parent Change(EPC) metric. The rare interference scenario hasalmost no excess parent change, i.e., almostevery time the node changes the parent, it alsochanged Rank. With high interference, the EPCis between 30 and 60 percent. This indicates that30–60 percent of the time the parent changeresulted in no change in Rank, thus resulting inno improvement in path quality.

This result together with the high controloverhead indicates that although RPL worksharder it does not find better paths when it issubjected to high interference.

DISCUSSION

Although our results show RPL performingpoorly with interference, the results somewhatdepend on the values of the configurationparameters chosen in the implementation. Weuse the defaults in the TinyOS implementationof RPL. It is certainly possible to tweak theparameters to make RPL work better in a spe-cific environment. However, parameter tweakingis tricky, especially in protocols like RPL that isexpected to be deployed in a wide range of set-tings. The qualitative results will still holdbecause of the way today’s network stacks aredesigned.

RPL’s poor performance under performance

= −EPC

Num ParentChange Num RankChange

Num RankChange

. .

.

Figure 4. Control overhead ratio under various interference scenarios.

ScenariosLow

0.9

0.1

Con

trol

ove

rhea

d ra

tio

0.8

0.7

0.6

0.5

0.4

0.3

0.2

Normal Mixed High

1.0

Figure 5. Parent change rate under various interference scenarios.

ScenariosLow

500

0

Pare

nt c

hang

e ra

te p

er h

our

1000

1500

2000

2500

3000

Normal Mixed High

3500

HAN_LAYOUT_Layout 12/3/13 2:59 PM Page 141

IEEE Communications Magazine • December 2013142

is not solely RPL’s fault. Isolation between lay-ers of the protocol stack is partly at fault. Theperformance of a network stack under any sce-nario depends on how each layer responds to theevents taking place in the network. Although thelower layers of the stack might be able to guessthe existence of interference, RPL is forced totreat the packet loss like any other packet loss.As a result the nodes spend a lot of energy get-ting few packets delivered.

The users care most about the performance ofthe complete system, not if the packet drops aredue to RPL or the MAC layer or due to interfer-ence from WiFi. Research has shown that gettinga network to work reliably under interference ischallenging and requires coordination across thelayers (more agile physical layer, less aggressiveMAC, transport discriminating between differenttypes of losses, moderation of data rates at theapplication) and types of devices.

Co-existence of different wireless technolo-gies has been an area of active research for sometime but in production system has been handledonly implicitly, for example, by treating signalsfrom overlapping communication by differentradio technology as noise. To handle coexistenceexplicitly, there needs to be an architecture thatallows coordination of devices through a com-mon backchannel agreed upon by many partiesin this ecosystem. This is easy to do in research.

Such coordinated response is much moredifficult to achieve in practice because differ-ent standard bodies are responsible for stan-dardizing different parts of the stack and typesof radio technologies. IEEE defines most ofthe low level standards. IETF standardizes thenetwork layer for the Internet. Then, there arealliances like ZigBee that extend all the way tothe application layer. Recently, we have seenincreasing coordination among the standardsfrom different bodies. For example, the IETF6LoWPAN standards are geared towards run-ning IPv6 on top of IEEE 802.15.4 devices.

ZigBee has recently adopted RPL as its rout-ing layer.

Cross layer protocol research has shown thatwider and more invasive interface between thePHY/MAC and network layers can improve thecoordination between these layers to make thenetwork more robust to interference and improveperformance. Translating such cross layer designsto commercial products requires coordinationbetween the IEEE, the IETF, and many otherorganizations. In the TCP/IP research, it is com-mon to emphasize that certain enhancements tothe protocol is achieved without changing packetformat. If the cross-layer wireless network proto-col research community embraced similar disci-pline while enhancing the interaction andvisibility between PHY/MAC and network layer,the research results would be more likely to beadopted by the standardization bodies.

CONCLUSIONSRPL is a recently standardized IETF routing pro-tocol for low power and lossy networks. In thisarticle, we share our findings from studying itsperformance under a variety of settings the net-work could encounter when it is deployed inpractice. We found that it challenging to deliverdata reliably even in environments that would betypical of smart homes or offices. Just the pres-ence of wireless access points with normal trafficreduced packet delivery reliability to 92%. This isa scenario we expect to find at every home andmany smart home and smart environments willhave additional sources of interference. As wedeploy massive number of devices, it is inevitablethat many nodes will experience harsher wirelessenvironments. For some applications, such assecurity, resource metering, and occupant track-ing, poor performance as we observed in ourexperiments will be unacceptable. Research hasshown that it is possible to deliver data reliablyunder interference. Protocols on which we runour smart homes should leverage such research.

ACKNOWLEDGMENTSThis work was partly supported by a generousgift from Cisco. Thanks to Tom Cumpian andBabu Sundaram for providing access to the com-puter lab for measurements. Thanks to PrahalArora for his help with performing experiment.

REFERENCES[1] E. T. Winter and E. P. Thubert, “Rpl: IPV6 Routing Pro-

tocol for Low Power and Lossy Networks,”http://tools.ietf.org/html/ draft-ietf-roll-rpl-19, 2011.

[2] R. Xu et al., “Muzi: Multi-Channel Zigbee Networks forAvoiding WiFi Interference,” Internet of Things(iThings/CPSCom), 2011 Int’l. Conf. and 4th Int’l. Conf.Cyber, Physical and Social Computing, Oct. 2011, pp.323–29.

[3] J. Huang et al., “Beyond Co-Existence: Exploiting WiFiWhite Space for Zigbee Performance Assurance,” 201018th IEEE Int’l. Conf. Network Protocols (ICNP), Oct.2010, pp. 305–314.

[4] C.-J. M. Liang et al., “Surviving Wi-Fi Interference inLow Power Zigbee Networks,” Proc. 8th ACM Conf.Embedded Networked Sensor Systems, ser. SenSys ’10,New York, NY, USA: ACM, 2010, pp. 309–22, available:http://doi.acm.org/10.1145/1869983.1870014.

[5] N. Accettura et al., “Performance Analysis of the RPLRouting Protocol,” Mechatronics (ICM), 2011 IEEE Int’l.Conf., Apr. 2011, pp. 767–72.

Figure 6. Excess parent change under various interference scenarios.

ScenariosLow

10

0

Exce

ss p

aren

t ch

ange

(%

)

20

30

40

50

Normal Mixed High

60

HAN_LAYOUT_Layout 12/3/13 2:59 PM Page 142

IEEE Communications Magazine • December 2013 143

[6] J. Tripathi, J. de Oliveira, and J. Vasseur, “A Perfor-mance Evaluation Study of RPL: Routing Protocol forLow Power and Lossy Networks,” 2010 44th AnnualConf. Information Sciences and Systems (CISS), Mar.2010, pp. 1–6.

[7] O. Gaddour et al., “Simulation and Performance Evalua-tion of Dag Construction with Rpl,” 2012 2rd Int’l.Conf. Commun. and Networking (ComNet), Apr. 1–29,2012, pp. 1–8.

[8] W. Xie et al., “A Performance Analysis of Point-to-PointRouting Along A Directed Acyclic Graph in Low Powerand Lossy Networks,” 2010 13th Int’l. Conf. Network-Based Information Systems (NBiS), Sept. 2010, pp.111–16.

[9] T. Potsch et al., “Performance Evaluation of COAP usingRPL and LPL in Tinyos,” 2012 5th Int’l. Conf. New Tech-nologies, Mobility and Security (NTMS), May 2012, pp.1–5.

[10] M. Kazandjieva et al., “Powernet: A Magnifying Glassfor Computing System Energy,” Proc. Stanford Energy& Feedback Workshop: End-Use Energy Reductionsthrough Monitoring, Feedback, and Behavior Modifica-tion, 2008.

[11] J. Hauer, “Tkn15. 4: An IEEE 802.15. 4 MAC Imple-mentation for Tinyos 2,” Telecommunication NetworksGroup, Technical University Berlin, TKN Technical ReportSeries TKN-08-003, 2009.

[12] J. Ko et al., “Evaluating the Performance of RPL and6lowpan in Tinyos,” Proc. Wksp. Extending the Internetto Low Power and Lossy Networks (IP+ SN 2011), Apr.2011.

BIOGRAPHIESDONG HAN (donny@cs.uh.edu) received his B.Sc.Eng. degreein computer science and technology in 2007 from ZhejiangUniversity of Technology, China, and his M.S. degree intelecommunication engineering from the University of Syd-ney, Australia. He is enrolled as a Ph.D. student at the Uni-versity of Houston, Texas. His current areas of researchfocuses on routing protocol in wireless sensor network,particularly fault-tolerance in CTP protocol, and user activi-ty identification based on energy measurement study ondesktop computers.

OMPRAKASH GNAWALI (gnawali@cs.uh.edu) is an assistantprofessor at the University of Houston. He was a post-doctoral scholar at Stanford University, got his Ph.D.from the University of Southern California, and receivedhis Master’s and Bachelor’s degrees from the Mas-sachusetts Institute of Technology. His research lies atthe intersection of low-power wireless networks andembedded sensing systems.

HAN_LAYOUT_Layout 12/3/13 2:59 PM Page 143