1. A Modular Network Layer for Sensornets Cheng Tien Er, Rodirgo Fonseca, Sukun Kim, Daekyeong Moon, Arsalan Tavakoli, David Culler, Scott Schenker, Ion Stoica

2. Sensor Network Protocols Today Phy Link Topology Routing Transport Appln RadioMetrix RFM CC1000 Bluetooth 802.15.4 eyes nordic WooMac SMAC TMAC WiseMAC FPS MintRoute ReORg PAMAS CGSR DBF MMRP TBRPF BMAC DSDV ARADSR TORA GSR GPSR GRAD Ascent SPIN SPAN Arrive AODV GAF Scheduling Resynch Yao Diffusion Deluge Trickle Drip Regions Hood EnviroTrack TinyDB PC TTDD Pico FTSP What if I want to use any two protocols together??

3. The need of modular network layer Vertical integrated design –Variety of sensornet applications –Heavy need for optimization –Lack of consistency in component module and interface Modular network layer –Solve the inconsistency in component module and interface –Better organization, easy development –Less consumption of resource, i.e. memory, energy etc. –Narrow-waist of sensornet arch lies between the link and network layer Design goal –Code reuse: rapid application development –Run-time sharing: sharing code and resource, i.e. code, radio etc.

5. Common Components in Srensor Network Protocols

6. 6 Network layer service and major components Provides best-effort, connectionless multi- hop communication abstraction to higher layer Balance flexibility and reusability –Control plane Routing engine(RE) Routing topology(RT) –Data plane Forward engine(FE) Output queue(OQ)

7. What a Typical Wireless Link Layer Looks Like Classifier Forwarder Scheduler Input PortOutput Port Data Plane Control Plane OSPFRIPCLI … Classifier Forwarder Scheduler Input PortOutput Port Data Plane Control Plane OSPFRIPCLI … Input Port Wireless Link Input Port Wireline Link Downlink Path Uplink Path Classifier / Policing Wireless Scheduler Event Processor Action Processor Statistics Monitor Registration DB to RAs from RAs

8. Sensor Network Interfaces FE | OQ: pass complete package around FE | RE –Basic interface: All routing protocols must provide this –Cost-based interface:Some routing protocols can extend the interface and provide this RE | RT –Unified interface have increased code size, added complexity, instability –Protocol specific necessary information to determine routes Interface BasicForwarding { neighbor_list getNextHops(RoutingHeader*) } Interface CostBasedForwarding { cost_t getCost(RoutingHeader*, neighbor) }

9. Package Header Separate headers for different components –Protocol identifier: select appropriate components –OQ header: info for scheduling and buffer management, i.e. packet priority. –FE header: info for forwarding packet, i.e. hopcount, unique message id etc –RE: info to determine next-hop

10. Output Queue Modules Implement packet scheduling –Basic OQ: high priority packet transferred before low priority ones –Flexible power scheduling (FPS): TDMA, fixed slot each cycle Balance supply and demand at each neighbor and achieve high utilization Require the knowledge of destination of the message to classify packet (help from RE) –Epoch-based proportional selection (EPS): Dynamic number of slots per cycle Weighted round-robin serving of children’s queue to achieve fairness. Require the knowledge of destination of the message to classify packets (help from RE)

11. Forwarding Engine Basic forwarding –Get per-packet next-hop info from RE –Check for packet interception request from higher layers Opportunistic forwarding –Use the knowledge of the cost to the destination (from RE) to forward the packages Multicast –RE implicitly returns the list of all next-hops

12. Routing Engines Module Broadcast RE: –Handles all packets that are logically broadcast to all one-hop neighbors Protocol specific routing –PathDCS: route along the network path which data is mapped to using beacon as guides –BVR: route based on hop distance to beacons –MintRout: route along the topology tree

13. Routing Topology MTree –M routing trees routed at random nodes in the network –Used for basic route-to-base applications –Routing info maintained in routing table Gradient topology –Each node maintains its cost-to-destination Geographic RT –Geographic coordinates, i.e. GPS etc. –Provide closet next-hop nodes towards a given destination –Euclidean distance can be used as a cost metric

14. Packet forwarding procedure

15. Example: Collection by MintRoute Tree based routing Routing Tree maintains: Cost to root Neighbor's costs Parent Tree RE/RTClassic FE neighbor_list getNextHops(RH*) data packet flow control signals Tree maintenance traffic Forward { getNextHops(RH*) SPSend(first_in_list) }

16. Example: Point-to-Point by Geographic Routing Greedy geographic routing My coordinates Neighbor coordinates Cost is euclidean. distance Geo RE/RT Classic FE Forward { getNextHops(RH*) SPSend(first_in_list) } data packet flow control signals Coordinates exchange with neighbors neighbor_list getNextHops(RH*)

17. Example: data-centric routing by Opportunistic FE Routing Tree maintains: Cost to root Neighbor's costs Parent Tree RE/RTOpportunistic FE cost getCost(RH*, me) Forward { if (my_cost < pkt.cost) { pkt.cost = my_cost SPSend(bcast) } data packet flow control signals Tree maintenance traffic

18. Constraint on Composition Basic FE|OQ works for all protocols Opport requires meaningful cost-to-dest metric

19. Evaluation: code size and memory footprint Two combination save 40%-58% less memory, 18%-37% program memory

20. Evaluation: Performance More delay in network layer than monolithic arch Performance is not the primary goal in sensornet, i.e. energy.

21. Conclusion Modular network layer design achieves 58% memory reduction and 37% less code when running protocols concurrently. Increase portability of sensornet application. Speedup the development of sensornet applications. Additional latency is accessible in the context of sensornets.

22. Discussion How complex can a sensornet application become in future? How does the layered design affect other functionalities, i.e. power management, security, reliability, and time synchronization? How to address issues which require cross- layer cooperation in a layered design? How well does the “end-to-end” argument fit into the sensornet applications?