merlin: a synergetic integration of mac and routing for distributed sensor networks

http://www.cs.ucd.ie/students/aruzzelli/homeMERLIN: Integrating energy-efficient MAC and Routing

MERLIN: A Synergetic Integration of MAC and Routing for Distributed Sensor Networks

A.G.Ruzzelli, M.J.O’Grady, R.Tynan, G.M.P.O’Hare.

Adaptive Information Cluster project (AIC) and

Smart Media Institute (SMI)

Department of Computer ScienceUniversity College Dublin

Ireland.http://www.adaptiveinformation.ie


Summary

• Overview of WNSs and protocols

• Motivation

• Phase1: MERLIN design– Motivation and objectives– Fundamental concept– MAC details – Routing details

• Phase2: Simulation and results– Scheduling performance – Comparison against SMAC+ESR

• Conclusion


Sensor network characteristics

• Energy consumption: primary objective

• The wake-up concept

• Very low duty cycle (even less than 5%)

• Small packets smaller than in ad-hoc networks (e.g. temperature data is few bytes)

• Low data traffic per node


Communication reliability: Nodes are prone to fail and bad channel condition might affect the transmission

Scalability: Medium Access control should be able to deal with large scale networks

Unique global addressing:

Low processing capability

High end-to-end latency of packets

Important issues of protocols for WSNs


What does MERLIN address?Energy-efficiency

• by an adaptive node activity scheduling

End-to-end latency reduction • Separate MAC and Routing layers in low duty-cycle multi-hop networks cause

an extremely high latency – (e.g. SMAC +DSR at 5% duty >35s delay for packets of 10 hops away

nodes )

Communication reliability • failure, interference, depletion, mobility Addressing a single node can

result in high error probability

Node-to-Gateway routing

Protocol generality

Initial idea presented at IWWAN04: A.G. Ruzzelli, Evers, Dulman, Van Hoesel, Havinga. “ On the design of an energy-efficient low-latency integrated protocol for Wireless Sensor networks"

What MERLIN does NOT address:•Node-to-node routing located at several hop distance


Design goals

•MAC+Routing integration into a simple architecture;

•No usage of handshake mechanisms;

•No specific node addressing;

•Reduce latency while ensuring a very low energy consumption

•Increasing communication reliability while limiting packet overhead;


Initial idea: Timezone division

Gateway

Node

(European EYES project, NL)

Nodes with the same color are in the same time zone

Every node sets its zone and forward the sync packet to more distant nodes.

A node division both in time and space is generated, i.e. timezone


Division of the network in timezones

Nodes report to the closest gateway

Nodes within the same zone wake up, transmit and go into sleep simultaneously


Timezone data traffic

Upstream multicast: Packets are forwarded to lower zones

Zone 2

Zone 3

Zone 1

Downstream multicast: Packets transmitted to higher zones

Local broadcast: Packets reach all neighbours. No forwarding performed

Sleeping


Global allocation

Zone 1

Zone 2

Zone 3

Zone 4

Zone 5

Zone 6

Zone 7

Zone 8

Frame Frame

Frame

The allocation of further zones can be obtained by appending the same table.

The allocation of further frames is obtained by flanking the same table.


Accessing the table

Nodes in the same timezone contend the slot for local broadcast only once each 4 frametimes

If Mod(FRAME#, NZONE) = Mod(myZone,NZONE)

To access the current slot in the table:

SLOT# = GlobalTime/SLOTTIMEcurrentSlot = Mod(SLOT#, NSLOT)

NZONE = 4NSLOT =9


Recall that • Nodes in the same zone share the same slot for activity• transmission in MERLIN (multicast) do not address a specific receiving

node

How can simultaneous transmission be handled?How can correct/incorrect receptions be notified?

Intra-zone MAC features

Zone N

Zone N+1

Zone N-1


Burst tones can help

• Properties– Are signal impulse Do not contain any coded

information– Are robust Several simultaneous burst can still be

identified as one burst– They are shorter that a normal ACK

• Utilization

Multicast: Bursts identify correct receptionsBACK

In transmission to the gateway

Broadcast: Bursts identify reception errorsBNACK

In local broadcast


Asynchronous transmission Mechanism

Tx1

Tx2

Tx2

Tx1

CCA

Preamble Packet

Preamble Packet

Listen

Sleep

Sleep

Random

Random

Burst*

* burstACK if local broadcast, burst NACK if multicast

CCA

CCA

Sleep

Sleep

Sleep

Listen

Transmit

CCA

CCA

Sleep

Tc

Tc

S l o t l e n g t h

Tc

Tx1

Tx2

Rx1

Rx1 Rx1

CCAListen SleepSleep

Rx2

Burst*

Rx2Rx2


Disadvantages

1)MERLIN does not address a specific receiving node

multiple copy of the same msg sent can be generated

increase overhead!

2) Some collisions due to the Hidden Terminal Problem (HTP)

Zone 1 Zone 2Zone 3

Zone 4Zone 5

A

B

Zone 3

A

B

?


Routing characteristics (I)

• 3 small buffers of upstream, downstream and local broadcast are provided

• Packets organised in multiple msgs of the same data traffic type;

• Packets contain a msg-ID index of included msgs;

• Nodes, which lose the contention, keep on listening to the beginning of the transmitted packet then go into sleep;

• Nodes discard from their buffer the msgs already fowarded.

Pro : Reduce overhead in transmission!

Con : Small increase of node activity;

Increase complexity.

Channel contention

messagesMsg-index

Discard msgs already forwarded from their queue

P a c k e t

Listen to the packet index

Controlled multipath


Routing characteristics (II)

Timezone maintenance• Timezone update are sent periodically;

• Failed reception of timezone update from zone N-1 node to zone N node triggers a upstream multicast of Timezone Update request (TUR)

– N-1 node/s reply Connection reestablished

• N-1 failed local broadcast TUR– At least one reply change of zoen to N+1

• N failed downstream broadcast TUR

1

23

3

4

2

4

1

3

4

2

TUR

1

3

4

2

TUR

1

3

4

2

6

5


Assessment

Simulation tool: OmNet++

Framework: EU EYES project

Evaluation against SMAC+ESR

In Progress:

Philips Sand node implementation


Scenario and Setup•Scenarios

•5 nodes two-hops

•70 nodes Random multihop

•Metrics:•Energy consumption per RX packet •Network lifetime•E-to-E latency•Total packet overhead•% sleeping time

•Parameters:•Duty cycle (acting on CW and frametime size)•Low traffic conditions (12 packet/min)•High traffic conditions (60 packet/min)

Sources

Forwarder

Destinations


Low traffic 2-hops scenario


High traffic 2-hops scenario


Multihop scenario: Lifetime

Note: These graphs have little relevance if not related to the EtoE latency


Multihop scenario: Latency/energy

Given a certain sustainable latency, MERLIN consumes between 2 and 2.5 times less energy than SMAC+ESR


Total packet overhead

The MAC routing integrated nature MERLIN results in a smaller packet overhead than SMAC+ ESR.


Conclusion

• Description and simulated results of MERLIN have been presented;

• MERLIN is suitable for large scale sensor networks with energy consumption as main goal;

• MERLIN is suitable for communication to a from the gateway

• The multicast mechanism with burst ACK showed large improvement on the communication reliability

• The integrated nature and the absence of handshake mechanisms help reducing the EtoE packet delay

• EtoE delay can be traded-off for a longer network lifetime Results showed lifetime being extended by a factor of 2.5 of MERLIN with respect to SMAC


Thank you for your kind attention

merlin: a synergetic integration of mac and routing for distributed sensor networks

Documents