This document provides a project report for the MicazXpl project. It describes the hardware and software used, including MICAz motes, sensor boards, TinyOS, and Linux. It outlines the roles and responsibilities of the group members. It proposes two versions of the MicazXpl system, the first collecting and transmitting sensor data and the second using the Collection Tree Protocol. It also provides tutorials on installing and using TinyOS and includes sections summarizing technical papers on topics like routing architectures, sensor network topologies, and energy efficiency.

1. MicazXpl
Project Report
http://micazxpl.googlecode.com
Ankit Singh
Philipp Orekhov
Rishu Seth
Mohammad Tarique Abdullah
February 12, 2011

2. Contents
I MicazXpl Project Description 7
1 Introduction to the Project Details 8
1.1 Hardware Description . . . . . . . . . . . . . . . . . . . . . . 8
1.1.1 MICAz Motes . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2 Sensor Boards . . . . . . . . . . . . . . . . . . . . . . 8
1.1.3 Micaz Motes Programming Board . . . . . . . . . . . 8
1.2 Software Description . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3 Programming Languages . . . . . . . . . . . . . . . . . 9
1.3 Group work and Individual Roles of Group Members . . . . . 10
1.3.1 Group Work . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.2 Ankit Singh . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3.3 Philipp Orekhov . . . . . . . . . . . . . . . . . . . . . 11
1.3.4 Rishu Seth . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.5 Mohammad Tarique Abdullah . . . . . . . . . . . . . 11
1.4 Beginning strategy for Project work . . . . . . . . . . . . . . 11
II Proposal For Reliable Data Acquisition System 14
2 Project Work Proposals for MicazXpl Versions 15
2.1 MicazXpl Version 0.1 . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.1 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.2 Transmission . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.3 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.4 Improving Availability . . . . . . . . . . . . . . . . . . 17
2.2 Implementation of MicazXpl Version 0.1 . . . . . . . . . . . . 17
2.3 MicazXpl Version 0.2 . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Issues on Dynamic Routing Protocol CTP . . . . . . . 20
2.3.2 Use Version 0.1 in CTP . . . . . . . . . . . . . . . . . 20
1

3. III TinyOS Manual for Beginners in Linux (Ubuntu) 21
3 TinyOS Installation Guide for Beginners 22
3.1 Procedure for Installation and configuring TinyOS . . . . . . 22
3.1.1 Installation of TinyOS (Source tinyos.net) . . . . . . . 22
3.1.2 Configuration of TinyOS . . . . . . . . . . . . . . . . . 23
3.1.3 Confirming the correct configuration of the Tinyos . . 24
3.1.4 Connecting Motes & pushing modules to Motes . . . . 24
3.1.5 Setting Up Environment for Mote Listener . . . . . . 26
3.2 Compiling and Pushing Sensor board specific Application . . 27
3.2.1 Compile Module . . . . . . . . . . . . . . . . . . . . . 27
3.2.2 To Push it to the Motes . . . . . . . . . . . . . . . . . 27
3.2.3 Running GUI in For Base Station . . . . . . . . . . . 27
IV Interesting Findings during Project Work 28
4 Interesting Findings 29
4.1 TinyOS Applications MicazXpl Version 0.1 . . . . . . . . . . 29
V Summarized Technical Paper 30
5 Adhoc Routing Architecture 31
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Receiving a Packet . . . . . . . . . . . . . . . . . . . . 31
5.2 Different Roles . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.1 MultihopRoute . . . . . . . . . . . . . . . . . . . . . . 33
5.2.2 MultiHopsend . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.3 RouteSelector . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4 Sliding Window Protocol . . . . . . . . . . . . . . . . . . . . 33
5.4.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.4.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4.3 Approach to the Problem . . . . . . . . . . . . . . . . 35
5.4.4 Merits . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4.5 Alertness . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.5 Protocol based Communication . . . . . . . . . . . . . . . . . 35
5.6 Protocol Operation . . . . . . . . . . . . . . . . . . . . . . . . 35
5.6.1 Receiver Operation . . . . . . . . . . . . . . . . . . . . 36
5.6.2 Transmitter Operation . . . . . . . . . . . . . . . . . . 37
5.6.3 Benefit of Sliding Window Protocol . . . . . . . . . . 37
5.6.4 Drawback of Sliding Window Protocol . . . . . . . . . 37
5.7 Connectionless Communication in Data Link Layer . . . . . . 37
2

4. 5.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6 Generalized Topologies 40
6.1 General Analysis of Wireless Sensor Network and its Topologies 40
6.1.1 Network Topologies . . . . . . . . . . . . . . . . . . . 40
6.2 Applications of Wireless Sensor Networks . . . . . . . . . . . 46
6.2.1 Advantages of WSN . . . . . . . . . . . . . . . . . . . 46
6.2.2 Disadvantages of WSN . . . . . . . . . . . . . . . . . . 47
6.3 Advantages and Disadvantages of Sensor Network Topology . 47
6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7 Collection Tree Protocol 50
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.2 Introduction to CTP - TEP 123 . . . . . . . . . . . . . . . . . 50
7.2.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 51
7.2.2 Some other Random Assumptions . . . . . . . . . . . 51
7.2.3 Collection and CTP . . . . . . . . . . . . . . . . . . . 51
7.2.4 Routing Loop . . . . . . . . . . . . . . . . . . . . . . . 51
7.2.5 CTP Address Loop Mechanisms . . . . . . . . . . . . 52
7.2.6 Solving Of Inconsistency . . . . . . . . . . . . . . . . . 52
7.2.7 Packet Duplication . . . . . . . . . . . . . . . . . . . . 52
7.2.8 Four Key Function . . . . . . . . . . . . . . . . . . . . 57
7.2.9 Limitation of CTP . . . . . . . . . . . . . . . . . . . . 57
8 Received Signal Strength Indicator - RSSI 60
8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.2 RSSI Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
8.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 60
8.2.2 Use of RSSI . . . . . . . . . . . . . . . . . . . . . . . . 61
8.2.3 Caution to Use RSSI in TinyOS . . . . . . . . . . . . 61
8.2.4 Intercept Base . . . . . . . . . . . . . . . . . . . . . . 62
8.2.5 Sending Node . . . . . . . . . . . . . . . . . . . . . . . 62
8.2.6 RSSI Base . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.2.7 Java Application . . . . . . . . . . . . . . . . . . . . . 62
8.2.8 Advantages of RSSI Method at Localisation . . . . . . 63
8.2.9 Difficulties at RSSI Method . . . . . . . . . . . . . . . 63
9 Energy Efficient Topologies 65
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
9.2 Analysis of Energy-efficient Topology control for WSN’s using
Online Battery Monitoring . . . . . . . . . . . . . . . . . . . 66
9.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 66
9.2.2 Architecture for Wireless Sensor Network systems . . 66
9.2.3 Energy consumption of WSN components . . . . . . . 67
3

5. 9.2.4 Battery technologies for WSN systems . . . . . . . . . 67
9.2.5 Battery monitoring . . . . . . . . . . . . . . . . . . . . 69
9.2.6 Circuitry and Measurements . . . . . . . . . . . . . . 69
9.2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 70
9.3 Energy-Efficient Topologies and Routing for Wireless Sensor
Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 71
9.3.2 Modelling Connected-Coverage WSN’s . . . . . . . . . 71
9.3.3 Performance Comparison : . . . . . . . . . . . . . . . . 76
9.4 Wireless Sensor Networks Energy-Efficient Topologies . . . . 78
9.4.1 Introduction to Ad Hoc and Wireless Sensor Networks 78
9.4.2 Communication Methods . . . . . . . . . . . . . . . . 79
9.4.3 Small Communication Range . . . . . . . . . . . . . . 79
9.4.4 Topology Control . . . . . . . . . . . . . . . . . . . . . 80
9.4.5 Location Based Protocols . . . . . . . . . . . . . . . . 81
9.4.6 The R and M and LMST protocols . . . . . . . . . . 81
9.4.7 LMST operates in three phases . . . . . . . . . . . . 82
9.4.8 Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.4.9 Simulation results . . . . . . . . . . . . . . . . . . . . 83
9.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4

6. List of Figures
5.1 Component Architecture . . . . . . . . . . . . . . . . . . . . . 32
5.2 OSI Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Our proposed Architecture . . . . . . . . . . . . . . . . . . . 38
6.1 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . 41
6.2 Wireless sensor node functional block diagram . . . . . . . . . 42
6.3 Basic Network Topologies . . . . . . . . . . . . . . . . . . . . 44
6.4 Hybrid Star-Mesh Network Topology . . . . . . . . . . . . . . 45
7.1 CTP Data Frame . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.2 Origin Packet . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.3 Packet Instance . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.4 CTP Routing Frame . . . . . . . . . . . . . . . . . . . . . . . 55
7.5 Sample Structure of CTP Node Deployment . . . . . . . . . . 58
8.1 RSSI Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
9.1 Wireless sensor node functional block diagram . . . . . . . . . 67
9.2 Comparison of power consumption . . . . . . . . . . . . . . . 68
9.3 Li-Ion and NiCd/NiMH battery behaviour. . . . . . . . . . . 68
9.4 Measurement setup and resulting graphs for 10 C and 10 C. . 69
9.5 Approximated discharge characteristics with Varying Tem-
perature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9.6 A WSN with hexagon-based topology . . . . . . . . . . . . . 73
9.7 A WSN with square-based topology . . . . . . . . . . . . . . 73
9.8 A WSN with triangle-based topology . . . . . . . . . . . . . . 74
9.9 A WSN with strip-based topology . . . . . . . . . . . . . . . 75
9.10 Performance comparison among WSNs with different pat-
terned topologies . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.11 Energy consumption and lifetime comparison among three
approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
9.12 Placement of topology control layer in the OSI stack . . . . . 80
9.13 Formula for Topology Control . . . . . . . . . . . . . . . . . . 81
9.14 Average energy usage for transmission w.r.t. to the number
of relay nodes; different TC methods . . . . . . . . . . . . . 82
5

7. 9.15 Average energy usage for transmission w.r.t. the distance to
the base station; different TC methods . . . . . . . . . . . . 83
9.16 Topology calculated using LMST method . . . . . . . . . . . 84
9.17 Topology calculated without TC protocols . . . . . . . . . . 85
9.18 Average energy consumption by one node for single transmis-
sion to the base station; different TC methods and network
size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6

8. Part I
MicazXpl Project
Description
7

9. Chapter 1
Introduction to the Project
Details
MicazXpl project is a project which explores the basic concepts and under-
standings of Intelligent Sensors Network working models. That is why Xpl
stands for explorer. The description of the required hardware and softwares
are described below.
1.1 Hardware Description
1.1.1 MICAz Motes
The MICAz is a 2.4GHz, IEEE 802.15.4 compliant, Mote module used for
enabling low-power, wireless, sensor networks.
1.1.2 Sensor Boards
Crossbow offers a variety of sensor and data acquisition boards for the MI-
CAz Mote. All of these boards connect to the MICAz via the standard
51-pin expansion connector.
We are using MTS300CA Light, Temp, Acoustic, and Sounder Sensor
Board for our project.
1.1.3 Micaz Motes Programming Board
Crossbow offers the MIB family of basic Mote programming and interface
boards for the MICA, MICA2, MICAz and MICA2DOT. The MIB510 offers
RS-232 based serial programming and serial interface to the MICA family
of Motes. The MIB520 provides USB connectivity to the MICA2/MICAz
Motes for both communication and in-system programming. The MIB600
Ethernet Interface board delivers a LAN data interface and Mote program-
ming.
8

10. Base Stations
A base station allows the aggregation of sensor network data onto a PC or
other computer platform. Any MICAz Mote can function as a base station
when it is connected to a standard PC interface or gateway board. The
MIB510 or MIB520 provides a serial/USB interface for both programming
and data communications. Crossbow also offers a stand-alone gateway so-
lution, the MIB600 for TCP/IP-based Ethernet networks.
We are using LAN data interface for PC-Motes Communication.
1.2 Software Description
1.2.1 Linux
We used Linux Ubuntu Version 10.4 operating system a platform for in-
stalling and working on TinyOS. The simple reason to use Linux is that
there is lots of support for linux environment and easy to configure it to
start working quickly with TinyOS and its application.
1.2.2 TinyOS
TinyOS is an open source, BSD-licensed operating system designed for low-
power wireless devices, such as those used in sensor networks, ubiquitous
computing, personal area networks, smart buildings, and smart meters. It
is a component-based operating system and platform targeting wireless sen-
sor networks (WSNs). TinyOS is an embedded operating system written
in the nesC programming language as a set of cooperating tasks and pro-
cesses. TinyOS started as a collaboration between the University of Califor-
nia, Berkeley in co-operation with Intel Research and Crossbow Technology,
and has since grown to be an international consortium, the TinyOS Alliance.
1.2.3 Programming Languages
nesC
TinyOS applications are written in nesC, a dialect of the C language opti-
mized for the memory limits of sensor networks.
nesC Programming Language Supports the TinyOS Kernel Design (Events
and Tasks).
Shell Scripting
We used Shell scripting for making Automation tools for Motes and en-
vironment setup. It is also used for developing front end for the TinyOS
application
9

11. Java
Java also used for front end applications. Specially for GUI Interfaces of
TinyOS applications.
1.3 Group work and Individual Roles of Group
Members
1.3.1 Group Work
• TinyOS Tutorial study and presentation to the team.
• Research on TinyOS modules and applications.
• Discussion of possible ideas for the project using tutorials.
• Proposals and presentations of possible solutions from various research
papers/work in the area of Intelligent Sensor Network to the team
members.
• Reviewing each others work time to time.
• Implementation of the individual tasks and push to projects reposito-
ries And
• Writing the reports on findings and work done by individuals.
• Review of the project developments.
1.3.2 Ankit Singh
• Managing Team and Project developments.
• Written Shell Script tools to automate settings and running of TinyOS
environment and applications.
• Tutorial Presented to the Team: Mote-Mote radio communication
• Design and development of TinyOS applications in nesC (MicazXpl
Version 0.1 & 0.2) .
• Project documentations.
10

12. 1.3.3 Philipp Orekhov
• Tutorial Presented to the Team: Sensing
• Finding and research on implementation solutions on ideas proposed
by the team.
• Design and development of TinyOS applications in nesC (MicazXpl
Version 0.1 and 0.2).
1.3.4 Rishu Seth
• Tutorial presentation to the team. Tutorial Presented: Boot Sequence
• Summarize and present the findings to the team for possible solutions
for different issues or problems discussed during project developments
(MicazXpl Version 0.1) .
• Responsible for research topics: Ad-Hoc Routing Architecture, Mi-
cazXpl Version 0.2 Topic RSSI
1.3.5 Mohammad Tarique Abdullah
• Tutorial presentation to the team. Tutorial Presented: Mote-PC serial
communication and SerialForwarder
• Summarize and present the findings on the research topic to the inter-
est of our Project MicazXpl: Generalized Topology
• Research on the topic of interest for the development MicazXpl Version
0.2 and presented the result to the team. Topic related to Multi-Hop
Routing: Collection Tree Protocol (CTP)
1.4 Beginning strategy for Project work
We started Intelligent Sensors Network project MicazXpl from scratch. We
begin learning and understanding the TinyOS environment from the tutori-
als provided on official website of TinyOS.
1. First tutorial ”Getting Started with TinyOS” given an overview of
various Motes family and steps to install the TinyOS on Linux Ubuntu.
We made one brief tutorial TinyOS Installation Guide for Beginners
to make it very simple for the beginners and newbie to linux. We
also included the tweaks and some tricks to make Micaz motes run
and shell scripts for making developers life easy to avoid typing many
commands to get started with TinyOS application pushed and run on
the motes.
11

13. 2. Second tutorial ”Modules and the TinyOS Execution Model” intro-
duces nesC modules, commands, events, and tasks. It explains the
TinyOS execution model using simple BlinkC application provided in
TinyOS applications folder. We learned how TinyOS applications are
written nesC language and usage of Interfaces, commands and Events.
BlinkC is a simple nesC application for motes which blinks the three
Leds of the motes at different timings. This helped us in understanding
TinyOS Execution Model.
3. The Tutorial ”Mote-Mote Radio Communication” introduced us to
radio communication in TinyOS. We familiar to the interfaces and
components which is used for communications. We learned to use the
common message buffer abstraction called message t and how to send
or receive buffer over radio.
In this tutorial, we get familiarized with various basic Communica-
tions interfaces given in tos/interfaces directory such as
• Packet
• Send
• Receive
• PacketAcknowledgements
• RadioTimeStamping
It also gives the oversight of Active Message Interfaces ”AM Type”
refers to the field used for multiplexing. AM types are similar in func-
tion to the Ethernet frame type field, IP protocol field, and the UDP
port in that all of them are used to multiplex access to a communica-
tion service.
• AMPacket
• AMSend
This tutorial modified BlinkC application which now uses Radio com-
munication. We followed the tutorial and tested the radio communi-
cation application provided in the tutorial.
4. The ”Mote-PC serial communication and SerialForwarder” tutorial is
one of the important tutorial for the scope of our project. This com-
munication helps us know how to communicate with a mote from a
computer which is very much needed to see the output data given by
motes.
12

14. But this tutorial uses serial communication which was not in our case.
We used RJ 45 cable i.e TCP/IP network for connecting programming
board to computer (in our case Laptop). The detail about this given
in the tutorial in the later chapters.
There is a java module to net.tinyos.tools.Listen for listening motes.
There is a already a base station utility application given in TinyOS
application directory which acts as a bridge between serial or TCP/IP
network port and radio network. We successfully tested the Base sta-
tion module by using BlinkToRadioC application by receiving the Data
packet with incrementing counter from motes.
5. ”Sensing” This tutorial introduces sensor data acquisition in TinyOS.
The two application demonstration is given in the tutorial.
• Sense Application It periodically takes sensor readings and dis-
plays the values on the LEDs.
• Oscilloscope It periodically broadcast their sensor readings to a
base station explained above. We tweaked Oscilloscope to sense
Temperature TempC, Light PhotoC, Sound MicC and send to the
base station.
After we received the sensors data to base station PC, we used the
Java GUI module to visualize the data on PC.
13

15. Part II
Proposal For Reliable Data
Acquisition System
14

16. Chapter 2
Project Work Proposals for
MicazXpl Versions
2.1 MicazXpl Version 0.1
2.1.1 Data
CRC
Cyclic redundancy check used to ensure the integrity of the data is intact.
There is a library function in TinyOS module for calculating the CRC sum
for the data. .../tos/interfaces/Crc.nc:
async command uint16_t crc16(void *buf, uint8_t len);
.../tos/system/CrcC.nc and crc.h: implementation
Timestamp
The idea is to avoid repeatition of the data by assigning the unique times-
tamp. There is timer available in the timer module.
.../tos/lib/timer:
startPeriodic()
startOneShot()
getNow()
Message Structure
MicazXpl own Message header to be implemented.
typedef nx_struct name {
nx_uintX_t var1...
}
15

17. counter + timestamp + security & integrity + msg content
Possibly two formats: for plain message and for encrypted message:
message data + crc of message data → encypted message + crc encrypted
Security
We planned to acheive this using simple encryption and Decryption. For
example, XOR operation with pre-defined shared value.
void crypt(void *buf, uint8_t lenBuf, uint16_t key);
void crypt(void *buf, uint8_t lenBuf, void *key, uint8_t lenKey)
and possibly: CC2420 radio builtin security features
Sensor readings
Checking sensor reading for missing data and possible outliers.
missing/wrong: predefined value eg 0xFF
outliers: dependent on sensor, statistics?
2.1.2 Transmission
Mulitihop And Routing
We are trying to achieve the reliable data transmission by different routing
scenarios. For example, simple multihop by forwarding to previous mote.
Simple:
mote id 3 with sensor → mote id 2 → mote id 1 → mote id 0 or base station
problem: what if some middle mote is missing/stops working?
Other:
tymo, ctp, ...
Data Loss and Damage
We are trying to prevent accidental or malicious data modification and
packet injection. Using the security and Data integrity proposals in pre-
vious section.
loss: use control messages eg Ack/Syn + timeout values/counters
damage: integrity+security
Network Congestion
We can use the local storage and retransmission of the data on demand.
Problems: how to identify network is busy??
16

18. Mote Availability
Identifying the lost and available motes. It is important to avoid data losses.
Example simple solution: motes broadcast their id periodically, base
station keeps counter. Problem: more motes added or base station fails...
or RSSI- radio signal strength
2.1.3 Methods
Redundancy
Storing multiple versions of the collected data and using multiple motes to
perform the same operation ⇒ Software redundancy + Data redundancy +
Hardware redundancy
Local Storage
It should have a locally stored copy of the data to be able to retransmit if
data is damaged and/or lost.
2.1.4 Improving Availability
Power Management
We try to keep the power consumption to the minimum to conserve battery
power. Disable unnecessary components / put components to sleep when
not used...
Low Power Listening
Its a feature provided by TinyOS. for example, the motes will go on sleep
and Wakeup on the event/timer expiry/remote message.
The implementation details are given in the later chapter.
2.2 Implementation of MicazXpl Version 0.1
We successfully implemented MicazXpl Version 0.1 with features given be-
low:
• Decremental Multihop Routing. Although its Static in nature and
major drawback of the this version is that if any mode goes down then
whole multihop routing architecture will fail.
• CRC checksum successfully applied on data to ensure integrity of data
17

19. • Successfully Encrypted data with the first CRC calculated and again
take CRC checksum of the encrypted data. For more clarification
please check the message structures of MicazXpl Version 0.1 header
file
• Base Station receives the encrypted data. Then it calculates the CRC
of encrypted data and compares with the received CRC. Then data is
decrypted successfully, the internal CRC is calculated and compared
against the one in the decrypted data and saves in the log file for
further processing of the data. If there is any change in CRC, then
whole message is set to 0xFF to indicate it being incorrect.
MicazXpl Version 0.1 Header File given below which represents the Data
Payload structure:
#ifndef MICAZXPL_H
#define MICAZXPL_H
enum {
NREADINGS = 8,
AM_ENC_MSG_CRC=0xEE,
ENCRYPTION_KEY=0xFEED,
DEFAULT_INTERVAL=250
};
typedef nx_struct data {
nx_uint16_t moteid; // ID OF THE SENSING MOTE
nx_uint16_t timestamp; // timestamp to distinguish between older data
// 3 types of sensor readings
nx_uint16_t light[NREADINGS];
nx_uint16_t sound[NREADINGS];
nx_uint16_t temp[NREADINGS];
} data_t;
// message content + crc sum of the content
typedef nx_struct msg_crc {
data_t msg_data;
nx_uint16_t crc;
} msg_crc_t;
// message to be encrypted + encrypted crc sum
typedef nx_struct enc_msg_crc {
msg_crc_t msg;
nx_uint16_t final_crc;
18

20. nx_uint8_t counter; // hop (incremented at each successive mote)
} enc_msg_crc_t;
#endif
The sample of live recorded data with encrypted and decrypted payload
data is given below:
Encrypted Payload Data
00 00 01 00 02 19 00 EE FE EF FE ED FF 12 FF 12 FF 12 FF 12 FF
12 FC ED FC ED FC ED DD F0 1D BF 00
00 00 01 00 02 19 00 EE FE EF FE EC FC ED FC ED FC ED FC ED
FC ED FC ED FC EC FC EF B4 45 1D BF 00
00 00 01 00 02 19 00 EE FE EF FE EF FC FF FC F5 FC F6 FC F3 FC
F1 FC FA FC F9 FC FF 88 22 1D BF 00
00 00 01 00 02 19 00 EE FE EF FE EE FC CA FC C6 FC C3 FC C2 FC
DD FC DD FC C6 FC CB 2F BF 1D BF 00
00 00 01 00 02 19 00 EE FE EF FE E9 FC F2 FC CE FC C2 FC DA FC
D6 FC D0 FC D3 FC D0 61 44 1D BF 00
00 00 01 00 02 19 00 EE FE EF FE E8 FC DE FC C3 FC C7 FC C2 FC
D7 FC AF FC AB FC AA 86 B4 1D BF 00
00 00 01 00 02 19 00 EE FE EF FE EB FC AB FC A9 FC AF FC D3 FC
D5 FC D9 FC DF FC DC D3 EA 1D BF 00
Decrypted Payload Data
00 00 01 00 02 19 00 EE 00 02 00 00 01 F5 01 F5 01 F5 01 F6 01 F6 01
F6 01 F6 01 F6 0F A7 1D BF 00
00 00 01 00 02 19 00 EE 00 02 00 02 02 11 02 1A 02 1C 02 16 02 11 02
0D 02 1B 02 25 DD 15 1D BF 00
00 00 01 00 02 19 00 EE 00 02 00 06 02 40 02 3B 02 36 02 33 02 31 02
3D 02 43 02 45 BD 4F 1D BF 00
00 00 01 00 02 19 00 EE 00 02 00 07 02 46 02 41 02 3C 02 37 02 34 02
32 02 31 02 30 81 80 1D BF 00
00 00 01 00 02 19 00 EE 00 02 00 08 02 30 02 30 02 2F 02 2F 02 2F 02
2E 02 2E 02 2E 47 E3 1D BF 00
00 00 01 00 02 19 00 EE 00 02 00 09 02 2C 02 2A 02 29 022E 02 39 02
41 02 44 02 46 73 FC 1D BF 00
00 00 01 00 02 19 00 EE 00 02 00 0A 02 45 02 43 02 41 02 3E 02 3B 02
38 02 3E 02 45 A0 93 1D BF 00
19

21. 2.3 MicazXpl Version 0.2
2.3.1 Issues on Dynamic Routing Protocol CTP
In MicazXpl version 0.2, the CTP protocol was intended to be used to
allow for more efficient multihop transmission of the data. The use of CTP
however does not allow for easy monitoring of traffic paths due to the use of
dynamic link estimation (eg. 4 bit link estimation protocol), which would
not add a significant benefit to the application. Additionally, CTP adds an
extra overhead on the message format and size, which makes the operations
on the data that are supposed to be happening in real time more time
consuming.
2.3.2 Use Version 0.1 in CTP
To allow for the use of the CTP in our application, the above meintioned
issues need to be considered. Assuming the uncontrolled use of CTP multi-
hop to be sufficient, the steps would be to:
• Link with the CTP, net and some link estimator libraries (in the Make-
File)
• Setup the rootnode to be at the basestation
• enable the routing to be performed using the CTP
• manage the message format and size for proper data handling
20

22. Part III
TinyOS Manual for
Beginners in Linux (Ubuntu)
21

23. Chapter 3
TinyOS Installation Guide
for Beginners
3.1 Procedure for Installation and configuring TinyOS
3.1.1 Installation of TinyOS (Source tinyos.net)
In Ubuntu operating system open following file:
System → Administration → Synaptic Package Manager
After Synaptic Package Manager get open goto:
Settings → Repositories → Other software → (Press) Add
After pressing Add button, Please enter the following line to add the tinyOS
repositories:
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu <distribution> main
Distribution is the distribution name of the Ubuntu. If you do not know
the distribution name then please follow the steps to know your Ubuntu
Distribution:
Type the the folllowing command on your linux command line:
ankit@ubuntu:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 10.04.1
LTS Release: 10.04
Codename: lucid
You will get some output like the above. The Codename: lucid is my dis-
tribution name. So, Just use the name which shows to you.
22

24. After you inserted the above line in the add pop-up then press close. The
linux will ask your permission to update the repositories. Just close it and
it will automatically do it.
Now, there is a option called Quick Search: Please enter tinyos as search
key. You can see some result on it. Choose tinyos-2.1.1.
Then press Apply button in Synaptic Package Manager.
It will install tinyos for you.
3.1.2 Configuration of TinyOS
Open Terminal in Ubuntu
You need to source the tinyos.sh (shell script) in bashrc. Type the following
command:
ankit@ubuntu:~$ sudo gedit .bashrc
The .bashrc file will be open after hitting enter
Then copy & paste the following lines after the first syntax lines:
#Sourcing the tinyos environment variable setup script
source /opt/tinyos-2.1.1/tinyos.sh
After that, save & exit.
Change the owner ship of the tinyos directory
Change directory to: (use the following command)
ankit@ubuntu:~$cd /opt/
ankit@ubuntu:~$sudo Chown -R ankit:ankit tinyos-2.1.1/
Note: use your home folder name given before ’@’ sign - Add path to
tinyos.jar file in tinyos.sh
ankit@ubuntu:~$cd /opt/tinyos-2.1.1
ankit@ubuntu:/opt/tinyos-2.1.1$sudo gedit tinyos.sh
Add the following line just after the end of the CLASSPATH:
:$TOSROOT/support/sdk/java/tinyos.jar:.
The line should look like:
CLASSPATH=$CLASSPATH:$TOSROOT/support/sdk/java:
$TOSROOT/support/sdk/java/tinyos.jar:.
23

25. 3.1.3 Confirming the correct configuration of the Tinyos
Change directory to:
ankit@ubuntu:~$cd /opt/tinyos-2.1.1/apps/Blink
Type the make command for the module Blink
ankit@ubuntu:/opt/tinyos-2.1.1/apps/Blink$ make micaz
You should see the output like this:
mkdir -p build/micaz
compiling BlinkAppC to a micaz binary
ncc -o build/micaz/main.exe -Os -fnesc-separator=__ -Wall -Wshadow -Wnesc-all
-target=micaz -fnesc-cfile=build/micaz/app.c -board=micasb -DDEFINED_TOS_AM_GROUP=
0x22 --param max-inline-insns-single=100000 -DIDENT_APPNAME="BlinkAppC" -
DIDENT_USERNAME="ankit" -DIDENT_HOSTNAME="ubuntu" -
DIDENT_USERHASH=0x1bba31edL
-DIDENT_TIMESTAMP=0x4cec121eL -DIDENT_UIDHASH=0x92b330deL -fnesc- dump=wiring -
fnesc-dump=’interfaces(!abstract())’ -fnesc- dump=’referenced(interfacedefs,
components)’ -fnesc- dumpfile=build/micaz/wiring-check.xml BlinkAppC.nc -lm
compiled BlinkAppC to build/micaz/main.exe
2052 bytes in ROM
51 bytes in RAM
avr-objcopy --output-target=srec build/micaz/main.exe
build/micaz/main.srec avr-objcopy --output-target=ihex
build/micaz/main.exe build/micaz/main.ihex
writing TOS image
If you are able to see ’writing TOS’ image at end then you have successfully
configured the Tinyos.
3.1.4 Connecting Motes & pushing modules to Motes
Every time you connect a new mote to the serial-based programming board
, you have to again setup & configure the network address of the program-
ming board and system. So, to make life easy, I wrote a shell script.
All SHELL SCRIPTS tools can be found in MicazXpl project repositories.
Following are the shell script for configuring network
ankit@ubuntu:~$sudo gedit /bin/runMoteSetup.sh
#!/bin/sh
sudo ifconfig eth0 10.5.5.1
24

26. sudo arp -s 10.5.5.5 00204A13E829
netcat 10.5.5.5 1
netcat 10.5.5.5 9999
NOTE: 00204A13E829 is the MAC address of my serial-based programming
board. You need to put your own MAC address finding on the board.
This will save the shell script in /bin folder which will make this shell script
accessible from any folder or path. Don’t forget to make the shell script to
executable file by using the following command.
ankit@ubuntu:~$sudo chmod +x /bin/runMoteSetup.sh
ankit@ubuntu:~$ runMoteSetup.sh
??#??#
*** Lantronix Universal Device Server ***
Serial Number 1359433 MAC address 00204A13E829
Software version V5.8.0.1 (041112) LTX
Press Enter for Setup Mode
Now, The shell script to push the modules to the Motes:
ankit@ubuntu:~$sudo gedit /bin/pushToMotes.sh
#!/bin/sh
## For comiling Data And pushing it in the Mote
make micaz install eprb,10.5.5.5
For making the above shell script executable.
ankit@ubuntu:~$sudo chmod +x /bin/pushToMotes.sh
ankit@ubuntu:/opt/tinyos-2.1.1/apps/Blink$ pushToMotes.sh mkdir -p build/micaz
compiling BlinkAppC to a micaz binary ncc -o build/micaz/main.exe -Os
-fnesc-separator=__ -Wall -Wshadow -Wnesc-all -target=micaz -fnesc-cfile=
build/micaz/app.c -board=micasb -DDEFINED_TOS_AM_GROUP=0x22
--param max-inline-insns-single=100000 -DIDENT_APPNAME="BlinkAppC" -
DIDENT_USERNAME="ankit" -DIDENT_HOSTNAME="ubuntu" -
DIDENT_USERHASH=0x1bba31edL -DIDENT_TIMESTAMP=0x4ceef6c4L -
DIDENT_UIDHASH=0x44161342L -fnesc- dump=wiring -fnesc-dump=’interfaces(!abstract())’
fnesc- dump=’referenced(interfacedefs, components)’ -fnesc- dumpfile=build/
micaz/wiring-check.xml BlinkAppC.nc -lm
compiled BlinkAppC to build/micaz/main.exe
2052 bytes in ROM
51 bytes in RAM
25

27. avr-objcopy --output-target=srec build/micaz/main.exe
build/micaz/main.srec avr-objcopy --output-target=ihex build/micaz/main.exe
build/micaz/main.ihex
writing TOS image
cp build/micaz/main.srec build/micaz/main.srec.out
installing micaz binary using eprb uisp -dprog=stk500 -dhost=10.5.5.5
--wr_fuse_h=0xd9 -
dpart=ATmega128 --wr_fuse_e=ff --erase --upload if=build/micaz/main.srec.out
--verify Firmware Version: 1.7 Atmel AVR ATmega128 is found.
Uploading: flash
Verifying: flash
Fuse High Byte set to 0xd9
Fuse Extended Byte set to 0xff
rm -f build/micaz/main.exe.out build/micaz/main.srec.out
3.1.5 Setting Up Environment for Mote Listener
Mote Listner is used to read the data broadcasted by motes in the network
and saves to the output file. Following are the commands for listening:
java net.tinyos.tools.Listen -comm network@10.5.5.5:10002
It is supposed to be serial communication but in our case, we are us-
ing TCP/IP connection. That is why we are using ”network@IP:PORT” in
above command.
You can also go through the java source for getting more details on number
of options available for your type of connection to your PC:
ankit@ubuntu:/opt/tinyos-2.1.1/support/sdk/java/net/tinyos$
vim packet/BuildSource.java
You can export the MOTECOM for not always passing option -comm
export MOTECOM=network@10.5.5.5:10002
Then run java listner without -comm parameter
ankit@ubuntu:/opt/tinyos-2.1.1/apps/tests/TestSerial$
java net.tinyos.tools.Listen
26

28. 3.2 Compiling and Pushing Sensor board specific
Application
We are going to take example of Oscilloscope application given with TinyOS
package.
Application Path is :
/opt/tinyos-2.1.1/apps/Oscilloscope/
3.2.1 Compile Module
To Compile this Module, You need to provide Sensor board type. In our
Case its: mts300.
Type the following command on your linux console.
SENSORBOARD=mts300 make micaz
3.2.2 To Push it to the Motes
Type the following command on your linux console using your variables into
the syntax bracket.
make micaz reinstall eprb,<Node-ID> <IP-Adr>
Node-ID: Mote ID you want to set like Mode ID 1 or 2 or anything
IP-Adr: IP address of the Motes
3.2.3 Running GUI in For Base Station
Goto to Java folder of Oscilloscope:
/opt/tinyos-2.1.1/apps/Oscilloscope/java/
Setting Environment variable for motes communication:
export MOTECOM=network@10.5.5.5:10002
Then RUN the Java Application:
ankit@ubuntu:/opt/tinyos-2.1.1/apps/Oscilloscope-Mic/java$./run
Hope it will be helpful for you to get started!!! Thank You!!
27

29. Part IV
Interesting Findings during
Project Work
28

30. Chapter 4
Interesting Findings
4.1 TinyOS Applications MicazXpl Version 0.1
1. CRC Module given with TinyOS: The function CRC16 function given
in the CRC module to calculate CRC16 is actually calculating CRC-
CCITT (XModem). The functionality of the function is different from
the function name. Need to be changed by TinyOS distributions.
2. The Default message Packet length is set to 28 Bytes. But we can
change it to any number required by our own setup. The file you need
to alter is /tinyos/tos/types/message.h in the following part
#define TOSH_DATA_LENGTH 28
You can change that 28 to your message packet size requirement.
29

31. Part V
Summarized Technical Paper
30

32. Chapter 5
Adhoc Routing Architecture
5.1 Introduction
Multihop routing has been broken into several components. At the top of
the layer architecture is an application component and between application
component and the multihop component is an arbitrary networking stack
component.
Multihop router is the top level configuration for the routing layer.
Sending a packet - Before sending a packet ,component uses getbuffer
comm.
In Ad -Hoc routing originator of the packet should call send.getbuffer.
Callingsend → multihopsends send command → MultihopRoute com-
mand (chooses) Route → Selected route → Packet Transmit(AM sendMsg
Interface)
MultihopRoute depends on some numbers of estimator components to make
decisions on which route to use.
5.1.1 Receiving a Packet
AMs message reception signals MultihopRoute and it determines if the
packet is destined for local node and then it signals Multihop Routers Re-
ceive Interface.
Not Local Node
It signals Multihop Routers Intercept and it allows high level component to
peek into or modify packet payload.
31

33. Figure 5.1: Component Architecture
32

34. 5.2 Different Roles
5.2.1 MultihopRoute
MultihopRoute is responsible for receiving protocol messages and deciding
whether it should forward them. If MultihopRoute decides that it should
forward a message,then it passes the packet to Multihopsend.
5.2.2 MultiHopsend
It is responsible for sending packets using the implemented Ad - Hoc routing
protocol. MultiHopSend does not have any route selection logic and does
not fill in the header fields necessary to send a packet, this is all performed
by RouteSelector.
5.2.3 RouteSelector
RouteSelector maintains routing state which it uses to choose routes for
packets to send. MultiHopsend passes it a packet buffer, which it fills in
with the necessary header fields to be later understood by MultiHopRoute.
RouteSelector makes its routing decisions using some number of Estimators,
each of which can have different interfaces.
5.3 OSI Model
Open System Interconnection Model (OSI) -
Layer - A layer is a collection of conceptually similar functions that provide
services to the layer above it and receives services from the layer below it.
5.4 Sliding Window Protocol
A sliding window protocol is a feature of Packet based data transmission
protocols. They are used where reliability in order to delivery of packets
is required, such as in data link layer as in the transmission control proto-
col(TCP).
5.4.1 Features
Each position of the transmission (Packets) is assigned a unique consecutive
sequence number and the receiver uses the numbers to place received packets
in the correct order. i.e.
• Discarding duplicate packets.
• Identifying missing packets.
33

35. Figure 5.2: OSI Model
34

36. 5.4.2 Problem
There is no limit of the size or sequence numbers that can be required in
this protocol.
5.4.3 Approach to the Problem
This problem can be chacked by placing a limit on the number of packets
that can be transmitted or received at any given time.
5.4.4 Merits
A sliding window protocol allows an unlimited numbers of packets to be
communicated using fixed sequence numbers.
5.4.5 Alertness
For highest possible throughput, it is important that the transmitter is not
permitted to stop sending by the sliding window protocol earlier than one
Round Trip Delay Time(RTT).
RTT: It is the length of time it takes for a signal to be sent plus the length
of time it takes for an acknowledge of that signal to be received.
RTT = SendTime + AckTime
5.5 Protocol based Communication
In communication based protocol , the receiver must acknowledge received
packets. If transmitter does not receive an acknowledgement within a rea-
sonable time, it resends data.
If a transmitter does not receive an acknowledgement it cannot know whether
actually receiver received the packet or not, or packet was damaged or it
may also happen that acknowledgement was sent but it was lost.
5.6 Protocol Operation
Basic terms used in it are -
• Transmitter sequence number = n(t)
• Receiver sequence number = n(r)
• Transmitter window size = w(t)
• Receiver window size = w(r)
35

37. Window size must be greater than Zero. As we mentioned , n(t) is the next
packet to be transmitted and the sequence number of this packet is not yet
received and n(r) is the first packet not yet received. These both numbers
are in increasing mode.
5.6.1 Receiver Operation
n(s) is one more than the sequence number of the highest sequence number
received.
• Received a Packet
• Updates its Variable
• Transmit acknowledgement with the new n(r)
• Transmitter keeps track of the highest acknowledgement it has received
n(a)
But it is uncertain about the packets n(a) and n(s).
n(a)<= n(r)<= n(s)
Some Facts
There are some facts that are listed below -
• The highest acknowledgement received by the transmitter cannot be
higher than the highest acknowledged by the receiver.
n(a)<= n(r)
• The span of fully received packets cannot extend beyond the end of
the partially received packet.
n(r)<=n(s).
• The highest packet received cannot be higher than the highest packet
send.
n(s)<=n(t)
• The highest packet sent is limited by the highest acknowledgement
received and the transmit window size.
n(t)<=n(a) +w(t)
36

38. 5.6.2 Transmitter Operation
If transmitter wants to send data, it may transmit upto w(t) packets ahead
of the latest acknowledgement n(a). A transmitter can send packet number
n(t) if and only if
n(t) < n(a) +w(t)
5.6.3 Benefit of Sliding Window Protocol
Some benefits of sliding window protocol -
• Data Reliability
• Data Integrity
• Unlimited Sequence numbers are used
5.6.4 Drawback of Sliding Window Protocol
• Ambiguity occurs
• Maintaining a Sequence number is difficult
5.7 Connectionless Communication in Data Link
Layer
Packet switching network (connectionless network) is a data transmission
method in which each data packet carries some information. The connec-
tionless communication mode has advantages over connection oriented com-
munication. It allows multihop also in Data link layer.
The data link layer supports reliable packet transmission between node to
node wireless connection. The sliding window protocol supports the reliable
data communication in data link layer. In our architecture all reliable datas
are going to upper layer which ensures there is no missing of data.
5.8 Conclusion
In our proposed architecture we mentioned how data can be sent with in-
tegrity and reliablity as we want reliable communication in multihop routing.
As data is very important and valuable, if we lose data then it has a great
impact on a persons condition and also has some environmental influences.
• So our proposed architecture refers Safety Critical Ad - Hoc routing
Architecture.
37

39. Figure 5.3: Our proposed Architecture
38

40. Bibliography
[1] Adhoc Routing Architecture, Philip Levis et.at, February 5, 2003
[2] Topology Control in Wireless Adhoc and sensors networks, Paolo Santi,
Institute of Information e Telematica
[3] Topological Detection on wormholes in wireless sensor Adhoc and sen-
sor networks, Dept. of Computer science and engineering, Hongkong
university of science and Technology, Dept. of computer science, Illi-
nois institute of Technology, chicago, IL, USA
39

41. Chapter 6
Generalized Topologies
6.1 General Analysis of Wireless Sensor Network
and its Topologies
Now a days wirelss sensor network has a great impact in various sectors. For
example - It has application in defence sector, buliding, monitoring, safety
medical application, and also sensitive area observation, even the observa-
tion of sea level and its application is increasing day by day.
Typically a wirelsess sensor network consists of spartially distributed au-
tonomous sensors to cooperatively monitor physical or environment condi-
tions such as temperature, sound, vibration, pressure, motion or pollutants.
In addition each sensor node consists of a radio transceiver, or wireless com-
munications device, a small microcontroller and an energy source usually a
battery.
6.1.1 Network Topologies
There are various kinds of network topologies in wireless sensor network.
The basic issue in communication networks is the transmission of messages
to achieve a prescribed message throughput (Quantity of service) and qual-
ity of service, quality of service can be specified in terms of message delay,
message due dates, bit error rates packet loss, economic cost of transmission,
transmission power etc.
A communication network is composed of nodes, each of which has comput-
ing power and transmit and receive messages over communication links.
Basic network topologies are -
• Star
• Ring
• Bus
40

42. Figure 6.1: Wireless Sensor Networks
41

43. Figure 6.2: Wireless sensor node functional block diagram
42

44. • Tree
• Fully Connected
• Mesh
• Hybride star - mesh
• Self Healing Ring
Description of above topologies are -
• Star: In this topology, all nodes are connected to a single hub node.
The hub has some specific different functions than other nodes like
handling messages and routing and decision making capabilities. If a
communication link is damaged or cut it only affects only one node
while other nodes are able to communicate with other nodes. If the
hub is damaged the network is destroyed.
• Ring : In this topology all nodes are logically same and they per-
form the same function and there is no head node. Messages travel
around the ring in a single direction. If the ring is cut or damaged all
communication is lost.
• Bus : In this topology, messages are broadcast on the bus to all nodes.
Each node has to check the destination address in the message header
and each node processes the messages addresed to it. The bus topology
is passive and in this topology each node simply listens for messages
and no node is responsible for retransmitting the messages.
• Tree : In this topology, there is root node or head node. It has two
child node and each child node again in turn has two child nodes. It is
a hierarchical structure. In it first messages are send to root or parent
node and then it goes to the destination node. If the root node is
damaged then the whole network is failed or damaged.
• Fully Connected : In this topology, every node is connected to each
other which means according to graph theory it is a complete graph.
For smaller number of nodes it is very efficient. If the number of nodes
increases there occurs great complexity and number of links increases
exponentially and also there is a routing problem.
• Mesh : In this topology, all nodes are equally distributed over a ge-
ographic region. For example, personnel or vehicle security surveil-
lance systems. Actually this architecture provides a square relation-
ship among the nodes that means 3*3 and 4*4 mesh architecture pro-
vides 9 and 16 respectively. It has an advantage, although all nodes
43

45. may be identical and have the same computing and transmission capa-
bilities, certain nodes can still be designated as ’group leader’ and take
an additional function. Also is the current group leader is damaged or
disabled, another node can take the charge and act as ’group leader’.
• Hybride star - mesh : In this topology, there is a more robust and
versatile communications network. Also it maintains the wireless sen-
sor node power consumption to the minimum. In this topology lowest
power sensor node is not capable of forwarding messages. It allows
for minimal power consumption to be maintained. On the other hand
other nodes of the networks have the ability with multihop capability,
that means they can forward messages from the low power nodes to
other nodes in the network.
• Self Healing Ring : In this topology, there are two rings as compared
to one ring of ’Ring Topology’ and is more fault tolerant.
Figure 6.3: Basic Network Topologies
44

46. Figure 6.4: Hybrid Star-Mesh Network Topology
45

47. 6.2 Applications of Wireless Sensor Networks
Various fields of applications of wireless sensor networks are :
• Environment Monitoring
• Acoustic Detection
• Seismic Detection
• Military Surveillance
• Inventory Tracking
• Medical Monitoring
• Smart Spaces
• Process Monitoring
• Green House Monitoring
• Landslide Detection
• Machine Health Monitoring
• Water Monitoring
• Agriculture Sector
• Medical Sector
6.2.1 Advantages of WSN
Advantages of WSN are :
• Implementation cost is cheaper than wired network.
• Ideal for temporary network setups.
• Ideal for the non reachable such as across river or mountains or rural
areas.
46

48. 6.2.2 Disadvantages of WSN
Various disadvantages of WSN are :
• Lower speed compared to wired network.
• Less secure because hacker’s laptop can act as acess point.
• More complex to configure than wired network.
• Can be affected by surrounding’s. For example, walls(blocking), mi-
crowave oven(interference), far distance.
• Sensor node has low battery power, so as battery goes down, node
goes down and so does the whole network.
6.3 Advantages and Disadvantages of Sensor
Network Topology
All topologies have various advantages and disadvantages :
• Ring : In this topology, one node failure causes whole network failure
and also messages can travel only in one direction.
Advantage is that each node is equal and no node is leader.
• Star : In this topology, if hub is damaged the whole network is dam-
aged.
Advantage is that if one node is cut of there is no effect on another
node.
• Bus : In this topology, there is no retransmitting capacity for each
node.
Advantage is that it is very simple to implement.
• Tree : In this topology, if root node is damaged then whole network is
damaged.
Advantage is that we can add priority according to structure or posi-
tion of nodes.
• Fully Connected : In this topology, implementation is difficult and
also routing problem is there if there is increase in network.
Advantage is that direct communication is achievable and all nodes
are identical.
• Mesh : In this topology, it can only be expanded with the same number
of nodes in both direction as it is having a square relation between the
47

49. nodes.
Advantage is that all nodes have equal priority and are identical. If
one node is damaged another node takes on the responsibility. It is
good for large scale network over a geographical region.
6.4 Conclusion
Wireless sensor networks already has huge application in various sec-
tors and fields inspite of some limitations one of which is ’low battery
power capacity’ which is also its main drawback. Still its applications
are increasing day by day. Also a thing to keep a check on in sensors
applications is its topology. We have various options and every topol-
ogy is having Pros and Cons.
The applications of WSN will increase in near future and its draw-
backs will hopefully reduce significantly as lot of research is goin on
both internationally and at domestic level in this field.
48

50. Bibliography
[1] Wireless Sensor Networks, F. L. LEWIS, Associate Director for Re-
search, Head, Advanced Controls, Sensors, and MEMS Group, Au-
tomation and Robotics Research Institute, The University of Texas at
Arlington, 7300 Jack Newell Blvd. S, Ft. Worth, Texas 76118-7115
[2] Wireless Sensor Network Topologies, May 1, 2000 By:
Wayne W. Manges, http://www.sensorsmag.com/networking-
communications/wireless-sensor-network-topologies-778
[3] Wireless Sensor Networks: Principles and Applications, Chris
Townsend, Steven Arms, MicroStrain, Inc.
49

51. Chapter 7
Collection Tree Protocol
7.1 Introduction
Collection tree’s are a core building block for sensor network application
and protocols. In their simplest use, collection tree’s provide an unreliable,
datagram routing layer that is used to gather data. Further collection proto-
cols provide the topology underlying most point to point routing protocols
such as BVR, RCRT etc. Despite the fact that it has played key role in
many systems, collection tree has some persistent problems if we look at it’s
history.
There are some key principles that are used for designing the collection
protocols to simultaneously achieve the following goals :
• Reliability : A collection tree protocol should deliver at least 90%
of end to end packets when a route exists even under worse network
condition.
• Robustness : It should be able to operate without tuning or configu-
ration in a wide range of network condition, topologies, workload and
environments.
• Efficiency : We can achieve this reliability and robustness while send-
ing few packets.
• Hardware Independence : Sensor networks use a wide range of plat-
forms, the implementation should be robust, reliable and efficient with-
out assuming specific radio chip features.
Achieving these goals depends on link estimation, accuracy and agility.
7.2 Introduction to CTP - TEP 123
CTP is a tree based collection protocol. Some number of nodes in a network
advertise themselves as tree roots. CTP has some special features like :
50

52. • CTP is address free.
• A node does not send packet to a particular root.
• CTP implicitly chooses a root by choosing a next hop.
• Node generate routes to root using a routing gradient.
7.2.1 Assumptions
But for doing so, CTP assumes that data link layer provides following four
things :
• The layer provides an efficient local broadcast address.
• It provides synchronous acknowledgement for unicast packet.
• It provides protocol dispatch field to support multiple higher level
protocol.
• The layer has single hop source and destination address.
7.2.2 Some other Random Assumptions
There are some other assumptions also which are listed below :
• It has link quality estimates of some number of nearby neighbours.
• These provide an estimate of the number of transmission it takes for
the node to send a unicast packet whose acknowledgement is success-
fully received.
7.2.3 Collection and CTP
CTP uses expected transmission as its routing gradient. A root has EXE 0.
The EXE of a node is the EXE of its parent node and the EXE of its link
to its parent node. In this case nodes uses link level transmission.
For choice of valid routes :
• The CTP choose the one with the lowest EXE value.
• CTP represent ETX values as 16 bit fixed point real number with 100
precision.
7.2.4 Routing Loop
A routing loop is a problem in a CTP network. A routing loop generally
occurs when a node choose a new route that has a higher value of ETX than
its old value of ETX.
A loop occurs when new routes include a node which was descendent.
51

53. 7.2.5 CTP Address Loop Mechanisms
There are two CTP address loop mechanisms :
The First Mechanism is :
• Every CTP packet contains the current gradient value of a node.
• An inconsistency occurs when a CTP receives a packet with a gradient
value and it is lower than its own gradient value.
The Second Mechanism is :
• The second mechanism of CTP does not consider routes with an ETX
higher than a reasonable constant.
• The value of the constant is implemented and is dependent.
7.2.6 Solving Of Inconsistency
Ways of solving inconsistency is :
• By broadcasting a beacon frame.
• Then the node that sent the data frame will hear it and adjust its
routes.
7.2.7 Packet Duplication
Packet duplication is another problem in CTP and various reasons for it are
listed below :
• When a node receives a packet successfully and transmit an acknowl-
edgement but the sender does not receive the acknowledgement.
• So the sender re-transmit’s the packet again and receiver receives it
for the second time.
Packet Duplication in Multihop
In multihop :
• The duplication is exponential.
• If each hop produces one duplicate, the second hop produces 4, third
produces 8, that means it grows 2n form.
Field definitions are as follows :
52

54. Figure 7.1: CTP Data Frame
53

55. • P : Routing pull. The P bit allows nodes to request routing information
from other nodes. If a node with a valid route hears a packet with the
P bit set, it SHOULD transmit a routing frame in the near future.
• C: Congestion notification. If a node drops a CTP data frame, it
MUST set the C field on the next data frame it transmits.
• THL : Time Has Lived. When a node generates a CTP data frame,
it MUST set THL to 0. When a node receives a CTP data frame,
it MUST increment the THL. If a node receives a THL of 255, it
increments it to 0.
• ETX : The ETX routing metric of the single-hop sender. When a node
transmits a CTP data frame, it MUST put the ETX value of its route
through the single-hop destination in the ETX field. If a node receives
a packet with a lower gradient than its own, then it MUST schedule
a routing frame in the near future.
• origin : The originating address of the packet. A node forwarding a
data frame MUST NOT modify the origin field.
• seqno : Origin sequence number. The originating node sets this field,
and a node forwarding a data frame MUST NOT modify it.
• collect id : Higher-level protocol identifier. The origin sets this field,
and a node forwarding a data frame MUST NOT modify it.
• data : the data payload, of zero or more bytes. A node forwarding a
data frame MUST NOT modify the data payload.
Figure 7.2: Origin Packet
54

56. Figure 7.3: Packet Instance
Figure 7.4: CTP Routing Frame
55

57. • P: Same as data frame.
• C: Congestion notification. If a node drops a CTP data frame, it
MUST set the C field on the next routing frame it transmits.
• parent: The node’s current parent.
• metric: The node’s current routing metric value.
In order to implement CTP it has three major subcompnonents :
• A Link Estimator : It is responsible for estimating the single hop ETX
of communication with single hop neighbours.
• A Routing Engine : It uses link estimates as well as network level
information to decide which neighbour is the next routing hop.
• A Forwarding Engine : It maintains a queue of packets to send. It
decides when and whether to send data or not. It is also responsible
for forwarded traffic.
Link Estimator
In this case the implementation uses two mechanisms to estimate the quality
of a link, periodic LEEP packets and DATA packets. The implementation
sends routing beacons as LEEP packets. These packets send the neighbour
table with bidirectional ETX value. The implementation reset the timer to
a small value when one or more of the following conditions are met.
• If the routing table is empty.
• The nodes routing ETX increases by ≥transmission.
• The node hears a packet with P bit set.
Additionaly, the rate at which CTP collects data estimates is proportional
to the transmission rate. Also it can quickly detect a broken link and switch
to another candidate neighbour.
Routing Engine
It is responsible for picking the next hop for a data transmission. It keeps
track of the path ETX values of a subset of nodes and it is maintained by
the link estimation table.
56

58. Forwarding Engine
It has four responsibilities :
• Transmitting packets to the next hop, retransmitting when necessary
and passing acknowledgement based information to the link estimator.
• It also takes decision when to transmit packet.
• It also detects routing inconsistencies and informs the routing engine.
• It also detects single hop transmission duplication caused by acknowl-
edgement.
7.2.8 Four Key Function
There are four main key functions in CTP protocol :
• Packet Reception [SubReceive.receive( ) ]: It decides whether or not
the node should forward packet. It checks for duplicates using a small
cache or recently received packets. If it decides a packet is not dupli-
cate, it calls the forwarding function.
• Packet Forwarding [ forward ( ) ] : It formats the packet for forwarding.
It also detects loop by checking the received packets. It also checks
whether there is a space in transmission queue. If there is no space
then it drops the packet.
Set the C bit. If the transmission queue is empty it posts the send
task.
• Packet Transmission [sendTask ( ) ] : It also examines the packet at
the head of the transmission queue.
• Packet Examination [ SubSend.sendDone ( ) ] : It examines the packet
to see the result. If the packet was acknowledged, it pulls the packet
off the transmission queue. If the packet is locally generated it signals
sendDone( ) to the client above. If the packet is forwarded it returns
the packet to the forwarding message pool.
If there are packets remaining in the queue (was not acknowledged) it
starts a timer which is random that reposts the tasks.
7.2.9 Limitation of CTP
There are various limitations of CTP :
– Although CTP has several mechanisms in order to improve de-
livery but does not promise 100% delivery.
57

59. – It is designed for low traffic rates.
– CTP is best effort, but best effort tries very hard.
Figure 7.5: Sample Structure of CTP Node Deployment
58

60. Bibliography
[1] The Collection Tree Protocol (CTP), TEP 123
59

61. Chapter 8
Received Signal Strength
Indicator - RSSI
8.1 Introduction
In wireless sensor networks (WSN) there are three main principles of mea-
surement that can be used to obtain distances and to measure distance is
necessary to obtain the position of the sensor node.
Three main principles are given below :
• Received Signal Strength Indicator (RSSI)
• Angle of Arrival
• Propogation Time Based. It includes -
– Time of Arrival
– Round Trip - Time - of - Flight
– Time Difference of Arrival
8.2 RSSI Method
Here we will discuss the RSSI in detail in Wireless Sensor network.
8.2.1 Introduction
Some basic characteristics of RSSI are :
• Received signal strength indication is a measurement of the received
signals power.
• Radio frequency signals : Power decreases with the distance.
loss(dB)Loss(db)=20log(d)+20log(f)+32.45
d = km,f = MHz
60

62. • We know communication frequency and transmit power. So, if we can
measure received signal’s power. We can find the distance ’d’.
Received power = Transmitted power - Path loss.
• In telecommunication, received signal strength indicator (RSSI) is a
measurement of the power present in a received radio signal.
• RSSI is an acronym for received signal strength indication. It is a
measure of the signal power on the radio link, usually in the units of
dBm while a message being received.
Figure 8.1: RSSI Method
8.2.2 Use of RSSI
Various uses of RSSI are listed below :
• RSSI can be used for estimating node connectivity and node distance.
• Another usage of RSSI is to sample the channel power, when no node
is transmitting to estimate the background noise also called noise floor.
8.2.3 Caution to Use RSSI in TinyOS
Various cautions to be taken while using RSSI in TinyOS are listed below :
61

63. • The RSSI data is not provided by the standard platform independent
hardware interface layer.
• RSSI must be accessed by a platform specific HAL interface.
• The RSSI values given by the TinyOS are usually not in dBm units and
should be converted by the platform specific relation to get meaningful
data out of it.
8.2.4 Intercept Base
It is a modified version of the Base station component that provides the
Intercept interface to allow the user application to inspect and modify radio
and serial messages before they are forwarded to the other link and to decide
whether they shall be forwarded or not.
8.2.5 Sending Node
Sending Node is the application to be put in the node that sends the mes-
sage whose RSSI will be ready by the base. It contains a simple logic to
periodically send a RSSI Msg.
8.2.6 RSSI Base
Various Characteristics of RSSI base are :
• It is the application that will be put in a node connected to the serial
port and will effectively read RSSI.
• It uses the Intercept Base component to forward the messages over the
radio but Intercept the RSSIMsg before it is forwarded and also the
RSSI value is included.
• It contains some cryptic macros so that it can work correctly with
chips that use either the CC2420 or CC1000 radio.
• It always forward the messages but modifies the payload by include
the RSSI.
8.2.7 Java Application
A java application called RSSIDEMO was created to see the results on the
computer. The output would be like this :
• RSSI Message received from node 1 : RSSI = -14.
• RSSI Message received from node 1 : RSSI = -1.
• RSSI Message received from node 1 : RSSI = 2.
62

64. 8.2.8 Advantages of RSSI Method at Localisation
Various advantages of RSSI Method are :
• No directional sensor like ultrasonic systems.
• Indoor and Outdoor usage.
• Data communication and sensor usage at the same hardware.
8.2.9 Difficulties at RSSI Method
Distance calculation is related RF signal power receiver :
• Multiple Propagation.
• Fading Effects.
• Bad frontend devices
63

65. Bibliography
[1] Received signal strength indication (RSSI), RSSI Demo
64

66. Chapter 9
Energy Efficient Topologies
9.1 Introduction
The performance of wireless sensor networks (WSNs) is greatly influenced
by their topology. WSNs with patterned topologies can efficiently save en-
ergy and achieve long networking lifetime. Energy efficiency is one of the big
issue in wireless sensor networks. As we know a sensor network consists of
collection of sensor node and each node has limited energy .If one node fails
it is disconnected from other node and the connectivity of networks fails.
Energy is a scarce resource for this class of devices. Mostly running on
batteries as energy source the improvement of energy-efficiency and power
management are becoming ever important research topics. Considering com-
mon application profiles for Wireless Sensor Networks (WSN).
In this paper we describe three energy efficiency approaches.
In the first approach we described, towards cooperative energy management
in wireless sensor networks using online battery monitoring. It is a simple
concept for measuring the battery voltage on the mote with little additional
hardware is shown. This is used for modelling of the battery discharge be-
havior of Li-Ion batteries and deriving the remaining lifetime under given
environmental conditions.
In the second approach we describe, the various kind of topologies in wire-
less sensor network with respect to minimum energy conservation. WSNs
with patterned topologies can efficiently save energy and achieve long net-
working lifetime. We discuss different patterned topologies for constructing
WSNs which can provide the required coverage area and the connectivity
of all sensor nodes. Different performance measures among all patterned
topologies are compared, and find that WSNs in strip-based topology can
provide the greatest coverage area with the same number of sensor nodes
as used for WSNs in other patterned topologies. Strip-based topology also
consumes least energy in the routing protocol of flooding. We also describe
several routing protocols for WSNs in patterned topologies, which are based
65

67. on different parameters when selecting next-hop neighbor.
An ad hoc network is a wireless decentralized structure network and it is
comprised of nodes, which autonomously set up a networks.There is no
external network infrastructure is necessary to transmit data there is no
central administration. Freely located network nodes participate in trans-
mission. In the third approach we discuss two efficient energy conservation
topologies. It is location based protocol LMST (Local Minimum Spanning
Tree) and R and M protocol.
9.2 Analysis of Energy-efficient Topology control
for WSN’s using Online Battery Monitoring
9.2.1 Introduction
Wireless Sensor Networks (WSN) offers a broad range of applications, from
industrial surveillance over security to medical monitoring. Another emerg-
ing application of WSN systems is the monitoring of perishable or sensitive
freight in logistics. Energy is a scarce resource for this class of devices.
Mostly running on batteries as energy source the improvement of energy-
efficiency and power management are becoming ever important research
topics. Because the power of sensor network for communication among the
nodes depends on the battery energy of the node. As the node battery
power is very limited so it is very important to utilize the battery power of
the sensor node and also life time of the sensor network s depends on the
battery power.
9.2.2 Architecture for Wireless Sensor Network systems
The basic elements of Wireless Sensor Networks are the network nodes or
mainly referred to as motes. These motes consist of an RF-transceiver, a
microcontroller for protocol processing and sensor interfacing, sensors for
measuring.
The use of flash memory allows the remote nodes to acquire data on com-
mand from a base station, or by an event sensed by one or more inputs to
the node. Furthermore, the embedded firmware can be upgraded through
the wireless network in the field.
The microprocessor has a number of functions including :
• Managing data collection from the sensors.
• Performing power management functions.
• Interfacing the sensor data to the physical radio layer.
• Managing the radio network protocol.
66

68. A key feature of any wireless sensing node is to minimize the power consumed
by the system. Generally, the radio subsystem requires the largest amount
of power. Therefore, it is advantageous to send data over the radio network
only when required.
Figure 9.1: Wireless sensor node functional block diagram
9.2.3 Energy consumption of WSN components
A hardware platform based on the commercially available TmoteSky sys-
tem by Moteiv Corporation is used here. These systems use the IEEE
802.15.4-compliant RFtransceiverCC2420 and the 16-bit low-power micro-
controllerMSP430F1611, both from Texas Instruments. The following mea-
surements were made for the sending of a data message (41 bytes) and the
reading of the internal temperature sensor in the microcontroller. The re-
sults are shown in Table below : From the table We can say that adaptively
tuning the output power of the transceiver and decreasing communication
overhead may drastically improve energy efficiency of a single mote and this
may increase the network lifetime.
9.2.4 Battery technologies for WSN systems
In this case Batteries are the common energy sources for motes. Although
energy harvesting may be an option for certain application where there is
enough energy in the surroundings of the WSN system. When sensor nodes
67

69. Figure 9.2: Comparison of power consumption
are surrounded by air ,light etc then there is enough energy. Considering
logistics as an application the amount of energy being harvested is much too
low to power a mote sufficiently. If we consider the discharge curves of the
Figure 9.3: Li-Ion and NiCd/NiMH battery behaviour.
most common types of secondary cells, NiCd and NiMH cells behave almost
equally with almost flat discharge behaviour while Li-Ion batteries have a
constant negative slope.
There is a advantage of this feature of the Li-Ion cells discharge character-
istic offers the advantage of computing the remaining capacity of the bat-
tery when the actual load and the temperature of the battery are known.
Li-Ion batteries are more favourable then using Ni-based batteries because
the small slopes of Ni-based batteries impose higher demands on the mea-
surement of the voltage as small changes in output voltage result in larger
changes in discharge capacity. Therefore, I-Ion cells were selected due to
68

70. their higher energy density and their behaviour towards discharge model-
ing.
9.2.5 Battery monitoring
There are some advantages using Li-Ion batteries. These kind of batteries
are more favourable for modelling due to their higher negative slope. This
enables the usage of the internal AD-converter of microcontroller of the
mote. It offers a sufficient resolution of 12 bits for the measurement of the
battery voltage.
9.2.6 Circuitry and Measurements
In order to measurement setup it is required minimum additional hardware
for the mote system. To verify this setup a series of measurements is taken
under controlled temperature using a constant load. As selected battery is
The Panasonic CGA103450A cell with a nominal output voltage of 3.6V.
The results for 10 C and 10 C are also shown in figure given below and
reflect the temperature dependency of the discharge behaviour.
Figure 9.4: Measurement setup and resulting graphs for 10 C and 10 C.
Modelling
By using these measurements, a simple numeric model is generated by divid-
ing the discharge curve into two phases: first is normal operation and second
is post-cut-off. One can get the normal operation for the slightly decreasing
slope. Post-cut-off is given just before the battery is empty. Both phases can
be described by a simple linear model as a set of four numerical parameters
c0 to c3, the temperature v and the output voltage of the battery Vout in
the following equation :
C = (c0 + c1 v) + (c2 + c3 v) Vout. (1) Furthermore a cut-off capacity
69

71. Figure 9.5: Approximated discharge characteristics with Varying Tempera-
ture
is defined which clearly marks the border of the two operational phases.
Ccutoff = Cbase + c4 .v........................................................... (2)
Here Cbase is a numerically found base capacity and constant c4 is the
slope of the cut-off capacity with varying temperature ’v’.The switch-over
between these phases is realized by using a different parameter set (c0 to c3)
for Eq. (1). The maximally usable capacity can be calculated by defining an
end-point voltage which is used in adding Eqs. (2) and (1) with the cut-off
parameters.
The endpoint voltage dependable. For example it is dependent on the used
voltage regulator type and the minimum system supply voltage. It can be
obtained by simply subtracting the current capacity from this maximum
capacity, the residual capacity is calculated.
9.2.7 Conclusion
It is an emerging field of research and that is the need for information on
residual energy in wireless sensor networks. The temperature behaviour of
batteries has strongly affect the residual energy and thereby the performance
of the network. Based on a standard platform, a simple measurement setup
and acomputationally simple linear model was developed which is capable
of calculating the residual energy as a function of temperature directly on
the mote.
70

72. 9.3 Energy-Efficient Topologies and Routing for
Wireless Sensor Networks
9.3.1 Introduction
The right kind of topology is must to get optimum performance from wireless
sensor networks (WSNs). WSNs with patterned topologies can efficiently
save energy and achieve long networking lifetime. We have a look at dif-
ferent patterned topologies for constructing WSN’s which can provide the
required coverage area and the connectivity of all sensor nodes and also are
highlighted the performance measures of each kind of topology. Then we
discuss several routing protocols for WSNs in patterned topologies, which
are based on different parameters when selecting next-hop neighbor.
9.3.2 Modelling Connected-Coverage WSN’s
In this model some important parameters that effect the performance of
WSN’s are featured : Connected-Coverage WSN’s is defined as network that
can ensure the coverage and connectivity within specified and described area
between the sensor nodes.
We assume the region to be 2-dimensional. Assume the area of the region to
be ’A’ and sensor nodes ’N’ and one base station placed in the region. Each
node participating can sense the event and collect data within a circular
region with radius rs , centre point being the node itself. No two nodes can
communicate with each other if the Euclidean distance (distance calculated
by Pythagorean formula) between them is maximum rt , that is, nodes s1
and s2 can communicate with each other if their Euclidean distance Ed(s1 ,
s2 ) ≤ r t .
The sensing ability of each sensor node diminishes as distance increases.
The sensing ability at point ’y’ of sensor node si is assumed to be inversely
proportional to Ed(si , y)k where ’k’ is a sensor technology-dependent param-
eter. This characteristic of sensor nodes introduces an important parameter,
we call it sensing strength factor dmm , stating how well region A is covered
and sensed. If we define mini Ed(si , y) as the distance of point y to its clos-
est sensor node, y ∈ A, then all points in A have a distance at most maxy A
mini Ed(si , y). We use dmm to denote this distance :
dmm = maxy A mini Ed(si , y)A .
Thus dmm is the maximum distance from any point to its closest sensor
node. The power consumption is another important parameter to measure
how much energy different topology patterns can save for WSNs. Each
sensor node includes :
71

73. • Sensing unit.
• Processing unit.
• Transceiver unit.
• Power unit.
Based on these ’power consumption’ can be divided into three domains :
• Sensing.
• Communication.
• Data Processing.
Out of these three our area of concern is with the maximum energy spent by
a sensor node in data communication which involves both power consumed
in data transmission, denoted by Pt , and in data reception, denoted by Pr .
That is, the power consumed by a sensor node is Ps = P t + Pr .
Patterned Topologies for Connected-Coverage WSNs :
In this section we discuss various topology patterns with a fixeed criteria
of having 25 sensor nodes and then compare performance of WSN’s under
those patterns :
WSN’s with Hexagon-Based Topology :
In hexagon-based WSNs, each sensor node has three neighbour nodes located
uniquely around the node and connection to the neighbour nodes are made
in such a way that it obtains the minimum unit in the shape of hexagon and
that is why it is called as Hexagon-Based WSN. The distance between two
neighbouring nodes is set to be rt so that direct communication is available
between them and each neighbor provides maximal additional sensing area.
A figure is given below and in that node 06 is assumed to be aggregation
node which plays the role of aggregating the sensed information in the WSN
and reporting to the base station.
WSN’s with Square-Based Topology :
In square based node each sensor node has four neighbour nodes located
around it and connection is made in such a way that it obtains the minimum
unit in shape of a square.The distances of the node to its neighbor nodes
are set to rt and node 04 is assumed to be the aggregation node.
72

74. Figure 9.6: A WSN with hexagon-based topology
Figure 9.7: A WSN with square-based topology
73

75. WSNs with Triangle-Based Topology :
In triangle-based WSNs each sensor node has six neighbour nodes located
around it and connection is made in such a way that it obtains the minimum
unit in shape of triangle.The distances of the node to its neighbor nodes are
set to rt and node 04 is assumed to be the aggregation node. In this topology
we find that every point within the area is covered by at least two sensor
nodes and the reliability provided by such kind of node placement is called
2-reliability. A 2-reliability WSN can maintain its connected-coverage for
any single sensor node failure. When every point is covered by at least k
sensor nodes, the sensor network is called k-reliability. The WSNs with
other patterned topologies are 1-reliability.
Figure 9.8: A WSN with triangle-based topology
WSNs with Strip-Based Topology :
We know that to maintain the connectivity, the distance between two nodes
should not be more than rt . So in order to maximise the coverage area with
same no of nodes, strip-based topology may be used.The strip-based WSN
below given figure clearly shows that sensor nodes 40, 41 and 42 connect 4
self-connected strips 00 - 05, 10 - 14, 20 - 25 and 30 - 34. By this way of node
placement, these sensor nodes construct a connected WSN with strip-based
topology. The total number of sensor nodes is 25 as before and here we
assume node 05 to be the aggregation node.
74

76. Figure 9.9: A WSN with strip-based topology
75

77. 9.3.3 Performance Comparison :
Now we compare the above four types of patterned topologies on basis of :
• Coverage area.
• Sensing strength factor.
• Reliability.
• Energy consumption.
We assume rt = rs = r in all WSN’s.
For coverage area comparison we do not consider the marginal places cov-
ered by edge sensor nodes because it occupies negligible portion of whole
coverage area.
For energy consumption comparison, we fix the destination to be the ag-
gregation node as designated above. The source is fixed to be a node with
distance ’4r’ from the destination. In this case, the less the energy is con-
sumed, the better the node placement pattern is.
The following table gives the results of these performances comparison.
Figure 9.10: Performance comparison among WSNs with different patterned
topologies
Looking at the table we can see that strip-based topology provides maxi-
mal connected-coverage with the same number of sensor nodes and consumes
least energy by the routing protocol of flooding. WSNs in triangle-based
topology provide the best reliability and the best sensing strength while
trading off total coverage area and energy consumption. These conclusions
hold when comparison is performed in general cases of large-scale WSNs.
76

78. Routing Protocols in Patterned WSNs :
Several routing protocols which only require local information and this way
they are different from Directional Source-Aware Protocol (DSAP) where
each node must have the knowledge of global information of topology are
highlighted.
We define a routing selection function f(h, s) for a sensor node to choose
neighbor nodes when routing the message back to the aggregation node.
The function is determined by the hop count value ’h’ of neighbor nodes
and stream unit ’s’ which has been sent by neighbor nodes. We denote the
battery life of sensor node i by bi .
There are three approaches to route back the message for different aims. All
of them are based on the routing selection function f(h, s) = α h + β s.
• Maximize the total energy saving for WSNs, i.e., B = i bi : This can
be obtained by minimizing first the hop count value ’h’ when choosing
next-hop neighbor and then minimize ’s’. In this case, α = 1, andβ =σ,
where σ is a small number which approximates to 0.
• Maximize the minimal energy maintained by all sensor nodes, i.e.,
mini bi : This can be obtained by minimizing first the stream units ’s’
of next-hop neighbour and then ’h’. In this case, α = σ, andβ = 1.
• Maximize both the total energy and minimal energy of all sensor nodes.
This can be obtained by minimizing both ’h’ and ’s’. In this case, α =β
= 1.
We name the protocols as routing selection function-based protocols. It
works as follows :
• Distance identification : The aggregation node floods the discovery
message in the WSN with a determined TTL value. Each sensor node
records its distance from the aggregation node by hop count. If a
sensor node receives several broadcast messages, it records the least
value of hop count.
• Data collection: When a sensor node senses any abnormal event and
needs to report the event, it chooses a neighbor with minimized f(h,
s) to route back the message.
From Figure given below, we can see that Approach 1 provides least
network lifetime. Approach 2 gets a longer lifetime than approach 1
and, however, trades off much more energy consumption by choosing
a longer path to the aggregation node in the WSN. Approach 3 can
provide the longest lifetime, which is almost as twice as that provided
by Approach 1 because it tries to find a shorter path and a next-hop
neighbor with more energy in every step.
77

79. Figure 9.11: Energy consumption and lifetime comparison among three ap-
proaches
9.4 Wireless Sensor Networks Energy-Efficient Topolo-
gies
9.4.1 Introduction to Ad Hoc and Wireless Sensor Networks
Ad hoc networks are the ultimate technology in wireless communication that
allows network nodes to communicate without the need for a fixed infras-
tructure. In this we describe addresses issues associated with control of data
transmission in wireless sensor networks (WSN) a popular type of ad hoc
networks with stationary nodes. Since the WSN nodes are typically battery
equipped, the primary design goal is to optimize the amount of energy used
for transmission.
An ad hoc network is a wireless decentralized structure network and it is
comprised of nodes, which autonomously set up a networks.There is no exter-
nal network infrastructure is necessary to transmit data there is no central
administration. Freely located network nodes participate in transmission.
Network nodes can travel in space as time passes, while direct communica-
tion between each pair of nodes is usually not possible. Generally, ad hoc
network can consist of different types of multi functional computation de-
vices.
Wireless sensor network (WSN) is most often set up in an ad hoc mode by
means of small-size identical devices grouped into network nodes distributed
densely over a significant area. Each device is equipped with central pro-
cessing unit (CPU), battery, sensor and radio transceiver networked through
78

80. wireless links provide unparalleled possibilities for collection and transmis-
sion of data and can be used for monitoring and controlling environment,
cities, homes, etc. In most cases WSNs are stationary or quasi-stationary,
while node mobility can be ignored. There is no prearrangement assumption
about specific role each node should perform. Each node makes its decision
independently, based on the situation in the deployment region, and its
knowledge about the networks. When the networks consist of hundreds of
nodes then it is necessary to make a physical architecture for a wireless sen-
sor networks. WSNs need some special treatment as they have unavoidable
limitations, for example, limited amount of power at their disposal. Each
battery powered device, participating in WSN needs to manage its power in
order to perform its duties as long, and as effective as possible.
9.4.2 Communication Methods
For the communication in wireless sensor networks there are some commu-
nication issues .These issues are given below :
Limited Resources
A sensor networks consists of nodes and these are an often small battery-fed
device, which means their power source is limited. The networks through-
put is also limited.
Poor Quality of Connection
In the wireless sensor networks the quality of wireless transmission depends
on numerous external factors, like weather conditions or landform features.
Part of those factors change with time. So, there must have some limitations
in communication in wireless sensor networks.
9.4.3 Small Communication Range
It is one of the main problems of wireless sensor networks. Small communi-
cation range in WSN networks results in communication limitations. Each
node communicates only with the nodes present in its closest vicinity the
neighbors .For this reason, the natural communication method in wireless
sensor networks is the multihop routing. When using multihop routing, it is
assumed that the receiving node is located outside the transmitters range.
Contrary to single-hop networks, the transmitter must transmit data to the
receiver by means of intermediate nodes. This is a certain limitation that
hinders the implementation of routing algorithms but enables the construc-
tion of network of greater capacity. Multihop network enables simultaneous
transmission via many independent route Independence of routes reduces
the interference between individual nodes, which additionally enhances the
79