doc/html/tep126.html

   1 <?xml version="1.0" encoding="utf-8" ?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   4 <head>
   5 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
   6 <meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
   7 <title>CC2420 Radio Stack</title>
   8 <meta name="author" content="David Moss, Jonathan Hui, Philip Levis, and Jung Il Choi" />
   9 <style type="text/css">
  10
  11 /*
  12 :Author: David Goodger
  13 :Contact: goodger@users.sourceforge.net
  14 :date: $Date$
  15 :version: $Revision$
  16 :copyright: This stylesheet has been placed in the public domain.
  17
  18 Default cascading style sheet for the HTML output of Docutils.
  19 */
  20 body {
  21   font-family: Times;
  22   font-size: 16px;
  23 }
  24
  25 .first {
  26   margin-top: 0 ! important }
  27
  28 .last {
  29   margin-bottom: 0 ! important }
  30
  31 .hidden {
  32   display: none }
  33
  34 a.toc-backref {
  35   text-decoration: none ;
  36   color: black }
  37
  38 blockquote.epigraph {
  39   margin: 2em 5em ; }
  40
  41 dd {
  42   margin-bottom: 0.5em }
  43
  44 div.abstract {
  45   margin: 2em 5em }
  46
  47 div.abstract p.topic-title {
  48   font-weight: bold ;
  49   text-align: center }
  50
  51 div.attention, div.caution, div.danger, div.error, div.hint,
  52 div.important, div.note, div.tip, div.warning, div.admonition {
  53   margin: 2em ;
  54   border: medium outset ;
  55   padding: 1em }
  56
  57 div.attention p.admonition-title, div.caution p.admonition-title,
  58 div.danger p.admonition-title, div.error p.admonition-title,
  59 div.warning p.admonition-title {
  60   color: red ;
  61   font-weight: bold ;
  62   font-family: sans-serif }
  63
  64 div.hint p.admonition-title, div.important p.admonition-title,
  65 div.note p.admonition-title, div.tip p.admonition-title,
  66 div.admonition p.admonition-title {
  67   font-weight: bold ;
  68   font-family: sans-serif }
  69
  70 div.dedication {
  71   margin: 2em 5em ;
  72   text-align: center ;
  73   font-style: italic }
  74
  75 div.dedication p.topic-title {
  76   font-weight: bold ;
  77   font-style: normal }
  78
  79 div.figure {
  80   margin-left: 2em }
  81
  82 div.footer, div.header {
  83   font-size: smaller }
  84
  85 div.line-block {
  86   display: block ;
  87   margin-top: 1em ;
  88   margin-bottom: 1em }
  89
  90 div.line-block div.line-block {
  91   margin-top: 0 ;
  92   margin-bottom: 0 ;
  93   margin-left: 1.5em }
  94
  95 div.sidebar {
  96   margin-left: 1em ;
  97   border: medium outset ;
  98   padding: 0em 1em ;
  99   background-color: #ffffee ;
 100   width: 40% ;
 101   float: right ;
 102   clear: right }
 103
 104 div.sidebar p.rubric {
 105   font-family: sans-serif ;
 106   font-size: medium }
 107
 108 div.system-messages {
 109   margin: 5em }
 110
 111 div.system-messages h1 {
 112   color: red }
 113
 114 div.system-message {
 115   border: medium outset ;
 116   padding: 1em }
 117
 118 div.system-message p.system-message-title {
 119   color: red ;
 120   font-weight: bold }
 121
 122 div.topic {
 123   margin: 2em }
 124
 125 h1 {
 126   font-family: Arial, sans-serif;
 127   font-size: 20px;
 128 }
 129
 130 h1.title {
 131  text-align: center;
 132  font-size: 32px;
 133 }
 134
 135 h2 {
 136  font-size: 16px;
 137  font-family: Arial, sans-serif;
 138 }
 139
 140 h2.subtitle {
 141   text-align: center }
 142
 143 h3 {
 144  font-size: 12px;
 145  font-family: Arial, sans-serif;
 146 }
 147
 148 hr {
 149   width: 75% }
 150
 151 ol.simple, ul.simple {
 152   margin-bottom: 1em }
 153
 154 ol.arabic {
 155   list-style: decimal }
 156
 157 ol.loweralpha {
 158   list-style: lower-alpha }
 159
 160 ol.upperalpha {
 161   list-style: upper-alpha }
 162
 163 ol.lowerroman {
 164   list-style: lower-roman }
 165
 166 ol.upperroman {
 167   list-style: upper-roman }
 168
 169 p.attribution {
 170   text-align: right ;
 171   margin-left: 50% }
 172
 173 p.caption {
 174   font-style: italic }
 175
 176 p.credits {
 177   font-style: italic ;
 178   font-size: smaller }
 179
 180 p.label {
 181   white-space: nowrap }
 182
 183 p.rubric {
 184   font-weight: bold ;
 185   font-size: larger ;
 186   color: maroon ;
 187   text-align: center }
 188
 189 p.sidebar-title {
 190   font-family: sans-serif ;
 191   font-weight: bold ;
 192   font-size: larger }
 193
 194 p.sidebar-subtitle {
 195   font-family: sans-serif ;
 196   font-weight: bold }
 197
 198 p.topic-title {
 199   font-weight: bold }
 200
 201 pre.address {
 202   margin-bottom: 0 ;
 203   margin-top: 0 ;
 204   font-family: serif ;
 205   font-size: 100% }
 206
 207 pre.line-block {
 208   font-family: serif ;
 209   font-size: 100% }
 210
 211 pre.literal-block, pre.doctest-block {
 212   margin-left: 2em ;
 213   margin-right: 2em ;
 214   background-color: #eeeeee;
 215   border-color: #000000;
 216   border-width: thin;
 217   font-size: 14px
 218 }
 219
 220 span.classifier {
 221   font-family: sans-serif ;
 222   font-style: oblique }
 223
 224 span.classifier-delimiter {
 225   font-family: sans-serif ;
 226   font-weight: bold }
 227
 228 span.interpreted {
 229   font-family: sans-serif }
 230
 231 span.option {
 232   white-space: nowrap }
 233
 234 span.option-argument {
 235   font-style: italic }
 236
 237 span.pre {
 238   white-space: pre }
 239
 240 span.problematic {
 241   color: red }
 242
 243 table {
 244   margin-top: 0.5em ;
 245   margin-bottom: 0.5em }
 246
 247 table.citation {
 248   border-left: solid thin gray ;
 249   padding-left: 0.5ex }
 250
 251 table.docinfo {
 252   margin: 2em 4em;
 253 }
 254
 255 table.footnote {
 256   border-left: solid thin black ;
 257   padding-left: 0.5ex }
 258
 259 td, th {
 260   padding-left: 0.5em ;
 261   padding-right: 0.5em ;
 262   vertical-align: top }
 263
 264 th.docinfo-name, th.field-name {
 265   font-weight: bold ;
 266   text-align: left ;
 267   white-space: nowrap;
 268   }
 269
 270 h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
 271   font-size: 100% }
 272
 273 tt {}
 274
 275 ul.auto-toc {
 276   list-style-type: none }
 277
 278 </style>
 279 </head>
 280 <body>
 281 <div class="document" id="cc2420-radio-stack">
 282 <h1 class="title">CC2420 Radio Stack</h1>
 283 <table class="docinfo" frame="void" rules="none">
 284 <col class="docinfo-name" />
 285 <col class="docinfo-content" />
 286 <tbody valign="top">
 287 <tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">126</td>
 288 </tr>
 289 <tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
 290 </tr>
 291 <tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
 292 </tr>
 293 <tr><th class="docinfo-name">Status:</th>
 294 <td>Draft</td></tr>
 295 <tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
 296 </tr>
 297 <tr><th class="docinfo-name">Author:</th>
 298 <td>David Moss, Jonathan Hui, Philip Levis, and Jung Il Choi</td></tr>
 299 <tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">5-Mar-2007</td>
 300 </tr>
 301 <tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.5</td>
 302 </tr>
 303 <tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-06-14</td>
 304 </tr>
 305 <tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Developer List &lt;tinyos-devel at mail.millennium.berkeley.edu&gt;</td>
 306 </tr>
 307 </tbody>
 308 </table>
 309 <div class="note">
 310 <p class="first admonition-title">Note</p>
 311 <p class="last">This memo documents a part of TinyOS for the TinyOS Community, and
 312 requests discussion and suggestions for improvements.  Distribution
 313 of this memo is unlimited. This memo is in full compliance with
 314 TEP 1.</p>
 315 </div>
 316 <div class="section">
 317 <h1><a id="abstract" name="abstract">Abstract</a></h1>
 318 <p>This TEP documents the architecture of the CC2420 low power listening
 319 radio stack found in TinyOS 2.x.  Radio stack layers and implementation
 320 details of the CC2420 stack will be discussed.  Readers will be better
 321 informed about existing features, possible improvements, and limitations
 322 of the CC2420 radio stack.  Furthermore, lessons learned from
 323 the construction of the stack can help guide development
 324 of future TinyOS radio stacks.</p>
 325 </div>
 326 <div class="section">
 327 <h1><a id="introduction" name="introduction">1. Introduction</a></h1>
 328 <p>The TI/Chipcon CC2420 radio is a complex device, taking care of
 329 many of the low-level details of transmitting and receiving packets
 330 through hardware.  Specifying the proper behavior of that hardware
 331 requires a well defined radio stack implementation.  Although much
 332 of the functionality is available within the radio chip itself, there
 333 are still many factors to consider when implementing a flexible,
 334 general radio stack.</p>
 335 <p>The software radio stack that drives the CC2420 radio consists of
 336 many layers that sit between the application and hardware.  The highest
 337 levels of the radio stack modify data and headers in each packet, while
 338 the lowest levels determine the actual send and receive behavior.
 339 By understanding the functionality at each layer of the stack, as well
 340 as the architecture of a layer itself, it is possible to easily extend
 341 or condense the CC2420 radio stack to meet project requirements.</p>
 342 <p>Some details about the CC2420 are out of the scope of this document.
 343 These details can be found in the CC2420 datasheet <a class="footnote-reference" href="#id11" id="id1" name="id1">[1]</a>.</p>
 344 </div>
 345 <div class="section">
 346 <h1><a id="cc2420-radio-stack-layers" name="cc2420-radio-stack-layers">2. CC2420 Radio Stack Layers</a></h1>
 347 <div class="section">
 348 <h2><a id="layer-architecture" name="layer-architecture">2.1 Layer Architecture</a></h2>
 349 <p>The CC2420 radio stack consists of layers of functionality stacked
 350 on top of each other to provide a complete mechanism that
 351 modifies, filters, transmits, and controls inbound and outbound messages.
 352 Each layer is a distinct module that can provide and use three sets of
 353 interfaces in relation to the actual radio stack:  Send, Receive, and
 354 SplitControl.  If a general layer provides one of those interfaces, it
 355 also uses that interface from the layer below it in the stack.  This
 356 allows any given layer to be inserted anywhere in the stack through
 357 independant wiring. For example::</p>
 358 <pre class="literal-block">
 359 provides interface Send;
 360 uses interface Send as SubSend;
 361
 362 provides interface Receive;
 363 uses interface Receive as SubReceive;
 364
 365 provides interface SplitControl;
 366 uses interface SplitControl as subControl;
 367 </pre>
 368 <p>The actual wiring of the CC2420 radio stack is done at the highest level
 369 of the stack, inside CC2420ActiveMessageC.  This configuration defines
 370 three branches:  Send, Receive, and SplitControl. Note that not all
 371 layers need to provide and use all three Send, Receive, and SplitControl
 372 interfaces::</p>
 373 <pre class="literal-block">
 374 // SplitControl Layers
 375 SplitControl = LplC;
 376 LplC.SubControl -&gt; CsmaC;
 377
 378 // Send Layers
 379 AM.SubSend -&gt; UniqueSendC;
 380 UniqueSendC.SubSend -&gt; LinkC;
 381 LinkC.SubSend -&gt; LplC.Send;
 382 LplC.SubSend -&gt; TinyosNetworkC.Send;
 383 TinyosNetworkC.SubSend -&gt; CsmaC;
 384
 385 // Receive Layers
 386 AM.SubReceive -&gt; LplC;
 387 LplC.SubReceive -&gt; UniqueReceiveC.Receive;
 388 UniqueReceiveC.SubReceive -&gt; TinyosNetworkC.Receive;
 389 TinyosNetworkC.SubReceive -&gt; CsmaC;
 390 </pre>
 391 <p>If another layer were to be added, CC2420ActiveMessageC would need
 392 to be modified to wire it into the correct location.</p>
 393 </div>
 394 <div class="section">
 395 <h2><a id="layer-descriptions" name="layer-descriptions">2.1 Layer Descriptions</a></h2>
 396 <p>The layers found within this radio stack are in the following order:</p>
 397 <ul>
 398 <li><p class="first">ActiveMessageP:  This is the highest layer in the stack, responsible
 399 for filling in details in the packet header and providing information
 400 about the packet to the application level <a class="footnote-reference" href="#id12" id="id2" name="id2">[2]</a>.  Because the CC2420 radio
 401 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
 402 for the layer to rearrange header bytes.</p>
 403 </li>
 404 <li><p class="first">UniqueSend:  This layer generates a unique Data Sequence
 405 Number (DSN) byte for the packet header.  This byte is incremented once
 406 per outgoing packet, starting with a pseudo-randomly generated number.
 407 A receiver can detect duplicate packets by comparing
 408 the source and DSN byte of a received packet with previous packets.
 409 DSN is defined in the 802.15.4 specification <a class="footnote-reference" href="#id13" id="id4" name="id4">[3]</a>.</p>
 410 </li>
 411 <li><p class="first">PacketLink: This layer provides automatic retransmission functionality
 412 and is responsible for retrying a packet transmission if no
 413 acknowledgement was heard from the receiver.  PacketLink is
 414 activated on a per-message basis, meaning the outgoing packet will
 415 not use PacketLink unless it is configured ahead of time to do so.
 416 PacketLink is most reliable when software acknowledgements are enabled
 417 as opposed to hardware auto acknowledgements.</p>
 418 </li>
 419 <li><p class="first">CC2420AckLplP / CC2420NoAckLplP <a class="footnote-reference" href="#id14" id="id5" name="id5">[4]</a>:  These layers provide
 420 asynchronous low power listening implementations.  Supporting both of them
 421 is CC2420DutyCycleP.  The DutyCycleP component is responsible for
 422 turning the radio on and off and performing receive checks.
 423 After a detection occurs, DutyCycleP is hands off responsibility to
 424 LowPowerListeningP to perform some transaction and turn the radio off
 425 when convenient.  Low power listening transmissions are activated on
 426 a per-message basis, and the layer will continuously retransmit the full outbound
 427 packet until either a response from the receiver is heard or the
 428 transmit time expires.</p>
 429 <p>The AckLplP implementation supports acknowledgement gaps during the
 430 low power listening packetized preamble, which allows
 431 transmitters to stop early but penalizes receive check lengths.
 432 AckLplP low power listening is optimal for high transmission, long
 433 receive check interval networks.</p>
 434 <p>The NoAckLplP implementation does not support acknowledgements during
 435 the packetized preamble.  It continuously modulates the channel,
 436 allowing the receiver to perform the smallest possible receive check.
 437 NoAckLpl low power listening is effective for low transmission, short
 438 receive check interval networks.</p>
 439 </li>
 440 <li><p class="first">UniqueReceive: This layer maintains a history of the source address
 441 and DSN byte of the past few packets it has received, and helps
 442 filter out duplicate received packets.</p>
 443 </li>
 444 <li><p class="first">TinyosNetworkC: This layer allows the TinyOS 2.x radio stack to
 445 interoperate with other non-TinyOS networks.  Proposed 6LowPAN
 446 specifications include a network identifier byte after the
 447 standard 802.15.4 header <a class="footnote-reference" href="#id15" id="id6" name="id6">[5]</a>. If interoperability frames are
 448 used, the dispatch layer provides functionality for setting
 449 the network byte on outgoing packets and filtering non-TinyOS
 450 incoming packets.</p>
 451 </li>
 452 <li><p class="first">CsmaC:  This layer is responsible for defining 802.15.4 FCF
 453 byte information in the outbound packet, providing default
 454 backoff times when the radio detects a channel in use, and
 455 defining the power-up/power-down procedure for the radio.</p>
 456 </li>
 457 <li><p class="first">TransmitP/ReceiveP: These layers are responsible for interacting
 458 directly with the radio through the SPI bus, interrupts, and GPIO lines.</p>
 459 </li>
 460 </ul>
 461 <blockquote>
 462 <table border="1" class="docutils">
 463 <colgroup>
 464 <col width="47%" />
 465 <col width="53%" />
 466 </colgroup>
 467 <tbody valign="top">
 468 <tr><td colspan="2">Application Layer</td>
 469 </tr>
 470 </tbody>
 471 </table>
 472 <blockquote>
 473 <table border="1" class="docutils">
 474 <colgroup>
 475 <col width="47%" />
 476 <col width="53%" />
 477 </colgroup>
 478 <tbody valign="top">
 479 <tr><td colspan="2">Active Message Layer</td>
 480 </tr>
 481 </tbody>
 482 </table>
 483 <table border="1" class="docutils">
 484 <colgroup>
 485 <col width="47%" />
 486 <col width="53%" />
 487 </colgroup>
 488 <tbody valign="top">
 489 <tr><td colspan="2">Unique Send Layer</td>
 490 </tr>
 491 </tbody>
 492 </table>
 493 <table border="1" class="docutils">
 494 <colgroup>
 495 <col width="47%" />
 496 <col width="53%" />
 497 </colgroup>
 498 <tbody valign="top">
 499 <tr><td colspan="2">Optional Packet Link Layer</td>
 500 </tr>
 501 </tbody>
 502 </table>
 503 <table border="1" class="docutils">
 504 <colgroup>
 505 <col width="47%" />
 506 <col width="53%" />
 507 </colgroup>
 508 <tbody valign="top">
 509 <tr><td colspan="2">Optional Low Power Listening Implementations</td>
 510 </tr>
 511 </tbody>
 512 </table>
 513 <table border="1" class="docutils">
 514 <colgroup>
 515 <col width="47%" />
 516 <col width="53%" />
 517 </colgroup>
 518 <tbody valign="top">
 519 <tr><td colspan="2">Unique Receive Filtering Layer</td>
 520 </tr>
 521 </tbody>
 522 </table>
 523 <table border="1" class="docutils">
 524 <colgroup>
 525 <col width="47%" />
 526 <col width="53%" />
 527 </colgroup>
 528 <tbody valign="top">
 529 <tr><td colspan="2">Optional 6LowPAN TinyOS Network Layer</td>
 530 </tr>
 531 </tbody>
 532 </table>
 533 <table border="1" class="docutils">
 534 <colgroup>
 535 <col width="47%" />
 536 <col width="53%" />
 537 </colgroup>
 538 <tbody valign="top">
 539 <tr><td colspan="2">Carrier Sense Multiple Access (CSMA)</td>
 540 </tr>
 541 </tbody>
 542 </table>
 543 </blockquote>
 544 <p>+----------+----------+   +----------+----------+
 545 |      ReceiveP       |   |      TransmitP      |
 546 +----------+----------+   +----------+----------+</p>
 547 <table border="1" class="docutils">
 548 <colgroup>
 549 <col width="48%" />
 550 <col width="52%" />
 551 </colgroup>
 552 <tbody valign="top">
 553 <tr><td colspan="2">SPI bus, GPIO, Interrupts, Timer Capture</td>
 554 </tr>
 555 </tbody>
 556 </table>
 557 </blockquote>
 558 </div>
 559 </div>
 560 <div class="section">
 561 <h1><a id="cc2420-packet-format-and-specifications" name="cc2420-packet-format-and-specifications">3. CC2420 Packet Format and Specifications</a></h1>
 562 <p>The CC2420 Packet structure is defined in CC2420.h.  The default
 563 I-Frame CC2420 header takes on the following format::</p>
 564 <pre class="literal-block">
 565 typedef nx_struct cc2420_header_t {
 566   nxle_uint8_t length;
 567   nxle_uint16_t fcf;
 568   nxle_uint8_t dsn;
 569   nxle_uint16_t destpan;
 570   nxle_uint16_t dest;
 571   nxle_uint16_t src;
 572   nxle_uint8_t network;  // optionally included with 6LowPAN layer
 573   nxle_uint8_t type;
 574 } cc2420_header_t;
 575 </pre>
 576 <p>All fields up to 'network' are 802.15.4 specified fields, and are
 577 used in the CC2420 hardware itself. The 'network' field is a 6LowPAN
 578 interoperability specification <a class="footnote-reference" href="#id15" id="id7" name="id7">[5]</a> only to be included when the
 579 6LowPAN TinyosNetwork layer is included.  The 'type' field is a
 580 TinyOS specific field.</p>
 581 <p>The TinyOS T-Frame packet does not include the 'network' field, nor
 582 the functionality found in the Dispatch layer to set and check
 583 the 'network' field.</p>
 584 <p>No software footer is defined for the CC2420 radio.  A 2-byte
 585 CRC byte is auto-appended to each outbound packet by the CC2420 radio
 586 hardware itself.</p>
 587 <p>The maximum size of a packet is 128 bytes including its headers and
 588 CRC, which matches the 802.15.4 specifications.  Increasing the
 589 packet size will increase data throughput and RAM consumption
 590 in the TinyOS application, but will also increase the probability
 591 that interference will cause the packet to be destroyed and need
 592 to be retransmitted. The TOSH_DATA_LENGTH preprocessor variable can
 593 be altered to increase the size of the message_t payload at
 594 compile time <a class="footnote-reference" href="#id12" id="id8" name="id8">[2]</a>.</p>
 595 </div>
 596 <div class="section">
 597 <h1><a id="csma-ca" name="csma-ca">4. CSMA/CA</a></h1>
 598 <div class="section">
 599 <h2><a id="clear-channel-assessment" name="clear-channel-assessment">4.1 Clear Channel Assessment</a></h2>
 600 <p>By default, the CC2420 radio stack performs a clear channel assessment
 601 (CCA) before transmitting.  If the channel is not clear, the radio backs
 602 off for some short, random period of time before attempting to transmit
 603 again.  The CC2420 chip itself provides a strobe command to transmit
 604 the packet if the channel is currently clear.</p>
 605 <p>To specify whether or not to transmit with clear channel assessment,
 606 the CC2420TransmitP requests CCA backoff input through the RadioBackoff
 607 interface on a per-message basis.  By default, each packet will be
 608 transmitted with CCA enabled.</p>
 609 <p>If layers above the CSMA layer wish to disable the clear channel
 610 assessments before transmission, they must intercept the
 611 RadioBackoff.requestCca(...) event for that message and call back
 612 using RadioBackoff.setCca(FALSE).</p>
 613 </div>
 614 <div class="section">
 615 <h2><a id="radio-backoff" name="radio-backoff">4.2 Radio Backoff</a></h2>
 616 <p>A backoff is a period of time where the radio pauses before attempting
 617 to transmit. When the radio needs to backoff, it can choose one of three
 618 backoff periods:  initialBackoff, congestionBackoff, and lplBackoff.
 619 These are implemented through the RadioBackoff interface, which signals
 620 out a request to specify the backoff period.  Unlike the CsmaBackoff
 621 interface, components that are interested in adjusting the backoff can
 622 call back using commands in the RadioBackoff interface.  This allows
 623 multiple components to adjust the backoff period for packets they are
 624 specifically listening to adjust.  The lower the backoff period, the
 625 faster the transmission, but the more likely the transmitter is to hog
 626 the channel.  Also, backoff periods should be as random as possible
 627 to prevent two transmitters from sampling the channel at the same
 628 moment.</p>
 629 <p>InitialBackoff is the shortest backoff period, requested on the first
 630 attempt to transmit a packet.</p>
 631 <p>CongestionBackoff is a longer backoff period used when the channel is
 632 found to be in use.  By using a longer backoff period in this case,
 633 the transmitter is less likely to unfairly tie up the channel.</p>
 634 <p>LplBackoff is the backoff period used for a packet being delivered
 635 with low power listening.  Because low power listening requires
 636 the channel to be modulated as continuously as possible while avoiding
 637 interference with other transmitters, the low power listening
 638 backoff period is intentionally short.</p>
 639 </div>
 640 </div>
 641 <div class="section">
 642 <h1><a id="acknowledgements" name="acknowledgements">5. Acknowledgements</a></h1>
 643 <div class="section">
 644 <h2><a id="hardware-vs-software-acknowledgements" name="hardware-vs-software-acknowledgements">5.1 Hardware vs. Software Acknowledgements</a></h2>
 645 <p>Originally, the CC2420 radio stack only used hardware generated
 646 auto-acknowledgements provided by the CC2420 chip itself.  This led
 647 to some issues, such as false acknowledgements where the radio chip
 648 would receive a packet and acknowledge its reception and the
 649 microcontroller would never actually receive the packet.</p>
 650 <p>The current CC2420 stack uses software acknowledgements, which
 651 have a higher drop percentage. When used with the UniqueSend
 652 and UniqueReceive interfaces, dropped acknowledgements are more desirable
 653 than false acknowledgements.  Received packets are always acknowledged
 654 before being filtered as a duplicate.</p>
 655 <p>Use the PacketAcknowledgements or PacketLink interfaces
 656 to determine if a packet was successfully acknowledged.</p>
 657 </div>
 658 <div class="section">
 659 <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>
 660 <p>The 802.15.4 specification identifies a Data Sequence Number (DSN)
 661 byte in the message header to filter out duplicate packets <a class="footnote-reference" href="#id13" id="id9" name="id9">[3]</a>.</p>
 662 <p>The UniqueSend interface at the top of the CC2420 radio stack is
 663 responsible for setting the DSN byte.  Upon boot, an initial DSN
 664 byte is generated using a pseudo-random number generator with a
 665 maximum of 8-bits (256) values.  This number is incremented on
 666 each outgoing packet transmission.  Even if lower levels such as
 667 PacketLink or LowPowerListening retransmit the packet, the DSN byte
 668 stays the same for that packet.</p>
 669 <p>The UniqueReceive interface at the bottom of the CC2420 radio stack
 670 is responsible for filtering out duplicate messages based on
 671 source address and DSN.  The UniqueReceive interface is not meant
 672 to stop sophisticated replay attacks.  '</p>
 673 <p>As packets are received, DSN and source address information is placed
 674 into elements of an array. Each subsequent message from previously
 675 logged addresses overwrite information in the element allocated to
 676 that source address. This prevents UniqueReceive's history from
 677 losing DSN byte information from sources that are not able to access
 678 the channel as often. If the number of elements in the history array
 679 runs out, UniqueReceive uses a best effort method to avoid replacing
 680 recently updated DSN/Source information entries.</p>
 681 </div>
 682 </div>
 683 <div class="section">
 684 <h1><a id="packetlink-implementation" name="packetlink-implementation">6. PacketLink Implementation</a></h1>
 685 <p>PacketLink is a layer added to the CC2420 radio stack to help unicast
 686 packets get delivered successfully.  In previous version of TinyOS radio
 687 stacks, it was left up to the application layer to retry a message
 688 transmission if the application determined the message was not properly
 689 received.  The PacketLink layer helps to remove the reliable delivery
 690 responsibility and functional baggage from application layers.</p>
 691 <div class="section">
 692 <h2><a id="compiling-in-the-packetlink-layer" name="compiling-in-the-packetlink-layer">6.1 Compiling in the PacketLink layer</a></h2>
 693 <p>Because the PacketLink layer uses up extra memory footprint,
 694 it is not compiled in by default.  Developers can simply define
 695 the preprocessor variable PACKET_LINK to compile the functionality
 696 of the PacketLink layer in with the CC2420 stack.</p>
 697 </div>
 698 <div class="section">
 699 <h2><a id="implementation-and-usage" name="implementation-and-usage">6.2 Implementation and Usage</a></h2>
 700 <p>To send a message using PacketLink, the PacketLink
 701 interface must be called ahead of time to specify two fields in the outbound
 702 message's metadata::</p>
 703 <pre class="literal-block">
 704 command void setRetries(message_t *msg, uint16_t maxRetries);
 705 command void setRetryDelay(message_t *msg, uint16_t retryDelay);
 706 </pre>
 707 <p>The first command, setRetries(..), will specify the maximum number
 708 of times the message should be sent before the radio stack stops
 709 transmission.  The second command, setRetryDelay(..), specifies
 710 the amount of delay in milliseconds between each retry.  The combination
 711 of these two commands can set a packet to retry as many times as needed
 712 for as long as necessary.</p>
 713 <p>Because PacketLink relies on acknowledgements, false acknowledgements
 714 from the receiver will cause PacketLink to fail.  If using software
 715 acknowledgements, false acknowledgements can still occur as a result
 716 of the limited DSN space, other 802.15.4 radios in the area with
 717 the same destination address, etc.</p>
 718 </div>
 719 </div>
 720 <div class="section">
 721 <h1><a id="asynchronous-low-power-listening-implementation" name="asynchronous-low-power-listening-implementation">7. Asynchronous Low Power Listening Implementation</a></h1>
 722 <p>Because the Low Power Listening layer uses up extra memory footprint,
 723 it is not compiled in by default.  Developers can simply define
 724 the preprocessor variable LOW_POWER_LISTENING to compile the functionality
 725 of the Low Power Listening layer in with the CC2420 stack.</p>
 726 <div class="section">
 727 <h2><a id="design-considerations" name="design-considerations">7.1 Design Considerations</a></h2>
 728 <p>The CC2420 radio stack low power listening implementation relies
 729 on clear channel assessments to determine if there is a transmitter
 730 nearby.  This allows the receiver to turn on and determine there are no
 731 transmitters in a shorter amount of time than leaving the radio on
 732 long enough to pick up a full packet.</p>
 733 <p>The transmitters perform a message delivery by transmitting
 734 the full packet over and over again for twice the duration of the receiver's
 735 duty cycle period.  Transmitting for twice as long increases the
 736 probability that the message will be detected by the receiver, and
 737 allows the receiver to shave off a small amount of time it needs to
 738 keep its radio on.</p>
 739 <p>Typically, the transmission of a single packet takes on the following
 740 form over time:</p>
 741 <blockquote>
 742 <table border="1" class="docutils">
 743 <colgroup>
 744 <col width="42%" />
 745 <col width="21%" />
 746 <col width="38%" />
 747 </colgroup>
 748 <tbody valign="top">
 749 <tr><td>LPL Backoff</td>
 750 <td>Packet Tx</td>
 751 <td>Ack Wait</td>
 752 </tr>
 753 </tbody>
 754 </table>
 755 </blockquote>
 756 <p>To decrease the amount of time required for a receive check, the channel
 757 must be modulated by the transmitter as continuously as possible.
 758 The only period where the channel is modulated is during the
 759 Packet Transmission phase.  The receiver must continuosly sample the CCA pin
 760 a moment longer than the LPL Backoff period and Ack Wait period combined
 761 to overlap the Packet Transmission period.  By making the LPL backoff
 762 period as short as possible, we can decrease the amount of time a receiver's
 763 radio must be turned on when performing a receive check.</p>
 764 <p>If two transmitters attempt to transmit using low power listening,
 765 one transmitter may hog the channel if its LPL backoff period
 766 is set too short.  Both nodes transmitting at the same time
 767 will cause interference and prevent each other from
 768 successfully delivering their messages to the intended recipient.</p>
 769 <p>To allow multiple transmitters to transmit low power listening packets
 770 at the same time, the LPL backoff period needed to be increased
 771 greater than the desired minimum.  This increases the amount of time
 772 receiver radios need to be on to perform a receive check because
 773 the channel is no longer being modulated as continuously as possible.
 774 In other words, the channel is allowed to be shared amongst multiple
 775 transmitters at the expense of power consumption.</p>
 776 </div>
 777 <div class="section">
 778 <h2><a id="minimizing-power-consumption" name="minimizing-power-consumption">7.2 Minimizing Power Consumption</a></h2>
 779 <p>There are several methods the CC2420 radio stack uses to minimize
 780 power consumption:</p>
 781 <ol class="arabic simple">
 782 <li>Invalid Packet Shutdown</li>
 783 </ol>
 784 <blockquote>
 785 Typically, packets are filtered out by address at the radio hardware
 786 level.  When a receiver wakes up and does not receive any
 787 packets into the low power listening layer of the radio stack, it
 788 will automatically go back to sleep after some period of time.  As a
 789 secondary backup, if address decoding on the radio chip is disabled,
 790 the low power listening implementation will shut down the radio if
 791 three packets are receive that do not belong to the node.  This helps
 792 prevent against denial of sleep attacks or the typical transmission
 793 behavior found in an ad-hoc network with many nodes.</blockquote>
 794 <ol class="arabic simple" start="2">
 795 <li>Early Transmission Completion</li>
 796 </ol>
 797 <blockquote>
 798 A transmitter typically sends a packet for twice the amount of time
 799 as the receiver's receive check period.  This increases the probability
 800 that the receiver will detect the packet.  However, if the transmitter receives
 801 an acknowledgement before the end of its transmission period, it
 802 will stop transmitting to save energy.  This is an improvement
 803 over previous low power listening implementations, which transmitted
 804 for the full period of time regardless of whether the receiver has
 805 already woken up and received the packet.</blockquote>
 806 <ol class="arabic simple" start="3">
 807 <li>Auto Shutdown</li>
 808 </ol>
 809 <blockquote>
 810 If the radio does not send or receive messages for some period of
 811 time while low power listening is enabled, the radio will automatically
 812 turn off and begin duty cycling at its specified duty cycle period.</blockquote>
 813 <ol class="arabic simple" start="4">
 814 <li>CCA Sampling Strategy</li>
 815 </ol>
 816 <blockquote>
 817 The actual receive check is performed in a loop inside a function,
 818 not a spinning task.  This allows the sampling to be performed
 819 continuously, with the goal of turning the radio off as quickly as
 820 possible without interruption.</blockquote>
 821 </div>
 822 </div>
 823 <div class="section">
 824 <h1><a id="cc2420-settings-and-registers" name="cc2420-settings-and-registers">8. CC2420 Settings and Registers</a></h1>
 825 <p>To interact with registers on the CC2420 chip, the SPI bus must be
 826 acquired, the chip selecct (CSn) pin must be cleared, and then the
 827 interaction may occur.  After the interaction completes, the
 828 CSn pin must be set high.</p>
 829 <p>All registers and strobes are defined in the CC2420.h file, and most
 830 are accessible through the CC2420SpiC component.  If your application
 831 requires access to a specific register or strobe, the CC2420SpiC component
 832 is the place to add access to it.</p>
 833 <p>Configuring the CC2420 requires the developer to access the CC2420Config
 834 interface provided by CC2420ControlC.  First call the CC2420Config commands to
 835 change the desired settings of the radio. If the radio happens to
 836 be off, the changes will be committed at the time it is turned on.
 837 Alternatively, calling sync() will commit the changes to the CC2420.</p>
 838 <p>RSSI can be sampled directly by calling the ReadRssi interface provided
 839 by CC2420ControlC.  See page 50 of the CC2420 datasheet for information
 840 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>
 841 </div>
 842 <div class="section">
 843 <h1><a id="cross-platform-portability" name="cross-platform-portability">9. Cross-platform Portability</a></h1>
 844 <p>To port the CC2420 radio to another platform, the following interfaces
 845 need to be implemented::</p>
 846 <pre class="literal-block">
 847 // GPIO Pins
 848 interface GeneralIO as CCA;
 849 interface GeneralIO as CSN;
 850 interface GeneralIO as FIFO;
 851 interface GeneralIO as FIFOP;
 852 interface GeneralIO as RSTN;
 853 interface GeneralIO as SFD;
 854 interface GeneralIO as VREN;
 855
 856 // SPI Bus
 857 interface Resource;
 858 interface SpiByte;
 859 interface SpiPacket;
 860
 861 // Interrupts
 862 interface GpioCapture as CaptureSFD;
 863 interface GpioInterrupt as InterruptCCA;
 864 interface GpioInterrupt as InterruptFIFOP;
 865 </pre>
 866 <p>The GpioCapture interface is tied through the Timer to provide a relative time
 867 at which the interrupt occurred.  This is useful for timestamping received
 868 packets for node synchronization.</p>
 869 <p>If the CC2420 is not connected to the proper interrupt lines,
 870 interrupts can be emulated through the use of a spinning task
 871 that polls the GPIO pin.  The MICAz implementation, for example, does this
 872 for the CCA interrupt.</p>
 873 </div>
 874 <div class="section">
 875 <h1><a id="future-improvement-recommendations" name="future-improvement-recommendations">10. Future Improvement Recommendations</a></h1>
 876 <p>Many improvements can be made to the CC2420 stack.  Below are some
 877 recommendations:</p>
 878 <div class="section">
 879 <h2><a id="aes-encryption" name="aes-encryption">10.1 AES Encryption</a></h2>
 880 <p>The CC2420 chip itself provides AES-128 encryption. The implementation
 881 involves loading the security RAM buffers on the CC2420 with the information
 882 to be encrypted - this would be the payload of a packet, without
 883 the header.  After the payload is encrypted, the microcontroller reads
 884 out of the security RAM buffer and concatenates the data with the
 885 unencrypted packet header.  This full packet would be uploaded again to the CC2420
 886 TXFIFO buffer and transmitted.</p>
 887 <p>Because the CC2420 cannot begin encryption at a particular offset
 888 and needs to be written, read, and re-written, use of the AES-128 may be
 889 inefficient and will certainly decrease throughput.</p>
 890 </div>
 891 <div class="section">
 892 <h2><a id="authentication" name="authentication">10.2 Authentication</a></h2>
 893 <p>In many cases, authentication is more desirable than encryption.
 894 Encryption significantly increases energy and decreases packet throughput,
 895 which does not meet some application requirements. A layer could be
 896 developed and added toward the bottom of the radio stack that validates
 897 neighbors, preventing packets from invalid neighbors from reaching the
 898 application layer.  Several proprietary authentication layers have
 899 been developed for the CC2420 stack, but so far none are available to
 900 the general public.</p>
 901 <p>A solid authentication layer would most likely involve the use of a
 902 neighbor table and 32-bit frame counts to prevent against replay attacks.
 903 Once a neighbor is verified and established, the node needs to ensure that
 904 future packets are still coming from the same trusted source.  Again,
 905 some high speed low energy proprietary methods to accomplish this exist, but
 906 encryption is typically the standard method used.</p>
 907 </div>
 908 <div class="section">
 909 <h2><a id="synchronous-low-power-listening" name="synchronous-low-power-listening">10.3 Synchronous Low Power Listening</a></h2>
 910 <p>A synchronous low power listening layer can be transparently built on
 911 top of the asynchronous low power listening layer.  One implementation
 912 of this has already been done on a version of the CC1000 radio stack.
 913 Moteiv's Boomerang radio stack also has a synchronous low power listening
 914 layer built as a standalone solution.</p>
 915 <p>In the case of building a synchronous layer on top of the asynchronous
 916 low power listening layer, a transmitter's radio stack can detect when
 917 a particular receiver is performing its receive checks by verifying the
 918 packet was acknowledged after a sendDone event.  The transmitter can then
 919 build a table to know when to begin transmission for that particular receiver.
 920 Each successful transmission would need to adjust the table with updated
 921 information to avoid clock skew problems.</p>
 922 <p>The asynchronous low power listening stack needs to be altered a bit
 923 to make this strategy successful.  Currently, duty cycling is started
 924 and stopped as packets are detected, received, and transmitted.  The
 925 stack would need to be altered to keep a constant clock running in the
 926 background that determines when to perform receive checks.  The
 927 clock should not be affected by normal radio stack Rx/Tx behavior.  This
 928 would allow the receiver to maintain a predictable receive check cycle
 929 for the transmitter to follow.</p>
 930 <p>If the synchronous low power listening layer loses synchronization,
 931 the radio stack can always fall back on the asynchronous low power listening
 932 layer for successful message delivery.</p>
 933 </div>
 934 <div class="section">
 935 <h2><a id="neighbor-tables" name="neighbor-tables">10.4 Neighbor Tables</a></h2>
 936 <p>Moteiv's Boomerange Sensornet Protocol (SP) implementation is a
 937 good model to follow for radio stack architecture.  One of the nice features
 938 of SP is the design and implementation of the neighbor table.  By
 939 providing and sharing neighbor table information across the entire
 940 CC2420 radio stack, RAM can be conserved throughout the radio stack
 941 and TinyOS applications.</p>
 942 </div>
 943 <div class="section">
 944 <h2><a id="radio-independant-layers" name="radio-independant-layers">10.5 Radio Independant Layers</a></h2>
 945 <p>The best radio stack architecture is one that is completely radio independant.
 946 Many of the layers in the CC2420 stack can be implemented independant
 947 of the hardware underneath if the radio stack architecture was redesigned
 948 and reimplemented. The low power listening receive check strategy may need a
 949 hardware-dependant implementation, but other layers like PacketLink,
 950 UniqueSend, UniqueReceive, ActiveMessage, Dispatch, etc. do not require
 951 a CC2420 underneath to operate properly.  The ultimate TinyOS radio
 952 stack would be one that forms an abstraction between radio-dependant
 953 layers and radio-independant layers, and operates with the same
 954 behavior across any radio chip.</p>
 955 </div>
 956 <div class="section">
 957 <h2><a id="extendable-metadata" name="extendable-metadata">10.6 Extendable Metadata</a></h2>
 958 <p>Layers added into the radio stack may require extra bytes of metadata.
 959 The PacketLink layer, for example, requires two extra fields
 960 in each message's metadata to hold the message's max retries and
 961 delay between retries.  The low power listening layer requires
 962 an extra field to specify the destination's duty cycle period for
 963 a proper delivery.</p>
 964 <p>If layers are not included in the radio stack during compile time,
 965 their fields should not be included in the message_t's metadata.</p>
 966 <p>One version of extendable metadata was implementing using an array at the end
 967 of the metadata struct that would adjust its size based on which layers were
 968 compiled in and what size fields they required.  A combination of
 969 compiler support in the form of unique(..) and uniqueCount(..) functions
 970 made it possible for the array to adjust its size.</p>
 971 <p>Explicit compiler support would be the most desirable solution to add
 972 fields to a struct as they are needed.</p>
 973 </div>
 974 <div class="section">
 975 <h2><a id="error-correcting-codes-ecc" name="error-correcting-codes-ecc">10.7 Error Correcting Codes (ECC)</a></h2>
 976 <p>When two nodes are communicating near the edge of their RF range,
 977 it has been observed that interference may cause the packet to be
 978 corrupted enough that the CRC byte and payload actually passes
 979 the check, even though the payload is not valid.  There is a one
 980 in 65535 chance of a CRC byte passing the check for a corrupted
 981 packet.  Although this is slim, in many cases it is unacceptable.
 982 Some work arounds have implemented an extra byte of software generated
 983 CRC to add to the reliability, and tests have proven its effectiveness.
 984 Taking this a step further, an ECC layer in the radio stack would help
 985 correct corrupted payloads and increase the distance at which nodes
 986 can reliably communicate.</p>
 987 </div>
 988 </div>
 989 <div class="section">
 990 <h1><a id="author-s-address" name="author-s-address">11. Author's Address</a></h1>
 991 <div class="line-block">
 992 <div class="line">David Moss</div>
 993 <div class="line">Rincon Research Corporation</div>
 994 <div class="line">101 N. Wilmot, Suite 101</div>
 995 <div class="line">Tucson, AZ  85750</div>
 996 <div class="line"><br /></div>
 997 <div class="line">phone - +1 520 519 3138</div>
 998 <div class="line">email ? <a class="reference" href="mailto:dmm&#64;rincon.com">dmm&#64;rincon.com</a></div>
 999 <div class="line"><br /></div>
1000 <div class="line"><br /></div>
1001 <div class="line">Jonathan Hui</div>
1002 <div class="line">657 Mission St. Ste. 600</div>
1003 <div class="line">Arched Rock Corporation</div>
1004 <div class="line">San Francisco, CA 94105-4120</div>
1005 <div class="line"><br /></div>
1006 <div class="line">phone - +1 415 692 0828</div>
1007 <div class="line">email - <a class="reference" href="mailto:jhui&#64;archedrock.com">jhui&#64;archedrock.com</a></div>
1008 <div class="line"><br /></div>
1009 <div class="line"><br /></div>
1010 <div class="line">Philip Levis</div>
1011 <div class="line">358 Gates Hall</div>
1012 <div class="line">Stanford University</div>
1013 <div class="line">Stanford, CA 94305-9030</div>
1014 <div class="line"><br /></div>
1015 <div class="line">phone - +1 650 725 9046</div>
1016 <div class="line">email - <a class="reference" href="mailto:pal&#64;cs.stanford.edu">pal&#64;cs.stanford.edu</a></div>
1017 <div class="line"><br /></div>
1018 <div class="line"><br /></div>
1019 <div class="line">Jung Il Choi</div>
1020 <div class="line">&lt;contact&gt;</div>
1021 <div class="line">phone -</div>
1022 <div class="line">email -</div>
1023 </div>
1024 </div>
1025 <div class="section">
1026 <h1><a id="citations" name="citations">12. Citations</a></h1>
1027 <table class="docutils footnote" frame="void" id="id11" rules="none">
1028 <colgroup><col class="label" /><col /></colgroup>
1029 <tbody valign="top">
1030 <tr><td class="label"><a name="id11">[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>
1031 </tbody>
1032 </table>
1033 <table class="docutils footnote" frame="void" id="id12" rules="none">
1034 <colgroup><col class="label" /><col /></colgroup>
1035 <tbody valign="top">
1036 <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>
1037 </tbody>
1038 </table>
1039 <table class="docutils footnote" frame="void" id="id13" rules="none">
1040 <colgroup><col class="label" /><col /></colgroup>
1041 <tbody valign="top">
1042 <tr><td class="label"><a name="id13">[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>
1043 </tbody>
1044 </table>
1045 <table class="docutils footnote" frame="void" id="id14" rules="none">
1046 <colgroup><col class="label" /><col /></colgroup>
1047 <tbody valign="top">
1048 <tr><td class="label"><a class="fn-backref" href="#id5" name="id14">[4]</a></td><td>TEP105: Low Power Listening</td></tr>
1049 </tbody>
1050 </table>
1051 <table class="docutils footnote" frame="void" id="id15" rules="none">
1052 <colgroup><col class="label" /><col /></colgroup>
1053 <tbody valign="top">
1054 <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>
1055 </tbody>
1056 </table>
1057 </div>
1058 </div>
1059 </body>
1060 </html>