<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
+<meta name="generator" content="Docutils 0.3.6: http://docutils.sourceforge.net/" />
<title>CC2420 Radio Stack</title>
<meta name="author" content="David Moss, Jonathan Hui, Philip Levis, and Jung Il Choi" />
<style type="text/css">
</style>
</head>
<body>
-<div class="document" id="cc2420-radio-stack">
<h1 class="title">CC2420 Radio Stack</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<td>David Moss, Jonathan Hui, Philip Levis, and Jung Il Choi</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">5-Mar-2007</td>
</tr>
-<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.1</td>
+<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.3</td>
</tr>
-<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-03-23</td>
+<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-04-20</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List <tinyos-devel at mail.millennium.berkeley.edu></td>
</tr>
</tbody>
</table>
+<div class="document" id="cc2420-radio-stack">
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This memo documents a part of TinyOS for the TinyOS Community, and
of this memo is unlimited. This memo is in full compliance with
TEP 1.</p>
</div>
-<div class="section">
-<h1><a id="abstract" name="abstract">Abstract</a></h1>
+<div class="section" id="abstract">
+<h1><a name="abstract">Abstract</a></h1>
<p>This TEP documents the architecture of the CC2420 low power listening
-radio stack found in TinyOS 2.x. Radio stack layers and implementation
+radio stack found in TinyOS 2.x. Radio stack layers and implementation
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.</p>
</div>
-<div class="section">
-<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
-<p>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,
+<div class="section" id="introduction">
+<h1><a name="introduction">1. Introduction</a></h1>
+<p>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.</p>
<p>The software radio stack that drives the CC2420 radio consists of
many layers that sit between the application and hardware. The highest
levels of the radio stack modify data and headers in each packet, while
-the lowest levels determine the actual send and receive behavior.
-By understanding the functionality at each layer of the stack, as well
-as the architecture of a layer itself, it is possible to easily extend
+the lowest levels determine the actual send and receive behavior.
+By understanding the functionality at each layer of the stack, as well
+as the architecture of a layer itself, it is possible to easily extend
or condense the CC2420 radio stack to meet project requirements.</p>
<p>Some details about the CC2420 are out of the scope of this document.
-These details can be found in the CC2420 datasheet <a class="footnote-reference" href="#id11" id="id1" name="id1">[1]</a>.</p>
+These details can be found in the CC2420 datasheet <a class="footnote-reference" href="#id13" id="id1" name="id1">[1]</a>.</p>
</div>
-<div class="section">
-<h1><a id="cc2420-radio-stack-layers" name="cc2420-radio-stack-layers">2. CC2420 Radio Stack Layers</a></h1>
-<div class="section">
-<h2><a id="layer-architecture" name="layer-architecture">2.1 Layer Architecture</a></h2>
-<p>The CC2420 radio stack consists of layers of functionality stacked
+<div class="section" id="cc2420-radio-stack-layers">
+<h1><a name="cc2420-radio-stack-layers">2. CC2420 Radio Stack Layers</a></h1>
+<div class="section" id="layer-architecture">
+<h2><a name="layer-architecture">2.1 Layer Architecture</a></h2>
+<p>The CC2420 radio stack consists of layers of functionality stacked
on top of each other to provide a complete mechanism that
-modifies, filters, transmits, and controls inbound and outbound messages.
-Each layer is a distinct module that can provide and use three sets of
-interfaces in relation to the actual radio stack: Send, Receive, and
-SplitControl. If a general layer provides one of those interfaces, it
-also uses that interface from the layer below it in the stack. This
+modifies, filters, transmits, and controls inbound and outbound messages.
+Each layer is a distinct module that can provide and use three sets of
+interfaces in relation to the actual radio stack: Send, Receive, and
+SplitControl. If a general layer provides one of those interfaces, it
+also uses that interface from the layer below it in the stack. This
allows any given layer to be inserted anywhere in the stack through
independant wiring. For example::</p>
<pre class="literal-block">
uses interface SplitControl as subControl;
</pre>
<p>The actual wiring of the CC2420 radio stack is done at the highest level
-of the stack, inside CC2420ActiveMessageC. This configuration defines
+of the stack, inside CC2420ActiveMessageC. This configuration defines
three branches: Send, Receive, and SplitControl. Note that not all
layers need to provide and use all three Send, Receive, and SplitControl
interfaces::</p>
// 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;
</pre>
<p>If another layer were to be added, CC2420ActiveMessageC would need
to be modified to wire it into the correct location.</p>
</div>
-<div class="section">
-<h2><a id="layer-descriptions" name="layer-descriptions">2.1 Layer Descriptions</a></h2>
-<p>The main layers we see in this version of the stack are:</p>
-<ul class="simple">
-<li>ActiveMessageP: This is the highest layer in the stack, responsible
+<div class="section" id="layer-descriptions">
+<h2><a name="layer-descriptions">2.1 Layer Descriptions</a></h2>
+<p>The layers found within this radio stack are in the following order:</p>
+<ul>
+<li><p class="first">ActiveMessageP: This is the highest layer in the stack, responsible
for filling in details in the packet header and providing information
-about the packet to the application level <a class="footnote-reference" href="#id12" id="id2" name="id2">[2]</a>. Because the CC2420 radio
-chip itself uses 802.15.4 headers in hardware <a class="footnote-reference" href="#id11" id="id3" name="id3">[1]</a>, it is not possible
-for the layer to rearrange header bytes.</li>
-<li>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
-the source and DSN byte of a received packet with previous packets.
-DSN is defined in the 802.15.4 specification <a class="footnote-reference" href="#id13" id="id4" name="id4">[3]</a>.</li>
-<li>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
+about the packet to the application level <a class="footnote-reference" href="#id14" id="id2" name="id2">[2]</a>. Because the CC2420 radio
+chip itself uses 802.15.4 headers in hardware <a class="footnote-reference" href="#id13" id="id3" name="id3">[1]</a>, it is not possible
+for the layer to rearrange header bytes.</p>
+</li>
+<li><p class="first">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 <a class="footnote-reference" href="#id15" id="id4" name="id4">[3]</a>.</p>
+</li>
+<li><p class="first">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,
-as opposed to hardware auto acknowledgements.</li>
-<li>LowPowerListeningP <a class="footnote-reference" href="#id14" id="id5" name="id5">[4]</a>: 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.</li>
-<li>UniqueReceive: This layer maintains a history of the source address
+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.</p>
+</li>
+<li><p class="first">CC2420AckLplP / CC2420NoAckLplP <a class="footnote-reference" href="#id16" id="id5" name="id5">[4]</a>: 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.</p>
+<p>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.</p>
+<p>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.</p>
+</li>
+<li><p class="first">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.</li>
-<li>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 <a class="footnote-reference" href="#id15" id="id6" name="id6">[5]</a>.
-If interoperability frames are used, the dispatch layer provides
-functionality for setting the network byte on outgoing packets
-and filtering non-TinyOS incoming packets.</li>
-<li>CsmaC: This layer is responsible for defining 802.15.4 FCF
+filter out duplicate received packets.</p>
+</li>
+<li><p class="first">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 <a class="footnote-reference" href="#id17" id="id6" name="id6">[5]</a>. If interoperability frames are
+used, the dispatch layer provides functionality for setting
+the network byte on outgoing packets and filtering non-TinyOS
+incoming packets.</p>
+</li>
+<li><p class="first">CsmaC: This layer is responsible for defining 802.15.4 FCF
byte information in the outbound packet, providing default
backoff times when the radio detects a channel in use, and
-defining the power-up/power-down procedure for the radio.</li>
-<li>TransmitP/ReceiveP: These layers are responsible for interacting
-directly with the radio through the SPI bus, interrupts, and GPIO lines.</li>
+defining the power-up/power-down procedure for the radio.</p>
+</li>
+<li><p class="first">TransmitP/ReceiveP: These layers are responsible for interacting
+directly with the radio through the SPI bus, interrupts, and GPIO lines.</p>
+</li>
</ul>
+<blockquote>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Application Layer</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 184)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 184)</p>
+Blank line required after table.</div>
+<blockquote>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
+<div class="line"><br /></div>
+</div>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 186)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Active Message Layer</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 189)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 189)</p>
+Blank line required after table.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
+</div>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 190)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Unique Send Layer</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 193)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 193)</p>
+Blank line required after table.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
</div>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 194)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Optional Packet Link Layer</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 197)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 197)</p>
+Blank line required after table.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
+</div>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 198)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Optional Low Power Listening Implementations</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 201)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 201)</p>
+Blank line required after table.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
+</div>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 202)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Unique Receive Filtering Layer</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 205)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 205)</p>
+Blank line required after table.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
</div>
-<div class="section">
-<h1><a id="cc2420-packet-format-and-specifications" name="cc2420-packet-format-and-specifications">3. CC2420 Packet Format and Specifications</a></h1>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 206)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Optional 6LowPAN TinyOS Network Layer</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 209)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 209)</p>
+Blank line required after table.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
+</div>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 210)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="47%" />
+<col width="53%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">Carrier Sense Multiple Access (CSMA)</td>
+</tr>
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 213)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 213)</p>
+Blank line required after table.</div>
+<blockquote>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
+</div>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 214)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 214)</p>
+<p>Malformed table.</p>
+<pre class="literal-block">
++------------+------------+
+| |
+</pre>
+</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 216)</p>
+Blank line required after table.</div>
+</blockquote>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 216)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<p>+----------+----------+ +----------+----------+
+| ReceiveP | | TransmitP |
++----------+----------+ +----------+----------+</p>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 219)</p>
+Unexpected indentation.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><a href="#id7" name="id8"><span class="problematic" id="id8">|</span></a></div>
+</div>
+<div class="system-message" id="id7">
+<p class="system-message-title">System Message: <a name="id7">WARNING/2</a> (<tt class="docutils">txt/tep126.txt</tt>, line 219); <em><a href="#id8">backlink</a></em></p>
+Inline substitution_reference start-string without end-string.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 220)</p>
+Line block ends without a blank line.</div>
+<table border="1" class="docutils">
+<colgroup>
+</colgroup>
+<tbody valign="top">
+</tbody>
+</table>
+<div class="system-message">
+<p class="system-message-title">System Message: ERROR/3 (<tt class="docutils">txt/tep126.txt</tt>, line 221)</p>
+Unexpected indentation.</div>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 221)</p>
+Blank line required after table.</div>
+<blockquote>
+<div class="line-block">
+<div class="line"><br /></div>
+</div>
+</blockquote>
+</blockquote>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 222)</p>
+Block quote ends without a blank line; unexpected unindent.</div>
+<table border="1" class="docutils">
+<colgroup>
+<col width="48%" />
+<col width="52%" />
+</colgroup>
+<tbody valign="top">
+<tr><td colspan="2">SPI bus, GPIO, Interrupts, Timer Capture</td>
+</tr>
+</tbody>
+</table>
+</blockquote>
+</div>
+</div>
+<div class="section" id="cc2420-packet-format-and-specifications">
+<h1><a name="cc2420-packet-format-and-specifications">3. CC2420 Packet Format and Specifications</a></h1>
<p>The CC2420 Packet structure is defined in CC2420.h. The default
I-Frame CC2420 header takes on the following format::</p>
<pre class="literal-block">
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;
</pre>
-<p>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 <a class="footnote-reference" href="#id15" id="id7" name="id7">[5]</a>. The 'type' field is a
+<p>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 <a class="footnote-reference" href="#id17" id="id9" name="id9">[5]</a> only to be included when the
+6LowPAN TinyosNetwork layer is included. The 'type' field is a
TinyOS specific field.</p>
<p>The TinyOS T-Frame packet does not include the 'network' field, nor
the functionality found in the Dispatch layer to set and check
<p>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.</p>
-<p>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 <a class="footnote-reference" href="#id12" id="id8" name="id8">[2]</a>.</p>
-</div>
-<div class="section">
-<h1><a id="csma-ca" name="csma-ca">4. CSMA/CA</a></h1>
-<div class="section">
-<h2><a id="clear-channel-assessment" name="clear-channel-assessment">4.1 Clear Channel Assessment</a></h2>
-<p>By default, the CC2420 radio stack performs a clear channel assessment
+<p>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 <a class="footnote-reference" href="#id14" id="id10" name="id10">[2]</a>.</p>
+</div>
+<div class="section" id="csma-ca">
+<h1><a name="csma-ca">4. CSMA/CA</a></h1>
+<div class="section" id="clear-channel-assessment">
+<h2><a name="clear-channel-assessment">4.1 Clear Channel Assessment</a></h2>
+<p>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
+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.</p>
<p>To specify whether or not to transmit with clear channel assessment,
-the CC2420TransmitP component provides two commands:</p>
-<pre class="literal-block">
-async command error_t Send.sendCCA( message_t* p_msg )
-async command error_t Send.send( message_t* p_msg )
-</pre>
-<p>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.</p>
-<p>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.</p>
-</div>
-<div class="section">
-<h2><a id="radio-backoff" name="radio-backoff">4.2 Radio Backoff</a></h2>
+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.</p>
+<p>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).</p>
+</div>
+<div class="section" id="radio-backoff">
+<h2><a name="radio-backoff">4.2 Radio Backoff</a></h2>
<p>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
+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
+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
+to prevent two transmitters from sampling the channel at the same
moment.</p>
<p>InitialBackoff is the shortest backoff period, requested on the first
attempt to transmit a packet.</p>
<p>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,
+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.</p>
<p>LplBackoff is the backoff period used for a packet being delivered
-with low power listening. Because low power listening requires
+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
+interference with other transmitters, the low power listening
backoff period is intentionally short.</p>
</div>
</div>
-<div class="section">
-<h1><a id="acknowledgements" name="acknowledgements">5. Acknowledgements</a></h1>
-<div class="section">
-<h2><a id="hardware-vs-software-acknowledgements" name="hardware-vs-software-acknowledgements">5.1 Hardware vs. Software Acknowledgements</a></h2>
+<div class="section" id="acknowledgements">
+<h1><a name="acknowledgements">5. Acknowledgements</a></h1>
+<div class="section" id="hardware-vs-software-acknowledgements">
+<h2><a name="hardware-vs-software-acknowledgements">5.1 Hardware vs. Software Acknowledgements</a></h2>
<p>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
+would receive a packet and acknowledge its reception and the
microcontroller would never actually receive the packet.</p>
-<p>The current CC2420 stack uses software acknowledgements, which
+<p>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
+and UniqueReceive interfaces, dropped acknowledgements are more desirable
+than false acknowledgements. Received packets are always acknowledged
before being filtered as a duplicate.</p>
-<p>Use the PacketAcknowledgements or MessageTransport interfaces
+<p>Use the PacketAcknowledgements or PacketLink interfaces
to determine if a packet was successfully acknowledged.</p>
</div>
-<div class="section">
-<h2><a id="data-sequence-numbers-uniquesend-and-uniquereceive" name="data-sequence-numbers-uniquesend-and-uniquereceive">5.2 Data Sequence Numbers - UniqueSend and UniqueReceive</a></h2>
+<div class="section" id="data-sequence-numbers-uniquesend-and-uniquereceive">
+<h2><a name="data-sequence-numbers-uniquesend-and-uniquereceive">5.2 Data Sequence Numbers - UniqueSend and UniqueReceive</a></h2>
<p>The 802.15.4 specification identifies a Data Sequence Number (DSN)
-byte in the message header to filter out duplicate packets <a class="footnote-reference" href="#id13" id="id9" name="id9">[3]</a>.</p>
-<p>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.</p>
+byte in the message header to filter out duplicate packets <a class="footnote-reference" href="#id15" id="id11" name="id11">[3]</a>.</p>
+<p>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.</p>
<p>The UniqueReceive interface at the bottom of the CC2420 radio stack
-is responsible for filtering out duplicate messages based on
+is responsible for filtering out duplicate messages based on
source address and DSN. The UniqueReceive interface is not meant
-to stop sophisticated replay attacks.</p>
+to stop sophisticated replay attacks. '</p>
+<p>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.</p>
</div>
</div>
-<div class="section">
-<h1><a id="message-transport-implementation" name="message-transport-implementation">6. Message Transport Implementation</a></h1>
-<p>Message transport 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
+<div class="section" id="packetlink-implementation">
+<h1><a name="packetlink-implementation">6. PacketLink Implementation</a></h1>
+<p>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.</p>
-<div class="section">
-<h2><a id="compiling-in-the-message-transport-layer" name="compiling-in-the-message-transport-layer">6.1 Compiling in the Message Transport layer</a></h2>
-<p>Because the Message Transport layer uses up extra memory footprint,
+<div class="section" id="compiling-in-the-packetlink-layer">
+<h2><a name="compiling-in-the-packetlink-layer">6.1 Compiling in the PacketLink layer</a></h2>
+<p>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.</p>
+the preprocessor variable PACKET_LINK to compile the functionality
+of the PacketLink layer in with the CC2420 stack.</p>
</div>
-<div class="section">
-<h2><a id="implementation-and-usage" name="implementation-and-usage">6.2 Implementation and Usage</a></h2>
-<p>To send a message using Message Transport, the MessageTransport
+<div class="section" id="implementation-and-usage">
+<h2><a name="implementation-and-usage">6.2 Implementation and Usage</a></h2>
+<p>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::</p>
<pre class="literal-block">
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.</p>
-<p>Because Message Transport relies on acknowledgements, false
-acknowledgements from the receiver will cause Message Transport to fail.</p>
+<p>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.</p>
</div>
</div>
-<div class="section">
-<h1><a id="asynchronous-low-power-listening-implementation" name="asynchronous-low-power-listening-implementation">7. Asynchronous Low Power Listening Implementation</a></h1>
+<div class="section" id="asynchronous-low-power-listening-implementation">
+<h1><a name="asynchronous-low-power-listening-implementation">7. Asynchronous Low Power Listening Implementation</a></h1>
<p>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.</p>
-<div class="section">
-<h2><a id="design-considerations" name="design-considerations">7.1 Design Considerations</a></h2>
+<div class="section" id="design-considerations">
+<h2><a name="design-considerations">7.1 Design Considerations</a></h2>
<p>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.</p>
<p>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
+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.</p>
-<p>Typically, the transmission of a single packet takes on the following
+<p>Typically, the transmission of a single packet takes on the following
form over time:</p>
+<blockquote>
<table border="1" class="docutils">
<colgroup>
-<col width="22%" />
-<col width="62%" />
-<col width="16%" />
+<col width="42%" />
+<col width="21%" />
+<col width="38%" />
</colgroup>
<tbody valign="top">
<tr><td>LPL Backoff</td>
-<td>Packet Transmission</td>
+<td>Packet Tx</td>
<td>Ack Wait</td>
</tr>
</tbody>
</table>
-<p>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
+</blockquote>
+<p>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
<p>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
+will cause interference and prevent each other from
successfully delivering their messages to the intended recipient.</p>
-<p>To allow multiple transmitters to transmit low power listening packets
-at the same time, the LPL backoff period needed to be increased
+<p>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
+In other words, the channel is allowed to be shared amongst multiple
transmitters at the expense of power consumption.</p>
</div>
-<div class="section">
-<h2><a id="minimizing-power-consumption" name="minimizing-power-consumption">7.2 Minimizing Power Consumption</a></h2>
+<div class="section" id="minimizing-power-consumption">
+<h2><a name="minimizing-power-consumption">7.2 Minimizing Power Consumption</a></h2>
<p>There are several methods the CC2420 radio stack uses to minimize
power consumption:</p>
+<ol class="arabic simple">
+<li>Invalid Packet Shutdown</li>
+</ol>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 471)</p>
+Enumerated list ends without a blank line; unexpected unindent.</div>
<blockquote>
-<p>1. <em>Invalid Packet Shutdown:</em>
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.</p>
-<p>2. <em>Early Transmission Completion:</em>
+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.</blockquote>
+<ol class="arabic simple" start="2">
+<li>Early Transmission Completion</li>
+</ol>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 482)</p>
+Enumerated list ends without a blank line; unexpected unindent.</div>
+<blockquote>
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.</p>
-<p>3. <em>Auto Shutdown:</em>
+for the full period of time regardless of whether the receiver has
+already woken up and received the packet.</blockquote>
+<ol class="arabic simple" start="3">
+<li>Auto Shutdown</li>
+</ol>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 492)</p>
+Enumerated list ends without a blank line; unexpected unindent.</div>
+<blockquote>
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.</p>
-<p>4. <em>CCA Sampling Strategy:</em>
-The actual receive check is performed in a loop inside a function,
+time while low power listening is enabled, the radio will automatically
+turn off and begin duty cycling at its specified duty cycle period.</blockquote>
+<ol class="arabic simple" start="4">
+<li>CCA Sampling Strategy</li>
+</ol>
+<div class="system-message">
+<p class="system-message-title">System Message: WARNING/2 (<tt class="docutils">txt/tep126.txt</tt>, line 497)</p>
+Enumerated list ends without a blank line; unexpected unindent.</div>
+<blockquote>
+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.</p>
-</blockquote>
+continuously, with the goal of turning the radio off as quickly as
+possible without interruption.</blockquote>
</div>
</div>
-<div class="section">
-<h1><a id="cc2420-settings-and-registers" name="cc2420-settings-and-registers">8. CC2420 Settings and Registers</a></h1>
+<div class="section" id="cc2420-settings-and-registers">
+<h1><a name="cc2420-settings-and-registers">8. CC2420 Settings and Registers</a></h1>
<p>To interact with registers on the CC2420 chip, the SPI bus must be
-acquired, the chip selecct (CSn) pin must be cleared, and then the
+acquired, the chip selecct (CSn) pin must be cleared, and then the
interaction may occur. After the interaction completes, the
CSn pin must be set high.</p>
-<p>All registers and strobes are defined in the CC2420.h file, and most
+<p>All registers and strobes are defined in the CC2420.h file, and most
are accessible through the CC2420SpiC component. If your application
requires access to a specific register or strobe, the CC2420SpiC component
is the place to add access to it.</p>
<p>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.</p>
+interface provided by CC2420ControlC. First call the CC2420Config commands to
+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.</p>
<p>RSSI can be sampled directly by calling the ReadRssi interface provided
by CC2420ControlC. See page 50 of the CC2420 datasheet for information
-on how to convert RSSI to LQI and why it may not be such a good idea <a class="footnote-reference" href="#id11" id="id10" name="id10">[1]</a>.</p>
+on how to convert RSSI to LQI and why it may not be such a good idea <a class="footnote-reference" href="#id13" id="id12" name="id12">[1]</a>.</p>
</div>
-<div class="section">
-<h1><a id="cross-platform-portability" name="cross-platform-portability">9. Cross-platform Portability</a></h1>
+<div class="section" id="cross-platform-portability">
+<h1><a name="cross-platform-portability">9. Cross-platform Portability</a></h1>
<p>To port the CC2420 radio to another platform, the following interfaces
need to be implemented::</p>
<pre class="literal-block">
interface GeneralIO as RSTN;
interface GeneralIO as SFD;
interface GeneralIO as VREN;
-
+
// SPI Bus
interface Resource;
interface SpiByte;
<p>The GpioCapture interface is tied through the Timer to provide a relative time
at which the interrupt occurred. This is useful for timestamping received
packets for node synchronization.</p>
-<p>If the CC2420 is not connected to the proper interrupt lines,
+<p>If the CC2420 is not connected to the proper interrupt lines,
interrupts can be emulated through the use of a spinning task
that polls the GPIO pin. The MICAz implementation, for example, does this
for the CCA interrupt.</p>
</div>
-<div class="section">
-<h1><a id="future-improvement-recommendations" name="future-improvement-recommendations">10. Future Improvement Recommendations</a></h1>
+<div class="section" id="future-improvement-recommendations">
+<h1><a name="future-improvement-recommendations">10. Future Improvement Recommendations</a></h1>
<p>Many improvements can be made to the CC2420 stack. Below are some
recommendations:</p>
-<div class="section">
-<h2><a id="aes-encryption" name="aes-encryption">10.1 AES Encryption</a></h2>
+<div class="section" id="aes-encryption">
+<h2><a name="aes-encryption">10.1 AES Encryption</a></h2>
<p>The CC2420 chip itself provides AES-128 encryption. The implementation
involves loading the security RAM buffers on the CC2420 with the information
to be encrypted - this would be the payload of a packet, without
the header. After the payload is encrypted, the microcontroller reads
-out of the security RAM buffer and concatenates the data with the
+out of the security RAM buffer and concatenates the data with the
unencrypted packet header. This full packet would be uploaded again to the CC2420
TXFIFO buffer and transmitted.</p>
<p>Because the CC2420 cannot begin encryption at a particular offset
-and needs to be written, read, and re-written, use of the AES-128 may be
+and needs to be written, read, and re-written, use of the AES-128 may be
inefficient and will certainly decrease throughput.</p>
</div>
-<div class="section">
-<h2><a id="authentication" name="authentication">10.2 Authentication</a></h2>
-<p>In many cases, authentication is more desirable than encryption.
+<div class="section" id="authentication">
+<h2><a name="authentication">10.2 Authentication</a></h2>
+<p>In many cases, authentication is more desirable than encryption.
Encryption significantly increases energy and decreases packet throughput,
-which does not meet some application requirements. A layer could be
+which does not meet some application requirements. A layer could be
developed and added toward the bottom of the radio stack that validates
neighbors, preventing packets from invalid neighbors from reaching the
application layer. Several proprietary authentication layers have
-been developed for the CC2420 stack, but so far none are available to
+been developed for the CC2420 stack, but so far none are available to
the general public.</p>
-<p>A solid authentication layer would most likely involve the use of a
+<p>A solid authentication layer would most likely involve the use of a
neighbor table and 32-bit frame counts to prevent against replay attacks.
Once a neighbor is verified and established, the node needs to ensure that
future packets are still coming from the same trusted source. Again,
-some high speed low energy proprietary methods to accomplish this exist, but
+some high speed low energy proprietary methods to accomplish this exist, but
encryption is typically the standard method used.</p>
</div>
-<div class="section">
-<h2><a id="synchronous-low-power-listening" name="synchronous-low-power-listening">10.3 Synchronous Low Power Listening</a></h2>
-<p>A synchronous low power listening layer can be transparently built on
+<div class="section" id="synchronous-low-power-listening">
+<h2><a name="synchronous-low-power-listening">10.3 Synchronous Low Power Listening</a></h2>
+<p>A synchronous low power listening layer can be transparently built on
top of the asynchronous low power listening layer. One implementation
of this has already been done on a version of the CC1000 radio stack.
-Moteiv's Boomerang radio stack also has a synchronous low power listening
+Moteiv's Boomerang radio stack also has a synchronous low power listening
layer built as a standalone solution.</p>
<p>In the case of building a synchronous layer on top of the asynchronous
-low power listening layer, a transmitter's radio stack can detect when
-a particular receiver is performing its receive checks by verifying the
-packet was acknowledged after a sendDone event. The transmitter can then
+low power listening layer, a transmitter's radio stack can detect when
+a particular receiver is performing its receive checks by verifying the
+packet was acknowledged after a sendDone event. The transmitter can then
build a table to know when to begin transmission for that particular receiver.
-Each successful transmission would need to adjust the table with updated
+Each successful transmission would need to adjust the table with updated
information to avoid clock skew problems.</p>
<p>The asynchronous low power listening stack needs to be altered a bit
to make this strategy successful. Currently, duty cycling is started
and stopped as packets are detected, received, and transmitted. The
stack would need to be altered to keep a constant clock running in the
background that determines when to perform receive checks. The
-clock should not be affected by normal radio stack Rx/Tx behavior. This
+clock should not be affected by normal radio stack Rx/Tx behavior. This
would allow the receiver to maintain a predictable receive check cycle
for the transmitter to follow.</p>
<p>If the synchronous low power listening layer loses synchronization,
the radio stack can always fall back on the asynchronous low power listening
layer for successful message delivery.</p>
</div>
-<div class="section">
-<h2><a id="neighbor-tables" name="neighbor-tables">10.4 Neighbor Tables</a></h2>
-<p>Moteiv's Boomerange Sensornet Protocol (SP) implementation is a very
+<div class="section" id="neighbor-tables">
+<h2><a name="neighbor-tables">10.4 Neighbor Tables</a></h2>
+<p>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
CC2420 radio stack, RAM can be conserved throughout the radio stack
and TinyOS applications.</p>
</div>
-<div class="section">
-<h2><a id="radio-independant-layers" name="radio-independant-layers">10.5 Radio Independant Layers</a></h2>
+<div class="section" id="radio-independant-layers">
+<h2><a name="radio-independant-layers">10.5 Radio Independant Layers</a></h2>
<p>The best radio stack architecture is one that is completely radio independant.
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,
+and reimplemented. The low power listening receive check strategy may need a
+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
layers and radio-independant layers, and operates with the same
behavior across any radio chip.</p>
</div>
-<div class="section">
-<h2><a id="extendable-metadata" name="extendable-metadata">10.6 Extendable Metadata</a></h2>
+<div class="section" id="extendable-metadata">
+<h2><a name="extendable-metadata">10.6 Extendable Metadata</a></h2>
<p>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
compiled in and what size fields they required. A combination of
compiler support in the form of unique(..) and uniqueCount(..) functions
made it possible for the array to adjust its size.</p>
-<p>Explicit compiler support would be the most desirable solution to add
+<p>Explicit compiler support would be the most desirable solution to add
fields to a struct as they are needed.</p>
</div>
-<div class="section">
-<h2><a id="error-correcting-codes-ecc" name="error-correcting-codes-ecc">10.7 Error Correcting Codes (ECC)</a></h2>
+<div class="section" id="error-correcting-codes-ecc">
+<h2><a name="error-correcting-codes-ecc">10.7 Error Correcting Codes (ECC)</a></h2>
<p>When two nodes are communicating near the edge of their RF range,
it has been observed that interference may cause the packet to be
corrupted enough that the CRC byte and payload actually passes
packet. Although this is slim, in many cases it is unacceptable.
Some work arounds have implemented an extra byte of software generated
CRC to add to the reliability, and tests have proven its effectiveness.
-Taking this a step further, an ECC layer in the radio stack would help
-correct corrupted payloads and increase the distance at which nodes
+Taking this a step further, an ECC layer in the radio stack would help
+correct corrupted payloads and increase the distance at which nodes
can reliably communicate.</p>
</div>
</div>
-<div class="section">
-<h1><a id="author-s-address" name="author-s-address">11. Author's Address</a></h1>
+<div class="section" id="author-s-address">
+<h1><a name="author-s-address">11. Author's Address</a></h1>
<div class="line-block">
<div class="line">David Moss</div>
<div class="line">Rincon Research Corporation</div>
<div class="line">email -</div>
</div>
</div>
-<div class="section">
-<h1><a id="citations" name="citations">12. Citations</a></h1>
-<table class="docutils footnote" frame="void" id="id11" rules="none">
+<div class="section" id="citations">
+<h1><a name="citations">12. Citations</a></h1>
+<table class="docutils footnote" frame="void" id="id13" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a name="id1
1">[1]</a></td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id3">2</a>, <a class="fn-backref" href="#id10">3</a>)</em> TI/Chipcon CC2420 Datasheet. <a class="reference" href="http://www.chipcon.com/files/CC2420_Data_Sheet_1_3.pdf">http://www.chipcon.com/files/CC2420_Data_Sheet_1_3.pdf</a></td></tr>
+<tr><td class="label"><a name="id1
3">[1]</a></td><td><em>(<a class="fn-backref" href="#id1">1</a>, <a class="fn-backref" href="#id3">2</a>, <a class="fn-backref" href="#id12">3</a>)</em> TI/Chipcon CC2420 Datasheet. <a class="reference" href="http://www.chipcon.com/files/CC2420_Data_Sheet_1_3.pdf">http://www.chipcon.com/files/CC2420_Data_Sheet_1_3.pdf</a></td></tr>
</tbody>
</table>
-<table class="docutils footnote" frame="void" id="id12" rules="none">
+<table class="docutils footnote" frame="void" id="id14" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a name="id12">[2]</a></td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id8">2</a>)</em> TEP111: message_t</td></tr>
+<tr><td class="label"><a name="id14">[2]</a></td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id10">2</a>)</em> TEP111: message_t</td></tr>
</tbody>
</table>
-<table class="docutils footnote" frame="void" id="id13" rules="none">
+<table class="docutils footnote" frame="void" id="id15" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a name="id1
3">[3]</a></td><td><em>(<a class="fn-backref" href="#id4">1</a>, <a class="fn-backref" href="#id9">2</a>)</em> IEEE 802.15.4 Specification: <a class="reference" href="http://standards.ieee.org/getieee802/802.15.html">http://standards.ieee.org/getieee802/802.15.html</a></td></tr>
+<tr><td class="label"><a name="id1
5">[3]</a></td><td><em>(<a class="fn-backref" href="#id4">1</a>, <a class="fn-backref" href="#id11">2</a>)</em> IEEE 802.15.4 Specification: <a class="reference" href="http://standards.ieee.org/getieee802/802.15.html">http://standards.ieee.org/getieee802/802.15.html</a></td></tr>
</tbody>
</table>
-<table class="docutils footnote" frame="void" id="id14" rules="none">
+<table class="docutils footnote" frame="void" id="id16" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a class="fn-backref" href="#id5" name="id14">[4]</a></td><td>TEP105: Low Power Listening</td></tr>
+<tr><td class="label"><a class="fn-backref" href="#id5" name="id16">[4]</a></td><td>TEP105: Low Power Listening</td></tr>
</tbody>
</table>
-<table class="docutils footnote" frame="void" id="id15" rules="none">
+<table class="docutils footnote" frame="void" id="id17" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
-<tr><td class="label"><a name="id15">[5]</a></td><td><em>(<a class="fn-backref" href="#id6">1</a>, <a class="fn-backref" href="#id7">2</a>)</em> TEP125: TinyOS 802.15.4 Frames</td></tr>
+<tr><td class="label"><a name="id17">[5]</a></td><td><em>(<a class="fn-backref" href="#id6">1</a>, <a class="fn-backref" href="#id9">2</a>)</em> TEP125: TinyOS 802.15.4 Frames</td></tr>
</tbody>
</table>
</div>
projects / tinyos-2.x.git / blobdiff