details of the CC2420 stack will be discussed. Readers will be better
informed about existing features, possible improvements, and limitations
of the CC2420 radio stack. Furthermore, lessons learned from
-the construction of the CC2420 radio stack can help guide development
+the construction of the stack can help guide development
of future TinyOS radio stacks.
1. Introduction
====================================================================
-The TI/Chipcon CC2420 radio is a complex device, requiring a rather
-complex software radio stack implementation. Although much of the
-functionality is available within the radio chip itself, there are
-still many factors to consider when implementing a flexible,
+The TI/Chipcon CC2420 radio is a complex device, taking care of
+many of the low-level details of transmitting and receiving packets
+through hardware. Specifying the proper behavior of that hardware
+requires a well defined radio stack implementation. Although much
+of the functionality is available within the radio chip itself, there
+are still many factors to consider when implementing a flexible,
general radio stack.
The software radio stack that drives the CC2420 radio consists of
// Send Layers
AM.SubSend -> UniqueSendC;
- UniqueSendC.SubSend -> TransportC;
- TransportC.SubSend -> LplC.Send;
- LplC.SubSend -> CC2420DispatchC.Send;
- CC2420DispatchC.SubSend -> CsmaC;
+ UniqueSendC.SubSend -> LinkC;
+ LinkC.SubSend -> LplC.Send;
+ LplC.SubSend -> TinyosNetworkC.Send;
+ TinyosNetworkC.SubSend -> CsmaC;
// Receive Layers
AM.SubReceive -> LplC;
- LplC.SubReceive -> UniqueReceiveC;
- UniqueReceiveC.SubReceive -> CC2420DispatchC.Receive;
- CC2420DispatchC.SubReceive -> CsmaC;
+ LplC.SubReceive -> UniqueReceiveC.Receive;
+ UniqueReceiveC.SubReceive -> TinyosNetworkC.Receive;
+ TinyosNetworkC.SubReceive -> CsmaC;
If another layer were to be added, CC2420ActiveMessageC would need
to be modified to wire it into the correct location.
2.1 Layer Descriptions
--------------------------------------------------------------------
-The main layers we see in this version of the stack are:
+The layers found within this radio stack are in the following order:
- ActiveMessageP: This is the highest layer in the stack, responsible
for filling in details in the packet header and providing information
chip itself uses 802.15.4 headers in hardware [1]_, it is not possible
for the layer to rearrange header bytes.
-- UniqueSend: This layer generates a unique data sequence
- number (DSN) byte for the packet header. This byte is generated once
- per outgoing packet. A receiver can detect duplicate packets by comparing
+- UniqueSend: This layer generates a unique Data Sequence
+ Number (DSN) byte for the packet header. This byte is incremented once
+ per outgoing packet, starting with a pseudo-randomly generated number.
+ A receiver can detect duplicate packets by comparing
the source and DSN byte of a received packet with previous packets.
DSN is defined in the 802.15.4 specification [3]_.
-- MessageTransportP: This layer provides the MessageTransport
- interface, and is responsible for retrying a packet transmission if no
- acknowledgement was heard from the receiver. MessageTransport is
+- PacketLink: This layer provides automatic retransmission functionality
+ and is responsible for retrying a packet transmission if no
+ acknowledgement was heard from the receiver. PacketLink is
activated on a per-message basis, meaning the outgoing packet will
- not use MessageTransport unless it is configured ahead of time to do so.
- MessageTransport is most reliable when software acknowledgements are enabled,
+ not use PacketLink unless it is configured ahead of time to do so.
+ PacketLink is most reliable when software acknowledgements are enabled
as opposed to hardware auto acknowledgements.
-- LowPowerListeningP [4]_: This layer provides the asynchronous low
- power listening functionality of the radio. It is broken up into
- two parts: CC2420LowPowerListeningP and CC2420DutyCycleP. The
- DutyCycleP component is responsible for turning the radio on
- and off and performing detections. After a detection occurs,
- DutyCycleP is hands off responsibility to LowPowerListeningP to turn
- the radio off and continue duty cycling when convenient. Low power listening
- transmissions are activated on a per-message basis, and the layer
- will retransmit the full outbound packet over and over until either a
- response from the receiver is heard or the transmit time expires.
+- CC2420AckLplP / CC2420NoAckLplP [4]_: These layers provide
+ asynchronous low power listening implementations. Supporting both of them
+ is CC2420DutyCycleP. The DutyCycleP component is responsible for
+ turning the radio on and off and performing receive checks.
+ After a detection occurs, DutyCycleP is hands off responsibility to
+ LowPowerListeningP to perform some transaction and turn the radio off
+ when convenient. Low power listening transmissions are activated on
+ a per-message basis, and the layer will continuously retransmit the full outbound
+ packet until either a response from the receiver is heard or the
+ transmit time expires.
+
+ The AckLplP implementation supports acknowledgement gaps during the
+ low power listening packetized preamble, which allows
+ transmitters to stop early but penalizes receive check lengths.
+ AckLplP low power listening is optimal for high transmission, long
+ receive check interval networks.
+
+ The NoAckLplP implementation does not support acknowledgements during
+ the packetized preamble. It continuously modulates the channel,
+ allowing the receiver to perform the smallest possible receive check.
+ NoAckLpl low power listening is effective for low transmission, short
+ receive check interval networks.
- UniqueReceive: This layer maintains a history of the source address
and DSN byte of the past few packets it has received, and helps
filter out duplicate received packets.
-- DispatchC: This layer allows the TinyOS 2.x radio stack to interoperate
- with other non-TinyOS networks. The 6LowPAN specifications include
- a network identifier byte after the standard 802.15.4 header [5]_.
- If interoperability frames are used, the dispatch layer provides
- functionality for setting the network byte on outgoing packets
- and filtering non-TinyOS incoming packets.
+- TinyosNetworkC: This layer allows the TinyOS 2.x radio stack to
+ interoperate with other non-TinyOS networks. Proposed 6LowPAN
+ specifications include a network identifier byte after the
+ standard 802.15.4 header [5]_. If interoperability frames are
+ used, the dispatch layer provides functionality for setting
+ the network byte on outgoing packets and filtering non-TinyOS
+ incoming packets.
- CsmaC: This layer is responsible for defining 802.15.4 FCF
byte information in the outbound packet, providing default
- TransmitP/ReceiveP: These layers are responsible for interacting
directly with the radio through the SPI bus, interrupts, and GPIO lines.
+ +--------------------------------------------------+
+ | Application Layer |
+ | |
+ +-----------------------+--------------------------+
+ |
+ |
+ +----------------------+-------------------------+
+ | Active Message Layer |
+ +----------------------+-------------------------+
+ |
+ +----------------------+-------------------------+
+ | Unique Send Layer |
+ +----------------------+-------------------------+
+ |
+ +----------------------+-------------------------+
+ | Optional Packet Link Layer |
+ +----------------------+-------------------------+
+ |
+ +----------------------+-------------------------+
+ | Optional Low Power Listening Implementations |
+ +----------------------+-------------------------+
+ |
+ +----------------------+-------------------------+
+ | Unique Receive Filtering Layer |
+ +----------------------+-------------------------+
+ |
+ +----------------------+-------------------------+
+ | Optional 6LowPAN TinyOS Network Layer |
+ +----------------------+-------------------------+
+ |
+ +----------------------+-------------------------+
+ | Carrier Sense Multiple Access (CSMA) |
+ +----------------------+-------------------------+
+ |
+ +------------+------------+
+ | |
+ +----------+----------+ +----------+----------+
+ | ReceiveP | | TransmitP |
+ +----------+----------+ +----------+----------+
+ | |
+ +------------+------------+
+ |
+ +-----------------------+-------------------------+
+ | SPI bus, GPIO, Interrupts, Timer Capture |
+ +-------------------------------------------------+
+
3. CC2420 Packet Format and Specifications
====================================================================
nxle_uint16_t destpan;
nxle_uint16_t dest;
nxle_uint16_t src;
- nxle_uint8_t network;
+ nxle_uint8_t network; // optionally included with 6LowPAN layer
nxle_uint8_t type;
} cc2420_header_t;
All fields up to 'network' are 802.15.4 specified fields, and are
used in the CC2420 hardware itself. The 'network' field is a 6LowPAN
-interoperability specification [5]_. The 'type' field is a
+interoperability specification [5]_ only to be included when the
+6LowPAN TinyosNetwork layer is included. The 'type' field is a
TinyOS specific field.
The TinyOS T-Frame packet does not include the 'network' field, nor
CRC byte is auto-appended to each outbound packet by the CC2420 radio
hardware itself.
-The CC2420 hardware has three RAM buffers: TXFIFO, RXFIFO, and a
-security RAM buffer. The TXFIFO and RXFIFO are both 128 bytes,
-while the security RAM buffer is 112 bytes. Therefore, the maximum size
-of a packet is 128 bytes including its headers and CRC. 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, which wastes energy. The TOSH_DATA_LENGTH
-preprocessor variable can be altered to increase the size
-of the message_t payload at compile time [2]_.
+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
the packet if the channel is currently clear.
To specify whether or not to transmit with clear channel assessment,
-the CC2420TransmitP component provides two commands::
-
- async command error_t Send.sendCCA( message_t* p_msg )
- async command error_t Send.send( message_t* p_msg )
-
-It is up to the CC2420CsmaP component to select the correct method of
-transmission. Sending a packet without CCA will transmit it as quickly
-as possible, but interference from other transmitters will prevent
-it from being delivered in many cases. Transmitting without CCA will
-also effectively jam other DSSS transmitters on the same channel.
-
-Future implementations should allow the application layer to specify
-the use of CCA on a per-packet basis, similar to how the application
-layer has the option to specify the backoff period for an outgoing
-message.
-
+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
--------------------------------------------------------------------
than false acknowledgements. Received packets are always acknowledged
before being filtered as a duplicate.
-Use the PacketAcknowledgements or MessageTransport interfaces
+Use the PacketAcknowledgements or PacketLink interfaces
to determine if a packet was successfully acknowledged.
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. It is set exactly one time
-per outgoing message. Even if lower levels such as MessageTransport
-or LowPowerListening retransmit the packet, the DSN byte stays the
-same.
+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.
+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. Message Transport Implementation
+6. PacketLink Implementation
====================================================================
-Message transport is a layer added to the CC2420 radio stack to help unicast
+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 Message Transport layer helps to remove the reliable delivery
+received. The PacketLink layer helps to remove the reliable delivery
responsibility and functional baggage from application layers.
-6.1 Compiling in the Message Transport layer
+6.1 Compiling in the PacketLink layer
--------------------------------------------------------------------
-Because the Message Transport layer uses up extra memory footprint,
+Because the PacketLink layer uses up extra memory footprint,
it is not compiled in by default. Developers can simply define
-the preprocessor variable MESSAGE_TRANSPORT to compile the functionality
-of the Message Transport layer in with the CC2420 stack.
+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 Message Transport, the MessageTransport
+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:::
of these two commands can set a packet to retry as many times as needed
for as long as necessary.
-Because Message Transport relies on acknowledgements, false
-acknowledgements from the receiver will cause Message Transport to fail.
+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
Typically, the transmission of a single packet takes on the following
form over time:
-+--------------+---------------------------------------+----------+
-| LPL Backoff | Packet Transmission | Ack Wait |
-+--------------+---------------------------------------+----------+
+ +----------------------+-----------+--------------------+
+ | 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.
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
- time while low power listening is enabled, the radio will automatically
- turn off and begin duty cycling at its specified duty cycle period.
-
- 4. *CCA Sampling Strategy:*
- The actual receive check is performed in a loop inside a function,
- not a spinning task. This allows the sampling to be performed
- continuously, with the goal of turning the radio off as quickly as
- possible without interruption.
+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
+ time while low power listening is enabled, the radio will automatically
+ turn off and begin duty cycling at its specified duty cycle period.
+
+4. CCA Sampling Strategy
+ The actual receive check is performed in a loop inside a function,
+ not a spinning task. This allows the sampling to be performed
+ continuously, with the goal of turning the radio off as quickly as
+ possible without interruption.
8. CC2420 Settings and Registers
Configuring the CC2420 requires the developer to access the CC2420Config
interface provided by CC2420ControlC. First call the CC2420Config commands to
-change the desired settings of the radio. Next, call CC2420Config.sync()
-to commit these changes to the radio chip. If the radio is currently
-off, the changes will be committed at the time it is turned on.
+change the desired settings of the radio. If the radio happens to
+be off, the changes will be committed at the time it is turned on.
+Alternatively, calling sync() will commit the changes to the CC2420.
RSSI can be sampled directly by calling the ReadRssi interface provided
by CC2420ControlC. See page 50 of the CC2420 datasheet for information
10.4 Neighbor Tables
--------------------------------------------------------------------
-Moteiv's Boomerange Sensornet Protocol (SP) implementation is a very
+Moteiv's Boomerange Sensornet Protocol (SP) implementation is a
good model to follow for radio stack architecture. One of the nice features
of SP is the design and implementation of the neighbor table. By
providing and sharing neighbor table information across the entire
Many of the layers in the CC2420 stack can be implemented independant
of the hardware underneath if the radio stack architecture was redesigned
and reimplemented. The low power listening receive check strategy may need a
-hardware-dependant implementation, but other layers like MessageTransport,
+hardware-dependant implementation, but other layers like PacketLink,
UniqueSend, UniqueReceive, ActiveMessage, Dispatch, etc. do not require
a CC2420 underneath to operate properly. The ultimate TinyOS radio
stack would be one that forms an abstraction between radio-dependant
10.6 Extendable Metadata
--------------------------------------------------------------------
Layers added into the radio stack may require extra bytes of metadata.
-The MessageTransport layer, for example, requires two extra fields
+The PacketLink layer, for example, requires two extra fields
in each message's metadata to hold the message's max retries and
delay between retries. The low power listening layer requires
an extra field to specify the destination's duty cycle period for
projects / tinyos-2.x.git / commitdiff