UNIT 5

ToOLS

S.1, INTRODUCTION
.TinyOS is des1gned to run on small, wireless sensors. Networks of these sensors
have the potential to revolutionize a wide range of disciplines, fields, and
technologies. Recent example uses of these devices include:
Golden Gate Bridge Safety. High-speed accelerometers collect synchronized
structure of San
data on the movement of and oscillations within the
bridge
Francisco'sGolden Gate Bridge. This data allows the maintainers of the
events such as
to easily observe the structural health of the bridge in response to
possible damage after an
high winds or traffic, as well as quickly assess
maintaining miles
earthquake. Being wireless avoids the need for installing and
of wires.
observe seismicevents
4 VolcanicMonitoring. Accelerometers and microphones
Ecuador. Nodes locally
on the Reventador and Tungurahua volcanoes in
location, and report
compare when they observe events to determine their
long-range wireless
aggregate data to a camp several kilometers away using a
link.
systems
&Datacenter Provisioning. Data centers and enterprise computing
regions
require huge amounts of energy, to the point at which they are placed in
that have low power costs. Approximately 50% of the energy in these systems
goes into cooling, in part due to highly conservative cooling systems. By
installing wireless sensors across machine racks, the data center can
automatically sense what areas need cooling and can adjust which computers do
work and generate heat.
 topofthe node has the radio,
5.2| Wireless Sensor Nework Design 4 The 5.3
The bottom, not sensors, and circuitry for the
shown, has the processor
Base station code Gateway code of the Printed
and flash USB connector.
Sensor code
(nesC/TinyOS) (nesC/Tinyos) (Java, C, ..)
part
concerns
Circuit Board (PCB). storage chip. The antenna is
4 Energy
need to be wireless,
domi nat e sensor hardware and
While it is often
small, low-cost, and operate software design. These nodes
poSsible to
panels, periodic battery provide large power
unattended for long periods.
or wall resources,
such as large solar
gateways, doing so to everyreplone acement ,
of hundreds of
power, to small number of
isensors is
Patch of sensors Data sink Gateway Internet
4 Four broad requirements motivate the infeasible.
/Iimited resources: Motes have very design of Tiny OS:
Fig. 5.1. A typical sensor network architecture
Goals of small size, low cost, and limited physical resources, due the
low power
Patches of ultra-low power sensors, running nesC/TinyOS, communicate to oonsist of about a 1-MIPS processor and tens consumption. Current motes
gateway nodes through data sinks. These gateways connect to the larger of kilobytes of storage.
JReactive
Internet. The sheer diversity of sensor network applications means that there are Concurrency: n a typical sensor network application, a node is
many network architectures, but a dominant portion of deployments tend to responsible for sampling aspects of its environment through sensors, perhaps
follow a common one, showm in Figure 5.1 of ultra-low power sensors self manipulating it through actuators, performing local data processing,
organize to form an ad-hoc routing network to one or more data sink nodes. transmitting data, routing data for others, and participating in various
* These sensor sinksare attached to gateways, which are typically a few orders of distributed processing tasks, such as statistical aggregation or feature
magnitude more powerfulthan the sensors: gateways run an embedded form of recognition.
Linux, Windows, or other multitasking operating system. Gateways have an Flexibility: The variation in hardware and applications and the rate of
Internet connection, either through a cell phone network, long-distance innovation require a flexible OS that is both application-specific to reduce
wireless, or wired Ethernet. space and power, and independent of the boundary between hardware and
software.
Antenna Radio Circuitry USB Serial
V Low Power: Demands of size and cost, as well as untethered operation make
low power operation a key goal of mote design. Battery density doubles
roughly every 50 years, which makes power an ongoing challenge.
Sensor Network Programming Challenges:
provide
* Traditional programming technologies rely on operating systems tohardware.
processing, VO, networking, and user interaction
abstraction for
networked embedded systems,
Expånsion Sensors When applying such a model to programming
programmers need to explicitly deal
Such as sensor networks, the application
Connector
synchronization, interrupt handling, and sensor
Fig. 5.2.ATelos sensor produced by
Moteiv With message passing, event
reading.
 Tools

5.4| Wireless Sensor Nework Design Node-Level Software Platforms:

5.5
* As a result, an application is typically implemented as a Finite State Machine at design
(FSM) that covers allextreme cases: unreliable communication channels, long
delays, imegular arrival of messages, simultaneous events etc. methodologies
where programmers think for sensornetworka software are
terms of how
* For resource-constrained embedded systems with real-time requirements,
environment.
node should node-centin ritheo.
behave
several mechanisms are used in embedded operating systems to reduce code A node level
platform can be node-centric
size, improve response time, and reduce energy consumption. hardware and operating system, which provides
n be a networking abstractions of a sensor
4 The microkernel technologies modularize the operating system so that only the language platform, which provides a node to programmers, or it
necessary parts are deployed with the application. Real-time scheduling
programmers. library of components 0
allocates resources to more urgent tasks so that they can be finished early. 4 Atypical operating system abstracts the hardware
* Event-driven execution allows the system to fall into low-power sleep mode of services for platform by providing aset
applications, including
task scheduling, peripheral device file management, memory
when no interesting events need to be processed.
drivers, and networking. allocation.
* At the extreme, embedded operating systems tend to expose more hardware For embedded systems, due to their
highly specialized applications and limited
controls to the programmers, who now have to directly face device drivers and resources, their operating systems make different trade-offs when providing
scheduling algorithms, and optimize code at the assembly level. these services.
4 Although these techniques may work well for small, stand-alone embedded Operating System Design lssues:
systems, they do not scale up for the programming of sensor networks for two
reasons:
& Traditional operating systems are system software, including programs that
manage computing resOurces, control peripheral devices, and provide software
Sensor networks are large-scale distributed systems, where global abstraction to the application software.
properties are derivable from program execution in a massive number of
distributed nodes. Distributed algorithms themselves are hard to implement, Traditional OS functions are therefore to manage processes, memory, CPU
especially when infrastructure support is limited due to the ad hoc formation time, file system, and devices. This is often implemented in a modular and
of the system and constrained power, memory, and bandwidth resources. layered fashion, including a lower layer of kernels and a higher laver of system
libraries.
V As sensor nodes deeply embed into the physical world, a sensor network
wireless sensor networks because WSNs
should be able to respond to multiple concurrent stimuli at the speed of o Traditional OSs are not suitable for
data-centric applications, in addition to
changes of the physical phenomena of interest. have constrained resources and diverse
4 There is no single universal design methodology for allapplications. Depending a variable topology.
type of operating system, considering
their special
on the specific tasks of a sensor network and the way the sensor nodes are * Hence, WSNs need a new consider when designing operating
to
organized, certain methodologies and platforms may be better choices than characteristics. There are several issues
others. systems for wireless sensor networks.
 Wireless Sensor Network Design s.2.
5.6
4 The first issue is process
management and scheduling. The traditional 0s
4
TinyOSis a OPERATING SYSTEM: Tiny0S
lightweight
S.7

Tiny0S operdiffersatingfromsystemostm specifically designed for low-power

for
memory space (stack)
provides process protection by allocating a separate wirelesS sensors.
intomation n its owm space
each process. Each process maintains data and design focuses on other operating systems in that its
than a ultra-low-power operation.
context switching
But this approach usually causes multiple data copying and Rather
between processes. This is obviously not energy
efficient for WSNs. 4
full-fledgedmotesprocessor, Tiny0S is designed for the Small, low-
+ The second issue is memory management. Memory is
often allocated
power
microcontrollers for have. Furthermore, TinyOS has very aggressive
systems and mechanisms
exclusively for each process/task in traditional operating systems, which js saving power.
helpful for protection and security of the tasks. Since sensor nodes
have small + TinyOS makes building sensor network
important services and
abstractions, suchapplas isensing,
cations easier. provides set of
t a
memory, another approach, sharing, can reduce memory requirements.
4 The third issue is the kemel model. The event-driven and Finite State
Machine
and timners. communication, storage,
(FSM) models have been used to design microkernels for WSNs. The event. TinvOS applications and systems, as well as the OS
nesC language. nesC is a Cdialect with features to
itself. are writen in the
driven model may serve WSNs well because they look like event-driven reduce RAM and code size,
systems. An event may comprise receiving a packet, transmitting a packet. enable significant optimizations, and help prevent low-level bugs like
conditions. race
detection of an event of interest, alarms about energy depletion of a sensor
node, and so on. The FSM-based model is convenient to realize concurrency, 4 The design of TinyOS allows application software to access hardware directly
reactivity, and synchronization. when required. Tiny0S is a tiny micro threaded OS that attempts to address two
+ The fourth issue is the Application Program Interface (API). Sensor nodes need issues:
to provide modular and general APIs for their applications. The APIs should How toguarantee concurrent data flows among hardware devices, and
enable applications access the underlying hardware.
V How to provide modularized components with litle processing and storage
j The fifth issue is code upgrade and reprogramming. Since the behavior of overhead.
sensor nodes and their algorithms may need to be adjusted either for their 4 These issues are important since TinyOS is required to manage hardware
in
functionality or for energy conservaion, the operating system should be able to capabilities and resources effectively while supporting concuTent operation
reprogram and upgrade. an efficient manner.
model to support high levels of concurment
fo Finally, because sensor nodes generally have no external disk, the operating * TinyOS uses an event-based
memory. Compared with a stack-based
system for WSNs cannot have a file system. These issues should be considered Pplication in a very small amount of each
require that stack space be reserved for
carefully in the design of WSN OSs and to meet their constrained resources, threaded approach, which would of execution context is slower
network behavior, and data-centric application requirements. switching rate
CXecution context, and because the throughput.
approach, TinyOS achieves higher
han in an event-based
 Tools

Wireless Sensor Network Design This

4 WNS operating
5.8
with no blocking or
system defines
" Hardware abstractionsthree type of
5.9

create tasks associated with an event, polling.

can rapidly
ItWhen CPUis idle, the process is maintained in asleep state to conServe ennergy.

TinyOS includes a tiny scheduler and a set of

components. The scheduler Synthetic hardware components.
schedules operation of those components.
4 Hardware
High-level software components
actually theabstraction components are the
handlers, event handlers an
Each component consists of four parts: command
encapsulated fixed-size frame, and a group of tasks. mapping physical hardwarelowest-level components. They are
of
4 Commands and tasks are executed in the context of the frame and operate on its
transceiver,
abstraction.
and sensors. Each component is such as toVO a devices, a radio
state. Each component will declare its commands and events to
enahla mapped certain hardware
modularity and easy interaction with other components. Synthetic hardware
Components are used to map the behavior of advanced
hardware and often sit on
4 The current task scheduler in TinyOS is a simple FIFO mechanism whose the
scheduling data structure is very small, but it is power efficient since it allows 2 designs a hardware abstract hardware abstraction TinyOS
components.
component
REM) for the radio transceiver, and a called the
Radio-Frequency
Module
processor to sleep when the task queue is empty and while the peripheral synthetic
devices are still running. The frame is fixed in size and is assigned statically. It radiobyte, which handles data into or out of hardware component called
the underlying RFM.
specifies the memory requirements of a component at compile time and &Higher-level components encapsulate
software functionality, but with a
removes the overhead from dynamic assignment. Commands are non-blocking abstraction. They provide commands, signal events, and have intermal similar handlers,
requests made to the low-level components. Therefore, commands do not have task threads, and state variables.
towait a long time to be executed.
4 Acommand provides feedback by returning status indicating whether it was
Main (Scheduler)
successful (e.g., in the case of buffer overrun or of timeout). A command often
stores request parameters into its frame and conditionally assigns a task for later
execution. Application
4 The occurrence of a hardware event will invoke event handlers. An event
Comms Other Libraries
handler can store information in its frame, assign tasks, and issue high-level Sensing
events or call low-level commands. Both commands and events can be used to
perform asmall and usually fixed amount of work as wellas to perform tasks. Hardware Abstractions (ADC, CLOCK,
Tasks are a major part of components. Like events, tasks can call low-level UART, PHOTO, LEDS)
commands, issue. high-level events, and assign other tasks. Through groups of
tasks, TinyOS can realize arbitrary computation in an event-based model. Fig. 5.3. TinyOS Archiecture
The design of components makes it easy to connect various components in the
form of function calls. The architecture of TinyOS shown in Figure 5.3.
 Tools

Wircless Sensor Network Desion S3.1, INTERFACES

5.10 5.11|
4 nesC
Advantages of TinyOS:
data.
componentapplications are built by
access to provides and uses
writing and
* lt requires very little code and a
small amount of
and the rate of posting atask and switching the
the
component. int
An erfaces. assembling
These Interfaces are thecoOmponent
only
s. A
and is interfaceby generally models some service
4 Events are propagated quickly (e.g., sending a point of
message)
corresponding context is very high. * Figure 5.4
shows the TimerM specified interface type.
an
4 Itenjoys efticient
modularity. provides the
StdControl and component, part of the TinyOS timer service that
Timer interfaces and uses a Clock.
53. nesC
module TimerM
programming language used to bu:la provides !
nesC is a component-based, event-driven StdContrl Timer
applications for the TinyOS platform. TimerM interface stdControl:
designed to run on embedded devices mead interface Timer.
& TinyOS is an operating environment HWClock
in distributed wireless sensor networks. uses interface clock as clk:
nesC is
The name nesC is an abbrevjation of "network embedded systems C', }..
an extension of C. Fig. 5.4. Specification and
graphical
interface stdControl { depiction of the TimerM component
4 nesC programs are subject to whole
program analysis (for safety) and
optimization (for performance). Therefore we do not consider separate command result tinit0;
compilation in nesC's design. interface Timer
approach tractable.
4 The limited program size on motes makes this command result tstart (char type, uint32_t interval);
4 nesC is a "static language". There is no dynamic memory allocation and the
command result tstop):
event result t fired);
call-graph is fully known at compile-time.
These restrictions make whole program analysis and optimization significantly interface clock
simpler and more accurate. nesC's component model and parameterized command result t setRate (char interval, char scale),
event result t fire);
interfaces eliminate many needs for dynamic memory allocation and dynamic
dispatch. interface send f
nesC is based on the concept of components, and directly supports Tiny0S's command result_t send (TOS_ Msg *msg, uint l6 tlength):
event result t sendDone (TOS Msg *msg, result tsuccess);
event based concurrency model. Additionally, nesC explicitly addresses the
issue of concurrent access to shared data. }
interface ADC {
4 In practice, nesC resolved many ambiguities in the TinyOS concepts of command result_t getData();
components and concurrency. event result t dataReady (uintl6 tdata);

Fig. 5.5. Some Interface Types

 Tools
|5.12
Wircless Sensor Nerwork Design
(Clock) i
4 TimerM provides the logic that maps from a hardware clock MODULES
5.13
TinyOS's timer abstraction (Timer). There are two
kinds of
& Interfaces in nesC are bidirectional. They contain commands and events ol. configurations can be components: modules and configurations. Modules and
used
of which are essentially functions.
4 The providers or an interface implement the commands, while the usere
larger services or
implementation abstractioint
ns.erch
Thean ge
twoablyty
when combining components
pes into
that looks like C.sections. Module
of
implement the events. For instance, the Timer interface (Figure 5.5) defines
start and stop commands and a fired event.
im pl ement ation component
sections s
consist
differ their
in
of nesC code
A Module code declares variables and
& In Figure 5.5 provided interfaces are shown above the TimerM component and functions, calls functions, and compiles
assembly code. Contigurat
used interfaces are below; downward-pointing arrows depict commands and code, which connects ion implementation sections consist of nesC wiring
upward-pointing arrows depict events. Although this same interaction betuweer components together.
the timer and its client could have been provided via two separate interfaces Configurations the major difference between nesC and C (and
are
(one for start and stop, and one for fired), grouping these commands and events derivatives). All components have two code blocks. The first block other C
signature, and the second block describes its describes its
in the same interface makes the specification much clearer and helps prevent
bugs when wiring components together.
implementation.
module PowerupC{ configuration LedsC {
* Split-phase operations are cleanly modelled by placing the command reauest I/ signature
and event response in the same interface. Figure 5.5 shows two examples of I signature
this.
4 The Send interface has the send command and sendDone event of the split implementation { implementation {
phased packet send. The ADC interface is similarly used to model split-phase Iimplementation Mlimplementation
sensor value reads. The separation of interface type definitions from their use in
components promotes the definition of standard interfaces, making components
more reusable and flexible. Fig. 5.6. The signature and implementation blocks
4 Signature blocks in modules and configurations have the same syntax.
o A component can provide and use the same interface type (e.g., when Interfaces define a set of
Component signatures contain zero or more interfaces.
interposing a component between a client and service), or provide the same or abstraction. For example, there is a Leds
related functions for a service
interface multiple times, In these cases, the component must give each interface interface for being notified when a
interface for controlling node LEDs, a Boot
instance a separate name using the notation as shown for Cik in Figure 5.5. for initializing a component's state.
node has booted, and an Init interface
o The components are also a clean way to abstract the boundary between uses an interface. For
comnponent signature declares whether it provides or
hardware and software. For instance, on one sensor board, the temperature A LEDs on and off uses the
needs to turn a node's
CXample, a component that functions that turns
sensor (accessed viaacomponent named Temp) is mostly in hardware; Temp 1S component that implements the
Leds interface, while the
a thin layer of software accessing on-chip hardware registers. the Leds interface.
them on and offprovides
 Tools

S.14 Wireless Sensor Network Design

Leds Boot
concurrency and AAtomicity:
4 nesC |5.15
detects
to.
the data at
races
updates
PowerupC LedsC MainC
shared state. In ordercompi
to
le time. Data races
occur
Boot Leds Init
Understand the concurpreventrencythem,modela,compiler mustdue to concurrent
Determine the target of every update
Fig. 5.7. PowerupC, LedsC, and MainC
S.4. TOSSIM
4 Triangles are interfaces. Triangles pointing out from a component are interfaces TOSSIM
it uses, while triangles inside a component are interfaces it provides. A solid specially
(TinyOS MoteSimulator) is an open-source operating system
box is a module, while a dashed box is a configuration.
developed for the wireless embedded sensor
hardware plattorms available for networks.
commercial. Tiny0S, some commercial andTheresomeare few
4 A single component can both provide and use interfaces. For example, this is non
the signature for the configuration MainC: TinyOS release includes a simulator called
Berkeley Mica Mote platform.TOSSIM is anTOSSIM. It is built especially for
emulator rather than a
module PowerupC { configuration LedsC{
as it runs actual
application code. Simulated application code can be simulator,
directly to the transferred
platform, but it might not run in a mote as it runs in a
uses interface Boot; provides interface Leds: due to the simplifying assumptions in simulation
uses interface Leds:
TOSSIM.
4 Figure 5.9 shows the working flow of
TOSSIM. The TOSSIM architecture is
consisted of five segments: Frames, Components, Models, Services and
Events.
Fig. 5.8. MainC's signature
TOSSIM is a very simple but powerful emulator for WSN. Each node can be
evaluated under perfect transmission conditions, and using this emulator can
4 MainC is a configuration which implements the boot sequence of a node. It capture the hidden terminal problems.
provides the Boot interface so other components, such as PowerupC, can be & As a specific network emulator, TOSSIM can support thousands of nodes
notified when a node has fully booted. MainC uses the Init interface so it can simulation. This is a very good feature, because it can more accurately simulate
initialize software as needed before finishing the boot sequence. If PowerupC the real world situation. Besides network, TOSSIM can emulate radio models
had state that needed initialization before the system boots, it might provide the and code executions. This emulator may be provided more precise simulation
Init interface. native codes.
result at component levels because of compiling directly to
 Tools

Wireless Sensor Network

Design &For completeness. a 5.17
5.16| system at a wide simulator must
Event Queue behavior of a levels. Andcaptforurefidelity,
variety of behavioar and interactions of a
o Model
between motes.
network with a subtle
timing of simulatoron must capture
Component Graphs Requirement
directly in areal mote. for interactions a mote and
bridging is met as the simulated code runs
The goal of
rather than
TOSSIM is to study the behavior of
Communication performance metrics of some new protocol. TinyOS and its applications
ADC Event Services. limitations, for
instance, it does not capture Hence. has some
APP
drawback of this energy
framework is that every node must run the sameAnother
consumption.
TEMP|PHOTO AM Therefore, TOSSIM cannot be used to evaluate some code.
applications. types of
heterogeneous
CRG

BYTE
S.5. CONTIKIOS
ADC CLOCK RPM & ContikiOS 1s open source operating system for
TOSSIM resource constraint hardware
Implementation devices with low power and less memory. It was developed by Adam Dunkels
in 2002. This OS is fully GUIbased system requires only 30 KBROM
and 10
ADC KB RAM. Italso provide multitasking feature and have the built in TCP/IP suit.
Model
The working environments of the WSNs are often energy-limited. This is one of
the most important constraint for WSNs. Likewise, tiny and simple designs of
the nodes are the other constraints. For this reason, WSNs should have some
Fig. 5.9. TOSSIMArchitecture
important hardware and software features to cope with these constraints.
emulator built in Python, a high Contiki OS is one of the convenient solutions to cope with mentioned
4 TOSSIM is a bit-level discrete event network low-powered
readability, and C++. It can run Çonstraints to its flexibility and support of lightweight and
levelprogramming language emphasizing code
Windows.
TOSSIM on Linux Operating Systems or on Cygwin on networks.
Stack
over IPv4, IPv6 and Rime Network
provides open sources and online documents. Developers had
set Contiki can provide communication structure.
4 TOSSIM also 5.10 gives more details for its
bridging. Contiki Network Stack shown in Figure
four requirements for TOSSIM: scalability,completeness, fidelity and operated
severely power-constrained. Battery
4 To be scalable, a simulator should manage networks of
thousands of nodes in a Many Contiki systems are operation and with
years of unattended
provide
TOSSIM is Wireless sensors may need to
wide variety of configurations. To achieve this, each node in replace batteries.
connected in adirected graph where each edge has a probabilistic bit error. little means to recharge or
 Toots
5.18 Wircless Sensor Network Design

* Contiki provides a set of mechanisms to reduce the power consumption of

power,
bandwidth, and
ementing actual scalhardware
mnlphysical nem on ability)andof potential algorithms 5.19

without
systems on which it runs. The default mechanism for attaining low-power
operation of the radio is called ContikiMAC. With Contiki MAC, nodes can be components: phenomena. A node-level simulator
dealing with the vagaries of actual
running in low-power mode and still be able to receive and relay radio typically has the following
&Sensor node model: A in a
platform, a sensor host, node
messages.
as well as siamulator acts as a software execution
LAYER

Application
PROTOCOL

CoAP/HTTP
designers to focus on the communication terminal. In order for
provides or simulates a application-level code, a node
model typically
communisystemcation protocolIf stack, sensor behaviours
Transport UDP/TCP sensing noise), and operating (e.g.,
Network Layer
Network, Routing IPV6/RPL
nositions and motion properties of theservices.
nodes
the nodes are mobile,
then the
need to be modelled. If
characteristics part of the design
are energy
MACLayer
Adaptation
MAC
6LoWPAN
consumption of the nodes needs to be modelled.considerations, then the power
CSMA A
RDCLayer Duty Cycling ContikiMAC
Commnunication model: Depending on the
may be captured at different layers. The details of modelling, communication
most elaborate
Radio Layer Radio IEEE 802.15.4 communication media at the physical layer, simulating simulators model the
the RF propagation
delay and collision of simultaneous
Fig. 5.10. Contiki Network Stack
transmissions. Alternately, the
communication may be simulated at the MAC layer or network layer, using, for
+ The Contiki programming model is based on protothreads. A protothread is a example, stochastic processes to represent low-level behaviours.
memory efficient programming abstraction that shares features of both 4 Physical environment model: A key element of the environment within a
multithreading and event-driven programming to attain a low memory overhead sensor network operates is the physical phenomenon of interest. The
of each protothread.
environnment can also be simulated at various levels of details. For example, a
* The kernel invokes the protothread of a process in response to an
internàl or moving object in the physical world may be abstracted into a point signal
external event. Examples of internal events are timers that fire or messages
source. The motion of the point signal source may be modelled by differential
being posted from other processes. Examples of external events are sensors that
equations or interpolated from atrajectory profile.
trigger or incoming packets from a radio neighbour.
+ Statistics and isualization: The simulation results need to be collected for
S.6. SIMULATION ENVIRONMENT analysis. Since the goal of a simulation is typically to derive global properties
behaviours is
from the execution of individual nodes, visualizing global
Node-Level Simulators: allow users to easily
extremely important. An ideal visualization tool should the
* Node-level design methodologies are and mobility of the nodes,
usually associated with simulators that Observe on demand the spatial distribution communication routes and
simulate the end-to-end
behavior of a sensor network on a per-node basis. Connectivity among nodes, link qualities,
Using
simulation, designers can quickly study the performance (in terms of spatio-temporal dynamics, sensor readings on cach
timing, delays, phenomena and their battery power).
node lifetime parameters (e.g.,
node, sensor nodes states, and
 fools
DE
5.20
Wircless Sensor Nework Desion 4 A cimulator typically requires a global
between nodes or
5.21
Asensor network simulator simulates
the behavior of a subset of the senso. are put in the event queue. All
modules
order. At each eventof queue and sortedevents
passing
4
time is advanced in the their chronological
nodes with respect to time. Depending on how the according to
simulation, there are two types of cxccution models:
removes the first
event (the one withiteration the simulation,
the simulator
Cycle-Driven Simulation
triggers the component that earliest
reacts to that event. timne stamp) from the gueue and
Diserete-Event Simulation NS2andits Extension to Sensor

Cycle-Driven Simulation:
The NS-2
discrete event
(Network Simulator-2)Networks:
is a
well-known network simulator for
4 ACycle-Driven (CD) simulation discretizes the continuous notion of real time OTcl.
simulation. Simulations are based on a combination of C+t and
into (typically regularly spaced) ticks and simulates the system behavior at NIS-2includes a large number of
these ticks. At each tick, the physical phenomena are first simulated, and then simulated network protocols and tools used for
all nodes are checked to see if they have anything to sense, process, or simulating Transport Control Protocol (TCP), routing algorithm, multicast
communicate. protocol over the wired or wireless (local connection or via satellite
networks. connection)
Sensing and computation are assumed to be finished before the next tick.
A NS-2 is committed to OSI model simulation,
Sending a packet is also assumed to be completed by then. However, the packet including the behaviour of
will not be available for the destination node until next tick. This split-phase physical layer and it is a free open source software and available for free
communication is a key mechanism to reduce cyclic dependencies that may download.
occur in cycle-driven simulations. Limitations of NS-2:
Discrete-Event Simulation: VIt puts some restrictions on the customisation of packet formats, energy
# A Discrete-Event (DE) simulator assumes that the time is continuous and an models, MACprotocols, and the sensing hardware models, which limits its
event may occur at any time. As event is 2-tuple with a value and a time stamp flexibility.
indicating when, the event is supposed to be handled. Components in a DE V The lack of an application model makes it ineffective in environments that
simulation react to input events and produce output events. In node-level require interaction between applications and the network protocols.
simulators, a component can be a sensor node, and the events can be It does not run real hardware code.
communication packets; or a component can be software module within and the
It has been built by many developers and
contains several inherent known
events can be message passing among these nodes.
and unknown bugs.
o Typically, components are causal, in the sense that if an output event is its object-oriented design.
computed from an input event, then the time stamp of the output should not be V It does not scale wellfor WSNs due to
scripts make it dificult to use.
earlier than that of the input event. Non-causal components require the V Using C++ code and OTcl
initially designed to simulate wireless sensor network,
simulators to be able to roll back in time, and worse, they may not define a * Actually, NS-2 was not enable it to support
had extended NS-2 in order to
deterministic behavior of a system. but a few research groups sensor model, battery model, a
simulation, including
Wireless sensor network
stack, and hybrid simulation tools.
small
 Tools

Wireless Sensor Network Design

5.22 Contiki Cooja WSN
4 It is extensible, but not very scalable
because of the split programming model
because NS-2 can simulate very
4 Contiki cooja is the simbestulator: 5.23

and object-oriented structure. In addition.

example, ifsimulweatoarer desiging
to
detailed data packet close to the exact number of running packets,
it is unable to property. For simulate any wireless sensors with its own
detects the a
carry out large scale network
simulation. earthquake,
ability, capacity, ete.
the wireless
sensor has its own property likesensor network that
4 To overcome the above drawbacks the
improved NS-3 simulator Wae lifetime, withstand
& When compared
developed. NS-3supports simulation and emulation. It is totally written in C++ to other
thile users can use python scripts to define
simulations. sensor networks. simulators cooja is developed purely for wireless
. In
4 Hence, transferring NS-2 implementation to NS-3 require manual intervention. addition, cooja 1s more flexible to
Besides the scalability and performance improvements, simulation nodes have could implement or own idea change the properties of a node so that we
IoT (Internet of Things), exactly. Wireless sensors play
the ability to support multiple radio interfaces and multiple channels. where contiki Operating system was important role in
for IoT devices, cooja is a developed mamly
simulator comes with the Contiki.
S.7. CO0JA
simulator isused for simulating any wireless sensor So Cooja
& Cooja simulator is the eficient simulate wireless sensor networks. Cooja is the
networks.
default simulator of Contiki operating system that helps to simulate the wireless S.8. PROGRAMMING BEYOND
NDIVIDUAL NODES
sensor networks in addition it helps to do the performance evolution. & Sensor-actuator network systems offer
some unique advantages. Dense
Contiki is alight weight operating system that is developed mainly for wireless networks of distributed sensors can improve perceived signal-to-noise ratio by
nodes. The motes that are developed by the contiki offers many advantages. reducing average distances from sensor to physical phenomena.
4 Contiki offers a java based simulator called as cooja which is used to simulate In-network processing and actuation shorten the feedback chain and improve
the wireless sensors. Cooja simulator is more flexible so that many parts of the the timeliness of observation and response. Untethered network nodes and
simulator is replaceable and extendable. The parts of the simulator like
infrastructure less mesh network topologies reduce deployment costs. However,
simulated node hardware, plug-ins and radio medium can be replaceable.
the greatest advantages of networked systems are improved robustness and
Characteristics of Cooja: scalability.
Scalability A decentralized system is inherently more robust against individual node or link
/ Eficiency failures because of network redundancy. Decentralized algorithms are also far
achieve
/ Extensibility more scalable in practical deployment; they might be the only way to
applications. Because of decentralized systems
/ Flexibility the large scales needed for some
and modality, the detection,
spatial coverage and multiplicity in sensing aspect
or low-observable events
Wireless sensor network has the powerful tool called tool in which it can be classification, and tracking of moving, nonlocal,
simulate the idea before it is implementing in real time. Contiki Cooja WSN require cross-node collaboration among
sensors.
Simulator mainly used to simulate many wireless scenario.
 Tools

Wireless Sensor Network Design

TWO MARKS 5.25
5.24

State Centric Programming:

simply , What is TinyOs?
OUESTIONS AND ANSWERS
Part - A
such as target tracking are not
Many sensor network applications, energy-constrained Tiny OS is an
an ad hoc network of
generic distributed programs over low-power embedded, component-based operating and
wireless
nodes.
applications is the notion of states of
phvsical (WSNs), smartdust, devices, such as those used in Wi system platform for
reless Sensor Networks
* Deeply rooted in these over space and time. Some of thece automation. ubiquitous comput ing, personal area networks, building
phenomena and models of their evolution over time
smallnumber of nodes and evolve Draw the TinyOS architecture.
states may be represented on a and
be represented over a large
in the target tracking problem, while others may temperature contour.
spatially distributed number of nodes, as in tracking a Main (Scheduler)
as location, shape, and motion of
A distinctive property of physical states, such Application
sensing and control is
objects, is their continuity in space and time. Their Sensing
theories, the basis for Comms
typically done through sequential state updates. Systen Other Litbraries
abstractions for Hardware Abstractions (ADC, CLOCK, UART,
most signal and information processing algorithms, provide
state updates, such as:
PHOTO, LEDS)
3. Define nesC.
nesC is a component-based, event-driven programming
language used to build
applications for the TinyOS platform. TinyOS is an operating environment
4 Wherex is the state of a system, u is the system input, y is the output and k is designed to run on embedded devices used in distributed wireless
function. sensor
an integer update index over space and/or time, f is the state update networks.
and g is the output or observation function. The name nesC is an abbreviation ofnetwork embedded systems C*. nesC
is
4 This formulation is broad enough to capture a wide variety of algorithms in an extension of C.
sensor fusion, signal processing, and control (e.g., Kalman filtering, Bayesian V nesC programs are subject to whole program analysis (for safety) and
estimation, system identification, feedback control laws, and finite-state
optimization (for performance). Therefore we do not consider separate
automata). compilation in nesC's design. The limited program size on motes makes this
4 However, in distributed real-time embedded systems such as sensor networks, approach tractable.
the formulation is not as clean as represented in the above equations. The
4. List the components used in nesC.
relationships among subsystems can be highly complex and dynamic over space
and time. Ihere are two types of components in nesC depending on how they are
implemented: modules and configurations.
4 State-centric programming aims at providing design methodologies and
C-like syntax).
frameworks that give meaningful abstractions for these issues, so that system Y Modules are implemented by application code (written in a
designers can continue to write algorithms on top of an intuitive understanding connecting interfaces of existing
Y Configurations are implemented by
of where and when the operations are performed.
components.
 Tools
Wireless Sensor Nerhwork Desipy
5.26 10. What is timer 5.27

What is TOSSIM
simulator? The Timer has an
component in Tiny0S?
$.
for TinyOS applications running On one or init) method that
VTOSSIM is a dedicated simulator
enabled and initializes
disabled via the start and stop calls. its internmal flag, and it can be
more Berkeley motes.
building TOSSIM were to make it scalable + Start Stop
AK SimeroFire
1fFire
Timer
The kev design decisions on
to use the actual
network of potentially thousands of nodes, and to be able
software code in the simulation.
6 Draw the Contiki architecture.
operating system for small
Contiki is a popular embedded open-source TIMER
microcontroller architectures.
Internal state: evenFlag
User apps Built-in apps SetRate
ulPv6 Fire
Socket-like AP!
UDP|TCPICMP Contiki OS
IPV6 LoWPAN

Rime (MAC)
REVIEW QUESTIONS
Platform CPU

Hardware drivers 1. What are the programming challenges of sensor network tools?
2. Explain the following (i) Tiny OS (ii) nesC in detail.
7. Whatis Cooja simulator? 3. Describe about the CONTIKIOS simulator.
use peripheral
A system that typically enables the host system to run software or
enabling your laptop to run the 4. Explain about the following () CO0JA (i) TOSSIM.
devices designed for the guest system: e.g. Cooja
RPL protocol, LIBP and/or other IoT protocols of interest. 5. Explain the node level simulator with example.
List the various commercial simulator used in WSN. CONTIKIOS for WSN.
8. 6. Outline the features of TinyOS and
as ns-2,
There are several open-source or commercial simulators available such
J-Sim (previously known as JavaSim), and GloMoSim/QualNet.
9. List the types of codes used in nesC.
In nesC, code can be classified into two types:
Asynchronous code (AC): Code that is reachable from at least one interrupt
handler.
V Synchronous code (S): Code that is only reachable from tasks.