nido.tex

无线通信的主要编程软件,是无线通信工作人员的必备工具,关天相关教程我会在后续传上.

\documentclass[10pt,fleqn]{article}

\usepackage{graphicx}
\usepackage{graphics}
\usepackage{multicol}
\usepackage{epsfig,amsmath,amsfonts}
\usepackage{xspace}
\usepackage{url}
\usepackage{subfigure}

\makeatletter                                   % Make '@' accessible. 
\oddsidemargin=0in                              % Left margin minus 1 inch.
\evensidemargin=0in                             % Same for even-numbered pages.
\marginparsep=0pt                               % Space between margin & text

\renewcommand{\baselinestretch}{1.2}              % Double spacing

\textwidth=6.5in                                % Text width (8.5in - margins).
\textheight=9in                                 % Body height (incl. footnotes)

\topmargin=0in                                  % Top margin minus 1 inch.
\headsep=0.0in                                  % Distance from header to body.
\skip\footins=4ex                               % Space above first footnote.
\hbadness=10000                                 % No "underfull hbox" messages.
\makeatother                                    % Make '@' special again.

\def\sim{TOSSIM\xspace}
\def\tinyviz{TinyViz\xspace}
\def\mote{mote\xspace}
\def\motes{motes\xspace}
\def\Mote{Mote\xspace}
\def\Motes{Motes\xspace}

\begin{document}

\fontfamily{cmss}                               % Make text sans serif.
\fontseries{m}                                  % Medium spacing.
\fontshape{n}                                   % Normal: not bold, etc.
\fontsize{10}{10}                               % 10pt font, 10pt line spacing 

\title{\vspace{2.5in}\sim: A Simulator for TinyOS Networks}
\author{Philip Levis and Nelson Lee\\ [e-mail]}

\maketitle
\vspace{2in}
\begin{center}
Version 1.0\\
June 26, 2003
\end{center}
\newpage

\fontfamily{cmr}                                % Make text Roman (serif).
\fontseries{m}                                  % Medium spacing.
\fontshape{n}                                   % Normal: not bold, etc.
\fontsize{10}{10}                               % 10pt font, 10pt line spacing

\tableofcontents

\section{Introduction}

\sim is a discrete event simulator for TinyOS sensor
networks. Instead of compiling a TinyOS application for a mote, users
can compile it into the \sim framework, which runs on a PC. This
allows users to debug, test, and analyze algorithms in a controlled
and repeatable environment. As \sim runs on a PC, users can examine
their TinyOS code using debuggers and other development tools. This
document briefly describes the design philosophy of
\sim, its capabilities, its structure. It also provides a brief
tutorial on how to use \sim for testing or analysis.

\sim's primary goal is to provide a high fidelity simulation of TinyOS
applications. For this reason, it focuses on simulating TinyOS and its
execution, rather than simulating the real world. While \sim can be
used to understand the causes of behavior observed in the real world,
it does not capture all of them, and should not be used for absolute
evaluations.

\sim is not always the right simulation solution; like any
simulation, it makes several assumptions, focusing on making some
behaviors accurate while simplying others. One of the most common
questions about \sim is whether it can ``simulate X'' or whether it
``has an accurate X model.'' In hope of answering most of such
questions, here is a brief summmary of its characteristics:

\begin{itemize}

\item{\bf Fidelity:} By default, \sim captures TinyOS' behavior at a
very low level. It simulates the network at the bit level, simulates
each individual ADC capture, and every interrupt in the system.

\item{\bf Time:} While \sim precisely times interrupts (allowing
things like bit-level radio simulation), it does not model execution
time. From \sim's perspective, a piece of code runs
instantaneously. Time is kept at a 4MHz granularity (the CPU clock
rate of the rene and mica platforms). This also means that spin locks
or task spin locks will never exit: as the code runs instantaneously,
the event that would allow the spin to stop will not occur until the
code completes (never).

\item{\bf Models:} \sim itself does not model the real world. Instead,
it provides abstractions of certain real-world phenomena (such as bit
error). With tools outside the simulation itself, users can then
manipulate these abstractions to implement whatever models they want
to use. By making complex models exterior to the simulation, \sim
remains flexible to the needs of many users without trying to
establish what is ``correct.'' Additionally, it keeps the simulation
simple and efficient.

\begin{itemize}
\item{\bf Radio:} \sim does not model radio propagation;
instead, it provides a radio abstraction of directed independent bit
errors between two nodes. An external program can provide a desired
radio model and map it to these bit errors. Having directed bit error
rates means that asymmetric links can be easily modeled. Independent
bit errors mean longer packets have a higher probability of
corruption, and each packet's loss probability is independent.

\item{\bf Power/Energy:} \sim does not model power draw or energy
consumption. However, it is very simple to add annotations to
components that consume power to provide information on when their
power states change (e.g., turned on or off). After a simulation is
run, a user can apply a energy or power model to these transitions,
calculating overall energy consumption. Because \sim does not model
CPU execution time, it cannot easily provide accurate information for
calculating CPU energy consumption.
\end{itemize}

\item{\bf Building:} \sim builds directly from TinyOS code. To simulate
a protocol or system, you must write a TinyOS implementation of it. On
one hand, this is often more difficult than an abstract simulation; on
the other, it means you can then take your implementation and run it
on actual motes.

\item{\bf Imperfections:} Although \sim captures TinyOS
behavior at a very low level, it makes several simplifying
assumptions. This means that it is very possible that code which runs
in a simulation might not run on a real mote. For example, in \sim
interrupts are non-preemptive (a result of being a discrete event
simulator). On a real mote, an interrupt can fire while other code is
running. If pre-emption can put a mote in an unrecoverable state, then
simulated motes will run without mishap while real-world motes may
fail. Also, if interrupt handlers run too long, a real-world mote may
crash; as code in \sim runs instantaneously, no problems will appear
in simulation. 

\item{\bf Networking:} Currently, \sim simulates the 40Kbit RFM mica
networking stack, including the MAC, encoding, timing, and synchronous
acknowledgements. It does not simulate the mica2 ChipCon CC1000 stack.
We are waiting to have a better understanding of the behavior of
CC1000 before writing a simulation implementation.

\item{\bf Authority:} Initial experience from real-world deployments has shown
that TinyOS networks have very complex and highly variable behavior.
While \sim is useful to get a sense of how algorithms perform in
comparison to one another, \sim results shouldn't be considered
authoritative. For example, \sim can tell you that one algorithm
behaves better than another under high loss, but the question remains
as to whether the specified loss scenario has any basis in the real
world. \sim should not be considered an end-point of evaluation;
instead, it is a system that allows the user to separate out
environmental noise to better understand algortithms.

\end{itemize}

\section{Compiling and Running a Simulation}

\sim is automatically built when you compile an
application. Applications are compiled by entering an application
directory (e.g. {\tt /apps/Blink}) and typing {\tt
make}. Alternatively, when in an application directory, you can type
{\tt make pc}, which will only compile a simulation of the
application.

There are several compilation options to {\tt ncc} when compiling for
TOSSIM, including the maximum number of motes that can be
simulated. The default options in the TinyOS 1.1 makefile should fit
almost any need; refer to the nesC manual for further information on
the options available.

The \sim executable is named {\tt main.exe}, and resides in {\tt
build/pc}. It has the following usage:

\begin{verbatim}
Usage: ./build/pc/main.exe [options] num_nodes
  [options] are:
  -h, --help        Display this message.
  -gui              pauses simulation waiting for GUI to connect
  -a=<model>        specifies ADC model (generic is default)
                    options: generic random
  -b=<sec>          motes boot over first <sec> seconds (default: 10)
  -ef=<file>        use <file> for eeprom; otherwise anonymous file is used
  -l=<scale>        run sim at <scale> times real time (fp constant)
  -r=<model>        specifies a radio model (simple is default)
                    options: simple static lossy
  -rf=<file>        specifies file input for lossy model (lossy.nss is default)
  -s=<num>          only boot <num> of nodes
  -t=<sec>          run simulation for <sec> virtual seconds
  num_nodes         number of nodes to simulate
\end{verbatim}

The {\tt -h} or {\tt --help} options prints out the above usage
message, and some additional information.

The {\tt -a} option specifies the ADC model to use. \sim currently
supports two models: generic and random. Section~\ref{sec:adc}
describes these models.

The {\tt -b} option specifies the interval over which motes
boot. Their boot times are uniformly distributed over this
interval. The default value is ten seconds.

The {\tt -e} option is for named EEPROM files. If {\tt -e} isn't
specified, the logger component stores and reads data, but this data
is not persistent across simulator invocations: it uses an anonymous
file. Section~\ref{sec:eeprom} describes how the EEPROM in \sim works.

The {\tt -l} option is for making \sim run at a rate representative of
real time. The {\tt scale} argument specifies what relative rate
should be used. For example, {\tt -l=2.0} means twice as fast as real
time (two virtual seconds run in one real second), while {\tt -l=0.1}
means one tenth of real time (one virtual seconds runs in ten real
seconds.). \sim can only run so fast; specifying it to run faster than
it can will cause it to run as quickly as possible. Using this option
imposes a significant performance overhead; it shouldn't be used when
trying to run simulations quickly.

The {\tt -r} option specifies the radio model to use. \sim currently
supports two models: simple and lossy. Earlier versions also supported
a ``static'' model, but this has been subsumed by the lossy
model. Section~\ref{sec:radio} describes these models

The {\tt -s} option tells \sim to only boot a subset of the number of
nodes specified. This is useful if you want some to boot later, in
response to user input. If the {\tt -s} option is specified, \sim
boots mote IDs 0-{\tt (num - 1)}.

The {\tt -t} option tells \sim to run for a specified number of
virtual seconds. After {\tt sec} seconds have passed, \sim exits cleanly.

The {\tt num\_nodes} option specifies how many nodes should be
simulated. A compile-time upper bound is specified in {\tt
/apps/Makerules}. The standard TinyOS distribution sets this value to
be 1000. By default, all {\tt num\_nodes} boot in the first ten
seconds of simulation, with bootup times uniformly distributed.

\sim catches SIGINT (control-C) to exit cleanly. This is useful when
profiling code.

\subsection{dbg}

\sim provides configuration of debugging output at run-time. Much of the
TinyOS source contains debugging statements. Each debugging statement
is accompanied by one or more modal flags. When the simulator starts,
it reads in the DBG environment variable to determine which modes
should be enabled. Modes are stored and processed as entries in a
bit-mask, so a single output can be enabled for multiple modes, and a
user can specify multiple modes to be displayed. The set of DBG modes
recognized by \sim can be identified by using the {\tt -h} option; all
available modes are printed. The current modes are:

\scriptsize