1 / 22

A Modular Network Layer for Sensornets

A Modular Network Layer for Sensornets. Cheng Tien Er, Rodirgo Fonseca, Sukun Kim, Daekyeong Moon, Arsalan Tavakoli, David Culler, Scott Schenker, Ion Stoica. Sensor Network Protocols Today. Appln. EnviroTrack. Hood. TinyDB. Regions. FTSP. Diffusion. SPIN. Transport. TTDD. Trickle.

fahim
Download Presentation

A Modular Network Layer for Sensornets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 Appln EnviroTrack Hood TinyDB Regions FTSP Diffusion SPIN Transport TTDD Trickle Deluge Drip MMRP Arrive Routing TORA Ascent MintRoute CGSR AODV GPSR DSR ARA GSR GRAD DBF DSDV TBRPF Scheduling Resynch SPAN GAF FPS ReORg Topology PC Yao SMAC WooMac PAMAS BMAC TMAC WiseMAC Link Pico 802.15.4 Bluetooth Phy eyes RadioMetrix CC1000 nordic RFM 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.

  4. Common Components in Srensor Network Protocols

  5. 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)

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

  7. 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) }

  8. 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

  9. 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)

  10. 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

  11. 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

  12. 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

  13. Packet forwarding procedure

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

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

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

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

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

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

  20. 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.

  21. 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?

More Related