tep105.txt

tinyos-2.x.rar

power listening is not compiled in with the stack, calls to 
LowPowerListening MUST be handled by a dummy implementation. 

The TEP proposes this LowPowerListening interface:::
  
  interface LowPowerListening {
    command void setLocalSleepInterval(uint16_t sleepIntervalMs);
    command uint16_t getLocalSleepInterval();
    command void setLocalDutyCycle(uint16_t dutyCycle);
    command uint16_t getLocalDutyCycle();
    command void setRxSleepInterval(message_t *msg, uint16_t sleepIntervalMs);
    command uint16_t getRxSleepInterval(message_t *msg);
    command void setRxDutyCycle(message_t *msg, uint16_t dutyCycle);
    command uint16_t getRxDutyCycle(message_t *msg);               
    command uint16_t dutyCycleToSleepInterval(uint16_t dutyCycle);
    command uint16_t sleepIntervalToDutyCycle(uint16_t sleepInterval);
  }

setLocalSleepInterval(uint16_t sleepIntervalMs)
  - Sets the local node?s radio sleep interval, in milliseconds.

getLocalSleepInterval()
  - Retrieves the local node?s sleep interval, in milliseconds.  If duty cycle percentage was originally set, it is automatically converted to a sleep interval.

setLocalDutyCycle(uint16_t dutyCycle)
  - Set the local node?s duty cycle percentage, in units of [percentage*100].

getLocalDutyCycle()
  - Retrieves the local node?s duty cycle percentage.  If sleep interval in milliseconds was originally set, it is automatically converted to a duty cycle percentage.

setRxSleepInterval(message_t \*msg, uint16_t sleepIntervalMs)
  - The given message will soon be sent to a low power receiver. The sleepIntervalMs is the sleep interval of that low power receiver, in milliseconds.  When sent, the radio stack will automatically transmit the message so as to be detected by the low power receiver.

getRxSleepInterval(message_t \*msg)
  - Retrieves the message destination?s sleep interval.  If a duty cycle was originally set for the outgoing message, it is automatically converted to a sleep interval.

setRxDutyCycle(message_t \*msg, uint16_t dutyCycle)
  - The given message will soon be sent to a low power receiver.  The dutyCycle is the duty cycle percentage, in units of [percentage*100], of that low power receiver.  When sent, the radio stack will automatically transmit the message so as to be detected by the low power receiver.

getRxDutyCycle(message_t \*msg)
  - Retrieves the message destination?s duty cycle percentage.  If a sleep interval was originally set for the outgoing message, it is automatically converted to a duty cycle percentage.

dutyCycleToSleepInterval(uint16_t dutyCycle)
  - Converts the given duty cycle percentage to a sleep interval in milliseconds.

sleepIntervalToDutyCycle(uint16_t sleepInterval)
  - Converts the given sleep interval in milliseconds to a duty cycle percentage.
  
3.2 Split Control Behaviour
--------------------------------------------------------------------

Low power listening MUST be enabled and disabled through the radio?s 
standard SplitControl interface, returning exactly one SplitControl 
event upon completion.  While the radio is duty cycling, it MUST NOT 
alert the application layer each time the radio turns on and off to 
perform a receive check or send a message.

3.3 Send Interface Behaviour
--------------------------------------------------------------------

Attempts to send a message before SplitControl.start() has been called 
SHOULD return EOFF, signifying the radio has not been enabled.  When
SplitControl.start() has been called by the application layer, calls 
to Send MUST turn the radio on automatically if the radio is currently 
off due to duty cycling.  If a message is already in the process of 
being sent, multiple calls to Send should return FAIL. 

The Send.sendDone(?) event SHOULD signal SUCCESS upon the successful 
completion of the message delivery process, regardless if any mote 
actually received the message.

3.4 Receive Interface Behaviour
--------------------------------------------------------------------

Upon the successful reception of a message, the low power receive event 
handler SHOULD drop duplicate messages sent to the broadcast address.  
For example, the CC2420 implementation can perform this by checking 
the message_t?s dsn value, where each dsn value is identical for every 
message used in the delivery. 

After the first successful message reception, the receiver?s radio 
SHOULD stay on for a brief period of time to allow any further 
transactions to occur at high speed.  If no subsequent messages are 
detected going inbound or outbound after some short delay, the radio 
MUST continue duty cycling as configured.

4. Low Power Listening message_t Metadata
====================================================================

To store the extra 16-bit receiver low power listening value, the radio 
stack?s message_t footer MUST contain a parameter to store the message 
destination?s receive check sleep interval in milliseconds or duty cycle
percentage.  For example, the low power listening CC2420 message_t footer 
stores the message's receive check interval in milliseconds, as shown 
below [TEP111]_.::

  typedef nx_struct cc2420_metadata_t {
    nx_uint8_t tx_power;
    nx_uint8_t rssi;
    nx_uint8_t lqi;
    nx_bool crc;
    nx_bool ack;
    nx_uint16_t time;
    nx_uint16_t rxInterval;
  } cc2420_metadata_t;

5. Recommendations for HAL Implementation
====================================================================
In the interest of minimizing energy while maximizing throughput, it 
is RECOMMENDED that any asynchronous low power listening implementation 
use clear channel assessment methods to determine the presence of a 
nearby transmitter.  It is also RECOMMENDED that the transmitter send 
duplicate messages continuously with minimum or no backoff period instead 
of one long message.  Removing backoffs on a continuous send delivery 
scheme will allow the channel to be modulated sufficiently for a receiver 
to quickly detect; furthermore, enabling acknowledgements on each 
outgoing duplicate packet will allow the transmit period to be cut short 
based on when the receiver actually receives the message.

Asynchronous low power listening requires some memory overhead, so 
sometimes it is better to leave the added architecture out when it is 
not required.  When it is feasible to do so, it is RECOMMENDED that 
the preprocessor variable LOW_POWER_LISTENING be defined when low 
power listening functionality is to be compiled in with the radio stack, 
and not defined when low power listening functionality shouldn?t exist.

It is RECOMMENDED that the radio on-time for actual receive checks be a 
measured value to help approximate the duty cycle percentage.

6. Author's Address
====================================================================

| David Moss
| Rincon Research Corporation
| 101 N. Wilmot, Suite 101
| Tucson, AZ  85750
|
| phone - [phone]
| email ? [e-mail]
|
| Jonathan Hui
| 657 Mission St. Ste. 600
| Arched Rock Corporation
| San Francisco, CA 94105-4120
|
| phone - [phone]
| email - [e-mail]
|
| Kevin Klues
| 503 Bryan Hall
| Washington University
| St. Louis, MO 63130
|
| phone - [phone]
| email - [e-mail]


7. Citations
====================================================================
.. [MICA2] "MICA2 Radio Stack for TinyOS."  http://www.tinyos.net/tinyos-1.x/doc/mica2radio/CC1000.html
.. [TEP111] TEP 111: message_t. 
.. [CC1000] TI/Chipcon CC1000 Datasheet.  http://www.chipcon.com/files/CC1000_Data_Sheet_2_2.pdf
.. [CC2420] TI/Chipcon CC2420 Datasheet.  http://www.chipcon.com/files/CC2420_Data_Sheet_1_3.pdf