A Unifying Link Abstraction for Wireless Sensor Networks

1
A Unifying Link Abstraction for Wireless Sensor
Networks

• Joseph Polastre, Jonathan Hui, Philip Levis,
  Jerry Zhao,David Culler, Scott Shenker, Ion
  Stoica
• UC, Berkeley

2
Contents

• Introduction Issues
• SP Layer
• Architecture
• Details of Neighbor Table
• Details of Message Pool
• Evaluation
• Conclusion

3
Introduction

• Many protocols for sensor nets have been
  proposed, but across their designs, there is no
  overall architecture
• Protocols (re)implement similar/same
  functionalities (e.g., neighbor table management)
  but they are not reusable

4

• MintRoute implementation (on TinyOS mica2)
• maintains information about routing (hop count)
  and link quality at the same time (in the same
  table), but link quality information can be
  shared among different routing protocols if
  separated
• depends on B-MAC (B-MACs nesC interface) at the
  data link layer. Its not easy to port the
  implementation to different platforms which do
  not support B-MAC
• e.g., Telos supports only subset of B-MAC, and
  micaZ only supports Zigbee (IEEE802.15.4 data
  link layer)

5
Issues

• The creation of new protocols requires
• Effort to recognize functionalities in existing
  implementations, or
• Reimplement functionalities from scratch
• Co-existing protocols in one node unnecessarily
  consume more resources (memory) because of
  overlapping functionalities.
• The authors expect sensor net applications will
  use multiple protocols in the same network in
  future

6
Research Objective

• Proposing a layer, called Sensornet Protocol (SP)
  Layer
• Defines common functionalities (i.e.,
  send/receive packets and neighbor table
  maintenance) for network layer
• Providing interfaces in NesC
• Implementations of the functinalities depend on
  underlying data link protocols (e.g., B-MAC, IEEE
  802.15.4, )
• Abstract data link layer (data link protocol)
• Network protocols and data link protocols are
  clearly separated by SP
• Network protocols implemented on SP can run on
  any data link protocols
• Benefits
• Increases code reuse
• Network protocols at network layer can be reused
  on different data link protocols without revision
• Enable runtime sharing
• Co-existing network protocols share common
  functionalities in the SP layer

7
Sensornet Protocol Layer

• SP provides three functionalities
• Neighbor management
• Maintain a neighbor table containing neighbors
  addresses, link quality,
• Data transmission
• Dispatch packets to a link interface (data link
  layer)
• Optimize packet transmission through a message
  pool
• Provides feedback (e.g., congestion) to the
  network layer
• Data reception
• Dispatch packets arriving on a link interface to
  a network layer

8
Network Layer
Neighbors
Send
Receive
SP Layer
SP
SP Adaptor A
SP Adaptor B
Data Link Layer
Data Link A
Data Link B
PHY A
PHY B

• SP provides three interfaces, and network
  protocols do not need to know the detail of lower
  layers

9
Neighbor management

• An entry (per neighbor) in the neighbor table
  consists of
• The address of a neighbor
• Address format depends on the data link protocol
• Link quality
• Scheduling information
• When to be awake and asleep?
• Listen mode?
• Whether the neighbor will listen (wait for
  packets) when its awake
• e.g., If false, a node does not wake up at the
  time even if it has packets to send
• ? According to this information, each node
  determines which actions to take and when.
• e.g., send a packet when a neighbor is awake

10
sp_neighbor_t
addresstime on time off listen quality
address_t local time node wakes local time node
sleeps true or false estimated link quality
Struct for an entry

• Neighbor table is extensible
• E.g., geological location
• To extend the table, developers need to change
  its definition before compiling it

11
Interface
12

• New Node detection
• When a link detects a new neighbor node, it
  notifies SP. SP asks each network protocol
  whether the node should be added to the table
• E.g., if the table contains enough neighbors, new
  node may not be added or existing one may be
  replaced (SP provides an interface to remove
  existing entry)
• SP also provides a methods to find neighbors

13

• Update
• After time to wake up/sleep, SP asks network/data
  link layers to update the entry
• e.g., In slotted data link protocol (e.g., IEEE
  802.15.4), each node notifies its schedule every
  cycle (in a beacon packet), and SP obtains the
  time of the next slot as neighbors wakeup time,
  and
• CSMA data link returns now as wakeup time and
  never as sleep time.
• After receiving message, network protocols can
  update information about link quality
• SP provides a method to calculate and update the
  quality information
• Listen
• Listen packets from a specific neighbor in the
  table on next wakeup

14
Data transmission

• Network protocols send messages through a SPs
  interface
• Can specify urgent/reliable messages
• Can get feedback
• SP layer maintains a message pool
• Messages are stored in a pool before its
  transmission
• SP optimize the transmission by using a message
  pool

15
Interface
16
One entry per message
Message Pool

• An entry per message
• Contains references to the next packets of a
  message
• A message may consist of multiple packets
• After sending the packet, SP asks the next packet
  to a network protocol
• Whether urgent/reliable message
• Two bits
• Two types of feedback
• Two bits

sp_message_t
destinationmessage quantity urgent reliability p
hase congestion
address_t 1st TOSMsg to send of pkts to send on
or off on or off D adjustment true or false
control
feedback
17

• Send a message through Send interface
• Create an entry and put a reference to the first
  packet
• Schedule and send packets
• Ack feedback
• SP requests the next packet
• Put a reference to the next packet

Network Protocol
packets
SP Message
1st packet
(1)
Next PacketHandler
(6)
(5)
Send
(2)
Message Dispatch
msg
SP
transmit
completed
feedback
(3)
(4)
(4)
Link Protocol
18
nesC basics
interface LED command void
turn_on() module LEDBoard provides
interface LED provides interface LED as
RED provides interface LED as
GREEN implementation // shared
variables // implementations
command void LED.turn_on() command void
RED.turn_on() command void
GREEN.turn_on()

• Module? interface implementation
• One interface in a module? One interface
  instance
• No dynamic memory allocation in nesC
• Module is used through interface instances

call
call LEDBoard.LED.turn_on() call
LEDBoard.RED.turn_on() call LEDBoard.GREEN.turn_o
n()
interface module
client code
19
interface LED command void turn_on()
event void no_battery() module LEDBoard
provides interface LED as RED provides
interface LED as GREEN implementation
command void RED.turn_on() signal
RED.no_battery() module Controller
uses interface LED as REDLED uses interface
LED as GREENLED implementation event void
REDLED.no_battery()

• Configuration? Wiring modules

wiring
configuration Signal implementation
components LEDBoard, Controller
Controller.REDLED -gt LEDBoard.RED
20
MintRoute
DirectedDiffusion
GPRS
module
uses
ltltinterfacegtgt SPSend
ltltinterfacegtgt SPSend
ltltinterfacegtgt SPSend
reference
wiring
ltltinterfacegtgt SPSend M
ltltinterfacegtgt SPSend D
ltltinterfacegtgt SPSend G
provides
BMAC
module
Message pool
21
module BMAC provides interface SPSenduint8_t
it // parameterized interface implementation
// shared message pool message_pool pool
command result_t SPSend.senduint8_t it(
sp_message_t msg ) // create and initialize
a table entity foreach // send a
packet // ask the next packet for
the network layer TOS_MsgPort nextPacket
signal SPSend.nextSendit( ... )
signal SPSend.sendDoneit( )
22
module MintRoute provides interface
NetworkLayerSend uses interface
SPSend implementation command void
NetworkLayerSend.send( sp_message_t msg )
// decide a route according to MintRoute
algorithm // Routing table is maintained by
this module // assign the destinagion
msg-gtdestination ... // send a message by
using SPLayer call SPSend.send(
sp_message_t msg ) event void
SPSend.sendDone( sp_message_t msg, result_t
success ) event TOS_MsgPtr
SPSend.nextSend( sp_message_t msg, uinit8_t pos
) // return the next packet
23
configuration Sensor implementation
components BMAC components MintRoute,
DirectedDiffusion, GPSR MintRoute.SPSend -gt
BMAC.SPSend0 DirectedDiffusion.SPSend -gt
BMAC.SPSend1 GPSR.SPSend -gt BMAC.SPSend2
24

• Example of scheduling Low Power Listening
• CSMA link with preamble sampling
• Preamble Ill send packets to you. Do prepare!
• Sampling Does someone send packets to me?
• Sending packets require preamble
• As many packets as possible per one preamble
• Batch messaging to a given destination

preamble
transmission
TX preamble
sleep
sleep
sleep
packet
Node 1
time
RX
sleep
sleep
sleep
Node 2
packet
time
sampling
Waiting for packets
25

• Urgent message (urgent bit ON)
• SP layer treats packets of the message as high
  priority
• E.g., CSMA data link transmit the packet soon
• Reliable message (reliable bit ON)
• SP layer uses mechanisms underlying data link
  protocol provides
• E.g., acknowledgement and retransmission

26

• Network protocol can change urgent and
  reliability bits during a message transmission
  through the change method
• Can cancel a transmission through the cancel
  method

27
Feedback

• After sending a packet, a data link protocol
  provides feedback
• Congestion (congestion bit ON)
• Retransmission rate is too high!
• Thresholds to determine congestion depends on
  data link protocols
• Phase shift (phase shift bit ON)
• Shifting the schedule would be beneficial
• Even at low duty cycle, the traffic pattern can
  result in congestion if sensors read at regular
  intervals (same time)
• Check neighbors schedule to determine?
• E.g., put some delay before transmissions, shift
  the duty cycle,

28
Evaluation

• Implementations
• Implements MintRoute protocol above SP layer
• SP adaptors (SP implementations) for
• B-MAC on mica2
• IEEE 802.15.4 (Zigbees data link layer) on telos
• MintRoute implementation can be used on mica2 and
  telos without changing code
• SP layer provides an interface, and hides the
  differences among lower layers

29

• Amount of compiled code and memory usage
• Original version on TinyOS
• Including MintRoute and B-MAC/IEEE 802.15.4
  implementations
• SP version (Above SP)
• Only MintRoute implementation
• Code for MintRoute (63 bytes in mica2 after
  compilation) can be reused
• Developers at the network layer (develop routing
  protocols) do not need to implement code for
  neighbor maintenance
• Provided by SP (SP adaptors)
• Neighbor table (e.g., around 800 bytes in
  B-MAC/mica2) in SP can be shared among different
  network protocols

code
memory
bytes
30
Conclusion

• The authors propose Sensornet Protocol (SP) layer
  on sensornet
• SP layer hides the difference among data link
  protocols, and provides common functionalities
  among different sensornet protocols