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

1. 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 Science University College Dublin Ireland. http://www.adaptiveinformation.ie

2. 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 Summary

3. 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 Sensor network characteristics

4. Important issues of protocols for WSNs 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

5. 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 • What MERLIN does NOT address: • Node-to-node routing located at several hop distance 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"

6. 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;

7. Initial idea: Timezone division (European EYES project, NL) Gateway Node 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 Nodes with the same color are in the same time zone

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

9. Zone 3 Zone 2 Zone 1 Upstream multicast: Packets are forwarded to lower zones Downstream multicast: Packets transmitted to higher zones Timezone data traffic Local broadcast: Packets reach all neighbours. No forwarding performed Sleeping

10. Global allocation Frame Frame Zone 1 Zone 2 Zone 3 Zone 4 Frame Zone 5 Zone 6 Zone 7 Zone 8 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.

11. Accessing the table NZONE = 4 NSLOT =9 To access the current slot in the table: SLOT# = GlobalTime/SLOTTIME currentSlot = Mod(SLOT#, NSLOT) Nodes in the same timezone contend the slot for local broadcast only once each 4 frametimes If Mod(FRAME#, NZONE) = Mod(myZone,NZONE)

12. 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+1 Zone N Zone N-1

13. 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 In transmission to the gateway In local broadcast Multicast: Bursts identify correct receptions BACK Broadcast: Bursts identify reception errors BNACK Burst tones can help

14. Tc Tc Preamble Preamble Packet Packet Asynchronous transmission Mechanism CCA CCA Sleep Sleep Tx1 Tc Random CCA CCA Listen Sleep Sleep Tx2 Transmit Burst* Random CCA Listen Sleep Sleep Rx1 Burst* CCA Listen Sleep Sleep Rx2 S l o t l e n g t h * burstACK if local broadcast, burst NACK if multicast Rx1 Rx1 Tx1 Tx1 Tx2 Tx2 Rx2 Rx2

15. Zone 3 Zone 5 Zone 1 Zone 2 Zone 4 A B 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 3 A ? B

16. 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. Routing characteristics (I) Controlled multipath Channel contention P a c k e t messages Msg-index • Pro : Reduce overhead in transmission! • Con : Small increase of node activity; • Increase complexity. Discard msgs already forwarded from their queue Listen to the packet index

17. 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 2 2 1 1 2 1 2 1 3 3 3 3 4 4 2 4 4 6 TUR 4 TUR 5 3

18. Assessment Simulation tool: OmNet++ Framework: EU EYES project Evaluation against SMAC+ESR In Progress: PhilipsSand node implementation

19. 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) Forwarder Sources Destinations

20. Low traffic 2-hops scenario

21. High traffic 2-hops scenario

22. Multihop scenario: Lifetime Note: These graphs have little relevance if not related to the EtoE latency

23. Multihop scenario: Latency/energy Given a certain sustainable latency, MERLIN consumes between 2 and 2.5 times less energy than SMAC+ESR

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

25. 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 Conclusion

26. Thank you for your kind attention