[Tinyos-2-commits] CVS: tinyos-2.x/doc/html tep122.html, NONE,
1.1 tep130.html, NONE, 1.1 tep127.html, NONE, 1.1 tep128.html,
NONE, 1.1 tep105.html, NONE, 1.1 tep129.html, NONE,
1.1 tep2.html, 1.11, 1.12 tep119.html, 1.10, 1.11 tep113.html,
1.9, 1.10 tep123.html, 1.9, 1.10 tep126.html, 1.2,
1.3 tep1.html, 1.10, 1.11 tep106.html, 1.9, 1.10 tep101.html,
1.9, 1.10 tep118.html, 1.7, 1.8 tep124.html, 1.3,
1.4 tep125.html, 1.3, 1.4 overview.html, 1.8, 1.9 tep112.html,
1.9, 1.10 tep109.html, 1.8, 1.9 tep114.html, 1.8,
1.9 tep108.html, 1.10, 1.11 tep115.html, 1.9, 1.10 tep117.html,
1.8, 1.9 tep120.html, 1.9, 1.10 porting.html, 1.6,
1.7 tep116.html, 1.12, 1.13 tep110.html, 1.7, 1.8 tep121.html,
1.7, 1.8 tep102.html, 1.9, 1.10 tep107.html, 1.13,
1.14 tep103.html, 1.7, 1.8 tep3.html, 1.7, 1.8 tep111.html,
1.10, 1.11
Jan Beutel
beutel at users.sourceforge.net
Tue Aug 14 11:58:05 PDT 2007
Update of /cvsroot/tinyos/tinyos-2.x/doc/html
In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv363/doc/html
Modified Files:
tep2.html tep119.html tep113.html tep123.html tep126.html
tep1.html tep106.html tep101.html tep118.html tep124.html
tep125.html overview.html tep112.html tep109.html tep114.html
tep108.html tep115.html tep117.html tep120.html porting.html
tep116.html tep110.html tep121.html tep102.html tep107.html
tep103.html tep3.html tep111.html
Added Files:
tep122.html tep130.html tep127.html tep128.html tep105.html
tep129.html
Log Message:
fixed html validation error in docs
--- NEW FILE: tep122.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<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/" />
<title>IEEE EUI-64 Unique Node Identifier</title>
<meta name="author" content="Gilman Tolle, Jonathan Hui" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2007/08/14 18:57:59 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
h3 {
font-size: 12px;
font-family: Arial, sans-serif;
}
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee;
border-color: #000000;
border-width: thin;
font-size: 14px
}
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {}
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="ieee-eui-64-unique-node-identifier">
<h1 class="title">IEEE EUI-64 Unique Node Identifier</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">122</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Gilman Tolle, Jonathan Hui</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">26-Apr-2006</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body"></td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body"></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="note">
<p class="first admonition-title">Note</p>
<p class="last">This memo documents a part of TinyOS for the TinyOS Community, and
requests discussion and suggestions for improvements. Distribution
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>
<p>A TinyOS application developer may desire a globally-unique node
identifier within the IEEE EUI-64 namespace. This document describes
the TinyOS components used to access such an identifier.</p>
</div>
<div class="section">
<h1><a id="interfaces" name="interfaces">1. Interfaces</a></h1>
<p>A platform that can provide a valid IEEE EUI-64 globally-unique node
identifier SHOULD provide it through a component with the signature
defined here, enabling platform-independent access to the identifier:</p>
<pre class="literal-block">
configuration LocalIeeeEui64C {
provides interface LocalIeeeEui64;
}
</pre>
<p>The identifier is accessed through the following interface:</p>
<pre class="literal-block">
interface LocalIeeeEui64 {
command ieee_eui64_t getId();
}
</pre>
<p>The ieee_eui64_t type is defined in <tt class="docutils literal"><span class="pre">tos/types/IeeeEui64.h</span></tt> as:</p>
<pre class="literal-block">
enum { IEEE_EUI64_LENGTH = 8; }
typedef struct ieee_eui64 {
uint8_t data[IEEE_EUI64_LENGTH];
} ieee_eui64_t;
</pre>
<p>If the platform can provide a valid IEEE EUI-64, the value returned
from this call MUST follow the IEEE EUI-64 standard.</p>
<p>If a platform can provide a unique identifier that is not a valid IEEE
EUI-64 identifier, it SHOULD provide its unique identifier through a
component with a different name and a different interface. The
definition of such an interface is outside the scope of this TEP.</p>
</div>
<div class="section">
<h1><a id="ieee-eui-64" name="ieee-eui-64">2. IEEE EUI-64</a></h1>
<p>The IEEE EUI-64 structure is copied here:</p>
<pre class="literal-block">
| company_id | extension identifier |
|addr+0 | addr+1 | addr+2 | addr+3 | addr+4 | addr+5 | addr+6 | addr+7|
| AC | DE | 48 | 23 | 45 | 67 | AB | CD |
10101100 11011110 01001000 00100011 01000101 01100111 10101011 11001101
| | | |
| most significant byte least significant byte |
most-significant bit least-significant bit
If provided in byte-addressable media, the original byte-address order
of the manufacturer is specified: the most through least significant
bytes of the EUI-64 value are contained within the lowest through
highest byte addresses, as illustrated above.
</pre>
<p>See: <a class="reference" href="http://standards.ieee.org/regauth/oui/tutorials/EUI64.html">http://standards.ieee.org/regauth/oui/tutorials/EUI64.html</a></p>
<p>The author of the LocalIeeeEui64C component MUST ensure that the
getId() call returns a valid EUI-64 identifier that follows the
standard, with the bytes in the order described above.</p>
</div>
<div class="section">
<h1><a id="implementation-notes" name="implementation-notes">3. Implementation Notes</a></h1>
<p>Some TinyOS node platforms contain a unique hardware identifier that
can be used to build the EUI-64 node identifier. That hardware
identifier may be obtained from several places, e.g. a dedicated
serial ID chip or a flash storage device. Users of the interface
described in this document MUST NOT require knowledge of how the
unique identifier is generated.</p>
<p>The EUI-64 node identifier MUST be available before the Boot.booted()
event is signalled. If the EUI-64 is derived from a hardware device,
the hardware device should be accessed during the Init portion of the
boot sequence.</p>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">4. Author's Address</a></h1>
<div class="line-block">
<div class="line">Gilman Tolle</div>
<div class="line">Arch Rock Corporation</div>
<div class="line">657 Mission St. Suite 600</div>
<div class="line">San Francisco, CA 94105</div>
<div class="line"><br /></div>
<div class="line">phone - +1 415 692 0828</div>
<div class="line">email - <a class="reference" href="mailto:gtolle@archrock.com">gtolle@archrock.com</a></div>
</div>
<div class="line-block">
<div class="line">Jonathan Hui</div>
<div class="line">Arch Rock Corporation</div>
<div class="line">657 Mission St. Suite 600</div>
<div class="line">San Francisco, CA 94105</div>
<div class="line"><br /></div>
<div class="line">phone - +1 415 692 0828</div>
<div class="line">email - <a class="reference" href="mailto:jhui@archrock.com">jhui@archrock.com</a></div>
</div>
</div>
</div>
</body>
</html>
--- NEW FILE: tep130.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<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/" />
<title>Testbeds - Setup and Interfaces</title>
<meta name="author" content="Jan Beutel" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2007/08/14 18:57:59 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
h3 {
font-size: 12px;
font-family: Arial, sans-serif;
}
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee;
border-color: #000000;
border-width: thin;
font-size: 14px
}
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {}
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="testbeds-setup-and-interfaces">
<h1 class="title">Testbeds - Setup and Interfaces</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">130</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Testbeds Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">All</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>Jan Beutel</td></tr>
<tr class="field"><th class="docinfo-name">Draft-Created:</th><td class="field-body">14-Jun-2007</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Version:</th><td class="field-body">1.2</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Modified:</th><td class="field-body">2007-06-28</td>
</tr>
<tr class="field"><th class="docinfo-name">Draft-Discuss:</th><td class="field-body">TinyOS Testbed WG <<a class="reference" href="mailto:tinyos-testbed-wg@eecs.harvard.edu">tinyos-testbed-wg@eecs.harvard.edu</a>>></td>
</tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This document specifies a Best Current Practices for the
TinyOS Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited.</p>
</div>
<div class="section">
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>This memo describes the structure and interfaces required for TinyOS compliant
testbeds.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>The testing and validation of embedded code on real hardware is key to
successful development of TinyOS applications. Although popular and powerful for
high level analysis, current simulation methods lack in terms of level of
detail and accuracy when used accross multiple system layers where abstractions
and models used are inherently imperfect and impair results. Methods such as
hardware emulation commonly used in embedded system development allow the
execution of code on a hardware platform and therefore can guarantee timing but
are very limited in terms of scalability and often confined to a lab usage only.</p>
<p>Sensor network testbeds try to overcome these deficiencies by allowing to execute
software code under realistic operating conditions on real hardware embedded in
a target environment. This approach allows to generate a level of detail especially
in respect to the whole system (radio. processor, storage, sensors, interfaces)
and the wireless environment (noise, fading, shading, errors, failures) while
maintaining a certain degree of scalability. Remote programming as well as a
feedback of status and debugging information from the nodes using testbed
infrastructure alleviates the need for integrated services in sensor network
applications. Additionally testbeds allow to operate a set of nodes in a
controlled environment, i.e. using temperature variations or a controlled
wireless environment.</p>
<p>A typical testbed is made up of a number of nodes (?do we state amounts here?)
connected to a central resource for control and logging that are deployed in a
physical space (testing area). Typically the central resource is a server with
integrated datalogging capability. Often a web front end serves as a simple control and
visualization resource. For the submission of testing jobs and the analysis of
testing results external tools are attached to the central resource using a
standardized interface. This document serves as a key specification document for
such an interface and its intended usage.</p>
<p>MISSING: Difference of a testbed vs. a desktop test (e.g. single nodes with a
programmer or a simple usb grid)</p>
<p>Examples of currently used sensor network testbeds are MoteLab [<a class="reference" href="#id1">1</a>] and the
Deployment-Support Network [<a class="reference" href="#id2">2</a>].</p>
</div>
<div class="section">
<h1><a id="testbed-usage" name="testbed-usage">2. Testbed Usage</a></h1>
<p>A testbed can serve different purposes depending on the development status and
requirements of a specific project. While this document does not target to restrict
such usage it defines a set of mandatory modes of operation that a testbed must
be able to support:</p>
<p>Modes of Operation:</p>
<ul class="simple">
<li>Single Shot Operation</li>
</ul>
<p>Execute a testing job consisting of an uploading of a specific code image onto a
set of nodes, remote programming of nodes using a testbed resource, the
synchronized start of this software, capture of resulting target response, the
centralized storage and timestamping of all actions and target response, ending
of test execution, notification of a user of the end of test execution, output
of all stored data on demand.</p>
<ul class="simple">
<li>Repetitive (e.g. using continuous integration or for regression testing)</li>
</ul>
<p>A concatenation of single shot testing jobs, that in practice often will be used
with the variation of one or more parameters.</p>
<ul class="simple">
<li>Long Term Operation (Profiling)</li>
</ul>
<p>Other Topics:</p>
<ul class="simple">
<li>Federated Testbeds (in multiple environments)</li>
<li>Access/Resource Arbitration</li>
<li>Scheduling of testing jobs</li>
</ul>
</div>
<div class="section">
<h1><a id="testbed-services" name="testbed-services">3. Testbed Services</a></h1>
<p>Required Services:</p>
<ul class="simple">
<li>identification of target devices (presence, type, hw rev)</li>
<li>programming of target devices</li>
<li>resetting of target devices</li>
<li>logging of target response (UART mandatory, IRQ optional)</li>
<li>versioning/identification of uploaded software</li>
<li>identification/versioning/archiving of testing jobs</li>
<li>testbed status information</li>
<li>identification of testbed services</li>
<li>user authentification</li>
</ul>
<p>Optional:
- power measurements
- stimuli
- distributed scheduling of actions (at nodes)</p>
</div>
<div class="section">
<h1><a id="implementation" name="implementation">4. Implementation</a></h1>
<ul class="simple">
<li>Server, DB/Storage, Interface XMLRPC</li>
<li>Connection fabric</li>
<li>On- and offline logging</li>
<li>Supplied Power</li>
<li>Mote Hardware</li>
</ul>
<p>THINGS TO DISCUSS</p>
<ul class="simple">
<li>?Do we state minimum requirements?</li>
<li>number of nodes</li>
<li>power supply (fixed/batt)</li>
<li>power profiling</li>
<li>power on/off of targets? is simple reset/erasing enough?</li>
<li>feedback channel capabilities (delay, errors, lost packets...)</li>
<li>target control? is control of (writing to) targets required or is it an optional feature?</li>
<li>scheduling of actions (time synched???)</li>
</ul>
</div>
<div class="section">
<h1><a id="reference" name="reference">5. Reference</a></h1>
</div>
<div class="section">
<h1><a id="acknowledgments" name="acknowledgments">6. Acknowledgments</a></h1>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">7. Author's Address</a></h1>
<div class="line-block">
<div class="line">Jan Beutel</div>
<div class="line">Gloriastr 35</div>
<div class="line">ETH Zurich</div>
<div class="line">8092 Zurich</div>
<div class="line">Switzerland</div>
<div class="line"><br /></div>
<div class="line">phone - +41 44 632 7032</div>
<div class="line"><br /></div>
<div class="line">email - <a class="reference" href="mailto:j.beutel@ieee.org">j.beutel@ieee.org</a></div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">8. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id1">[1]</a></td><td>G. Werner-Allen, P. Swieskowski, and M. Welsh. MoteLab: A wireless sensor
network testbed. In Proc. 4th Int'l Conf. Information Processing Sensor
Networks (IPSN '05), pages 483-488. IEEE, Piscataway, NJ, April 2005.</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id2">[2]</a></td><td>M. Dyer, J. Beutel, L. Thiele, T. Kalt, P. Oehen, K. Martin, and P. Blum.
Deployment support network - a toolkit for the development of WSNs. In Proc.
4th European Workshop on Sensor Networks (EWSN 2007), volume 4373 of Lecture
Notes in Computer Science, pages 195-211. Springer, Berlin, January 2007.</td></tr>
</tbody>
</table>
</div>
<div class="section">
<h1><a id="appendix-a-example-appendix" name="appendix-a-example-appendix">Appendix A. Example Appendix</a></h1>
<p>This is an example appendix. Appendices begin with the letter A.</p>
</div>
</div>
</body>
</html>
--- NEW FILE: tep127.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<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/" />
<title>Packet Link Layer</title>
<meta name="author" content="David Moss, Philip Levis" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2007/08/14 18:57:59 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
h3 {
font-size: 12px;
font-family: Arial, sans-serif;
}
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee;
border-color: #000000;
border-width: thin;
font-size: 14px
}
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {}
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="packet-link-layer">
<h1 class="title">Packet Link Layer</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">127</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Draft</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>David Moss, Philip Levis</td></tr>
</tbody>
</table>
<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
requests discussion and suggestions for improvements. Distribution
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>
<p>This TEP describes the behavior and interfaces of the TinyOS 2.x
Packet Link Layer. The Packet Link Layer is an optional radio stack
layer responsible for the reliable delivery of a packet from node to
node. Packet Link provides error correction functionality found in
Layer 2 of the OSI model <a class="footnote-reference" href="#id2" id="id1" name="id1">[1]</a>.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>In wireless networks, packets are regularly dropped between point to point
communications due to interference or RF range. Correcting these dropped
packets requires the transmitter to first recognize that the packet was
not acknowledged, and then retransmit that packet.</p>
<p>Retransmitting the packet adds its own set of issues. Specifically, the
receiver will receive duplicate packets due to its own dropped acknowledgements.
Logic is therefore required to allow receiver to recognize and dump duplicate
packets, but only after the acknowledgement has been sent back to the
transmitter.</p>
<p>With these two pieces of functionality: the ability for a transmitter to
keep retrying until it gets an acknowledgement and the ability
for a receiver to accept only a single copy of the packet, a Packet Link Layer
can be formed to reliably deliver a single packet from point to point.</p>
</div>
<div class="section">
<h1><a id="design-considerations" name="design-considerations">2. Design Considerations</a></h1>
<div class="section">
<h2><a id="time-spent-retrying-a-delivery" name="time-spent-retrying-a-delivery">2.1 Time spent retrying a delivery</a></h2>
<p>Some networks have different timing characteristics than others.
Consider a person carrying a wireless device while walking in and out
of RF range of another node. In this case, the device may want to
retry the transmission a few times over the course of a few seconds before
declaring the delivery unsuccessful. A robust Packet Link Layer should
allow the developer to specify the amount of time spent retrying as well
as the number of retries to send.</p>
</div>
<div class="section">
<h2><a id="setting-the-packet-sequence-number" name="setting-the-packet-sequence-number">2.2 Setting the packet sequence number</a></h2>
<p>To detect duplicate packets, a sequence number byte can be used
within the packet to verify against previously received
packets. If the source address and sequence number of a newly received
packet matches that of a previously received packet, then the newly received
packet is a duplicate and may be dumped. To prevent the packet sequence
number byte from changing on each retransmission, the byte should be set
at or above the Packet Link Layer and never changed below.</p>
</div>
<div class="section">
<h2><a id="false-acknowledgements" name="false-acknowledgements">2.3 False Acknowledgements</a></h2>
<p>The low levels of a radio stack or the radio chip itself are typically
responsible for generating packet acknowledgements. It has been
observed in some platforms that the radio chip will generate false
auto-acknowledgements. This occurs when the radio receives the packet and
sends an acknowledgement but the microcontroller never gets the message
due to some error. In this case, the transmitter would believe the
packet got to the destination successfully but the receiver would have
no knowledge that a packet was received. Software initiated
acknowledgements prevent this issue by removing the possibility of
false acknowledgements.</p>
</div>
</div>
<div class="section">
<h1><a id="interface" name="interface">3. Interface</a></h1>
<div class="section">
<h2><a id="packetlink-interface" name="packetlink-interface">3.1 PacketLink Interface</a></h2>
<p>The TEP proposes this PacketLink interface::</p>
<pre class="literal-block">
interface PacketLink {
command void setRetries(message_t *msg, uint16_t maxRetries);
command void setRetryDelay(message_t *msg, uint16_t retryDelay);
command uint16_t getRetries(message_t *msg);
command uint16_t getRetryDelay(message_t *msg);
command bool wasDelivered(message_t *msg);
}
</pre>
<p>PacketLinks interface functions:</p>
<blockquote>
<tt class="docutils literal"><span class="pre">setRetries(message_t</span> <span class="pre">*msg,</span> <span class="pre">uint16_t</span> <span class="pre">maxRetries)</span></tt></blockquote>
<ul>
<li><p class="first">Sets the maximum number of times to retry the transmission of the message</p>
<p><tt class="docutils literal"><span class="pre">setRetryDelay(message_t</span> <span class="pre">*msg,</span> <span class="pre">uint16_t</span> <span class="pre">retryDelay)</span></tt></p>
</li>
<li><p class="first">Set the delay, in milliseconds, between each retransmission</p>
<p><tt class="docutils literal"><span class="pre">getRetries(message_t</span> <span class="pre">*msg)</span></tt></p>
</li>
<li><p class="first">Returns the maximum number of retries configured for the given message</p>
<p><tt class="docutils literal"><span class="pre">getRetryDelay(message_t</span> <span class="pre">*msg)</span></tt></p>
</li>
<li><p class="first">Returns the delay, in milliseconds, between each retransmission for the given
message</p>
<p><tt class="docutils literal"><span class="pre">wasDelivered(message_t</span> <span class="pre">*msg)</span></tt></p>
</li>
<li><p class="first">This command may be called after the sendDone() event is signaled. It is the
equivalent of <tt class="docutils literal"><span class="pre">PacketAcknowledgements.wasAcked(message_t</span> <span class="pre">*msg)</span></tt>, so is only
a helper function to make the PacketLink interface easier to use.</p>
</li>
</ul>
</div>
<div class="section">
<h2><a id="expected-behavior" name="expected-behavior">3.2 Expected Behavior</a></h2>
<p>The PacketLink interface is accessed by the application layer before
the packet is passed to the radio stack for transmission. The application
layer will call setRetries(...) and setRetryDelay(...), passing in the
message it is about to send.</p>
<p>The interface MUST configure metadata for the packet to specify the maximum
number of retries and the amount of delay between each retry. When the
send process reaches the Packet Link Layer, it MUST automatically check the
packet's metadata and retry sending the packet as previously configured.</p>
<p>For example, to configure a packet to be retried a maximum of 50 times
over the next 5 seconds, the developer would execute the following commands
before sending the packet::</p>
<pre class="literal-block">
call PacketLink.setRetries(msg, 50);
call PacketLink.setRetryDelay(msg, 100);
</pre>
<p>By placing a 100 ms delay between each retry and allowing up to 50 retries
maximum, the maximum amount of time the message will be transmitted is
(50 * 100) ms, or 5000 ms.</p>
<p>When transmitting a packet configured for reliable delivery to the
broadcast address, the Packet Link Layer SHOULD allow the packet to be
retried. This will let the transmitter know that at least one node
received the message.</p>
</div>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">4. 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">101 N. Wilmot, Suite 101</div>
<div class="line">Tucson, AZ 85750</div>
<div class="line"><br /></div>
<div class="line">phone - +1 520 519 3138</div>
<div class="line">email ? <a class="reference" href="mailto:dmm@rincon.com">dmm@rincon.com</a></div>
<div class="line"><br /></div>
<div class="line"><br /></div>
<div class="line">Philip Levis</div>
<div class="line">358 Gates Hall</div>
<div class="line">Stanford University</div>
<div class="line">Stanford, CA 94305-9030</div>
<div class="line"><br /></div>
<div class="line">phone - +1 650 725 9046</div>
<div class="line">email - <a class="reference" href="mailto:pal@cs.stanford.edu">pal@cs.stanford.edu</a></div>
<div class="line"><br /></div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">5. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1" name="id2">[1]</a></td><td>"OSI model" <a class="reference" href="http://en.wikipedia.org/wiki/OSI_model">http://en.wikipedia.org/wiki/OSI_model</a></td></tr>
</tbody>
</table>
</div>
</div>
</body>
</html>
--- NEW FILE: tep128.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<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/" />
<title>Platform Independent Non-Volatile Storage Abstractions</title>
<meta name="authors" content="David Moss Junzhao Du Prabal Dutta Deepak Ganesan Kevin Klues Manju Ajay Martin and Gaurav Mathur" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2007/08/14 18:58:00 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
h3 {
font-size: 12px;
font-family: Arial, sans-serif;
}
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee;
border-color: #000000;
border-width: thin;
font-size: 14px
}
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {}
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="platform-independent-non-volatile-storage-abstractions">
<h1 class="title">Platform Independent Non-Volatile Storage Abstractions</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">128</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Storage Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>DRAFT</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Authors:</th>
<td>David Moss
<br />Junzhao Du
<br />Prabal Dutta
<br />Deepak Ganesan
<br />Kevin Klues
<br />Manju
<br />Ajay Martin
<br />and Gaurav Mathur</td></tr>
</tbody>
</table>
<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
requests discussion and suggestions for improvements. Distribution
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>
<p>The storage abstractions proposed by TEP 103 are implemented on a
platform-dependent basis. A version of BlockStorage, ConfigStorage,
and LogStorage were created from the ground up for both the
AT45DB and ST M25P80 flash chips. Looking forward into the further
growth and development of hardware, rebuilding each of these storage
layers for every new flash chip will be time consuming and cause
compatibility issues.</p>
<p>We propose a layer of abstraction to reside between a chip-dependent
flash chip implementation and platform-independent storage
implementations. This abstraction layer should provide methods
to perform basic flash operations (read, write, erase, flush, crc),
as well as provide information about the physical properties of the
flash chip. Efficiency concerns are mitigated by the fact that each
platform-independent abstraction is implemented in a platform-dependent
manner, allowing it to exist on different types of memory such as
NAND flash, NOR flash, and EEPROM. This abstraction layer should
allow one implementation of each storage solution to operate across
many different platforms.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>The implementations of the BlockStorage, ConfigStorage, and LogStorage
layers described in TEP 103 [1] are platform dependent. Platform-
dependent implementations can cause behavioral and usage differences
as well as compiling problems when attempting to port an application
written on one platform to another. A true abstraction layer would
exhibit the same set of interfaces and no differences in behavior when
implemented across various types of non-volatile memory.</p>
<p>A well defined non-volatile memory abstraction layer should allow core
functionality to work on a variety of platforms without modification.
Some flash chips may provide extra functionality. If a particular
applications on a specific platform wants to take advantage of
extra functionality provided by a flash chip, it still has the opportunity
to access those features directly with the understanding that its
implementation is no longer considered platform-independent.</p>
<div class="section">
<h2><a id="platform-dependent-volume-settings" name="platform-dependent-volume-settings">1.1 Platform-dependent volume settings</a></h2>
<p>Differences exist between the TEP 103 storage implementations
on the AT45DB, ST M25P80, and PXA27X P30 flash chips.</p>
<p>First, volume information is defined using two distinct methods. As
was discussed in TEP 103, an XML file is responsible for the
allocation of flash memory into volumes at compile time. Individual
storage layers can then mount to the defined volumes, which
allows those layers to share the flash memory resource amongst
each other.</p>
<p>The AT45DB implementation running on mica* platforms converts the
information presented in the application's volumes XML file into
information accessible through macros::</p>
<pre class="literal-block">
#ifndef STORAGE_VOLUMES_H
#define STORAGE_VOLUMES_H
enum {
VOLUME_BLOCKTEST,
};
#endif
#if defined(VS)
VS(VOLUME_BLOCKTEST, 1024)
#undef VS
#endif
#if defined(VB)
VB(VOLUME_BLOCKTEST, 0)
#undef VB
#endif
</pre>
<p>The ST M25P80 implementation running on TelosB/Tmote platforms,
on the other hand, converts the information in the volumes XML
file into an array of constants::</p>
<pre class="literal-block">
#ifndef __STORAGE_VOLUME_H__
#define __STORAGE_VOLUME_H__
#include "Stm25p.h"
#define VOLUME_BLOCKTEST 0
static const stm25p_volume_info_t STM25P_VMAP[ 1 ] = {
{ base : 0, size : 4 },
};
#endif
</pre>
<p>Furthermore, the two implementations defined incompatible interfaces for
accessing information about volumes. For example, the AT45DB interface
provides the following::</p>
<pre class="literal-block">
interface At45dbVolume {
command at45page_t remap(at45page_t volumePage);
command at45page_t volumeSize();
}
</pre>
<p>The ST M25P80 interface defines a different interface, which allows
applications to access the volume settings directly through the
stm25p_volume_info_t array::</p>
<pre class="literal-block">
interface Stm25pVolume {
async event volume_id_t getVolumeId();
}
</pre>
<p>Accessing volume information is very platform-dependent.
A single method should be integrated to access volume
settings and non-volatile memory properties across any platform.</p>
<p>Another issue exists with the previous concept of volumes. Any storage
solution that wishes to retain valid data while erasing invalid data
MUST have access to at least two erase units. Circular logging,
configuration storage, variable storage, dictionary storage, file
systems, and more all require a minimum of two erase units to be
implemented effectively. One erase unit can be used to erase
all the invalid data while other erase unit(s) retains any valid data.</p>
<p>Therefore, the minimum allowable volume size should be twice the size
of a single erase unit to effectively support the majority of
storage applications. The XML tools that process and allocate
volumes should prevent a user from defining a volume too small::</p>
<pre class="literal-block">
+------------+--------+------------+-----------+------------+
| | AT45DB | ST M25P | PXA27x | K9K1G08R0B |
+------------+--------+------------+-----------+------------+
| Min.Volume | 512B | 512B-128kB | 128-256kB | 16kB-64kB |
+------------+--------+------------+-----------+------------+
</pre>
</div>
<div class="section">
<h2><a id="platform-dependent-component-signatures" name="platform-dependent-component-signatures">1.2 Platform-dependent component signatures</a></h2>
<p>The storage components' signatures differ across implementations.
For example, the PXA27X P30 flash defines "P30BlockC", "P30ConfigC",
and "P30LogC" in place of "BlockStorageC", "ConfigStorageC", and
"LogStorageC". Furthermore, the BlockStorageC configuration in the
AT45DB implementation takes the following form::</p>
<pre class="literal-block">
generic configuration BlockStorageC(volume_id_t volid) {
provides {
interface BlockWrite;
interface BlockRead;
}
}
</pre>
<p>while the ST M25P80 implementation adds another interface::</p>
<pre class="literal-block">
generic configuration BlockStorageC( volume_id_t volume_id ) {
provides interface BlockRead;
provides interface BlockWrite;
provides interface StorageMap;
}
</pre>
<p>The StorageMap interface on the M25P80 flash chip simply allows
an application to convert a volume-based virtual address into
a physical address on flash. Although it is a good idea, it
is not consistent with other platforms' defined interfaces.</p>
</div>
</div>
<div class="section">
<h1><a id="directstorage" name="directstorage">2. DirectStorage</a></h1>
<div class="section">
<h2><a id="differences-and-advantages" name="differences-and-advantages">3.1 Differences and advantages</a></h2>
<p>The core current BlockStorage, ConfigStorage, and LogStorage
layers can all be implemented on a platform-independent abstraction
layer. Providing an interface that allows direct, unimpeded
access to the memory below while offering information about
the properties of that memory is the first step in doing so.</p>
<p>The DirectStorage interface was created to as part of the answer to this
issue. DirectStorage resembles the BlockStorage interface in many ways,
with two significant exceptions:</p>
<p>1. Erase operation
BlockStorage's behavior erases the entire volume at a time, which may
consist of multiple erase units. DirectStorage allows erases to occur
on per-erase unit basis. Therefore, if only a portion of the volume
needs to be erased, it can.</p>
<p>2. Organization
BlockStorage defines two different interfaces for interacting with the
flash: BlockRead and BlockWrite. These two interfaces are combined
into one interface. The getSize() command provided by the BlockRead
interface is removed and replaced with VolumeSettings, which will be
discussed later. Also, sync()/syncDone() is replaced with
flush/flushDone(), which is responsible for writing any data that
has not already been written to non-volatile memory. Although
the crc() command can technically exist above BlockStorage as
well as DirectStorage, it remains in DirectStorage for its ease
of use.</p>
<p>Finally, layers should have the ability to be added beneath DirectStorage
to further optimize and enable memory operation. For example, the
ST M25P80 flash does not have any on-board RAM buffers, so it
is up to the microcontroller to buffer and flush out data to write units.
This functionality may not be desirable on all applications because
it uses valuable microcontroller resources; therefore, it should
be removable as layers can be added and removed from radio stack
architecture.</p>
<p>Other memory types may require extra support in and underneath
the hood of DirectStorage as well. NAND flash, for example,
requires bad block management and error correction. This functionality
can be implemented without changing the behavior of the DirectStorage
interface above.</p>
</div>
<div class="section">
<h2><a id="directstorage-interface" name="directstorage-interface">3.2 DirectStorage Interface</a></h2>
<p>The DirectStorage interface is described below. Each "addr" variable
is a virtual address, with 0x0 relative to the base address of the
volume. This base address may actually be physically located
somewhere else on the non-volatile memory::</p>
<pre class="literal-block">
interface DirectStorage {
command error_t read(uint32_t addr, void *buf, uint32_t len);
command error_t write(uint32_t addr, void *buf, uint32_t len);
command error_t erase(uint16_t eraseUnitIndex);
command error_t flush();
command error_t crc(uint32_t addr, uint32_t len, uint16_t baseCrc);
event void readDone(uint32_t addr, void *buf, uint32_t len, error_t error);
event void writeDone(uint32_t addr, void *buf, uint32_t len, error_t error);
event void eraseDone(uint16_t eraseUnitIndex, error_t error);
event void flushDone(error_t error);
event void crcDone(uint16_t calculatedCrc, uint32_t addr, uint32_t len, error_t error);
}
</pre>
<dl class="docutils">
<dt><tt class="docutils literal"><span class="pre">read(uint32_t</span> <span class="pre">addr,</span> <span class="pre">void</span> <span class="pre">'*buf',</span> <span class="pre">uint32_t</span> <span class="pre">len);</span></tt></dt>
<dd><ul class="first last simple">
<li>Read 'len' bytes into <tt class="docutils literal"><span class="pre">*buf</span></tt> from the given address</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals readDone(...) when complete.</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">write(uint32_t</span> <span class="pre">addr,</span> <span class="pre">void</span> <span class="pre">'*buf',</span> <span class="pre">uint32_t</span> <span class="pre">len);</span></tt></dt>
<dd><ul class="first last simple">
<li>Write 'len' bytes from <tt class="docutils literal"><span class="pre">*buf</span></tt> starting at the given address</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals writeDone(...) when complete.</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">erase(uint16_t</span> <span class="pre">eraseUnitIndex);</span></tt></dt>
<dd><ul class="first last simple">
<li>Erase a single 0-indexed erase unit</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals eraseDone(...) when complete.</li>
</ul>
</dd>
<dt>flush()</dt>
<dd><ul class="first last simple">
<li>All data that has been previously written and is not yet located on
non-volatile memory should be immediately stored to non-volatile memory.</li>
<li>Returns FAIL if the operation cannot be completed at this time</li>
<li>Signals flushDone(...) when complete.</li>
</ul>
</dd>
<dt>crc(uint32_t addr, uint32_t len, uint16_t baseCrc);</dt>
<dd><ul class="first last simple">
<li>Calculate the CRC of 'len' bytes starting at the given address, using
the given baseCrc as a seed.</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals crcDone(...) when complete.</li>
</ul>
</dd>
</dl>
</div>
<div class="section">
<h2><a id="directmodify-interface" name="directmodify-interface">3.3 DirectModify Interface</a></h2>
<p>Some memory types have the ability to modify their contents without
destroying surrounding data.</p>
<p>The AT45DB NOR-flash, for example, is able to do this because
it has built in RAM buffers coupled with small erase unit sizes.
The physical RAM buffers perform a read-modify-write operation to
effectively change the contents of flash, allowing it to emulate
the behavior of an EEPROM with the speed and efficiency of NOR-flash.</p>
<p>The ATmega128 microcontroller has 4kB of internal EEPROM memory which
can be directly modified. Also, the MSP430 has 256 bytes of internal
NOR-flash memory which is divided into two segments of 128 bytes each.
When implemented properly, this NOR-flash memory can be modified in a
fault-tolerant manner.</p>
<p>The ST M25P80 NOR-flash cannot support modification without sacrificing
significant overhead. It has 16 erase units that are 64kB each,
which is too large to effectively modify bytes.</p>
<p>While not all memories support modification, a unified interface
should exist to interact with memories that do. This interface
should be access with the understanding that applications built
on top may not be portable to all memory types. Also, DirectStorage
and DirectModify are mounted to their own individual volumes, so
DirectModify cannot share its allocated memory resources with
a DirectStorage interface::</p>
<pre class="literal-block">
interface DirectModify {
command error_t modify(uint32_t addr, void *buf, uint32_t len);
command error_t read(uint32_t addr, void *buf, uint32_t len);
command error_t erase(uint16_t eraseUnitIndex);
command error_t flush();
command error_t crc(uint32_t addr, uint32_t len, uint16_t baseCrc);
command bool isSupported();
event void modified(uint32_t addr, void *buf, uint32_t len, error_t error);
event void readDone(uint32_t addr, void *buf, uint32_t len, error_t error);
event void eraseDone(uint16_t eraseUnitIndex, error_t error);
event void flushDone(error_t error);
event void crcDone(uint16_t calculatedCrc, uint32_t addr, uint32_t len, error_t error);
}
</pre>
<dl class="docutils">
<dt><tt class="docutils literal"><span class="pre">modify(uint32_t</span> <span class="pre">addr,</span> <span class="pre">void</span> <span class="pre">*buf,</span> <span class="pre">uint32_t</span> <span class="pre">len)</span></tt></dt>
<dd><ul class="first last simple">
<li>Modify 'len' bytes located on non-volatile memory at the given address,
replacing them with data from the given buffer</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals modified(...) when the operation is complete</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">read(uint32_t</span> <span class="pre">addr,</span> <span class="pre">void</span> <span class="pre">*buf,</span> <span class="pre">uint32_t</span> <span class="pre">len)</span></tt></dt>
<dd><ul class="first last simple">
<li>Read 'len' bytes into <tt class="docutils literal"><span class="pre">*buf</span></tt> from the given address</li>
<li>Same as DirectStorage.read(...)</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals readDone(...) when complete.</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">erase(uint16_t</span> <span class="pre">eraseUnitIndex);</span></tt></dt>
<dd><ul class="first last simple">
<li>Erase a single 0-indexed erase unit</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals eraseDone(...) when complete.</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">flush()</span></tt></dt>
<dd><ul class="first last simple">
<li>All data that has been previously written and is not yet located on
non-volatile memory should be immediately stored to non-volatile memory.</li>
<li>Same behavior as flush() methods found in Java</li>
<li>Returns FAIL if the operation cannot be completed at this time</li>
<li>Signals flushDone(...) when complete.</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">crc(uint32_t</span> <span class="pre">addr,</span> <span class="pre">uint32_t</span> <span class="pre">len,</span> <span class="pre">uint16_t</span> <span class="pre">baseCrc);</span></tt></dt>
<dd><ul class="first last simple">
<li>Calculate the CRC of 'len' bytes starting at the given address, using
the given baseCrc as a seed.</li>
<li>Returns FAIL if the volume is already in use</li>
<li>Signals crcDone(...) when complete.</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">isSupported()</span></tt></dt>
<dd><ul class="first last simple">
<li>Returns TRUE if DirectModify is available on the current memory type</li>
</ul>
</dd>
</dl>
</div>
<div class="section">
<h2><a id="volumesettings-interface" name="volumesettings-interface">3.4 VolumeSettings Interface</a></h2>
<p>As was shown in Section 1.1, finding information about the current
volume required platform-dependent methods of access. VolumeSettings
provides a unified method of accessing information about the underlying
memory chip and volume settings.</p>
<p>VolumeSettings MUST be implemented separately for DirectStorage and
DirectModify, not only because those abstractions will exist on
separate volumes, but also because the DirectModify interface may
change the available size of the volume to support certain memory
types such as NAND- and NOR-flash::</p>
<pre class="literal-block">
interface VolumeSettings {
command uint32_t getVolumeSize();
command uint32_t getTotalEraseUnits();
command uint32_t getEraseUnitSize();
command uint32_t getTotalWriteUnits();
command uint32_t getWriteUnitSize();
command uint8_t getFillByte();
command uint8_t getEraseUnitSizeLog2();
command uint8_t getWriteUnitSizeLog2();
}
</pre>
<dl class="docutils">
<dt>getVolumeSize()</dt>
<dd><ul class="first last simple">
<li>Returns the size of the volume the DirectStorage layer
is mounted to, in bytes</li>
</ul>
</dd>
<dt>getTotalEraseUnits()</dt>
<dd><ul class="first last simple">
<li>Returns the total number of erase units on the mounted volume</li>
</ul>
</dd>
<dt>getEraseUnitSize()</dt>
<dd><ul class="first last simple">
<li>Returns the size of an individual erase unit, in bytes</li>
</ul>
</dd>
<dt>getTotalWriteUnits()</dt>
<dd><ul class="first last simple">
<li>Returns the total number of write units on the mounted volume</li>
</ul>
</dd>
<dt>getWriteUnitSize()</dt>
<dd><ul class="first last simple">
<li>Returns the size of an individual write unit, in bytes</li>
</ul>
</dd>
<dt>getFillByte()</dt>
<dd><ul class="first last simple">
<li>Returns the default byte value found on the memory after an erase,
which is typically 0xFF</li>
</ul>
</dd>
<dt>getEraseUnitSizeLog2()</dt>
<dd><ul class="first last simple">
<li>Returns the size of an erase unit in Log2 format for ease of
calculations</li>
</ul>
</dd>
<dt>getWriteUnitSizeLog2()</dt>
<dd><ul class="first last simple">
<li>Returns the size of a write unit in Log2 format for ease of
calculations</li>
</ul>
</dd>
</dl>
</div>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">4. 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">101 N. Wilmot, Suite 101</div>
<div class="line">Tucson, AZ 85750</div>
<div class="line"><br /></div>
<div class="line">phone - +1 520 519 3138</div>
<div class="line">phone - +1 520 519 3146</div>
<div class="line">email ? <a class="reference" href="mailto:dmm@rincon.com">dmm@rincon.com</a></div>
<div class="line"><br /></div>
<div class="line">Junzhao Du</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Prabal Dutta</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Deepak Ganesan</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Kevin Klues</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Manju</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Ajay Martin</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Gaurav Mathur</div>
<div class="line">Contact -</div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">5. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id1" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id1">[1]</a></td><td>TEP 103: Permanent Data Storage (Flash). <a class="reference" href="http://tinyos.cvs.sourceforge.net/">http://tinyos.cvs.sourceforge.net/</a><em>checkout</em>/tinyos/tinyos-2.x/doc/html/tep103.html</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id2">[2]</a></td><td>Atmel AT45DB041B datasheet. <a class="reference" href="http://www.atmel.com/dyn/resources/prod_documents/DOC1432.PDF">http://www.atmel.com/dyn/resources/prod_documents/DOC1432.PDF</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id3" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id3">[3]</a></td><td>ST M25P80 datasheet. <a class="reference" href="http://www.st.com/stonline/products/literature/ds/8495/m25p80.pdf">http://www.st.com/stonline/products/literature/ds/8495/m25p80.pdf</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id4" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id4">[4]</a></td><td>K9K1G08R0B datasheet. <a class="reference" href="http://www.samsung.com/Products/Semiconductor/NANDFlash/SLC_SmallBlock/1Gbit/K9K1G08R0B/ds_k9k1g08x0b_rev10.pdf">http://www.samsung.com/Products/Semiconductor/NANDFlash/SLC_SmallBlock/1Gbit/K9K1G08R0B/ds_k9k1g08x0b_rev10.pdf</a></td></tr>
</tbody>
</table>
</div>
</div>
</body>
</html>
--- NEW FILE: tep105.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<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/" />
<title>Low Power Listening</title>
<meta name="author" content="David Moss, Jonathan Hui, Kevin Klues" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2007/08/14 18:58:00 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
h3 {
font-size: 12px;
font-family: Arial, sans-serif;
}
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee;
border-color: #000000;
border-width: thin;
font-size: 14px
}
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {}
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="low-power-listening">
<h1 class="title">Low Power Listening</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">105</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Core Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>Final</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Author:</th>
<td>David Moss, Jonathan Hui, Kevin Klues</td></tr>
</tbody>
</table>
<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
requests discussion and suggestions for improvements. Distribution
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>
<p>This TEP describes the structure and implementation of the TinyOS 2.x
link layer abstractions. The architecture is designed to allow each radio
type to implement its own low power strategy within the Hardware Adaptation
Layer (HAL), while maintaining a common application interface. The
history and strategies for low power listening are discussed, as well
as expected behavior and implementation recommendations.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>Asynchronous low power listening is a strategy used to duty cycle
the radio while ensuring reliable message delivery since TinyOS 1.x
<a class="citation-reference" href="#mica2" id="id1" name="id1">[MICA2]</a>.</p>
<p>While a CC1000 or CC2420 radio is turned on and listening, it can
actively consume anywhere between 7.4 to 18.8 mA on top of the power
consumed by other components in the system <a class="citation-reference" href="#cc1000" id="id2" name="id2">[CC1000]</a>,[CC2420]_.
This can rapidly deplete batteries. In the interest of extending
battery lifetime, it is best to duty cycle the radio on and off to
prevent this idle waste of energy. In an asychronous low power
message delivery scheme, the duty cycling receiver node saves the
most energy by performing short, periodic receive checks. The power
consumption burden is then placed on the transmitter node, which
must modulate the radio channel long enough for the recipient?s
receive check to detect an incoming message. A synchronous low
power message delivery scheme takes this idea a step further by
allowing the transmitter to only transmit when it knows the
destination node is performing a receive check.</p>
</div>
<div class="section">
<h1><a id="background" name="background">2. Background</a></h1>
<div class="section">
<h2><a id="early-tinyos-1-x-cc1000-low-power-listening-implementation" name="early-tinyos-1-x-cc1000-low-power-listening-implementation">2.1 Early TinyOS 1.x CC1000 Low Power Listening Implementation</a></h2>
<p>TinyOS 1.x introduced low power listening on the CC1000 radio, but
never introduced a similar scheme for the CC2420 radio in the baseline.
The CC1000 radio had the following low power listening commands,
provided directly by CC1000RadioIntM::</p>
<pre class="literal-block">
command result_t SetListeningMode(uint8_t power);
command uint8_t GetListeningMode();
command result_t SetTransmitMode(uint8_t power);
command uint8_t GetTransmitMode();
</pre>
<p>The uint8_t 'power' mode parameter was initially defined as follows::</p>
<pre class="literal-block">
//Original CC1000 Low Power Listening Modes
Power Mode 0 = 100% duty cycle
Power Mode 1 = 35.5% duty cycle
Power Mode 2 = 11.5% duty cycle
Power Mode 3 = 7.53% duty cycle
Power Mode 4 = 5.61% duty cycle
Power Mode 5 = 2.22% duty cycle
Power Mode 6 = 1.00% duty cycle
</pre>
<p>There were several issues with this interface and implementation.
First, setting up a low power network was cumbersome. The low power
listening commands had to be directly wired through CC1000RadioIntM,
and called while the radio was not performing any transactions.
Second, each node in a network was expected to have the same radio
power mode. Finally, the pre-programmed duty cycles were not linear
and offered a very limited selection of options.</p>
<p>In this low power listening implementation, the transmitter mote would
transmit a packet that consisted of an extremely long preamble. This
preamble was long enough to span a complete receive check period. On
the receiver?s end, the radio would turn on and read bits from the
radio. If a preamble sequence was detected in the incoming bits, the
receiver?s radio would remain on for the full duration of the
transmitter?s preamble and wait for the packet at the end.</p>
<p>This original low power listening scheme was rather inefficient on both
the transmit and receive end. On the receive end, turning on the radio
completely and reading in bits typically cost much more energy than
necessary. The transmitter's long preamble could end up costing both
nodes to have their radios on much longer than required, sending and
receiving useless preamble bits.</p>
</div>
<div class="section">
<h2><a id="cc1000-pulse-check-implementation" name="cc1000-pulse-check-implementation">2.2 CC1000 Pulse Check Implementation</a></h2>
<p>Joe Polastre and Jason Hill developed a better receive check
implementation in the CC1000 ?Pulse Check? radio stack for TinyOS 1.x,
while maintaining the same interface. This implementation took advantage
of a Clear Channel Assessment (CCA) to determine if a transmitter was
nearby.</p>
<p>In this implementation, the CC1000 radio did not have to be turned on
completely, so it consumed less maximum current than the previous
implementation. The radio on-time was also significantly reduced, only
turning on long enough for a single ADC conversion to occur. If energy
was detected on the channel after the first ADC conversion, subsequent
ADC conversions would verify this before committing to turning the
radio receiver on completely.</p>
<p>In this implementation the receiver's efficiency dramatically improved,
but the transmitter still sent a long, inefficient preamble. Energy
consumption used to transmit messages was still high, while throughput
was still low.</p>
</div>
<div class="section">
<h2><a id="possible-improvements" name="possible-improvements">2.3 Possible Improvements</a></h2>
<p>Low power listening is a struggle between minimizing energy efficiency
and maximizing throughput. In an asynchronous low power listening
scheme, several improvements can be made over earlier implementations.
One improvement that could have been made to earlier implementations is
to remove the long transmitted preamble and send many smaller messages
instead. For example, the transmitter could send the same message over
and over again for the duration of the receiver's receive check period.
The receiver could wake up and see that another node is transmitting,
receive a full message, and finally send back an acknowledgement for that
message. The transmitter would see the acknowledgement and stop
transmitting early, so both nodes can perform some high speed transaction
or go back to sleep. Useless preamble bits are minimized while useful
packet information is maximized. Incidentally, this is a good strategy
for CC2420 low power listening. This strategy certainly improves energy
efficiency and throughput, but further improvements may be possible by
employing a synchronous delivery method on top of this type of
asynchronous low power listening scheme.</p>
<p>Improvements can also be made to the original low power listening
interfaces. For example, instead of pre-programming power modes and
duty cycles, a low power listening interface should allow the developer
the flexibility to deploy a network of nodes with whatever duty cycle
percentage or sleep time desired for each individual node. Nodes with
different receive check periods should still have the ability to
reliably communicate with each other with little difficulty.</p>
</div>
</div>
<div class="section">
<h1><a id="interfaces" name="interfaces">3. Interfaces</a></h1>
</div>
<div class="section">
<h1><a id="low-power-listening-interface" name="low-power-listening-interface">3.1 Low Power Listening Interface</a></h1>
<p>The LowPowerListening interface MUST be provided for each radio by the
platform independent ActiveMessageC configuration.</p>
<p>In some implementations, low power listening may have an option to
compile into the radio stack for memory footprint reasons. If low
power listening is not compiled in with the stack, calls to
LowPowerListening MUST be handled by a dummy implementation.</p>
<p>The TEP proposes this LowPowerListening interface::</p>
<pre class="literal-block">
interface LowPowerListening {
command void setLocalSleepInterval(uint16_t sleepIntervalMs);
command uint16_t getLocalSleepInterval();
command void setLocalDutyCycle(uint16_t dutyCycle);
command uint16_t getLocalDutyCycle();
command void setRxSleepInterval(message_t *msg, uint16_t sleepIntervalMs);
command uint16_t getRxSleepInterval(message_t *msg);
command void setRxDutyCycle(message_t *msg, uint16_t dutyCycle);
command uint16_t getRxDutyCycle(message_t *msg);
command uint16_t dutyCycleToSleepInterval(uint16_t dutyCycle);
command uint16_t sleepIntervalToDutyCycle(uint16_t sleepInterval);
}
</pre>
<dl class="docutils">
<dt>setLocalSleepInterval(uint16_t sleepIntervalMs)</dt>
<dd><ul class="first last simple">
<li>Sets the local node?s radio sleep interval, in milliseconds.</li>
</ul>
</dd>
<dt>getLocalSleepInterval()</dt>
<dd><ul class="first last simple">
<li>Retrieves the local node?s sleep interval, in milliseconds. If duty cycle percentage was originally set, it is automatically converted to a sleep interval.</li>
</ul>
</dd>
<dt>setLocalDutyCycle(uint16_t dutyCycle)</dt>
<dd><ul class="first last simple">
<li>Set the local node?s duty cycle percentage, in units of [percentage*100].</li>
</ul>
</dd>
<dt>getLocalDutyCycle()</dt>
<dd><ul class="first last simple">
<li>Retrieves the local node?s duty cycle percentage. If sleep interval in milliseconds was originally set, it is automatically converted to a duty cycle percentage.</li>
</ul>
</dd>
<dt>setRxSleepInterval(message_t *msg, uint16_t sleepIntervalMs)</dt>
<dd><ul class="first last simple">
<li>The given message will soon be sent to a low power receiver. The sleepIntervalMs is the sleep interval of that low power receiver, in milliseconds. When sent, the radio stack will automatically transmit the message so as to be detected by the low power receiver.</li>
</ul>
</dd>
<dt>getRxSleepInterval(message_t *msg)</dt>
<dd><ul class="first last simple">
<li>Retrieves the message destination?s sleep interval. If a duty cycle was originally set for the outgoing message, it is automatically converted to a sleep interval.</li>
</ul>
</dd>
<dt>setRxDutyCycle(message_t *msg, uint16_t dutyCycle)</dt>
<dd><ul class="first last simple">
<li>The given message will soon be sent to a low power receiver. The dutyCycle is the duty cycle percentage, in units of [percentage*100], of that low power receiver. When sent, the radio stack will automatically transmit the message so as to be detected by the low power receiver.</li>
</ul>
</dd>
<dt>getRxDutyCycle(message_t *msg)</dt>
<dd><ul class="first last simple">
<li>Retrieves the message destination?s duty cycle percentage. If a sleep interval was originally set for the outgoing message, it is automatically converted to a duty cycle percentage.</li>
</ul>
</dd>
<dt>dutyCycleToSleepInterval(uint16_t dutyCycle)</dt>
<dd><ul class="first last simple">
<li>Converts the given duty cycle percentage to a sleep interval in milliseconds.</li>
</ul>
</dd>
<dt>sleepIntervalToDutyCycle(uint16_t sleepInterval)</dt>
<dd><ul class="first last simple">
<li>Converts the given sleep interval in milliseconds to a duty cycle percentage.</li>
</ul>
</dd>
</dl>
<div class="section">
<h2><a id="split-control-behaviour" name="split-control-behaviour">3.2 Split Control Behaviour</a></h2>
<p>Low power listening MUST be enabled and disabled through the radio?s
standard SplitControl interface, returning exactly one SplitControl
event upon completion. While the radio is duty cycling, it MUST NOT
alert the application layer each time the radio turns on and off to
perform a receive check or send a message.</p>
</div>
<div class="section">
<h2><a id="send-interface-behaviour" name="send-interface-behaviour">3.3 Send Interface Behaviour</a></h2>
<p>Attempts to send a message before SplitControl.start() has been called
SHOULD return EOFF, signifying the radio has not been enabled. When
SplitControl.start() has been called by the application layer, calls
to Send MUST turn the radio on automatically if the radio is currently
off due to duty cycling. If a message is already in the process of
being sent, multiple calls to Send should return FAIL.</p>
<p>The Send.sendDone(?) event SHOULD signal SUCCESS upon the successful
completion of the message delivery process, regardless if any mote
actually received the message.</p>
</div>
<div class="section">
<h2><a id="receive-interface-behaviour" name="receive-interface-behaviour">3.4 Receive Interface Behaviour</a></h2>
<p>Upon the successful reception of a message, the low power receive event
handler SHOULD drop duplicate messages sent to the broadcast address.
For example, the CC2420 implementation can perform this by checking
the message_t?s dsn value, where each dsn value is identical for every
message used in the delivery.</p>
<p>After the first successful message reception, the receiver?s radio
SHOULD stay on for a brief period of time to allow any further
transactions to occur at high speed. If no subsequent messages are
detected going inbound or outbound after some short delay, the radio
MUST continue duty cycling as configured.</p>
</div>
</div>
<div class="section">
<h1><a id="low-power-listening-message-t-metadata" name="low-power-listening-message-t-metadata">4. Low Power Listening message_t Metadata</a></h1>
<p>To store the extra 16-bit receiver low power listening value, the radio
stack?s message_t footer MUST contain a parameter to store the message
destination?s receive check sleep interval in milliseconds or duty cycle
percentage. For example, the low power listening CC2420 message_t footer
stores the message's receive check interval in milliseconds, as shown
below <a class="citation-reference" href="#tep111" id="id3" name="id3">[TEP111]</a>.:</p>
<pre class="literal-block">
typedef nx_struct cc2420_metadata_t {
nx_uint8_t tx_power;
nx_uint8_t rssi;
nx_uint8_t lqi;
nx_bool crc;
nx_bool ack;
nx_uint16_t time;
nx_uint16_t rxInterval;
} cc2420_metadata_t;
</pre>
</div>
<div class="section">
<h1><a id="recommendations-for-hal-implementation" name="recommendations-for-hal-implementation">5. Recommendations for HAL Implementation</a></h1>
<p>In the interest of minimizing energy while maximizing throughput, it
is RECOMMENDED that any asynchronous low power listening implementation
use clear channel assessment methods to determine the presence of a
nearby transmitter. It is also RECOMMENDED that the transmitter send
duplicate messages continuously with minimum or no backoff period instead
of one long message. Removing backoffs on a continuous send delivery
scheme will allow the channel to be modulated sufficiently for a receiver
to quickly detect; furthermore, enabling acknowledgements on each
outgoing duplicate packet will allow the transmit period to be cut short
based on when the receiver actually receives the message.</p>
<p>Asynchronous low power listening requires some memory overhead, so
sometimes it is better to leave the added architecture out when it is
not required. When it is feasible to do so, it is RECOMMENDED that
the preprocessor variable LOW_POWER_LISTENING be defined when low
power listening functionality is to be compiled in with the radio stack,
and not defined when low power listening functionality shouldn?t exist.</p>
<p>It is RECOMMENDED that the radio on-time for actual receive checks be a
measured value to help approximate the duty cycle percentage.</p>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">6. 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">101 N. Wilmot, Suite 101</div>
<div class="line">Tucson, AZ 85750</div>
<div class="line"><br /></div>
<div class="line">phone - +1 520 519 3138</div>
<div class="line">email ? <a class="reference" href="mailto:dmm@rincon.com">dmm@rincon.com</a></div>
<div class="line"><br /></div>
<div class="line">Jonathan Hui</div>
<div class="line">657 Mission St. Ste. 600</div>
<div class="line">Arched Rock Corporation</div>
<div class="line">San Francisco, CA 94105-4120</div>
<div class="line"><br /></div>
<div class="line">phone - +1 415 692 0828</div>
<div class="line">email - <a class="reference" href="mailto:jhui@archedrock.com">jhui@archedrock.com</a></div>
<div class="line"><br /></div>
<div class="line">Kevin Klues</div>
<div class="line">503 Bryan Hall</div>
<div class="line">Washington University</div>
<div class="line">St. Louis, MO 63130</div>
<div class="line"><br /></div>
<div class="line">phone - +1-314-935-6355</div>
<div class="line">email - <a class="reference" href="mailto:klueska@cs.wustl.edu">klueska@cs.wustl.edu</a></div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">7. Citations</a></h1>
<table class="docutils citation" frame="void" id="mica2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1" name="mica2">[MICA2]</a></td><td>"MICA2 Radio Stack for TinyOS." <a class="reference" href="http://www.tinyos.net/tinyos-1.x/doc/mica2radio/CC1000.html">http://www.tinyos.net/tinyos-1.x/doc/mica2radio/CC1000.html</a></td></tr>
</tbody>
</table>
<table class="docutils citation" frame="void" id="tep111" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id3" name="tep111">[TEP111]</a></td><td>TEP 111: message_t.</td></tr>
</tbody>
</table>
<table class="docutils citation" frame="void" id="cc1000" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id2" name="cc1000">[CC1000]</a></td><td>TI/Chipcon CC1000 Datasheet. <a class="reference" href="http://www.chipcon.com/files/CC1000_Data_Sheet_2_2.pdf">http://www.chipcon.com/files/CC1000_Data_Sheet_2_2.pdf</a></td></tr>
</tbody>
</table>
<table class="docutils citation" frame="void" id="cc2420" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="cc2420">[CC2420]</a></td><td>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>
</div>
</div>
</body>
</html>
--- NEW FILE: tep129.html ---
<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<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/" />
<title>Basic Platform Independent Non-Volatile Storage Layers</title>
<meta name="authors" content="David Moss Junzhao Du Prabal Dutta Deepak Ganesan Kevin Klues Manju Ajay Martin and Gaurav Mathur" />
<style type="text/css">
/*
:Author: David Goodger
:Contact: goodger at users.sourceforge.net
:date: $Date: 2007/08/14 18:58:00 $
:version: $Revision: 1.1 $
:copyright: This stylesheet has been placed in the public domain.
Default cascading style sheet for the HTML output of Docutils.
*/
body {
font-family: Times;
font-size: 16px;
}
.first {
margin-top: 0 ! important }
.last {
margin-bottom: 0 ! important }
.hidden {
display: none }
a.toc-backref {
text-decoration: none ;
color: black }
blockquote.epigraph {
margin: 2em 5em ; }
dd {
margin-bottom: 0.5em }
div.abstract {
margin: 2em 5em }
div.abstract p.topic-title {
font-weight: bold ;
text-align: center }
div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
margin: 2em ;
border: medium outset ;
padding: 1em }
div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
color: red ;
font-weight: bold ;
font-family: sans-serif }
div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
font-weight: bold ;
font-family: sans-serif }
div.dedication {
margin: 2em 5em ;
text-align: center ;
font-style: italic }
div.dedication p.topic-title {
font-weight: bold ;
font-style: normal }
div.figure {
margin-left: 2em }
div.footer, div.header {
font-size: smaller }
div.line-block {
display: block ;
margin-top: 1em ;
margin-bottom: 1em }
div.line-block div.line-block {
margin-top: 0 ;
margin-bottom: 0 ;
margin-left: 1.5em }
div.sidebar {
margin-left: 1em ;
border: medium outset ;
padding: 0em 1em ;
background-color: #ffffee ;
width: 40% ;
float: right ;
clear: right }
div.sidebar p.rubric {
font-family: sans-serif ;
font-size: medium }
div.system-messages {
margin: 5em }
div.system-messages h1 {
color: red }
div.system-message {
border: medium outset ;
padding: 1em }
div.system-message p.system-message-title {
color: red ;
font-weight: bold }
div.topic {
margin: 2em }
h1 {
font-family: Arial, sans-serif;
font-size: 20px;
}
h1.title {
text-align: center;
font-size: 32px;
}
h2 {
font-size: 16px;
font-family: Arial, sans-serif;
}
h2.subtitle {
text-align: center }
h3 {
font-size: 12px;
font-family: Arial, sans-serif;
}
hr {
width: 75% }
ol.simple, ul.simple {
margin-bottom: 1em }
ol.arabic {
list-style: decimal }
ol.loweralpha {
list-style: lower-alpha }
ol.upperalpha {
list-style: upper-alpha }
ol.lowerroman {
list-style: lower-roman }
ol.upperroman {
list-style: upper-roman }
p.attribution {
text-align: right ;
margin-left: 50% }
p.caption {
font-style: italic }
p.credits {
font-style: italic ;
font-size: smaller }
p.label {
white-space: nowrap }
p.rubric {
font-weight: bold ;
font-size: larger ;
color: maroon ;
text-align: center }
p.sidebar-title {
font-family: sans-serif ;
font-weight: bold ;
font-size: larger }
p.sidebar-subtitle {
font-family: sans-serif ;
font-weight: bold }
p.topic-title {
font-weight: bold }
pre.address {
margin-bottom: 0 ;
margin-top: 0 ;
font-family: serif ;
font-size: 100% }
pre.line-block {
font-family: serif ;
font-size: 100% }
pre.literal-block, pre.doctest-block {
margin-left: 2em ;
margin-right: 2em ;
background-color: #eeeeee;
border-color: #000000;
border-width: thin;
font-size: 14px
}
span.classifier {
font-family: sans-serif ;
font-style: oblique }
span.classifier-delimiter {
font-family: sans-serif ;
font-weight: bold }
span.interpreted {
font-family: sans-serif }
span.option {
white-space: nowrap }
span.option-argument {
font-style: italic }
span.pre {
white-space: pre }
span.problematic {
color: red }
table {
margin-top: 0.5em ;
margin-bottom: 0.5em }
table.citation {
border-left: solid thin gray ;
padding-left: 0.5ex }
table.docinfo {
margin: 2em 4em;
}
table.footnote {
border-left: solid thin black ;
padding-left: 0.5ex }
td, th {
padding-left: 0.5em ;
padding-right: 0.5em ;
vertical-align: top }
th.docinfo-name, th.field-name {
font-weight: bold ;
text-align: left ;
white-space: nowrap;
}
h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
font-size: 100% }
tt {}
ul.auto-toc {
list-style-type: none }
</style>
</head>
<body>
<div class="document" id="basic-platform-independent-non-volatile-storage-layers">
<h1 class="title">Basic Platform Independent Non-Volatile Storage Layers</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">129</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Storage Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>DRAFT</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Authors:</th>
<td>David Moss
<br />Junzhao Du
<br />Prabal Dutta
<br />Deepak Ganesan
<br />Kevin Klues
<br />Manju
<br />Ajay Martin
<br />and Gaurav Mathur</td></tr>
</tbody>
</table>
<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
requests discussion and suggestions for improvements. Distribution
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>
<p>The storage abstractions proposed by TEP 103 are implemented on a
platform-dependent basis. A version of BlockStorage, ConfigStorage,
and LogSt