A modular network layer for sensornets
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

A Modular Network Layer for Sensornets PowerPoint PPT Presentation


  • 43 Views
  • Uploaded on
  • Presentation posted in: General

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.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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


A modular network layer for sensornets

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


The need of modular network layer

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.


Common components in srensor network protocols

Common Components in Srensor Network Protocols


Network layer service and major components

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)


A modular network layer for sensornets

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


Sensor network interfaces

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)

}


Package header

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


Output queue modules

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)


Forwarding engine

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


Routing engines module

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


Routing topology

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


Packet forwarding procedure

Packet forwarding procedure


Example collection by mintroute

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


Example point to point by geographic routing

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


Example data centric routing by opportunistic fe

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


Constraint on composition

Constraint on Composition

  • Basic FE|OQ works for all protocols

  • Opport requires meaningful cost-to-dest metric


Evaluation code size and memory footprint

Evaluation: code size and memory footprint

  • Two combination save 40%-58% less memory, 18%-37% program memory


Evaluation performance

Evaluation: Performance

  • More delay in network layer than monolithic arch

  • Performance is not the primary goal in sensornet, i.e. energy.


Conclusion

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.


Discussion

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?


  • Login