1 Introduction2 SP Design2.1 Description2.2 Neighbor Table2.3 Message Pool2.4 Discussion3 Implementation4 Link Protocols4.1 Slotted Protocols4.2 Channel Sampling Protocols5 Network Protocols5.1 Collection Routing5.2 Dissemination5.3 Aggregation6 Results6.1 Single Hop Benchmarks6.2 Multihop Benchmarks7 Related Protocols7.1 Link Layer Protocols7.2 Network Layer Protocols8 Concluding Remarks9 REFERENCES -9ptA Unifying Link Abstraction for Wireless Sensor NetworksJoseph Polastre, Jonathan Hui, Philip Levis, Jerry Zhao,David Culler, Scott Shenker, and Ion StoicaComputer Science Department International Computer Science InstituteUniversity of California, Berkeley 1947 Center Street. Suite 600Berkeley, CA 94720 Berkeley, CA 94704ABSTRACTRecent technological advances and the continuing quest for greaterefficiency have led to an explosion of link and network protocolsfor wireless sensor networks. These protocols embody very dif-ferent assumptions about network stack composition and, as such,have limited interoperability. It has been suggested [3] that, in prin-ciple, wireless sensor networks would benefit from a unifying ab-straction (or “narrow waist” in architectural terms), and that thisabstraction should be closer to the link level than the network level.This paper takes that vague principle and turns it into practice, byproposing a specific unifying sensornet protocol (SP) that providesshared neighbor management and a message pool.The two goals of a unifying abstraction are generality and ef-ficiency: it should be capable of running over a broad range oflink-layer technologies and supporting a wide variety of networkprotocols, and doing so should not lead to a significant loss of ef-ficiency. To investigate the extent to which SP meets these goals,we implemented SP (in TinyOS) on top of two very different ra-dio technologies: B-MAC on mica2 and IEEE 802.15.4 on Telos.We also built a variety of network protocols on SP, including ex-amples of collection routing [53], dissemination [26], and aggrega-tion [33]. Measurements show that these protocols do not sacrificeperformance through the use of our SP abstraction.Categories and Subject Descriptors:C.2.2 [Computer-Communication Networks] Network Protocols,D.4.7 [Operating Systems]: Organization and DesignGeneral Terms: Design, Experimentation, StandardizationKeywords: Protocol architecture, link protocols, network proto-cols, wireless sensor networks, network abstractions1. INTRODUCTIONWireless sensor networks (hereafter sensornets) pose many net-working challenges. These challenges have motivated a broad setof investigations, which have given us a cornucopia of possible pro-tocols at each level in the system. Many physical links, with widelydiffering characteristics, have been utilized ([2, 18, 47, 48, 49]).Myriad low power media access protocols have been developed,Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SenSys’05, November 2–4, 2005, San Diego, California, USA.Copyright 2005 ACM 1-59593-054-X/05/0011 ...$5.00.based on CSMA ([35, 41, 52]), TDMA ([10, 37, 50, 56]), or both([15, 38]). Numerous topology formation algorithms ([1, 14, 55]),routing protocols ([34, 53]), aggregation algorithms ([27, 33]), anddissemination protocols ([14, 16, 22, 26]) have been proposed.The extreme resource scarcity of sensornets requires minimizingenergy usage while maintaining high reliability and data qualityover time-varying and noisy links ([53, 57]). To meet these am-bitious goals, most research efforts have emphasized performancemore than modularity, with many issues (such as power manage-ment, scheduling, and data buffering) handled simultaneously atmany levels in a deeply intertwined fashion. As a result, the fieldhas produced a few vertically integrated designs, each with theirown interface assumptions, and there is little code reuse.The response to this situation has been a call for a sensornet ar-chitecture [3]. Such an architecture would provide much greatermodularity to sensornet designs, thereby regularizing assumptionsabout interfaces, encouraging code reuse, and fostering greater in-tellectual synergy.1Moreover, if the architecture has a “narrowwaist” (as does the Internet architecture), then it could effectivelydecouple many aspects of the software from the underlying hard-ware. Such a decoupling would be of great benefit given the rapidtechnological advances in the sensornet arena, particularly in radiotransceivers. The authors of [3] make the case that, in contrast tothe Internet, the narrow waist (which they call the sensornetworkprotocol, SP), not be at the network layer but instead sit betweenthe network and link layers. This “lowering of the waist” is nec-essary because processing potentially occurs at each hop, not justat the end points, and there are many application-specific multi-point communication patterns (collection, aggregation, dissemina-tion, etc.). As observed in [3], one cannot base the sensornet archi-tecture around the end-to-end delivery of packets, but instead mustbuild upon the lower-level base of best-effort single-hop communi-cations.The key challenge for SP is providing adequate insulation be-tween the hardware below and the various communication abstrac-tions above while still providing adequate efficiency. It should al-low network level protocols to optimize for the underlying link interms of the characteristics expressed at SP, rather than knowingwhich particular link and physical layer resides beneath.2More-over, SP must allow network protocols to choose neighbors wisely,taking into account information available at the link layer.1Zigbee proposes a classic layered architecture, but each layer as-sumes a specific instance of the surrounding layers; e.g., the routinglayer assumes the IEEE 802.15.4 link and physical layers. An ar-chitecture built on static technologies is destined for obsolescence.2This is in contrast to IEEE 802.2 [46] which provides a uniformsyntactic interface to various link layers, but the code above takesspecific actions based on the particular protocol beneath, whetherit is ethernet, 802.11, and so on.Rather than
View Full Document
Unlocking...