XMesh Low-Power MAC Features

Feb 2007WSN Training: XMesh Route Cntrl - Low Power 1

XMesh Low-Power MAC Features

Objectives: Motivation Overall Power Usage Profile General Low-Power

Approach Network Wide

Synchronization Mica2 Implementation MicaZ Implementation Interface and Usage Labs

Low-power MAC Low-power XMesh

WSN Training: XMesh Route Cntrl - Low Power 2 Feb 2007

Motivation – Mote Energy Consumption

How much power do motes consume?

Combined Total: 20 mA to 30 mA

*8 MHz cpu clock, 32 khz oscillator on

Processors Power Consumption

Atmega128L*

8 mA to 10 mA (active)

20 A (sleep)

MSP430* 5 mA (active) 5 A (sleep)

Radios Power Consumption

CC2420 19.7 mA (Rx); 17.4 mA (Tx)

1 A (sleep)

CC1000 10.4 mA (Rx); 16.5 mA (Tx)

1 A (sleep)


Motivation – Battery

How long will motes last on 2 AA alkaline* batteries?

* Note: Alkaline cells are not the only battery, but their wide availability and price point makes them a standard by which to measure performance

Capacity Hours

2000 mA-hr

60 to 90


Motivation – Typical Application Requirements

Many sensor network applications require battery powered motes with life times greater than one year.

Most sensor network applications have very low data rates that do not require continuous processor or network activity.

Our low power strategy implemented in the MAC layer Power cycles the radio while maintaining

communication with neighboring nodes.


Motivation -- Estimating Average Current

Sleep The system is in this state approximately 95% of the

time.Timer0:

This timer service is always running For the MICAz this timer wakes every 230 msec for 400 µsec,

increments a counter, and goes back to sleep During this time the processor is using 8 mA of current.

Measure Sensor Specific to sensor board Affected by sensor power requirements, number and type of

sensors, sample time and rateTransmit Data

This occurs at intervals dependent on the sensor system requirements.

Without a low-power radio strategy the Mote will only last a few days (as seen in the previous slide)

We can improve battery life with a better strategy.


Current Draw of a Mote in Various Modes

Sensor power on

8 mA

Xmit data

Timer Service

Sensor Measure Interval

50 msec idle to acquire sensor data

Measured averaged current including health packets: 309 µA



Objectives: Motivation General Low-Power Approach Network Wide Synchronization Mica2 Implementation MicaZ Implementation Interface and Usage Labs



General Strategy – Receiver

Fixed Period

(time)Fixed Period

Device 1

Device 2

Radio On Listening

Radio On Listening


General Strategy – Receiver (text version)

Every node when not transmitting will periodically power on their radio in receive mode for short durations.

This period is known and fixed through out the network.


General Strategy – Sender

Fixed Period

(time)Fixed Period

Device 1 (Receiver)

Device 2 (Sender)

Radio Listen

Transmit wake up Transmit data

Receives wakes up & packet


General Strategy – Sender (text version)

Before transmitting any data packets, a node will send a long wake up sequence which spans the duration of the fixed listening period first.

Any receiving node that hears the wake up sequence will keep listening until the data packet is received. Otherwise the listening node will power down the transceiver.



Objectives Motivation General Low-Power Approach Network Wide Synchronization Mica2 Implementation MicaZ Implementation Interface and Usage Labs



General Strategy – Synchronized

Fixed Period

(time)Fixed Period

Device 1

Device 2

Radio Listen

Transmit short wake up

Transmit data

Receives wakes up & packet


General Strategy – Synchronized (text)

If we then synchronize every node to sniff and send at the same time through out the network, then we do not always need to send a long wake up sequence.

We can shorten the wakeup sequence to within the synchronization accuracy and only send synchronization messages with long preamble.


Network Wide Sync – Components

Disseminate time synchronization packets

Establish hierarchy graph Propagating time stamps Compensate for oscillator skew/drift over

time


Network Wide Sync – Disseminate

Note: Arrows indicate transmitter and receiver of time synchronization broadcasts with long wakeup

Time Source (Base)

1 Hop Nodes

2 Hop Nodes

3 Hop Nodes


Network Wide Sync – Disseminate (text)

Time synchronization messages are disseminated through out the network as local broadcasts.

Every node in the network will periodically send out time synchronization messages.

Every time synchronization message is sent with a long wake up sequence to ensure that every node hears the message.


Network Wide Sync – Authority

Time Source (Base)

1 Hop Nodes

2 Hop Nodes

3 Hop Nodes

Authority = 0

Authority >= 2

Authority >= 4

Authority >= 6


Network Wide Sync – Authority (text)

Every time synchronization update message contains an authority value in addition to a time stamp.

The authority value of the base station is always 0. No other node may have authority equal to 0.

When a node accepts a time stamp in a time update, the Node will also adopt the authority level + 2.

Nodes will only accept time updates with an authority level lower than the authority level of the node.

Since time updates are infrequent, oscillator drift over time is tracked to improve accuracy.


Propagating Time Stamps

Tim

e Sy

nc p

acke

t

queu

ed fo

r

trans

miss

ion

Star

t Pre

ambl

e /

Wak

eup

Sequ

ence

Tran

smiss

ion

Star

t of P

acke

t Pay

load

Tim

e St

amp

Take

n.

Inse

rted

into

Pay

laod

Queueing Delay BackoffPreamble +

Wakeup SequenceStart

SymbolPacket Transmission

RX IDLE / SLEEP SYNC Packet Reception

Transit Delay

New Time = Time Stamp + Transit Delay


nesC Interface – RadioCoordinator

interface RadioCoordinator{ /** * This event indicates that the start symbol has been detected * and its offset */ async event void startSymbol(uint8_t bitsPerBlock, uint8_t offset, TOS_MsgPtr msgBuff);

/** * This event indicates that another byte of the current packet has been rxd */ async event void byte(TOS_MsgPtr msg, uint8_t byteCount);

/** * Signals the start of processing of a new block by the radio. This * event is signaled regardless of the state of the radio. This * function is currently used to aid radio-based time synchronization. */ async event void blockTimer();}

RadioCoordinator is used for time stamping

Low level MAC features generate interrupts through the RadioCoordinator interface when packet transmissions are initiated. In this way time stamps can be taken without the ambiguity cause by undetermined delay in the stack.


Compensate For Oscillator Skew/Drift Over Time

• The worest case skew between any 2 nodes over temperature will not exceed 50ppm.

• Typical skew between nodes is usually < 10ppm.

• Over a 10 minute interval, worest case drift will be 6 to 30 ms.

•Essentially every node synchronizes to the base station, the drift caused by the crystal can be track and eliminated via the forum above.

TimeSource = Skew * TimeRemote + RemoveOffset



Objectives Motivation General Low-Power Approach Network Wide Synchronization Mica2 Implementation MicaZ Implementation Interface and Usage Labs



Implementation

The wake sequence is implemented differently between the MICA2 and MICAz platforms.

The MICA2 platform uses a byte radio The wake up sequence is implemented by increasing

the preamble of the data packet.

The MICAz platform uses a packet based radio The length of packets is fixed Long preambles are implemented as series of small

packets


MICA2 Implementation – Unsynchronized

time

125 ms 125 ms 125 ms 125 ms

Receiver

Receiver

Sender preamble

data

data

data


MICA2 Implementation – Unsynchronized (text)

Long Preamble: Every data packet will be sent with an extended

preamble as the wake up sequence. In this example the preamble length is 140 ms.

Algorithm:1. Wake up 8 times per second

2. Sniff radio channel

3. If preamble, receive data

4. If clear, send if needed, else sleep


MICA2 Implementation – Synchronized

time

125 ms 125 ms 125 ms 125 ms

Receiver

Receiver

Sender preamble

data

data

data


MICA2 Implementation – Synchronized (text)

Algorithm Every node in the network synchronizes to sniff and

send at the same moments In this example it is every 125 msec.

Senders and receivers are synchronized so data packets do not need long preambles.

Preamble type

Duration

Usage

Long 140 ms Allows arbitrary new nodes to join mesh network

Short 25 ms Optimizes power when sending to nodes already in mesh

Standard 2 ms Optimizes communication speed for nodes talking to base


MICA2 Implementation – Synchronized

time

125 ms 125 ms 125 ms 125 ms

Receiver

Receiver

Sender preamble

data

data

data


MICA2 Implementation – Sniff Timing

Fast Channel check: 140 µsec


MICA2 Implementation – Sniff Current Draw


MICA2 Implementation -- Performance

Testbed: 20 MICA2 Majority of the nodes 2

hops from the base station

Estimated battery lifetime 1.2 years @ 3-minute

reporting intervals Battery life depends on

type of sensor(s) attached to node.

Expected LifetimeSurge Time Sync (20 nodes)

00.511.522.533.544.5

0 20 40 60 80 100 120

Reporting Interval

Yea

rs


MICAz Implementation -- Unsynchronized

τ

τ

Sniff for activity

Transmit data packet

Transmit Wakeup packet sequence

Sender

Receiver

Rx Wake Up + Data Packets

Link Lvl Ack

Rx Link Lvl Ack


MICAz Implementation -- Text

Long Preamble: Every data packet will be sent with a wake up

sequence composed of a series of short packets. In this example the sequence length is 135 ms.

Algorithm: Wake up 8 times per second Sniff radio channel If any packets detected, receive data If clear, send if needed, else sleep


MICAz Implementation – Sniff Current Draw


MICAz Implementation

Moteworks 2.0 Only asynchronous low power available for MICAz Synchronized version available in MW 2.2

Estimated battery lifetime 400 A @ 8 sniffs per second and no traffic 700 A @ one sensor sample and send per 3 minutes ~4 month on two AA alkaline cells Battery life depends on type of sensor(s) attached to

node.


Lab on Low-Power MAC

Applications: CountSend CountReceive


Lab – Part 1: Low Power MAC

Background The low power features of XMesh is implemented in the MAC

layer. It is thus possible to enable low power in applications that do

not use a networking layer. In this lab we will compile two programs, CountSend and

CountReceive to use a low-power MAC.

File Location CountSend: Moteworks/apps/general/CountSend CountRecv: Moteworks/apps/general/CountReceive

Notes This lab requires two Motes We recommended that you enable low power is via the route,lp flag at compile time for both applications

The following examples assumes a MIB510 on COM1 therefore adjust as necessary


Lab Step 1: High Power MAC Compile & Flash

Example for MICAz being flashed on a MIB520

Example for MICA2 being flashed on a MIB520

$ cd /opt/Moteworks/apps/general/CountSend$ make micaz route,hp install mib520,COM<#>

$ cd /opt/Moteworks/apps/general/CountReceive$ make micaz route,hp install mib520,COM<#>

$ cd /opt/Moteworks/apps/general/CountSend$ make mica2 route,hp install mib520,COM<#>

$ cd /opt/Moteworks/apps/general/CountReceive$ make mica2 route,hp install mib520,COM<#>

But use the appropriate <programmer> and COM port# or IP Address

After flashing is done, remove

Mote 1 and attach Mote 2

to MIB



to MIB


Lab Step 2: Low Power MAC Compile & Flash

Example for MICAz being flashed on a MIB520

Example for MICA2 being flashed on a MIB520

$ cd /opt/Moteworks/apps/general/CountSend$ make micaz route,lp install mib520,COM<#>

$ cd /opt/Moteworks/apps/general/CountReceive$ make micaz route,lp install mib520,COM<#>

$ cd /opt/Moteworks/apps/general/CountSend$ make mica2 route,lp install mib520,COM<#>

$ cd /opt/Moteworks/apps/general/CountReceive$ make mica2 route,lp install mib520,COM<#>

But use the appropriate <programmer> and COM port# or IP Address



to MIB



to MIB


Lab Notes: Low Power Enabling an XMesh App

Usage The low power feature can be enable in any XMesh-enabled

application in the same manner. Go to any application that is XMesh enabled and use the route,lp flag during compilation.

For instance, try it with MyApp_Mesh

Notes The low power feature is meant for applications that run at low

duty cycles There is always a trade off between sampling rate, duty cycle,

and power. For example is not feasible to expect a high sampling data rate

and high duty cycle application to last very long running solely on batteries.


Q & A

Documents

XMesh Low-Power MAC Features