UNIT – 5 SENSOR NETWORK PLATFORMS AND TOOLS

Sensor Node Hardware – Berkeley Motes, Programming

Challenges, Node-level software platforms – TinyOS, nesC,
CONTIKIOS, Node-level Simulators – NS2 and its extension to
sensor networks, COOJA, TOSSIM, Programming beyond
individual nodes – State centric programming.

TABLE OF CONTENTS
5.1 Sensor Node Hardware 5.1
5.2 Berkeley Motes 5.2

5.3 Sensor Network Programming Challenges 5.4

5.4 Node-Level Software Platforms 5.5

5.5 Operating System Design Issues 5.6

5.6 Operating System: TinyOS 5.8

5.7 nesC 5.10

5.8 ContikiOS 5.13

5.9 Node-Level Simulators 5.14

5.10 NS2 and its Extension to Sensor Networks 5.17

5.11 COOJA 5.18

5.12 TOSSIM 5.19

5.13 Programming Beyond Individual Nodes 5.21

5.14 State Centric Programming 5.23

5.1 Sensor Node Hardware

 Sensor node hardware can be grouped into three categories, each of which entails a
different trade-offs in the design choices.

 Augmented general-purpose computers

 Dedicated embedded sensor nodes

 System on-chip (SoC) nodes

5.1.1 Augmented general-purpose computers

 These nodes typically run off-the-shelf operating systems such as WinCE, Linux, or
real-time operating systems and use standard wireless communication protocols such
as IEEE 802.11, Bluetooth, Zigbee etc.
 Because of their relatively higher processing capability, they can accommodate wide
variety of sensors, ranging from simple microphones to more sophisticated video
cameras. It is fully supported for popular programming languages.

 Examples include low-power PCs, embedded PCs (e.g. PC104), custom-designed PCs,
(e.g. Sensoria WINS NG nodes), and various personal digital assistants (PDA).

5.1.2 Dedicated embedded sensor nodes

 These platforms typically use commercial off-the-shelf (COTS) chip sets with
emphasis on small form factor, low power processing and communication, and simple
sensor interfaces.
 AD HOC and Wireless Sensor Networks 5.2

 Because of their COTS CPU, these platforms typically support at least one
programming language, such as C. However, in order to keep the program footprint
small to accommodate their small memory size, programmers of these platforms are
given full access to hardware but rarely any operating system support.

 Examples include the Berkeley mote family, the UCLA Medusa family, Ember nodes and
MIT µAMP. A classical example is the TinyOS platform and its companion programming
language, nesC, mica.

5.1.3 System on-chip (SoC) nodes

 These platforms try to push the hardware limits by fundamentally rethinking the
hardware architecture trade-offs for a sensor node at the chip design level.

 The goal is to find new ways of integrating CMOS, MEMS, and RF technologies to
build extremely low power and small footprint sensor nodes that still provide certain
sensing, computation, and communication capabilities.

 Examples of SoC hardware include smart dust the BWRC picoradio node, and the
PASTA node.

5.2 Berkeley Motes

 Berkeley Mote platform as it is an open hardware/software, smart-sensing platform
with a large user community.

 The Berkeley Mote platform was developed under the Networked Embedded Systems
Technology (NEST) program with the quantitative target of building dependable,
real-time, distributed, embedded applications comprising 100 to 100 000 simple
computing nodes.

 Berkeley motes tiny, self-contained, battery powered computers with radio links,
which enable to communicate and exchange data with one other, and to self- organize
into ad hoc networks.

 Motes form the building blocks of wireless sensor networks.

 The platform consists of four basic components: Power, sensors, computation, and
communication. These motes are autonomous and connectable to other motes.

 The main advantages are small physical size, low cost, modest power consumption,
and diversity in design and usage. The latest versions of the Berkeley Mote include
the MicaZ, Mica2, and Mica2dot processor boards (Fig. 5. 1). The Motes have
 AD HOC and Wireless Sensor Networks 5.3

improvements in memory and radio over predecessors and specifications are

summarised in Table 5.1. The same sensor board can be also used for the MicaZ and
modified for use with the Mica2dot

Figure 5.1 Berkeley Mote processor boards: (a) MicaZ, (b) Mica2, and (c) Mica2dot.
Source : Protocol and Architecture for Wireless Sensor Networks by Holger Karl ,
Andreas willig

Table 5.1 Characteristics of the MicaZ, Mica2, and Mica2dot processor boards

 The Motes have the versatility to connect different Printed Circuit Boards (PCB); that
is, the Motes have the modularity to support different types of sensors. Users can
switch the sensor board or customise it, independent of the other hardware
components. Table 5. 2 provides a description of the sensors that are used on the
respective boards.

 The current sensor board designs for the Mica2 platform includes: MTS101CA,
MTS300CA, MTS310CA, MTS400CA, and MTS420CA
 AD HOC and Wireless Sensor Networks 5.4

Table 5. 2. Description of the available sensor boards

5.3 Sensor Network Programming Challenges

 Traditional programming technologies rely on operating systems to provide abstraction
for processing, I/O, networking, and user interaction hardware. When applying such a
model to programming networked embedded systems, such as sensor networks, the
application programmers need to explicitly deal with message passing, event
synchronization, interrupt handling, and sensor reading.

 As a result, an application is typically implemented as a finite state machine (FSM)

that covers all extreme cases: unreliable communication channels, long delays,
irregular arrival of messages, simultaneous events etc.

 For resource-constrained embedded systems with real-time requirements, several

mechanisms are used in embedded operating systems to reduce code size, improve
response time, and reduce energy consumption.

 The microkernel technologies modularize the operating system so that only the
necessary parts are deployed with the application. Real-time scheduling allocates
resources to more urgent tasks so that they can be finished early.

 Event-driven execution allows the system to fall into low-power sleep mode when no
interesting events need to be processed.

 At the extreme, embedded operating systems tend to expose more hardware controls to
the programmers, who now have to directly face device drivers and scheduling
algorithms, and optimize code at the assembly level.

 Although these techniques may work well for small, stand-alone embedded systems,
they do not scale up for the programming of sensor networks for two reasons:
 AD HOC and Wireless Sensor Networks 5.5

 Sensor networks are large-scale distributed systems, where global properties

are derivable from program execution in a massive number of distributed nodes.
Distributed algorithms themselves are hard to implement, especially when
infrastructure support is limited due to the ad hoc formation of the system and
constrained power, memory, and bandwidth resources.

 As sensor nodes deeply embed into the physical world, a sensor network should
be able to respond to multiple concurrent stimuli at the speed of changes of the
physical phenomena of interest.

 There no single universal design methodology for all applications. Depending on the
specific tasks of a sensor network and the way the sensor nodes are organized, certain
methodologies and platforms may be better choices than others.

 For example, if the network is used for monitoring a small set of phenomena and the
sensor nodes are organized in a simple star topology, then a client-server software
model would be sufficient.

 If the network is used for monitorin g a large area from a single access point (i.e., the
base station), and if user queries can be decoupled into aggregations of sensor readings
from a subset of nodes, then a tree structure that is rooted at the base station is a better
choice. However, if the phenomena to be monitored are moving targets, as in the target
tracking, then neither the simple client-server model nor the tree organization is
optimal. More sophisticated design and methodologies and platforms are required.

5.4 Node-Level Software Platforms

 Most design methodologies for sensor network software are node-centric, where
programmers think in terms of how a node should behave in the environment.

 A node level platform can be node-centric operating system, which provides hardware
and networking abstractions of a sensor node to programmers, or it can be a language
platform, which provides a library of components to programmers.

 A typical operating system abstracts the hardware platform by providing a set of

services for applications, including file management, memory allocation, task
scheduling, peripheral device drivers, and networking.

 For embedded systems, due to their highly specialized applications and limited
resources, their operating systems make different trade-offs when providing these
services.
 AD HOC and Wireless Sensor Networks 5.6

 For example, if there is no file management requirement, then a file system is

obviously not needed. If there is no dynamic memory allocation, then memory
management can be simplified. If prioritization among tasks is critical, then a more
elaborate priority scheduling mechanism may be added.

5.5 Operating System Design Issues

 Traditional operating systems are system software, including programs that manage
computing resources, control peripheral devices, and provide software abstraction to
the application software.

 Traditional OS functions are therefore to manage processes, memory, CPU time, file
system, and devices. This is often implemented in a modular and layered fashion,
including a lower layer of kernels and a higher layer of system libraries.

 Traditional OSs are not suitable for wireless sensor networks because WSNs have
constrained resources and diverse data-centric applications, in addition to a variable
topology.

 Hence, WSNs need a new type of operating system, considering their special
characteristics. There are several issues to consider when designing operating systems
for wireless sensor networks.

 The first issue is process management and scheduling. The traditional OS provides
process protection by allocating a separate memory space (stack) for each process.
Each process maintains data and information in its own space. But this approach
usually causes multiple data copying and context switching between processes. This is
obviously not energy efficient for WSNs. For some real-time applications in WSNs, a
real-time scheduler such as earliest deadline first (EDF) or its variants may be a good
choice, but the number of processes should be confined since that would determine the
time complexity of the EDF scheduler.

 The second issue is memory management. Memory is often allocated exclusively for
each process/task in traditional operating systems, which is helpful for protection and
security of the tasks. Since sensor nodes have small memory, another approach,
sharing, can reduce memory requirements.

 The third issue is the kernel model. The event-driven and finite state machine (FSM)
models have been used to design microkernels for WSNs. The event-driven model
may serve WSNs well because they look like event-driven systems. An event may
comprise receiving a packet, transmitting a packet, detection of an event of interest,
 AD HOC and Wireless Sensor Networks 5.7

alarms about energy depletion of a sensor node, and so on. The FSM-based model is
convenient to realize concurrency, reactivity, and synchronization.

 The fourth issue is the application program interface (API). Sensor nodes need to
provide modular and general APIs for their applications. The APIs should enable
applications access the underlying hardware.

 The fifth issue is code upgrade and reprogramming. Since the behavior of sensor
nodes and their algorithms may need to be adjusted either for their functionality or for
energy conservation, the operating system should be able to reprogram and upgrade.

 Finally, because sensor nodes generally have no external disk, the operating syst em
for WSNs cannot have a file system. These issues should be considered carefully in the
design of WSN OSs and to meet their constrained resources, network behavior, and
data-centric application requirements.

 Sensor operating systems (SOS) should represent the following functions, bearing in
mind the limited resource of sensor nodes:

 Should be compact and small in size since the sensor nodes have very small
memory. The sensor nodes often have memories of only tens or hundreds of
kilobytes.

 Should provide real-time support, since there are real-time applications, especially
when actuators are involved. The information received may become outdated
rather quickly. Therefore, information should be collected and reported as quickly
as possible.

 Should provide efficient resource management mechanisms in order to allocate

microprocessor time and limited memory. The CPU time and limited memory
must be scheduled and allocated for processes carefully to guarantee fairness (or
priority if required).

 Should support reliable and efficient code distribution since the functionality
performed by the sensor nodes may need to be changed after deployment. The
code distribution must keep WSNs running normally and use as little wireless
bandwidth as possible.

 Should support power management, which helps to extend the system lifetime and
improve its performance. For example, the operating system may schedule the
process to sleep when the system is idle, and to wake up with the advent of an
incoming event or an interrupt from the hardware.
 AD HOC and Wireless Sensor Networks 5.8

 Should provide a generic programming interface up to sensor middleware or

application software. This may allow access and control of hardware directly, to
optimize system performance.

5.6 Operating System: TinyOS

 The design of TinyOS allows application software to access hardware directly when
required. TinyOS is a tiny micro threaded OS that attempts to address two issues:

 How to guarantee concurrent data flows among hardware devices, and

 How to provide modularized components with little processing and storage

overhead.

 These issues are important since TinyOS is required to manage hardware capabilities
and resources effectively while supporting concurrent operation in an efficient manner.

 TinyOS uses an event-based model to support high levels of concurrent application in

a very small amount of memory. Compared with a stack-based threaded approach,
which would require that stack space be reserved for each execution context, and
because the switching rate of execution context is slower than in an event-based
approach, TinyOS achieves higher throughput.

 It can rapidly create tasks associated with an event, with no blocking or polling. When
CPU is idle, the process is maintained in a sleep state to conserve energy. TinyOS
includes a tiny scheduler and a set of components. The scheduler schedules operation
of those components.

 Each component consists of four parts: command handlers, event handlers, an

encapsulated fixed-size frame, and a group of tasks

 Commands and tasks are executed in the context of the frame and operate on its state.
Each component will declare its commands and events to enable modularity and easy
interaction with other components.

 The current task scheduler in TinyOS is a simple FIFO mechanism whose scheduling
data structure is very small, but it is power efficient since it allows a processor to sleep
when the task queue is empty and while the peripheral devices are still running. The
frame is fixed in size and is assigned statically. It specifies the memory requirements
of a component at compile time and removes the overhead from dynamic assignment.
Commands are non-blocking requests made to the low-level components. Therefore,
commands do not have to wait a long time to be executed.
 AD HOC and Wireless Sensor Networks 5.9

 A command provides feedback by returning status indicating whether it was 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.

 The occurrence of a hardware event will invoke event handlers. An event handler can
store information in its frame, assign tasks, and issue high-level events or call low-
level commands. Both commands and events can be used to perform a small and
usually fixed amount of work as well as to pre-empt tasks.

 Tasks are a major part of components. Like events, tasks can call low-level commands,
issue high-level events, and assign other tasks. Through groups of tasks, TinyOS can
realize arbitrary computation in an event-based model.

 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.2.

 This WNS operating system defines three type of components:

 Hardware abstractions

 Synthetic hardware

 High-level software components

 Hardware abstraction components are the lowest-level components. They are

actually the mapping of physical hardware such as I/O devices, a radio transceiver, and
sensors. Each component is mapped to a certain hardware abstraction.

 Synthetic hardware components are used to map the behavior of advanced hardware
and often sit on the hardware abstraction components. TinyOS designs a hardware
abstract component called the radio-frequency module (RFM) for the radio transceiver,
and a synthetic hardware component called radio byte, which handles data into or out
of the underlying RFM.

 Higher-level components encapsulate software functionality, but with a similar

abstraction. They provide commands, signal events, and have internal handlers, task
threads, and state variables
 AD HOC and Wireless Sensor Networks 5.10

Figure 5.2 TinyOS Architecture

Source : Protocol and Architecture for Wireless Sensor Networks by Holger Karl ,
Andreas willig

 An evaluation of TinyOS shows that it achieves the following performance gains or

advantages:

 It requires very little code and a small amount of data.

 Events are propagated quickly and the rate of posting a task and switching the
corresponding context is very high.

 It enjoys efficient modularity.

5.7 nesC
 nesC is a component-based, event-driven programming language used to build
applications for the TinyOS platform. TinyOS is an operating environment designed to
run on embedded devices used in distributed wireless sensor networks.

 The name nesC is an abbreviation of "network embedded systems C". nesC is an

extension of C.

 nesC programs are subject to whole program analysis (for safety) and optimization (for
performance). Therefore we do not consider separate compilation in nesC’s design.
The limited program size on motes makes this approach tractable.

 nesC is a “static language”. There is no dynamic memory allocation and the call-graph
is fully known at compile-time. These restrictions make whole program analysis and
optimization significantly simpler and more accurate. nesC’s component model and
parameterized interfaces eliminate many needs for dynamic memory allocation and
dynamic dispatch.
 AD HOC and Wireless Sensor Networks 5.11

 nesC is based on the concept of components, and directly supports TinyOS’s event
based concurrency model. Additionally, nesC explicitly addresses the issue of
concurrent access to shared data. In practice, nesC resolved many ambiguities in the
TinyOS concepts of components and concurrency.

Component Specification

 nesC applications are built by writing and assembling components. A component

provides and uses interfaces. These interfaces are the only point of access to the
component. An interface generally models some service (e.g., sending a message) and
is specified by an interface type. Figure 5.3 shows the TimerM component, part of the
TinyOS timer service that provides the StdControl and Timer interfac es and uses a
Clock interface (all shown in Figure 5.4).

Figure 5.3 Specification and graphical depiction of the TimerM component

Source : Protocol and Architecture for Wireless Sensor Networks by Holger Karl ,
Andreas willig

Figure 5.4 Some Interface Types

 AD HOC and Wireless Sensor Networks 5.12

 TimerM provides the logic that maps from a hardware clock (Clock) into TinyOS’s
timer abstraction (Timer).

 Interfaces in nesC are bidirectional. They contain commands and events, both of which
are essentially functions. The providers or an interf ace implement the commands,
while the users implements the events. For instance, the Timer interface (Figure 5.4)
defines start and stop commands and a fired event.

 In Figure 5.3 provided interfaces are shown above the TimerM component and used
interfaces are below; downward-pointing arrows depict commands and upward-
pointing arrows depict events. Although this same interaction between the timer and its
client could have been provided via two separate interfaces (one for start and stop, and
one for fired), grouping these commands and events in the same interface makes the
specification much clearer and helps prevent bugs when wiring components together.

 Split-phase operations are cleanly modelled by placing the command request and event
response in the same interface. Figure 5.4 shows two examples of this.

 The Send interface has the send command and sendDone event of the split-phased
packet send. The ADC interface is similarly used to model split-phase 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.

 A component can provide and use the same interface type (e.g., when interposing a
component between a client and service), or provide the same interface multiple times.
In these cases, the component must give each interface instance a separate name using
the as notation shown for Clk in Figure 5.3.

 The components are also a clean way to abstract the boundary between hardware an d
software. For instance, on one sensor board, the temperature sensor (accessed via a
component named Temp) is mostly in hardware; Temp is a thin layer of software
accessing on-chip hardware registers.

Component Implementation

 There are two types of components in nesC: modules and configurations. Modules
provide application code, implementing one or more interfaces. Configurations are
used to wire other components together, connecting interfaces used by components to
interfaces provided by others.
 AD HOC and Wireless Sensor Networks 5.13

Concurrency and Atomicity

 nesC detects the data races at compile time. Data races occur due to concurrent updates
to shared state. In order to prevent them, a compiler must

 Understand the concurrency model,

 Determine the target of every update

5.8 ContikiOS
 ContikiOS is open source operating system for resource constraint hardware devices
with low power and less memory. It was developed by Adam Dunkels in 2002. This
OS is fully GUI based system requires only 30 KB RO M and 10 KB RAM. It also
provide multitasking feature and have the built in TCP/IP suit.

 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 important hardware
and software features to cope with these constraints.

 Contiki OS is one of the convenient solutions to cope with mentioned constraints to its
flexibility and support of lightweight and low-powered networks.

 Contiki can provide communication over IPv4, IPv6 and Rime Network Stack. Contiki
Network Stack shown in Figure 5.5 gives more details for its structure.

Figure 5.5 Contiki Network Stack

Source : Protocol and Architecture for Wireless Sensor Networks by Holger Karl ,
Andreas willig
 AD HOC and Wireless Sensor Networks 5.14

 Many Contiki systems are severely power-constrained. Battery operated wireless

sensors may need to provide years of unattended operation and with little means to
recharge or replace batteries.

 Contiki provides a set of mechanisms to reduce the power consumption of systems on

which it runs. The default mechanism for attaining low-power operation of the radio is
called ContikiMAC. With ContikiMAC, nodes can be running in low-power mode and
still be able to receive and relay radio messages.

 The Contiki programming model is based on protothreads. A protothread is a memory-

efficient programming abstraction that shares features of both
multithreading and event-driven programming to attain a low memory overhead of
each protothread.

 The kernel invokes the protothread of a process in response to an internal or external

event. Examples of internal events are timers that fire or messages being posted from
other processes. Examples of external events are sensors that trigger or incoming
packets from a radio neighbour.

5.9 Node-Level Simulators

 Node-level design methodologies are usually associated with simulators that simulate
the behavior of a sensor network on a per-node basis. Using simulation, designers can
quickly study the performance (in terms of timing, power, bandwidth, and scalability)
of potential algorithms without implementing them on actual hardware and dealing
with the vagaries of actual physical phenomena. A node-level simulator typically has
the following components:

 Sensor node model: A node in a simulator acts as a software execution platform,

a sensor host, as well as a communication terminal. In order for designers to focus
on the application-level code, a node model typically provides or simulates a
communication protocol stack, sensor behaviours (e.g., sensing noise), and
operating system services. If the nodes are mobile, then the positions and motion
properties of the nodes need to be modelled. If energy characteristics are part of
the design considerations, then the power consumption of the nodes needs to be
modelled.

 Communication model: Depending on the details of modelling, communication

may be captured at different layers. The most elaborate simulators model the
communication media at the physical layer, simulating the RF propagation delay
and collision of simultaneous transmissions. Alternately, the communication may
 AD HOC and Wireless Sensor Networks 5.15

be simulated at the MAC layer or network layer, using, for example, stochastic
processes to represent low-level behaviours.

 Physical environment model: A key element of the environment within a sensor

network operates is the physical phenomenon of interest. The environment can
also be simulated at various levels of details. For example, a moving object in the
physical world may be abstracted into a point signal source. The motion of the
point signal source may be modelled by differential equations or interpolated from
a trajectory profile.

 Statistics and visualization: The simulation results need to be collected for

analysis. Since the goal of a simulation is typically to derive global properties
from the execution of individual nodes, visualizing global behaviours is extremely
important. An ideal visualization tool should allow users to easily observe on
demand the spatial distribution and mobility of the nodes, the connectivity among
nodes, link qualities, end-to-end communication routes and delays, phenomena
and their spatio-temporal dynamics, sensor readings on each node, sensor nodes
states, and node lifetime parameters (e.g., battery power).

 A sensor network simulator simulates the behavior of a subset of the sensor nodes with
respect to time. Depending on how the time is advanced in the simulation, there are
two types of execution models:

 Cycle-Driven Simulation

 Discrete-Event Simulation

5.9.1 Cycle-Driven Simulation

 A cycle-driven (CD) simulation discretizes the continuous notion of real time into
(typically regularly spaced) ticks and simulates the system behavior at these ticks.
At each tick, the physical phenomena are first simu lated, and then all nodes are
checked to see if they have anything to sense, process, or communicate.

 Sensing and computation are assumed to be finished before the next tick. Sending
a packet is also assumed to be completed by then. However, the packet will not be
available for the destination node until next tick. This split-phase communication
is a key mechanism to reduce cyclic dependencies that may occur in cycle-driven
simulations.
 AD HOC and Wireless Sensor Networks 5.16

5.9.2 Discrete-Event Simulation

 A Discrete-Event (DE) simulator assumes that the time is continuous and an event
may occur at any time. As event is 2-tuple with a value and a time stamp indicating
when the event is supposed to be handled. Components in a DE simulation react
to input events and produce output events. In node-level simulators, a component
can be a sensor node, and the events can be communication packets; or a
component can be software module within and the events can be message passing
among these nodes.

 Typically, components are causal, in the sense that if an output event is computed
from an input event, then the time stamp of the output should not be earlier than
that of the input event. Non-causal components require the simulators to be able to
roll back in time, and worse, they may not define a deterministic b ehavior of a
system.

 A DE simulator typically requires a global event queue. All events passing

between nodes or modules are put in the event queue and sorted according to their
chronological order. At each iteration of the simulation, the simulator removes the
first event (the one with earliest time stamp) from the queue and triggers the
component that reacts to that event.

 In terms of timing behaviour, a DE simulator is more accurate than a CD simulator,

and as a consequence, DE simulators run slower. The overhead of ordering all events
and computation, in addition to the values and time stamps of events, usually
dominates the computation time.

 CD simulations usually require less complex components and give faster simulations.
DE simulations are sometimes considered as good as actual implementations, because
of their continuous notion of time and discrete notion of events.

 There are several open source or commercial simulators available. One class of these
simulators comprises extensions of classical network simulators, such as ns-2, J-Sim
(previously known as JavaSim), and GloMoSim/ Qualnet. The focus of these
simulators is on network modelling, protocol stacks, and simulation performance.

 Another class of simulators, sometimes called software-in-the-loop simulators,

incorporate the actual node software into the simulation. For this reason, they are
typically attached to particular hardware platforms and are less portable. Example
include TOSSIM for Berkeley motes.
 AD HOC and Wireless Sensor Networks 5.17

5.10 NS2 and its Extension to Sensor Networks

 The NS-2 (Network Simulator-2) is a well-known network simulator for discrete event
simulation. Simulations are based on a combination of C++ and OTcl.

 NS-2 includes a large number of simulated network protocols and tools used for
simulating transport control protocol (TCP), routing algorithm, multicast protocol over
the wired or wireless (local connection or via satellite connection) networks.

 NS-2 is committed to OSI model simulation, including the behaviour of physical layer
and it is a free open source software and available for free download.

Limitations of NS-2

 It puts some restrictions on the customisation of packet formats, energy models,

MAC protocols, and the sensing hardware models, which limits its flexibility.

 The lack of an application model makes it ineffective in environments that require

interaction between applications and the network protocols.

 It does not run real hardware code.

 It has been built by many developers and contains several inherent known and
unknown bugs.

 It does not scale well for WSNs due to its object-oriented design.

 Using C++ code and OTcl scripts make it difficult to use.

 Actually, NS-2 was not initially designed to simulate wireless sensor network, but a
few research groups had extended NS-2 in order to enable it to support wireless sensor
network simulation, including sensor model, battery model, a small stack, and hybrid
simulation tools.

 It is extensible, but not very scalable because of the split programming model and
object-oriented structure. In addition, because NS-2 can simulate very detailed data
packet close to the exact number of running packets, it is unable to carry out large-
scale network simulation.

 To overcome the above drawbacks the improved NS-3 simulator was developed. NS-3
supports simulation and emulation. It is totally written in C++, while users can use
python scripts to define simulations.
 AD HOC and Wireless Sensor Networks 5.18

 Hence, transferring NS-2 implementation to NS-3 require manual intervention.

Besides the scalability and performance improvements, simulation nodes have the
ability to support multiple radio interfaces and multiple channels.

 Furthermore, NS-3 supports a real-time schedule that makes it possible to interact with
real systems. For example, a real network device can emit and receive NS-3 generated
packets.

5.11 COOJA
 Cooja simulator is the efficient simulate wireless sensor networks. Cooja is the default
simulator of Contiki operating system that helps to simulate the wireless sensor
networks in addition it helps to do the performance evolution.

 Contiki is a light weight operating system that is developed mainly for wireless nodes.
The motes that are developed by the contiki offers many advantages.

 Contiki offers a java based simulator called as cooja which is used to simulate the
wireless sensors. Cooja simulator is more flexible so that many parts of the simulator
is replaceable and extendable. The parts of the simulator like simulated node hardware,
plug-ins and radio medium can be replaceable.

Characteristics of Cooja

 Scalability

 Efficiency

 Extensibility

 Flexibility

 Wireless sensor network has the powerful tool called tool in which it can be simulate
the idea before it is implementing in real time. Contiki Cooja WSN Simulator mainly
used to simulate many wireless scenario.

Contiki Cooja WSN simulator

 Contiki cooja is the best simulator to simulate any wireless sensors with its own
property. For example, if we are designing a wireless sensor network that detects the
earth quake, the sensor has its own property like lifetime, withstand ability, capacity,
etc.
 AD HOC and Wireless Sensor Networks 5.19

 We can design this wireless sensors with the same property in contiki cooja. When
compared to other simulators cooja is developed purely for wireless sensor networks.

 In addition cooja is more flexible to change the properties of a node so that we could
implement our own idea exactly. Wireless sensors play important role in IOT (Internet
of Thins), where contiki Operating system was developed mainly for IOT devices,
cooja is a simulator comes with the Contiki. So we can use the Cooja simulator for
simulating any wireless sensor networks.

5.12 TOSSIM
 TOSSIM (TinyOS Mote Simulator) is an open-source operating system specially
developed for the wireless embedded sensor networks. There are few hardware
platforms available for TinyOS, some commercial and some non-commercial.

 TinyOS release includes a simulator called TOSSI M. It is built especially for Berkeley
Mica Mote platform. TOSSIM is an emulator rather than a simulator, as it runs actual
application code. Simulated application code can be transferred directly to the
platform, but it might not run in a mote as it runs in a simulation due to the simplifying
assumptions in TOSSI M.

 Figure 5.6 shows the working flow of TOSSIM. The TOSSIM architecture is consisted
of five segments: Frames, Components, Models, Services and Events.

 TOSSIM is a very simple but powerful emulator for WSN. Each node can be
evaluated under perfect transmission conditions, and using this emulator can capture
the hidden terminal problems.

 As a specific network emulator, TOSSIM can support thousands of nodes simulation.

This is a very good feature, because it can more accurately simulate the real world
situation. Besides network, TOSSIM can emulate radio models and code executions.
This emulator may be provided more precise simulation result at compone nt levels
because of compiling directly to native codes.
 AD HOC and Wireless Sensor Networks 5.20

Figure 5.6 TOSSIM Architecture

Source : Protocol and Architecture for Wireless Sensor Networks by Holger Karl ,
Andreas willig

 TOSSIM is a bit-level discrete event network emulator built in Python, a high-level

programming language emphasizing code readability, and C++. It can run TOSSI M on
Linux Operating Systems or on Cygwin on Windows.

 TOSSIM also provides open sources and online documents. Developers had set four
requirements for TOSSIM: scalability, completeness, fidelity and bridging.

 To be scalable, a simulator should manage networks of thousands of nodes in a wide

variety of configurations. To achieve this, each node in TOSSIM is connected in a
directed graph where each edge has a probabilistic bit error.

 For completeness, a simulator must capture behavior and interactions of a system at a

wide variety of levels. And for fidelity, a simulator must capture behavior of a network
with a subtle timing of interactions on a mote and between motes. Requirement for
bridging is met as the simulated code runs directly in a real mote.

 The goal of TOSSIM is to study the behavior of TinyOS and its applications rather
than performance metrics of some new protocol. Hence, it has some limitations, for
instance, it does not capture energy consumption. Another drawback of this framework
is that every node must run the same code. Therefore, TOSSIM cannot be used to
evaluate some types of heterogeneous applications.
 AD HOC and Wireless Sensor Networks 5.21

5.13 Programming Beyond Individual Nodes

 Sensor-actuator network systems offer some unique advantages. Dense networks of
distributed sensors can improve perceived signal-to-noise ratio by reducing average
distances from sensor to physical phenomena.
 In-network processing and actuation shorten the feedback chain and improve the
timeliness of observation and response. Untethered network nodes and infrastructure
less mesh network topologies reduce deployment costs. However, the greatest
advantages of networked systems are improved robustness and scalability.
 A decentralized system is inherently more robust against individual node or link
failures because of network redundancy. Decentralized algorithms are also far more
scalable in practical deployment; they might be the only way to achieve the large scales
needed for some applications. Because of decentralized systems spatial coverage and
multiplicity in sensing aspect and modality, the detection, classification, and tracking
of moving, nonlocal, or low-observable events require cross-node collaboration
among sensors.
Target tracking as a motivating example
 Tracking is a canonical problem for sensor networks and essential for many
commercial and military applications such as traffic monitoring, facility security, and
battlefield situational awareness.
 Given a moving point signal source or target in a 2D sensor field, a tracking system’s
goal is to estimate target state histories, such as spatial trajectory, on the basis of sensor
measurements.
 From a tracking expert’s point of view, each sensor node provides a local measurement
useful in estimating the target state. However, in most cases, only a relatively small
subset of sensors contribute significantly to the estimation, owing to sensing-range
limitations. In this case, a good solution is a leader-based tracking scheme, such as
Information-Driven Sensor Querying (IDSQ), to fuse information from only the
sensors that provide high-quality measurements.
 As Figure 5.7 illustrates, at any time instant t, IDSQ designates a single node, located
close to the target, as leader. The leader node fuses these high signal-to-noise ratio
measurements and updates its current target location estimate, referred to as the belief.
 For most sensor types, owing to the physical properties of signal propagation, the
sensors with high signal-to-noise ratio will be within a limited range of the leader node.
So, we can minimize the communication cost and latency for gathering sensor data. 
 AD HOC and Wireless Sensor Networks 5.22

 As the target traverses the sensor field and the belief evolves to follow its motion, the
most “informative” sensors might no longer be those closest to the current leader. A
nearby sensor might then be selected to replace this leader on the basis of the updated
belief and a criterion combining resource constraints with some measure of sensing
utility (such as mutual information). The current leader then hands off the belief to this
sensor, which becomes the next leader at time t + δ, where δ is the communication
delay. The process of sensing, estimation, and leader selection repeats.

Figure 5.7. Collaborative processing in a leader-based object-tracking scenario.

Source : Protocol and Architecture for Wireless Sensor Networks by Holger Karl ,
Andreas willig

 As a vehicle moves through a sensor field, nearby sensors detect it. An elected leader
node aggregates data from the active sensors and migrates the information from node
to node as the vehicle moves.
 The sensor nodes collaborate primarily to improve sensing accuracy, and acceptable
estimation quality might be achieved using only a subset of the sensors.
 One node, the leader, plays a key role in fusing others’ sensor measurements. If no
leader is present, all sensors that form the contour are equally important. Each node
might locally update and repair its observation of a contour section, but the global state
can only be assembled from observations of many nodes along the entire contour.
Hence, System designers must explicitly write code to
 Maintain sensor connectivities in a neighbourhood
 Discover the best node for handoff
 Invite neighbour nodes into the group
 Handle communication delays and failures
 AD HOC and Wireless Sensor Networks 5.23

5.14 State Centric Programming

 Many sensor network applications, such as target tracking (Discussed in previous
section 5.13), are not simply generic distributed programs over an ad hoc network of
energy-constrained nodes.
 Deeply rooted in these applications is the notion of states of physical phenomena and
models of their evolution over space and time. Some of these states may be represented
on a small number of nodes and evolve over time, as in the target tracking problem,
while others may be represented over a large and spatially distributed number of nodes,
as in tracking a temperature contour.
 A distinctive property of physical states, such as location, shape, and motion of
objects, is their continuity in space and time. Their sensing and control is typically
done through sequential state updates. System theories, the basis for most signal and
information processing algorithms, provide abstractions for state updates, such as:
xk+1 = f(xk, uk)
yk = g(xk, uk)
 Where x is the state of a system, u is the system input, y is the output and k is an integer
update index over space and/or time, f is the state update function, and g is the output
or observation function.
 This formulation is broad enough to capture a wide variety of algorithms in sensor
fusion, signal processing, and control (e.g., Kalman filtering, Bayesian estimation,
system identification, feedback control laws, and finite-state automata).
 However, in distributed real-time embedded systems such as sensor networks, the
formulation is not as clean as represented in the above equations. The relationships
among subsystems can be highly complex and dynamic over space and time.
 The following issues must be properly addressed during the design to ensure the
correctness and efficiency of the system.
 Where are the state variables stored?
 Where do the inputs come from?
 Where do the outputs go?
 Where are the functions f and g evaluated?
 How long does the acquisition of input take?
 Are the inputs in uk collected synchronously?
 Do the inputs arrive in the correct order through communication?
 What is the time duration between indices k and k +1? Is it a constant?
 These issues, addressing where and when,
AD HOCrather
andthan how,Sensor
Wireless to perform sensing,
Networks 5.24
computation, and communication, play a central role in the overall system performance.
 However, these ‘non-functional” aspects of computation, related to concurrency,
responsiveness, networking, and resource management, are not well supported by
traditional programming models and languages.
 State-centric programming aims at providing design methodologies and frameworks
that give meaningful abstractions for these issues, so that system designers can continue
to write algorithms on top of an intuitive understanding of where and when th e
operations are performed.
 A collaborative group is such an abstraction. A collaborative group is a se t of entities
that contribute to a state update. These entities can be physical sensor nodes, or they
can be more abstract system components such as virtual sensors or mobile agents
hopping among sensors. These are all referred to as agents.
 Intuitively, a collaboration groups provides two abstractions: its scope to encapsulate
network topologies and its structure to encapsulate communication protocols. The
scope of a group defines the membership of the nodes with respect to the group.
 A software agent that hops among the sensor nodes to track a target is a virtual node,
while a real node is physical sensor. Limiting the scope of a group to a subset of the
entire space of all agents improves scalability.
 Grouping nodes according to some physical attributes rather than node addresses is an
important and distinguishing characteristic of sensor networks. The structure of a group
defines the “roles” each member plays in the group, and thus the flow of data.
 Are all members in the group equal peers?
 Is there a “leader” member in the group that consumes data?
 Do members in the group form a tree with parent and children relations?
 For example, a group may have a leader node that collects certain sensor readings from
all followers. By mapping the leader and the followers onto concrete sensor nodes, one
can effectively define the flow of data from the hosts of followers to the host of the
leader. The notion of roles also shields programmers from addressing individual nodes
either by name or address.
 Furthermore, having multiple members with the same role provides some degree of
redundancy and improves robustness of the application in the presence of node and link
failures.