A unifying link abstraction for wireless sensor networks Joseph Polastre, Jonathan Hui, Philip Levis, Jerry Zhao, David Culler, Scott Shenker, and Ion Stoica University of California, Berkeley, International Computer Science Institute SenSys’05, November 2–4, 2005 Mong Nam Han AN Lab, CS dept. KAIST, Korea

2 Overview  Motivation  SP Design  Implementation  Link Protocol  Network Protocol  Experiment Result  Conclusion, Q & A

3 Motivation IP TCP, UDP,... SMTP, HTTP, RTP,... , WWW, phone,... Ethernet, PPP,... CSMA, Sonet,... Copper, fiber, radio,... Reference [3]Towards a sensor network architecture: Lowering the waistline, D. Culler et. al, HotOS  SP (Sensornetwork Protocol) : Narrow Waist  Modularity  Decoupling  lowering of the waist  Challenge  Insulation  Translucent  Implementation

4 SP Design  Sensor network  Aggregate communication is prevalent  Node operates as a data source, data sink and/or router  Node form and maintain routes, and forward traffic  Noisy, time-varying, and even intermittent connectivity  Challenge  Rare interchangeability among layers  Variations in assumptions due to resource constraints, Power management, application specific processing  No complete solution  Goal  Providing a unified interface to data link and physical layer  Allowing multiple network protocols and link thechnologies to coexist and evolve like IP layer of Internet

5 SP Design: Conceptual view (1) Data Reception (2) Data Transmission (3) Neighbor Management

6 SP Design: Neighbor table and Message pool

7 SP Design: Send process

8 Implementation

9 Link Protocol: Slotted Protocol  IEEE used by Zigbee [49]  Beacon schedule  When receive beacon, insert into SP’s neighbor table  When beacon period expired, SP ask to renew, then 15.4 update  SP check message to send or listen bit, SP tells 15.4  Broadcast message  Use broadcast neighbor table or unicast by cycling  If neighbor table is sparse, SP request a beacon scan  Link estimation  When receives message, ask SP to adjust the quality of neighor  SP then ask 15.4 to compute LQI in the neighbor table  When reliability is requested, SP enables 15.4 link Ack

10 Link Protocol: Channel Sampling Protocol  Default mica2 MAC protocol [35]  Sampling Schedule  Synchronization information extracted from packet with long preamble and neighbor is inserted with LPL sampling schedule  SP transmit data with short preamble to destined neighbor  Packet will be sent with long preamble to unknown destination or broadcast address  Piggy back  As maintaining message pool, SP can piggyback data  Collisions are mitigated while piggybacking  Reliability  SP enables B-MAC’s link layer Ack  Neighbor estimation  A basic RSSI link estimator  A packet error rate estimator

11 Network Protocol: Collection Routing  MinRoute over B-MAC and 15.4 [53]  Broadcast  Mica2 use long preambles, 15.4 use unicast round-robine emulation  Neighbor table  request SPNeighbor interface  Data packet transmission  use quantity field of SP message  SP bursts when destination is available with reliability turned on, notify if successful  Link estimation  Add parent’s ETX and hop count to neighbor table  Handle admit and evicted event

12 Network Protocol: Dissemination  Trickle [26] both on mica2 and Telos  Sends only broadcast messages  Delays between submission and transmission : backoffs for collision avoidance, cancel of SPSend interface  Deluge[16] on top of Trickle  Extensive use of message futures keep resource usage minimum  With SP’s shared neighbor table, contention and packet drop can be reduced

13 Network Protocol: Aggregation  Synopsis Diffusion (SD) [33]  Gradient to the collection point  When running with MinRoute, SD quries the SP neighbor table and extracts Minroute’s neighbor hopcounts to determine the direction of the collection point  Broadcast  Using SPSend interface, set not reliability nor urgency

14 Experiment Result: Single Hop

15 Experiment Result: Multi Hop

16 Experiment Result: Interaction  Between SP and link protocol  Between SP and network protocol

17 Conclusion, Q & A  Culler et. al. claim that “the primary factor currently limiting progress in sensornets is not a specific technical challenge but instead is the lack of an overall sensor network architecture.”  One step towards an “overall sensor network architecture.”

18 Q & A