Ad hoc and Wireless Sensor Networks 1

Unit 5
Sensor Network Platforms and Tools
Introduction 2

Wireless sensor networks (WSN) consists of group of sensor nodes to perform distributed
sensing task using wireless medium.
Characteristics
- low-cost, low-power, lightweight
- densely deployed
- prone to failures
- two ways of deployment: randomly, pre-determined or engineered
Objectives
- Monitor activities
- Gather and fuse information
- Communicate with global data processing unit
Introduction 3

Recent sensor networks research involves almost all the layers and can be
categorized into the following three aspects:

Energy Efficiency

• small devices, limited amount of energy, essential to prolong system lifetime

Scalability

• deployment of thousands of sensor nodes, low-cost

Locality

• smallest networks cannot depend on having global states

 4
WSN Architecture
 5
Functional Block Diagram of Sensor Node
General WSN System Architecture 6

The components of a sensor node

General WSN System Architecture 7

• Constructing a platform for WSN falls into the area of embedded system development
usually consists of developing environment.

• Hardware and Software platforms.

1. Hardware Platform
Consists of the following four components:

a) Processing Unit - Associates with small storage unit (tens of kilo bytes order) and manages the
procedures to collaborate with other nodes to carry out the assigned sensing task

b) Transceiver Unit - Connects the node to the network via various possible transmission medias
such as infra, light, radio and so on.
General WSN System Architecture 8

c) Power Unit
Supplies power to the system by small size batteries which makes the energy a scarce
resource.

d) Sensing Units
Usually composed of two subunits:
• Sensors
• Analog-to-digital Converters (ADCs).

e) Other Application Dependent Components

• Location finding system is needed to determine the location of sensor nodes with high
accuracy
• Mobilizer may be needed to move sensor nodes when it is required to carry out the task.
General WSN System Architecture 9

2. Software Platform
a) Embedded Operating System (EOS)
 Manages the hardware capability efficiently as well as supports concurrency-
intense operations.
 Apart from traditional OS tasks such as processor, memory and I/O
management, it must be
real-time to rapidly responding hardware triggered events.
 Multi-threading to handle concurrent flows.

b) Application Programming Interface (API)

 A series of functions provided by OS and other system-level components for
assisting developers to build applications upon itself.
General WSN System Architecture 10

c) Device Drivers
 A series of routines that determine how the upper layer entities communicate
with the peripheral devices.

d) Hardware Abstract Layer (HAL)

 Intermediate layer between the hardware and the OS.
 Provides uniform interfaces to the upper layer while its implementation is highly
dependent on the lower layer hardware.
 With the use of HAL, the OS and applications easily transplant from one
hardware platform to another.
General WSN System Architecture 11

d) Hardware Abstract Layer (HAL)

General WSN System Architecture 12

3.System Development Environment

Provides various tools for every stage of software development over the specific
hardware platform.
a) Cross-Platform Development
Generally, an embedded system unlike PC does not have the ability of self-
development.
The final binary code run on that system, termed as target system, will be
generated on the PC, termed as host system, by cross-platform compilers and
linkers, and download the resulted image via the communication port onto the
target system.
General WSN System Architecture 13

b) Debug Techniques
Due to the difficulties introduced by cross-platform development mode, the debug
techniques become critical for the efficiency of software production.
Sensor Node Architecture 14

• A real-world sensor network application has to incorporate all elements subject

to energy, bandwidth, computation, storage, and real-time constraints.

• This makes sensor network application development quite different from

traditional distributed system development or database programming.

• A sensor network application can assume an always-on infrastructure that

provides reliable services such as optimal routing, global directories, or service
discovery.

• There are two types of programming for sensor networks, those carried out by
end users and those performed by application developers.
Sensor Node Architecture 15
• An end user may view a sensor network as a pool of data and interact with the network
via queries.

• An application developer must provide end users of a sensor network with the
capabilities of data acquisition, processing, and storage.

• A typical sensor node hardware contains a general purpose CPU and working memory,
long-term stable storage such as flash memory or disk and I/O capabilities to support
sensors.

• Sensor nodes have evolved into two broad categories:

– Small devices with 8-bit microcontrollers as CPUs, 10–100 KB of working memory and
100–1000 KB of flash secondary storage
– Larger devices with 32-bit CPUs, megabytes each of working memory and secondary
storage
Small Devices (Berkeley Notes) 16
• The Berkeley motes are a family of embedded sensor nodes sharing roughly the
same architecture.

• The MICA motes have a two-CPU design. The main microcontroller (MCU), an
Atmel ATmega103L takes care of regular processing.

• A separate and less capable coprocessor is only active when the MCU is being
reprogrammed.

• The ATmega103L MCU has integrated 512 KB flash memory and 4 KB of data
memory.

• In addition to that, a MICA mote also has a separate 512 KB flash memory unit
for holding data.
 17
MICA Mote Architecture
 18
MICA Mote Architecture
• Since the connection between the MCU and this external memory is via a low-
speed serial peripheral interface (SPI) protocol, the external memory is more
suited for storing data than for storing programs.

• The RF communication on MICA motes uses the TR1000 chip set operating at
916 MHz band.

• It can achieve a maximum of 50 kbps raw data rate. MICA motes implement a
40 kbps transmission rate.

• The maximum transmission range is about 300 feet in open space.

• MICA motes support a 51 pin I/O extension connector. Sensors, actuators, serial
I/O boards, or parallel I/O boards can be connected via the connector
 19
MICA Mote Architecture
• A sensor/actuator board can host a temperature sensor, a light sensor, an
accelerometer etc.

• The serial I/O connection allows the mote to communicate with a PC in real
time.

• The parallel connection is primarily for downloading programs to the mote.

• A radio transmission bears the maximum power consumption.

• However, each radio packet (e.g., 30 bytes) only takes 4 ms to send, while
listening to incoming packets turns the radio receiver ON all the time.

• There are huge differences among the power consumption levels in active
mode, idle mode and suspend mode of the MCU.
Large Devices 20
• The larger class of devices is exemplified by products such as Stargate designed
by Intel and Cerfcube from Intrinsyc.

• These devices are used in a variety of embedded applications.

• In the sensor network, they are used as gateways to a collection of motes, or for
applications that require heavier-duty signal processing.

• Each such device employs an X-Scale or ARM-based processor which has 64MB
working memory and 1GB flash-based secondary storage.

• They support many connectivity options including USB, IEEE 802.11 wireless and
a 51-pin mote connector allowing use of a mote and its radio.
Programming Challenges 21
• A sensor network differs from traditional computing environments in various
aspects, thereby insisting programming frameworks and tools required for a
sensor network.

• Specifically, the following characteristics affect the design of sensor network

programming tools:

• Reliability

• Resource Utilization

• Scalability

• Data Centric Networks

Reliability 22
• Wireless sensor networks are more unreliable than other distributed systems.

• Therefore, sensor networks are built to adapt to changing dynamics and node
& link errors such that network continues to serve until the network fails.

• While many faults in a network will never be noticed by application, resilience to

failures and topology changes should be supported by a programming
environment.
Resource Constraints 23
• Wireless sensor networks are very resource-constrained which affects the
programming approach, maximum code size and other aspects of application
development.

• Energy efficiency is particularly critical in WSNs and penetrates every aspect of

sensor network design from duty cycles to routing protocols.

• Therefore, programming tools and models should be developed to exploit

energy-saving techniques and approaches.
Scalability 24
• Sensor networks can scale up to hundreds and thousands of sensor nodes.

• Therefore programming models should support developers in designing

applications and software for large-scale and heterogeneous networks.

• Manual configuration, maintenance and repair of individual sensor nodes will

be infeasible due to the large number of devices, therefore insisting support for
self-management and self-configuration.

• The scale of a network can also be addressed by using programming models

that consider entire network as a single entity instead of focusing on each
individual device.
Data Centric Networks 25

• In many wireless sensor networks, not only are the individual sensor nodes of interest, but
also the data they generate and disseminate.

• Sensor network applications obtain useful information in a timely fashion. Many

applications are only concerned with the collection of data at a central point.

• For example, a server that stores, analyzes, or visualizes the sensor data.

• Other applications require immediate processing and analysis of data within the network
to eliminate redundant information, to aggregate data from multiple sensors etc.

• Each category will require different programming models so that programming a

network results in generating distributed algorithms to work across many nodes in an
efficient manner.
Node Level Software Platforms 26
• The following are the node level software platforms used in wireless sensor
networks –

• TinyOS

• NesC

• Sensor Network Application Construction Kit (Snack)

• Thread Based Model

Introduction – TinyOS 27

What is TinyOS?
• Free, open-source OS designed for low-power embedded distributed wireless
devices used in sensor networks.

• Designed to support the concurrency intensive operations required by networked

sensors with minimal hardware requirements.

• Developed by University of California, Berkeley, Intel Research and Crossbow

Technology.

• Written in nesC programming language.

TinyOS 28
Sensor code Base station Gateway
(nesC/TinyOS code code
) (nesC/TinyOS) (Java, c, …)

Wireless

Serial/USB

micaz/sensor
TinyOS 29
• TinyOS is an embedded component-based operating system and platform for
low-power wireless devices in wireless sensor networks (WSNs), ubiquitous
computing, personal area networks, building automation and smart meters.

• It is written in the programming language nesC, as a set of cooperating tasks

and processes.

• It was collaboration between the University of California, Berkeley, Intel

Research and Crossbow Technology.

• It was released as open-source software under BSD license and has grown into
an international consortium, the TinyOS Alliance.

• TinyOS has been used in space, being implemented in ESTCube-1.

Features of TinyOS 30
• TinyOS applications are written in the programming language nesC a dialect of
C language optimized for the memory limits of sensor networks.

• Its supplementary tools are mainly in the form of Java and shell script front-ends.

• The associated libraries and tools are mostly written in C.

• TinyOS programs are built of software components and they present hardware
abstractions.

• Components are connected to each other using interfaces.

• TinyOS provides interfaces and components for common abstractions such as

packet communication, routing, sensing, actuation and storage.
TinyOS – Design Model 31

Component-based model (modularity)

• Simple functions are incorporated in components with clean interfaces.

• Complex functions can be implemented by composing components.

Event-based model

• Interact with outside by events (no command shell)

• There are two kinds of events for TinyOS:

• External events: Clock events and message events.

• Internal events: triggered by external events.

Characteristics of TinyOS 32
• TinyOS is fully non-blocking and it has one call stack.

• All I/O operations are asynchronous and have a callback.

• TinyOS uses nesC's features to link these callbacks called events to enable the native
compiler for better optimization,

• TinyOS forces programmers to write complex logic by combining together many small
event handlers.

• TinyOS provides tasks similar to a Deferred Procedure Call in order to support larger
computations,.

• Tasks are non-preemptive and run in first in first out order.

• This simple concurrency model is sufficient for I/O centric applications but difficult with
CPU-heavy applications.
Field Monitor - Example 33
NesC 34
• The name nesC is an abbreviation of "network embedded systems C".

• NesC is a component-based event-driven programming language used to

build applications for TinyOS platform.

• TinyOS is an operating environment designed to run on embedded devices

used in distributed wireless sensor networks.

• NesC is built as an extension to the C programming language with components

"wired" together to run applications on TinyOS.
NesC 35
• Modules are components implemented by application code, while
configurations are components implemented by connecting interfaces of
existing components.

• Every nesC application has a top-level configuration that describes how

components are wired together.

• Functions in nesC are described as (f. i) where f is a function in an interface i.

• Functions are invoked using the call operation (for commands) and the signal
operation (for events).
NesC 36
• In TinyOS, code executes either asynchronously or synchronously.

• Race conditions can occur when concurrent updates to shared state are
performed.
• Asynchronous code (AC): Code reachable from at least one interrupt
handler
• Synchronous code (SC) : Code only reachable from tasks
• Synchronous code is always atomic to other synchronous codes because tasks
are always executed sequentially without preemption.

• Race conditions are possible when shared state is modified from AC or when
shared state from SC is also modified from AC
TinyOS and nesC 37

• TinyOS is an operating environment designed to run on embedded devices used

in distributed wireless sensor networks.

• nesC is a component-based, event-driven programming language used to build

applications for the TinyOS platform.

• nesC is built as an extension to the C programming language with components

"wired" together to run applications on TinyOS.

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

NesC 38
• Therefore, nesC provides programmers with two options to ensure atomicity.

• The first option is to convert all of the sharing code to tasks.

• The second option is to use atomic sections to modify shared state.

Node Level Simulator 39

• 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.
• NS2
• GloMoSim and QualNet
• JiST/SWANS
• OMNeT++
• TOSSIM
• EmStar
• Avrora
NS2 40

• It was written in a combination of C++ and an object oriented dialect of Tcl called OTcl.
• Many enhancements and extensions were developed to provide support for wireless
networks and mobile adhoc networks.
• Similarly, a variety of extensions for sensor networks have been created.
• For example, one such extension adds the concept of a phenomenon to a sensor network
simulation.
• The model uses broadcast packets transmitted through a designated channel to represent
a phenomenon.
• Broadcast packets are generated using the PHENOM routing protocol, which emits packets
with a certain configurable pulse rate
The nesC Language 41

it is a system, runtime environment, for nesC programs running on Mote hardware.

Features Include:

Resource management.

Selected components are linked into program at compile time.

Written in nesC and C.

All time-consuming commands are non-blocking.

ContikiOS 42

• Contiki is an operating system for networked, memory-constrained systems with a focus on

low-power wireless Internet of Things devices.
• Contiki was created by Adam Dunkels in 2002[2] and has been further developed by a
worldwide team of developers from Texas Instruments, Atmel, Cisco, etc,.
• Contiki gained popularity because of its built in TCP/IP stack and lightweight preemptive
scheduling over event-driven kernel
• Contiki provides multitasking and a built-in Internet Protocol Suite (TCP/IP stack), yet needs
only about 10 kilobytes of random-access memory (RAM) and 30 kilobytes of read-only
memory (ROM).[1] A full system, including a graphical user interface, needs about 30
kilobytes of RAM.
ContikiOS 43

• Contiki is designed to run on types of hardware devices that are severely constrained
in memory, power, processing power, and communication bandwidth. A typical Contiki
system has memory on the order of kilobytes, a power budget on the order of milliwatts,
processing speed measured in megaHertz, and communication bandwidth on the order of
hundreds of kilobits/second. Such systems include many types of embedded systems, and
old 8-bit computers.
•
ContikiOS 44

• Contiki is an open source operating system for the Internet of Things.

• Runs on networked embedded systems and wireless sensor nodes.
• It is designed for microcontrollers with small amounts of memory.
• A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes of ROM.
• Contiki provides IP communication, both for IPv4 and IPv6.
• It has an IPv6 stack that, combined with power-efficient radio mechanisms
such as ContikiMAC, allow battery-operated devices to participate in IPv6
networking.
• Contiki supports 6lowPAN header compression and the CoAP application
layer protocol.
The Contiki OS 45

Loadable programs
Loaded program Can be easily updated

Communication service

Core Language runtime

Service Core: single binary
Program Loader Usually never modified

Kernel
Applications Of Contiki OS 46

• There are more applications, comes in a package as a part of Contiki OS. Those

include a small net browser, net server, calculator, shell, telnet patron and

daemon, e-mail customer, the vnc viewer, and ftp.

• Contiki OS additionally provides mechanisms to measure strength for various

operations that help developers produce programs that are power sensitive.

Software package deal additionally comes with a UNIX-style shell for interacting

with OS and debugging.

Communication Components in Contiki OS 47

• Contiki OS supports protocols for IoT −

6LoWPAN − This stands for IPv6 over low-energy wi-fi personal place networks. It provides
compression era to guide the low information charge wi-fi wished by means of devices with
restrained resources.
b. RPL − This distance vector IPv6 protocol for LLNs (Low-Strength and Lossy Networks) permits
the quality viable path to be discovered in a complicated network of devices with various
capacities.
c. CoAP − This protocol helps communique for simple devices, generally gadgets requiring
heavy remote supervision.
d. uIP (for IPv4) − This TCP/IP implementation is used for 8-bit and sixteen-bit microcontrollers.
e. uIPv6 (for IPv6) − This is a fully compliant IPv6 extension to uIP.