1. Completely Distributed Low Duty Cycle Communication for Long-living Sensor Networks
IHP: Innovation for High Performance Microelectronics
독일 연방정부와 부란덴부르크주 지원받음.
라이프니츠연구협회(WGL) 산하에 있으며 프랑크푸르트에 소재
연구분야
System Design
Circuit Design
Technology
Materials Research
ETRI와 60 GHz이상의 밀리미터파 통신 및 회로기술, SiGe BiCMOS 기술, MPW 활용 및 반도체 관련 상호 교류 가능한 기술분야 등의 MOU 체결
Marcin Brzozowski, Hendrik Salomon and Peter Langendoerfer
IHP Im Technologiepark Frankfurt
RTLab. Kim Tae-Hyon

2. Contents Introduction Related work Problem Statement Protocol Overview
Protocol Detail
Implementation
Experiment Result
Conclusion

3. Introduction
An off-the-shelf sensor node works only for few days if all the parts are permanently powered on
The challenge is to guarantee a lifetime of several years
Therefore, low duty cycle protocol are essential in long-living sensor networks. Such protocol keep the nodes sleeping most of the time
However, to transmit and to receive data the nodes must be awake at the same time. This problem is referred to as rendezvous problem
In This paper they continue their work, and present a completely Distributed Low Duty Cycle MAC(DLDC-MAC) protocol

4. Related work Classified rendezvous schemes Purely Synchronous
Nodes agree on the next communication time
ex) SMAC
Purely Asynchronous
A node wakes up another node, e.g. wake-up radio
Pseudo Asynchronous
Nodes use an underlying periodic wake-up scheme
STEM(Sparse Topology and Energy Management), WiseMAC

5. Problem Statement Lifetime and rendezvous Decentralized networks
To achieve longer lifetimes, the nodes stay in sleep mode for a long time, keeping the transceiver powered down
Synchronize their wake-up phases is referred to as rendezvous
Decentralized networks
As there are no base stations and no permanent sinks in decentralized networks, rendezvous and data dissemination is very challenging

6. Problem Statement (Cont’)
Fig1. Example decentralized application
Each source node replicates data (guaranteed replication within 1-hop neighborhood + random replication outside 1-hop)
A temporary sink may appear anywhere and at any time; the sink issues data gathering request, which are forwarded randomly until they reach the source

7. Problem Statement (Cont’)
Protocol requirement
We need a low duty cycle protocol which achieves a long lifetime.
Nodes must realize a global wake-up synchronization scheme
Such a MAC protocol must support data replication in this scenario

8. Protocol Overview

9. Protocol Overview (Cont’)
Beacons
The beacon period is the same for all nodes
Upon receiving a neighbor’s beacon, the node estimate the next beacon
After sending a beacon, the node stays in the receive mode shortly. During this time other nodes can send request.
Schedule setup
After powering on, a node listens for the whole beacon period.
Then knowing the beacon times of neighbors, the node sends network join announcements during the receive time of neighbor
Each node collects the complete list of the two-hop neighbors with corresponding beacon times.

10. Protocol Overview (Cont’)
Two-hop neighborhood
To get the two-hop neighborhood, each node sends its neighbor list together with corresponding beacon times once in a while
Data transmission
With Beacon
Piggy-backed in beacons
Additional Time Slot
The node arranges additional data slots in cooperation with its neighbor

11. Protocol Details Clock drift and missed beacons
Each node stores for each neighbor the reception time of the last beacon
If a node misses a neighbor’s beacon, it increases the guard time for the next receive attempt

12. Protocol Details (Cont’)
Asymmetric links
If a node can transmit data to its neighbor but cannot receive anything from it, the link is Asymmetric
In this protocol ignores permanent asymmetric links
Experiment revealed that links tend to be temporarily asymmetric
Links failures
A node detects a broken link, when it does not receive several consecutive beacon from a neighbor.
After detecting a broken link, the corresponding neighbor is not immediately regard as not working
After some time, the node tries to receive beacon from the neighbor again by waking up neighbor at neighbor’s beacon time

13. Protocol Details (Cont’)
Beacon overlap prevention
The beacons overlap leading to collisions
To counter this threat, each node monitors beacon times. When the time difference between any two beacon is smaller than a threshold, one of the affected nodes choose a new beacon time
The node includes in its beacon the new beacon time together with the remaining number of beacon periods until the beacon change take place
Collision avoidance
As the nodes prevents the overlap of transmit times, there is no collisions risk in this protocol

14. Implementation Hardware Software Tmote sky TinyOS DLDC-MAC
8MHz MSP430 (10k RAM, 48k Flash)
CC2420
Humidity, Temperature, Light Sensor
Software
TinyOS
DLDC-MAC

15. Experimental Result

16. Experimental Result (Cont’)
Description
10 tmote sky sensor nodes using DLDC-MAC protocol
Transmitter output power to -25dBm
Beacon period is one minute
Nodes transmitted data a few bytes a minute towards node 1
14 day office experimental
Beacon overlap prevention and clock drift
They observed that the clock drift was quite stable for each sensor node
The experiment showed that each node can use shorter guard times related to the real clock drift

17. Experimental Result (Cont’)

18. Experimental Result (Cont’)
Robustness against link failure

19. Experimental Result (Cont’)
Direct communication drawback

20. Conclusion
DLDC-MAC copes with the problem of clock drift, i.e. nodes wake up at right time and do not miss beacon due to the clock drift
The experiment revealed that the clock drift is stable and much smaller than the worst possible drift
We observed that direct communication over long distances led to a very high packet error rate. In that case, multi-hop communication achieved much higher communication reliability.