tep105.txt

tinyos-2.x.rar

===================================
Low Power Listening
===================================

:TEP: 105
:Group: Core Working Group 
:Type: Documentary
:Status: Final
:TinyOS-Version: 2.x
:Author: David Moss, Jonathan Hui, Kevin Klues

.. Note::

   This memo documents a part of TinyOS for the TinyOS Community, and
   requests discussion and suggestions for improvements.  Distribution
   of this memo is unlimited. This memo is in full compliance with
   TEP 1.


Abstract
====================================================================

This TEP describes the structure and implementation of the TinyOS 2.x 
link layer abstractions. The architecture is designed to allow each radio 
type to implement its own low power strategy within the Hardware Adaptation
Layer (HAL), while maintaining a common application interface.  The 
history and strategies for low power listening are discussed, as well 
as expected behavior and implementation recommendations.

1. Introduction
====================================================================

Asynchronous low power listening is a strategy used to duty cycle 
the radio while ensuring reliable message delivery since TinyOS 1.x 
[MICA2]_. 

While a CC1000 or CC2420 radio is turned on and listening, it can 
actively consume anywhere between 7.4 to 18.8 mA on top of the power 
consumed by other components in the system [CC1000]_,[CC2420]_.  
This can rapidly deplete batteries.  In the interest of extending 
battery lifetime, it is best to duty cycle the radio on and off to
prevent this idle waste of energy.  In an asychronous low power 
message delivery scheme, the duty cycling receiver node saves the 
most energy by performing short, periodic receive checks.  The power 
consumption burden is then placed on the transmitter node, which 
must modulate the radio channel long enough for the recipient?s 
receive check to detect an incoming message.  A synchronous low 
power message delivery scheme takes this idea a step further by 
allowing the transmitter to only transmit when it knows the 
destination node is performing a receive check.

2. Background
====================================================================

2.1 Early TinyOS 1.x CC1000 Low Power Listening Implementation
--------------------------------------------------------------------

TinyOS 1.x introduced low power listening on the CC1000 radio, but 
never introduced a similar scheme for the CC2420 radio in the baseline.  
The CC1000 radio had the following low power listening commands, 
provided directly by CC1000RadioIntM:::

  command result_t SetListeningMode(uint8_t power);
  command uint8_t GetListeningMode();
  command result_t SetTransmitMode(uint8_t power);
  command uint8_t GetTransmitMode();

The uint8_t 'power' mode parameter was initially defined as follows:::

  //Original CC1000 Low Power Listening Modes
  Power Mode 0 = 100% duty cycle
  Power Mode 1 = 35.5% duty cycle
  Power Mode 2 = 11.5% duty cycle
  Power Mode 3 = 7.53% duty cycle
  Power Mode 4 = 5.61% duty cycle
  Power Mode 5 = 2.22% duty cycle
  Power Mode 6 = 1.00% duty cycle

There were several issues with this interface and implementation.  
First, setting up a low power network was cumbersome.  The low power 
listening commands had to be directly wired through CC1000RadioIntM, 
and called while the radio was not performing any transactions.  
Second, each node in a network was expected to have the same radio 
power mode.  Finally, the pre-programmed duty cycles were not linear 
and offered a very limited selection of options.

In this low power listening implementation, the transmitter mote would 
transmit a packet that consisted of an extremely long preamble.  This 
preamble was long enough to span a complete receive check period.   On 
the receiver?s end, the radio would turn on and read bits from the 
radio.  If a preamble sequence was detected in the incoming bits, the 
receiver?s radio would remain on for the full duration of the 
transmitter?s preamble and wait for the packet at the end.  

This original low power listening scheme was rather inefficient on both 
the transmit and receive end.  On the receive end, turning on the radio 
completely and reading in bits typically cost much more energy than 
necessary.  The transmitter's long preamble could end up costing both 
nodes to have their radios on much longer than required, sending and 
receiving useless preamble bits.

2.2 CC1000 Pulse Check Implementation
--------------------------------------------------------------------

Joe Polastre and Jason Hill developed a better receive check 
implementation in the CC1000 ?Pulse Check? radio stack for TinyOS 1.x, 
while maintaining the same interface.  This implementation took advantage 
of a Clear Channel Assessment (CCA) to determine if a transmitter was 
nearby. 

In this implementation, the CC1000 radio did not have to be turned on 
completely, so it consumed less maximum current than the previous 
implementation.  The radio on-time was also significantly reduced, only 
turning on long enough for a single ADC conversion to occur.  If energy 
was detected on the channel after the first ADC conversion, subsequent 
ADC conversions would verify this before committing to turning the 
radio receiver on completely.

In this implementation the receiver's efficiency dramatically improved, 
but the transmitter still sent a long, inefficient preamble.  Energy 
consumption used to transmit messages was still high, while throughput 
was still low.

2.3 Possible Improvements
--------------------------------------------------------------------

Low power listening is a struggle between minimizing energy efficiency 
and maximizing throughput.   In an asynchronous low power listening 
scheme, several improvements can be made over earlier implementations.  
One improvement that could have been made to earlier implementations is 
to remove the long transmitted preamble and send many smaller messages 
instead.  For example, the transmitter could send the same message over 
and over again for the duration of the receiver's receive check period.  
The receiver could wake up and see that another node is transmitting, 
receive a full message, and finally send back an acknowledgement for that 
message.  The transmitter would see the acknowledgement and stop 
transmitting early, so both nodes can perform some high speed transaction 
or go back to sleep.  Useless preamble bits are minimized while useful 
packet information is maximized.  Incidentally, this is a good strategy 
for CC2420 low power listening.  This strategy certainly improves energy
efficiency and throughput, but further improvements may be possible by 
employing a synchronous delivery method on top of this type of 
asynchronous low power listening scheme.

Improvements can also be made to the original low power listening 
interfaces.  For example, instead of pre-programming power modes and 
duty cycles, a low power listening interface should allow the developer 
the flexibility to deploy a network of nodes with whatever duty cycle 
percentage or sleep time desired for each individual node.  Nodes with 
different receive check periods should still have the ability to 
reliably communicate with each other with little difficulty.

3. Interfaces
====================================================================

3.1 Low Power Listening Interface
====================================================================

The LowPowerListening interface MUST be provided for each radio by the 
platform independent ActiveMessageC configuration.  

In some implementations, low power listening may have an option to 
compile into the radio stack for memory footprint reasons.  If low