tep126.txt

tinyos-2.x.rar

The TinyOS T-Frame packet does not include the 'network' field, nor
the functionality found in the Dispatch layer to set and check
the 'network' field.

No software footer is defined for the CC2420 radio.  A 2-byte
CRC byte is auto-appended to each outbound packet by the CC2420 radio
hardware itself.

The maximum size of a packet is 128 bytes including its headers and 
CRC, which matches the 802.15.4 specifications.  Increasing the 
packet size will increase data throughput and RAM consumption 
in the TinyOS application, but will also increase the probability 
that interference will cause the packet to be destroyed and need 
to be retransmitted. The TOSH_DATA_LENGTH preprocessor variable can 
be altered to increase the size of the message_t payload at 
compile time [2]_. 


4. CSMA/CA
====================================================================

4.1 Clear Channel Assessment
--------------------------------------------------------------------
By default, the CC2420 radio stack performs a clear channel assessment 
(CCA) before transmitting.  If the channel is not clear, the radio backs
off for some short, random period of time before attempting to transmit 
again.  The CC2420 chip itself provides a strobe command to transmit
the packet if the channel is currently clear.

To specify whether or not to transmit with clear channel assessment,
the CC2420TransmitP requests CCA backoff input through the RadioBackoff
interface on a per-message basis.  By default, each packet will be
transmitted with CCA enabled.

If layers above the CSMA layer wish to disable the clear channel
assessments before transmission, they must intercept the 
RadioBackoff.requestCca(...) event for that message and call back
using RadioBackoff.setCca(FALSE).
 

4.2 Radio Backoff
--------------------------------------------------------------------
A backoff is a period of time where the radio pauses before attempting
to transmit. When the radio needs to backoff, it can choose one of three 
backoff periods:  initialBackoff, congestionBackoff, and lplBackoff.
These are implemented through the RadioBackoff interface, which signals
out a request to specify the backoff period.  Unlike the CsmaBackoff
interface, components that are interested in adjusting the backoff can
call back using commands in the RadioBackoff interface.  This allows 
multiple components to adjust the backoff period for packets they are 
specifically listening to adjust.  The lower the backoff period, the
faster the transmission, but the more likely the transmitter is to hog
the channel.  Also, backoff periods should be as random as possible
to prevent two transmitters from sampling the channel at the same 
moment.

InitialBackoff is the shortest backoff period, requested on the first
attempt to transmit a packet.

CongestionBackoff is a longer backoff period used when the channel is
found to be in use.  By using a longer backoff period in this case, 
the transmitter is less likely to unfairly tie up the channel. 

LplBackoff is the backoff period used for a packet being delivered
with low power listening.  Because low power listening requires 
the channel to be modulated as continuously as possible while avoiding
interference with other transmitters, the low power listening 
backoff period is intentionally short.


5. Acknowledgements
====================================================================

5.1 Hardware vs. Software Acknowledgements
--------------------------------------------------------------------

Originally, the CC2420 radio stack only used hardware generated
auto-acknowledgements provided by the CC2420 chip itself.  This led
to some issues, such as false acknowledgements where the radio chip
would receive a packet and acknowledge its reception and the 
microcontroller would never actually receive the packet.

The current CC2420 stack uses software acknowledgements, which 
have a higher drop percentage. When used with the UniqueSend
and UniqueReceive interfaces, dropped acknowledgements are more desirable 
than false acknowledgements.  Received packets are always acknowledged 
before being filtered as a duplicate.

Use the PacketAcknowledgements or PacketLink interfaces
to determine if a packet was successfully acknowledged.


5.2 Data Sequence Numbers - UniqueSend and UniqueReceive
--------------------------------------------------------------------
The 802.15.4 specification identifies a Data Sequence Number (DSN)
byte in the message header to filter out duplicate packets [3]_.  

The UniqueSend interface at the top of the CC2420 radio stack is 
responsible for setting the DSN byte.  Upon boot, an initial DSN
byte is generated using a pseudo-random number generator with a 
maximum of 8-bits (256) values.  This number is incremented on
each outgoing packet transmission.  Even if lower levels such as 
PacketLink or LowPowerListening retransmit the packet, the DSN byte 
stays the same for that packet.

The UniqueReceive interface at the bottom of the CC2420 radio stack
is responsible for filtering out duplicate messages based on 
source address and DSN.  The UniqueReceive interface is not meant
to stop sophisticated replay attacks.  '

As packets are received, DSN and source address information is placed 
into elements of an array. Each subsequent message from previously 
logged addresses overwrite information in the element allocated to 
that source address. This prevents UniqueReceive's history from 
losing DSN byte information from sources that are not able to access 
the channel as often. If the number of elements in the history array
runs out, UniqueReceive uses a best effort method to avoid replacing 
recently updated DSN/Source information entries.


6. PacketLink Implementation
====================================================================
PacketLink is a layer added to the CC2420 radio stack to help unicast
packets get delivered successfully.  In previous version of TinyOS radio 
stacks, it was left up to the application layer to retry a message 
transmission if the application determined the message was not properly
received.  The PacketLink layer helps to remove the reliable delivery
responsibility and functional baggage from application layers.


6.1 Compiling in the PacketLink layer
--------------------------------------------------------------------
Because the PacketLink layer uses up extra memory footprint,
it is not compiled in by default.  Developers can simply define
the preprocessor variable PACKET_LINK to compile the functionality
of the PacketLink layer in with the CC2420 stack.


6.2 Implementation and Usage
--------------------------------------------------------------------
To send a message using PacketLink, the PacketLink
interface must be called ahead of time to specify two fields in the outbound
message's metadata:::
  
  command void setRetries(message_t *msg, uint16_t maxRetries);
  command void setRetryDelay(message_t *msg, uint16_t retryDelay);

The first command, setRetries(..), will specify the maximum number
of times the message should be sent before the radio stack stops
transmission.  The second command, setRetryDelay(..), specifies
the amount of delay in milliseconds between each retry.  The combination
of these two commands can set a packet to retry as many times as needed
for as long as necessary.

Because PacketLink relies on acknowledgements, false acknowledgements 
from the receiver will cause PacketLink to fail.  If using software
acknowledgements, false acknowledgements can still occur as a result
of the limited DSN space, other 802.15.4 radios in the area with
the same destination address, etc.



7. Asynchronous Low Power Listening Implementation
====================================================================
Because the Low Power Listening layer uses up extra memory footprint,
it is not compiled in by default.  Developers can simply define
the preprocessor variable LOW_POWER_LISTENING to compile the functionality
of the Low Power Listening layer in with the CC2420 stack.

7.1 Design Considerations
--------------------------------------------------------------------
The CC2420 radio stack low power listening implementation relies
on clear channel assessments to determine if there is a transmitter
nearby.  This allows the receiver to turn on and determine there are no
transmitters in a shorter amount of time than leaving the radio on
long enough to pick up a full packet. 

The transmitters perform a message delivery by transmitting
the full packet over and over again for twice the duration of the receiver's 
duty cycle period.  Transmitting for twice as long increases the 
probability that the message will be detected by the receiver, and 
allows the receiver to shave off a small amount of time it needs to 
keep its radio on.

Typically, the transmission of a single packet takes on the following 
form over time:

 +----------------------+-----------+--------------------+
 |     LPL Backoff      | Packet Tx |      Ack Wait      |
 +----------------------+-----------+--------------------+

To decrease the amount of time required for a receive check, the channel 
must be modulated by the transmitter as continuously as possible. 
The only period where the channel is modulated is during the 
Packet Transmission phase.  The receiver must continuosly sample the CCA pin 
a moment longer than the LPL Backoff period and Ack Wait period combined
to overlap the Packet Transmission period.  By making the LPL backoff
period as short as possible, we can decrease the amount of time a receiver's
radio must be turned on when performing a receive check.

If two transmitters attempt to transmit using low power listening,
one transmitter may hog the channel if its LPL backoff period
is set too short.  Both nodes transmitting at the same time
will cause interference and prevent each other from 
successfully delivering their messages to the intended recipient.  

To allow multiple transmitters to transmit low power listening packets 
at the same time, the LPL backoff period needed to be increased 
greater than the desired minimum.  This increases the amount of time
receiver radios need to be on to perform a receive check because
the channel is no longer being modulated as continuously as possible.
In other words, the channel is allowed to be shared amongst multiple 
transmitters at the expense of power consumption.


7.2 Minimizing Power Consumption
--------------------------------------------------------------------
There are several methods the CC2420 radio stack uses to minimize
power consumption:

1. Invalid Packet Shutdown

  Typically, packets are filtered out by address at the radio hardware
  level.  When a receiver wakes up and does not receive any
  packets into the low power listening layer of the radio stack, it 
  will automatically go back to sleep after some period of time.  As a 
  secondary backup, if address decoding on the radio chip is disabled, 
  the low power listening implementation will shut down the radio if 
  three packets are receive that do not belong to the node.  This helps 
  prevent against denial of sleep attacks or the typical transmission 
  behavior found in an ad-hoc network with many nodes.

2. Early Transmission Completion

  A transmitter typically sends a packet for twice the amount of time
  as the receiver's receive check period.  This increases the probability
  that the receiver will detect the packet.  However, if the transmitter receives
  an acknowledgement before the end of its transmission period, it
  will stop transmitting to save energy.  This is an improvement
  over previous low power listening implementations, which transmitted
  for the full period of time regardless of whether the receiver has 
  already woken up and received the packet.

3. Auto Shutdown

  If the radio does not send or receive messages for some period of