FYP0703 With Appendix

IEEE 802.15.
4/ZigBee Network Lifetime Optimization
Batch: 2007
Group ID: FYP0703
Usman M. Nooruddin 07-0039

Bilal Waheed Siddique 07-0070
Internal Advisor:
Engr. Daud Amir Channa (FYP I)
Engr. Nadeem Kafi Khan (FYP II)
Department of Electrical Engineering

National University of Computers & Emerging Sciences FAST
Karachi Campus
December 2011
ii
ACKNOWLEDGEMENT
We would like to gratefully thank everyone who assisted us in making this project a reality. Without their
colossal support, this Final Year Project would have just remained a blue print.
We would like to take this opportunity to thank our parents, since without their tremendous support, it would
have been extremely tough for us to cope with the haphazard schedule that we had laid out for ourselves.
Again, we would take the opportunity present our sincerest thanks to Sir Daud Amir Channa, who fascinated
us with his wide experience in Wireless Sensor Networks and humored us in every way possible, to relax us
and to show us a far shorter path realizing the fact of our inexperience during the FYP-I.
We would also like to thank most sincerely, Sir Nadeem Kafi Khan, for making us believe that what we set to
achieve was achievable and inducing practical thinking in us so we could realize the details of our work
incorporate them into this project.
We dedicate this project to Sir Daud Amir Channa, for inspiring us to do more than we thought we could ever
accomplish, for setting a higher standard and showing us a way to achieve it, for making us believe in
ourselves and trusting our instincts as engineers.
Usman M. Nooruddin 07-0039
Dated: December 2011
iii
TABLE OF CONTENTS
Acknowledgement iii
Abstract vii
CHAPTER 1 INTRODUCTION 1
1.1 Introduction 1
1.2 Problem Statement 1
.1 Project Aims 1
.2 Project Goals 1
1.3 Tools Used 1
.1 OMNeT++ 1
.2 INET Framework 2
.3 MiXiM 2
1.4 Professional Standards 2
CHAPTER 2 IEEE 802.15.4 / ZigBee 3

2.1 Introduction 3
.1 Evaluation of Low-Rate Wireless Personal Area Network (LR-WPAN) Standardization 3
.2 ZigBee and IEEE 802.15.4 3
.3 Why is it called ZigBee? 4
2.2 IEEE 802.15.4 4
.1 General Description 4
.2 ZigBee Characteristics 4
.3 Device Types 5
.4 Network Topologies 5
.1 Star Topology 6
.2 Peer-to-Peer (Ad-Hoc)Topology 6
.3 Cluster-tree Topology 7
.4 Mesh Topology 7
2.3 Architecture 8
.1 Network and Application Support Layer 9
.2 Physical (PHY) Layer 9
.3 Media Access Control (MAC) Layer 9
2.4 Applications 10
.1 Types of Applications 10
.2 Application Examples 10
CHAPTER 03 RELATED WORK 13

3.1 Related Work 13
.1 Annealing Sensor Networks 13
.2 Seminar Report on ZigBee 13
.3 A Simulation Model of IEEE 802.15.4 in OMNeT++ 13
.4 An Energy Model for Simulation Studies of Wireless Sensor Networks using OMNeT++ 13
.5 Performance Evaluation of IEEE 802.15.4 LR-WPAN for Industrial Applications 13
.6 Performance Limitations of IEEE 802.15.4 Networks and Potential Enhancements 13
.7 Simulating Queuing Networks with OMNeT++ 14
.8 Simulating Wireless Sensor Networks with OMNeT++ 14
.9 Simulation Tools for Wireless Sensor Networks 14
.10 Coverage-Time Optimization for Clustered Wireless Sensor Networks: A Power- 14
Balancing Approach
.11 Next Century Challenges: Scalable Coordination in Sensor Networks 14
iv
.12 Prolonging the Network Lifetime in WSN through Computational Intelligence 15
.13 Increasing ZigBee Network Lifetime with X-MAC 15
.14 A Holistic Approach for Optimizing Lifetime of IEEE 802.15.4/ZigBee Networks with 15
Deterministic Guarantee of Real-Time Flows
CHAPTER 04 PROBLEM STATEMENT 17

4.1 Energy Efficiency 17
4.2 Problem Statement 17
CHAPTER 05 PROPOSED SOLUTION 19

5.1 Proposed Solution 19
5.2 Proposed Scenario 19
5.3 Tools Used 22
.1 OMNeT++ 22
.2 INET Framework 22
.3 MiXiM 22
5.4 Simulation Setup 23
5.5 Drawing Results 23
5.6 Interpreting Results 23
CHAPTER 06 SIMULATION SETUP 25

6.1 Installation 25
.1 Installation of OMNeT++ 25
.2 Installation of INET Framework 25
.3 Installation of MiXiM 25
6.2 Simulation Setup 26
CHAPTER 07 RESULTS 33
7.1 Observed Results 33
CHAPTER 08 DISCUSSION OF RESULTS 37

8.1 Review of Results 37
8.2 Discussion of Results 37
CHAPTER 09 CONCLUSION 39
9.1 Conclusion 39
9.2 Advantages 39
9.3 Limitations 39
CHAPTER 10 FUTURE WORKS 41

10.1 Future Works 41
CHAPTER 11 LIST OF REFERENCES 43
APPENDIX 45
v
LIST OF FIGURES
Figure Title Page
2.1 Star Topology 6
2.2 Peer-to-Peer Topology 6
2.3 Cluster Topology 7
2.4 Mesh Topology 8
2.5 The ZigBee Stack 9
5.1 Proposed Scenario 21
6.1 OMNeT++ Main Window 26

6.2 New OMNeT++ Project... 27
6.3 Naming the Project File 28
6.4 Defining MiXiM as the framework 29
6.5 NIC Configuration 30
6.6 The created Project Files 31
LIST OF GRAPHS
Graph Title Page
7.1 Network Sequence Chart 34
7.2 Network Energy Graph 35
vi
ABSTRACT
IEEE 802.15.4/ZIGBEE NETWORK LIFETIME OPTIMIZATION
Although the ZigBee Alliance employs enough intelligence for a network to grant ZigBee devices a long
uptime, in certain conditions even the default device uptime is not enough.
In this project, we investigate how we can increase the Network Lifetime of a ZigBee network up time by
configuring the NWK layer of the ZigBee stack as to include the energy of the node in the packet, which would
be recorded by the ZigBee Coordinator.
When a packet would be routed through the ZigBee Coordinator, the ZigBee Coordinator would determine the
most economic route, in order to achieve higher Energy Efficient Routing.
Advisor:
Engr. Daud Amir Channa (FYP I) Engr. Nadeem Kafi Khan (FYP II)
Assistant Professor Assistance Professor
vii
[This page is intentionally left blank]
viii
Chapter 1 Introduction
CHAPTER 1
INTRODUCTION
1.1 INTRODUCTION:
IEEE 802.15.4 or ZigBee is a standards-based technology for remote monitoring, control and sensor network
applications. The ZigBee standard was created to address the need for a cost-effective, standards-based
wireless networking solution that supports low data-rates, low-power consumption, security, and reliability.
The technology defined by the ZigBee specification is intended to be simpler and less expensive than other
WPANs, such as Bluetooth. ZigBee is targeted at radio-frequency (RF) applications that require a low data rate,
long battery life, and secure networking.
Core markets include consumer electronics, energy management and efficiency, health care, home
automation, telecommunication services, building automation and industrial automation.
1.2 DEFINING THE PROBLEM
The current applications of the ZigBee transceiver are numerous, which also leads to much possible
advancements and enhancements. Most of the applications in various different criterions require only major
enhancement: Network Lifetime Prolongation.
The longer we can maintain the nodes alive, i.e., prolonging the battery life in the network, the better the
application and hence broaden the scope of the ZigBee Transceiver.
1.2.1 PROJECT AIMS
To bring modification to the NWK layer of the ZigBee Transceiver, so that it would store what are the
current energy levels of the one hop members.
To enable the NWK layer to decide accordingly as to which route to take in order to save energy.
To simulate our results and explain how we were able to accomplish this.
1.2.2 PROJECT GOALS
After the simulation, we would be able to tell as to how much we can enhance and prolong the
network lifetime of the ZigBee transceiver.
We would suggest the best and most convenient way to do so.
Research may further analyze other authors comparisons and observations with respect to our own
work.
1.3 TOOLS USED
1.3.1 OMNET++
OMNeT++ is a discrete event simulation environment. Its primary application area is the simulation of
communication networks, but because of its generic and flexible architecture, is successfully used in other
areas like the simulation of complex IT systems, queuing networks or hardware architectures as well.
OMNeT++ provides a component architecture for models. Components (modules) are programmed in C++,
then assembled into larger components and models using a high-level language (NED). Reusability of models
comes for free. OMNeT++ has extensive GUI support, and due to its modular architecture, the simulation
kernel (and models) can be embedded easily into your applications.
1
IEEE 802.15.4/ZigBee Network Life Optimization
1.3.2 INET FRAMEWORK:
The INET Framework is an open-source communication networks simulation package for

the OMNeT++ simulation environment. The INET Framework contains models for several wired and wireless
networking protocols, including:
UDP,
TCP,
SCTP,
IP,
IPv6,
Ethernet,
PPP,
802.11,
MPLS,
OSPF and many others.
1.3.3 MIXIM
MiXiM is an OMNeT++ modeling framework created for mobile and fixed wireless networks (wireless sensor
networks, body area networks, ad-hoc networks, vehicular networks, etc.). It offers detailed models of radio
wave propagation, interference estimation, radio transceiver power consumption and wireless MAC protocols
(e.g. ZigBee).
1.4 PROFESSIONAL STANDARDS:
This research project studies the implementation of a new Networking protocol that provides further
intelligence to the ZigBee Coordinators so that they can well manage the routing of packets from source to
sink.
This project complies with the standards set by:
IEEE 802.15.4
ZigBee Alliance
2
Chapter 2 IEEE 802.15.4 / ZigBee
CHAPTER 2
IEEE 802.15.4 / ZigBee
2.1 INTRODUCTION
The cellular network was a natural extension of the wired telephony network that became persistent during
the mid-20th century. As the need for mobility and the cost of laying new wires increased, the motivation for
a personal connection independent of location to that network also increased. Coverage of large area is
provided through (1-2km) cells that co-operate with their neighbours to create a seamless network. Cellular
standards basically aimed at facilitating voice communications throughout a metropolitan area. During
themid-1980s, it turned out that an even smaller coverage area is needed for higher user densities and the
emergent data traffic.
2.1.1 EVOLUTION OF LOW-RATE WIRELESS PERSONAL AREA NETWORK (LR-WPAN)

STANDARDIZATION
The IEEE 802.11 working group for Wireless Local Area Network (WLAN) was formed, to create a wireless local
area network standard. Whereas IEEE 802.11 was concerned with features such as Ethernet matching speed,
long range(100m), complexity to handle seamless roaming, message forwarding, and data throughput of 2-11
Mbps.
Wireless personal area networks (WPANs) are used to convey information over relatively short distances.
WPANs are focused on a space around a person or object that typically extends up to 10m in all directions.
The focus of WPANs is low-cost, low power, short-range and very small size.
The high data rate WPAN (IEEE 802.15.3) is suitable for multi-media applications that require very high
quality of services.
Medium rate WPANs (IEEE 802.15.1/Bluetooth) will handle a variety of tasks ranging from cell phones
to PDA communications and have QoS suitable for voice communications.
The low rate WPANs (IEEE 802.15.4/LR-WPAN) is intended to serve a set of industrial, residential and
medical applications with very low power consumption, with relaxed needs for data rate and QoS. The
low data rate enables the LR-WPAN to consume very little power. This feature allows small, power-
efficient, inexpensive solutions to be implemented for a wide range of devices.
We would be focusing on the IEEE 802.15.4 standard, commonly known as ZigBee in this chapter.
2.1.2 ZIGBEE AND IEEE 802.15.4
The IEEE 802.15.4 standard is a simple packet data protocol for lightweight wireless networks and specifies
the Physical (PHY) and Medium Access Control (MAC) layers for Multiple Radio Frequency (RF) bands,
including 868 MHz, 915 MHz, and 2.4 GHz. The IEEE 802.15.4 standard is designed to provide reliable data
transmission of modest amounts of data up to 100 meters or more while consuming very little power.
ZigBee technology takes full advantage of the IEEE 802.15.4 standard and extends the capabilities of this new
radio standard by defining a flexible and secure network layer that supports a variety of architectures to
provide highly reliable wireless communication. ZigBee technology also offers simplicity and a cost-effective
approach to building, construction and remodeling with wireless technology. ZigBee is all set to provide the
consumers with ultimate flexibility, mobility, and ease of use by building wireless intelligence and capabilities
into every day devices.
Thus, ZigBee technology is a low data rate, low power consumption, low cost, wireless networking protocol
targeted towards automation and remote control applications.
3
2.1.3 WHY IS IT CALLED ZIGBEE?
It has been suggested that the name evokes the haphazard paths that bees follow as they harvest pollen,
similar to the way packets would move through a mesh network. Using communication system, whereby the
bee dances in a zigzag pattern, worker bee is able to share information such as the location, distance, And
direction of a newly discovered food source to her fellow colony members. Instinctively implementing the
ZigBee Principle, bees around the world actively sustain productive itchiness and promote future generations
of Colony members.
2.2 IEEE 802.15.4 WPAN
2.2.1 GENERAL DESCRIPTION
A LR-WPAN is a simple, low-cost communication network that allows wireless connectivity in applications with
limited power and relaxed throughput requirements. The main objectives of an LR-WPAN are ease of
installation, reliable data transfer, short range operation, extremely low cost, and a reasonable battery life,
while maintaining a simple and flexible protocol.
The three license-free frequencies of the IEEE 802.15.4 standard include sixteen channels at 2.4 GHz, ten
channels at 915 MHz, and one channel at 868 MHz, to support global or regional deployment. The maximum
data rates for each band are 250 kbps, 40 kbps and 20 kbps, respectively. The air interface is direct sequence
spread spectrum (DSSS) using binary phase shift keying (BPSK) for 868 MHz and 915 MHz and offset-
quadrature phase shift keying (OQPSK) for 2.4 GHz.
Other features of the IEEE 802.15.4 PHY include receiver energy detection, link quality indication and clear
channel assessment. Both contention-based and contention-free channel access methods are supported.
Maximum packet size is 128 bytes, including variable payload of up to 104 bytes. IEEE 802.15.4 employs 64-bit
IEEE and 16-bit short addresses, which supports over 65,000 nodes per network.
The IEEE 802.15.4 MAC also enables network association and disassociation, has an optional super frame
structure with beacons for time synchronization, and a guaranteed time slot (GTS) mechanism for high priority
communications. The access method is carrier sense multiple access with collision avoidance (CSMA-CA).
Network routing schemes are designed to ensure power conservation, and low latency through guaranteed
time slots. A unique feature of ZigBee network layer is communication redundancy eliminating single point of
failure in mesh networks.
IEEE and ZigBee Alliance have been working closely to specify the entire protocol stack. IEEE 802.15.4 focuses
on the specification of the lower two layers of the protocol (physical and data link layer). On the other hand,
ZigBee Alliance aims to provide the upper layers of the protocol stack (from network to the application layer)
for interoperable data networking, security services and a range of wireless home and building control
solutions.
2.2.2 ZIGBEE CHARACTERISTICS
The focus of network applications under the IEEE 802.15.4 / ZigBee standard include the features of low
power consumption, needed for only two major modes (Tx/Rx or Sleep), high density of nodes per network,
low costs and simple implementation. These features are enabled by the following characteristics:
2.4GHz and 868/915 MHz dual PHY modes.

This represents three license-free bands: 2.4-2.4835 GHz, 868-870 MHz and 902-928 MHz. The
number of channels allotted to each frequency band is fixed at 16 channels in the 2.45 GHz band, 10
channels in the 915 MHz band, and 1 channel in the 868 MHz band
Maximum data rates allowed for each of these frequency bands are fixed as 250kbps @2.4 GHz, 40
kbps @ 915 MHz, and 20 kbps @868 MHz.
4
Allocated 16 bit short or 64 bit extended addresses.

Allocation of guaranteed time slots (GTSs)
Carrier sense multiple access with collision avoidance (CSMA-CA) channel access Yields high
throughput and low latency for low duty cycle devices like sensors and controls.
Fully hand-shake acknowledged protocol for transfer reliability.
Low power consumption with battery life ranging from months to years.
Energy detection (ED).
Link quality indication (LQI).
Multiple topologies : star, peer-to-peer, mesh topologies
2.2.3 DEVICE TYPES
ZigBee devices are required to conform to the IEEE 802.15.4-2006 Low-Rate Wireless Personal Area Network
(WPAN) standard. ZigBee wireless devices are expected to transmit 10-75 meters, depending on the RF
environment and the power output consumption required for a given application, and will operate in the
unlicensed Worldwide (2.4GHz global, 915MHz Americas or 868 MHz Europe). The data rate is250kbps at
2.4GHz, 40kbps at 915MHz and 20kbps at 868MHz.
There are three different ZigBee device types that operate on these layers in any self-organizing application
network. These devices have 64-bit IEEE addresses, with option to enable shorter addresses to reduce packet
size, and work in either of two addressing modes star and peer-to-peer.
The ZigBee (PAN) coordinator node: The most capable device, the coordinator forms the root of the
network tree and might bridge to other networks. It is able to store information about the network.
There is one, and only one, ZigBee coordinator in each network to act as the router to other network.
It also acts as the repository for security keys.
The Full Function Device (FFD): The FFD is an intermediary router transmitting data from other
devices. It needs lesser memory than the ZigBee coordinator node, and entails lesser manufacturing
costs. It can operate in all topologies and can act as coordinator.
The Reduced Function Device (RFD): This device is just capable of talking in the network; it cannot
relay data from other devices. Requiring even less memory, (no flash, very little ROM and RAM), an
RFD will thus be cheaper than an FFD. This device talks only to a network coordinator and can be
implemented very simply in star topology.
An FFD can talk to RFDs or other FFDs, while an RFD can talk only to an FFD. An RFD is intended for
applications that are extremely simple, such as a light switch or a passive infrared sensor; they do not have the
need to send large amounts of data and may only associate with a single FFD at a time. Consequently, the RFD
can be implemented using minimal resources and memory capacity.
2.2.4 NETWORK TOPOLOGIES
The figures from 2.1 2.4 show the 4 topologies implemented in ZigBee:
Star Topology,
Peer-to-Peer Topology,
Cluster Topology
Mesh Topology.
5
2.2.4.1 STAR TOPOLOGY
In the star topology, the communication is established between devices and a single central controller, called
the PAN coordinator. The PAN coordinator may be mains powered while the devices will most likely be
battery powered. Applications that benefit from this topology include home automation, personal computer
(PC) peripherals, toys and games. After an FFD is activated for the first time, it may establish its own network
and become the PAN coordinator. Each start network chooses a PAN identifier, which is not currently used by
any other network within the radio sphere of influence. This allows each star network to operate
independently.
Figure 2.1: Star Topology Network
2.2.4.2 PEER-TO-PEER (AD-HOC) TOPOLOGY
In peer-to-peer topology, there is also one PAN coordinator. In contrast to star topology, any device can
communicate with any other device as long as they are in range of one another. A peer-to-peer network can
be ad hoc, self-organizing and self-healing. Applications such as industrial control and monitoring, wireless
sensor networks, asset and inventory tracking would benefit from such a topology. It also allows multiple hops
to route messages from any device to any other device in the network. It can provide reliability by multipath
routing.
Figure 2.2: Peer-to-Peer Topology
6
2.2.4.3 CLUSTER-TREE TOPOLOGY
Cluster-tree network is a special case of a peer-to-peer network in which most devices are FFDs and an RFD
may connect to a cluster-tree network as a leave node at the end of branch. Any of the FFD can act as a
coordinator and provide synchronization services to other devices and coordinators.
Only one of these coordinators however is the PAN coordinator. The PAN coordinator forms the first cluster
by establishing itself as the cluster head (CLH) with a cluster identifier (CID) of zero, choosing an unused PAN
identifier, and broadcasting beacon frames to neighboring devices. A candidate device receiving a beacon
frame may request to join the network at the CLH. If the PAN coordinator permits the device to join, it will add
this new device as a child device in its neighbor list. The newly joined device will add the CLH as its parent in
its neighbor list and begin transmitting periodic beacons such that other candidate devices may then join the
network at that device. Once application or network requirements are met, the PAN coordinator may instruct
a device to become the CLH of a new cluster adjacent to the first one. The advantage of this clustered
structure is the increased coverage area at the cost of increased message latency.
Figure 2.3: Cluster Network
2.2.4.4 MESH TOPOLOGY
The structure of the Mesh topology is similar to that of the Tree topology, with the Co-ordinator at the top of
a tree-like structure:
The Co-ordinator is linked to a set of Routers and End Devices - its children.
A Router may then be linked to more Routers and End Devices - its children. This can continue to a
number of levels.
However, the communication rules are more flexible in that Router nodes within range of each other can
communicate directly.
7
The Mesh topology gives rise to more efficient message propagation, and means that alternative routes can
be found if a link fails or there is congestion. A route discovery feature is provided which allows the network
to find the best available route for a message.
Figure 2.3: Mesh Network
2.3 ARCHITECTURE
The ZigBee protocol layers are based on the International Standards Organization (ISO) Open System
Interconnect (OSI) basic reference model. There are seven layers in the ISO/OSI model, but ZigBee
implements only the layers that are essential for low-power, low-data rate wireless networking. The lower two
layers (PHY and MAC) are defined by the IEEE 802.15.4 standard. The NWK and APL layers are defined by the
ZigBee standard. The security features are defined in both standards. A network that implements all of the
layers in Figure 2.4 is considered a ZigBee wireless network.
Each layer communicates with the adjacent layers through service access points (SAPs). A SAP is a conceptual
location at which one protocol layer can request the services of another protocol layer.
8
Figure 2.4: ZigBee Networking Protocol Layers
2.3.1 NETWORK AND APPLICATION SUPPORT LAYER:
The network layer permits growth of network without high power transmitters. This layer can handle huge
numbers of nodes. This level in the ZigBee architecture includes:
The ZigBee Device Object (ZDO)

User-Defined Application Profile(s)
The Application Support (APS) Sub-layer.
The APS sub-layer's responsibilities include maintenance of tables that enable matching between two devices
and communication among them, and also discovery, the aspect that identifies other devices that operate in
the operating space of any device.
The responsibility of determining the nature of the device (Coordinator / FFD or RFD) in the network,
commencing and replying to binding requests and ensuring a secure relationship between devices rests with
the ZDO (ZigBee Define Object). The user defined application refers to the end device that conforms to the
ZigBee Standard.
2.3.2 PHYSICAL (PHY) LAYER:
The PHY service enables the transmission and reception of PHY protocol data units (PPDU) across the physical
radio channel.
The features of the IEEE 802.15.4 PHY physical layer are Activation and deactivation of the radio transceiver,
energy detection (ED), Link quality indication (LQI), channel selection, clear channel assessment (CCA) and
transmitting as well as receiving packets across the physical medium.
2.3.3 MEDIA ACCESS CONTROL (MAC) LAYER:

The MAC service enables the transmission and reception of MAC protocol data units (MPDU) across the PHY
data service. The features of MAC sub layer are beacon management, channel access, GTS management,
frame validation, acknowledged frame delivery, association and disassociation.
9
2.4 APPLICATIONS
The claim of wireless sensor network proponents is that this technological vision will facilitate many existing
application areas and bring into existence entirely new ones. This claim depends on many factors, but a couple
of the envisioned application scenarios shall be highlighted.
On the basis of nodes that have such sensing and/or actuation faculties, in combination with computation and
communication abilities, many different kinds of applications can be constructed, with very different types of
nodes, even of different kinds within one application.
2.4.1 TYPES OF APPLICATIONS
Many of these applications share some basic characteristics. In most of them, there is a clear difference
between sources of data the actual nodes that sense data and sinks nodes where the data should be
delivered to. These sinks sometimes are part of the sensor network itself; sometimes they are clearly systems
outside the network (e.g. the re ghters PDA communicating with a WSN). Also, there are usually, but not
always, more sources than sinks and the sink is oblivious or not interested in the identity of the sources; the
data itself is much more important.
The interaction patterns between sources and sinks show some typical patterns. The most relevant ones are:
EVENT DETECTION
Sensor nodes should report to the sink(s) once they have detected the occurrence of a specied event. The
simplest events can be detected locally by a single sensor node in isolation (e.g. a temperature threshold is
exceeded); more complicated types of events require the collaboration of nearby or even remote sensors to
decide whether a (composite) event has occurred (e.g. a temperature gradient becomes too steep). If several
different events can occur, event classication might be an additional issue.
PERIODIC MEASUREMENTS
Sensors can be tasked with periodically reporting measured values. Often, these reports can be triggered by a
detected event; the reporting period is application dependent.
FUNCTION APPROXIMATION AND EDGE DETECTION
The way a physical value like temperature changes from one place to another can be regarded as a function of
location. A WSN can be used to approximate this unknown function (to extract its spatial characteristics),
using a limited number of samples taken at each individual sensor node. This approximate mapping should be
made available at the sink. How and when to update this mapping depends on the applications needs, as do
the approximation accuracy and the inherent trade-off against energy consumption.
TRACKING
The source of an event can be mobile (e.g. an intruder in surveillance scenarios). The WSN can be used to
report updates on the event sources position to the sink(s), potentially with estimates about speed and
direction as well. To do so, typically sensor nodes have to cooperate before updates can be reported to the
sink.
2.4.2 APPLICATION EXAMPLES
The claim of wireless sensor network proponents is that this technological vision will facilitate many existing
application areas and bring into existence entirely new ones. This claim depends on many factors, but a couple
of the envisioned application scenarios shall be highlighted:
10
DISASTER RELIEF APPLICATIONS
One of the most often mentioned application types for WSN are disaster relief operations. A typical scenario is
wildre detection: Sensor nodes are equipped with thermometers and can determine their own location
(relative to each other or in absolute coordinates). These sensors are deployed over a wildre, for example, a
forest, from an airplane. They collectively produce a temperature map of the area or determine the
perimeter of areas with high temperature that can be accessed from the outside, for example, by re ghters
equipped with Personal Digital Assistants (PDAs).
Similar scenarios are possible for the control of accidents in chemical factories, for example. Some of these
disaster relief applications have commonalities with military applications, where sensors should detect, for
example, enemy troops rather than wildres. In such an application, sensors should be cheap enough to be
considered disposable since a large number is necessary; lifetime requirements are not particularly high.
ENVIRONMENT CONTROL AND BIODIVERSITY MAPPING
WSNs can be used to control the environment, for example, with respect to chemical pollutants a possible
application is garbage dump sites. Another example is the surveillance of the marine ground oor; an
understanding of its erosion processes is important for the construction of offshore wind farms. Closely
related to environmental control is the use of WSNs to gain an understanding of the number of plant and
animal species that live in a given habitat (biodiversity mapping).
The main advantages of WSNs here are the long-term, unattended, wire free operation of sensors close to the
objects that have to be observed; since sensors can be made small enough to be unobtrusive, they only
negligibly disturb the observed animals and plants. Often, a large number of sensors is required with rather
high requirements regarding lifetime.
INTELLIGENT BUILDINGS
Buildings waste vast amounts of energy by inefcient Humidity, Ventilation, Air Conditioning (HVAC) usage. A
better, real-time, high-resolution monitoring of temperature, airow, humidity, and other physical parameters
in a building by means of a WSN can considerably increase the comfort level of inhabitants and reduce the
energy consumption.
In addition, such sensor nodes can be used to monitor mechanical stress levels of buildings in seismically
active zones. By measuring mechanical parameters like the bending load of girders, it is possible to quickly
ascertain via a WSN whether it is still safe to enter a given building after an earthquake or whether the
building is on the brink of collapse a considerable advantage for rescue personnel. Similar systems can be
applied to bridges. Other types of sensors might be geared toward detecting people enclosed in a collapsed
building and communicating such information to a rescue team.
The main advantage here is the collaborative mapping of physical parameters. Depending on the particular
application, sensors can be retrotted into existing buildings (for HVAC type applications) or have to be
incorporated into the building already under construction. If power supply is not available, lifetime
requirements can be very high up to several dozens of years but the number of required nodes, and hence
the cost, is relatively modest, given the costs of an entire building.
FACILITY MANAGEMENT
In the management of facilities larger than a single building, WSNs also have a wide range of possible
applications. Simple examples include keyless entry applications where people wear badges that allow a WSN
to check which person is allowed to enter which areas of a larger company site. This example can be extended
to the detection of intruders, for example of vehicles that pass a street outside of normal business hours. A
wide area WSN could track such a vehicles position and alert security personnel this application shares
11
many commonalities with corresponding military applications. Along another line, a WSN could be used in a
chemical plant to scan for leaking chemicals.
These applications combine challenging requirements as the required number of sensors can be large, they
have to collaborate (e.g. in the tracking example), and they should be able to operate a long time on batteries.
MACHINE SURVEILLANCE AND PREVENTIVE MAINTENANCE
One idea is to x sensor nodes to difcult to-reach areas of machinery where they can detect vibration
patterns that indicate the need for maintenance. Examples for such machinery could be robotics or the axles
of trains.
Other applications in manufacturing are easily conceivable. The main advantage of WSNs here is the cable free
operation, avoiding a maintenance problem in itself and allowing a cheap, often retrotted installation of such
sensors. Wired power supply may or may not be available depending on the scenario; if it is not available,
sensors should last a long time on a nite supply of energy since exchanging batteries is usually impractical
and costly. On the other hand, the size of nodes is often not a crucial issue, nor is the price very heavily
constrained.
PRECISION AGRICULTURE
Applying WSN to agriculture allows precise irrigation and fertilizing by placing humidity/soil composition
sensors into the elds. A relatively small number is claimed to be sufcient, about one sensor per 100 m 100
m area. Similarly, pest control can prot from a high-resolution surveillance of farm land.
MEDICINE AND HEALTH CARE
Along somewhat similar lines, the use of WSN in health care applications is a potentially very benecial, but
also ethically controversial, application. Possibilities range from postoperative and intensive care, where
sensors are directly attached to patients the advantage of doing away with cables is considerable here to
the long-term surveillance of (typically elderly) patients and to automatic drug administration (embedding
sensors into drug packaging, raising alarms when applied to the wrong patient, is conceivable). Also, patient
and doctor tracking systems within hospitals can be literally lifesaving.
LOGISTICS
In several different logistics applications, it is conceivable to equip goods (individual parcels, for example) with
simple sensors that allow a simple tracking of these objects during transportation or facilitate inventory
tracking in stores or warehouses. In these applications, there is often no need for a sensor node to actively
communicate; passive readout of data is often sufcient, for example, when a suitcase is moved around on
conveyor belts in an airport and passes certain checkpoints. Such passive readout is much simpler and cheaper
than the active communication and information processing concept discussed in the other examples; it is
realized by so-called Radio Frequency Identier (RF ID) tags.
On the other hand, a simple RFID tag cannot support more advanced applications. It is very difcult to imagine
how a passive system can be used to locate an item in a warehouse; it can also not easily store information
about the history of its attached object questions like where has this parcel been? are interesting in many
applications but require some active participation of the sensor node.
TELEMATICS
Partially related to logistics applications are applications for the telematics context, where sensors embedded
in the streets or roadsides can gather information about trafc conditions at a much ner grained resolution
than what is possible today. Such a so called intelligent roadside could also interact with the cars to
exchange danger warnings about road conditions or trafc jams ahead.
12
Chapter 3 Related Work
CHAPTER 3
RELATED WORK
3.1 RELATED WORK
This section summarizes the work of other authors, describing their work on power efficiency of IEEE
802.15.4/ZigBee and Wireless Sensor Networks and gives a central idea on what their achievements and their
loopholes were.
3.1.1 Andrew Jennings and Daud A. Channa, Annealing Sensor Networks, Lecture Notes in
Computer Science, Volume 3684, Aug 2005, Pages 581 - 586.
The concept behind every Wireless Sensor Network is that the network should kept simple and energy
consumption should be closely monitored so that no energy is wasted. Also, this paper also mentions that
since the progress in battery technology is dead slow, one should consider to introduce intelligence into the
network so that the network could monitor the energy consumption itself and decide when to transmit and
when not to.
3.1.2 Arun S., Seminar Report on ZigBee, September 2008.
ZigBee is an evolving technology and was essentially thought out to overcome the limitations of WiFi and
Bluetooth. Since it is built on the PHY and MAC layers specified by the IEEE 802.15.4 standard, it has a lot of
room for change since the basic layer that specifies the ZigBee standard starts from the NKW layer.
3.1.3 Feng Chen and Falko Dressler, A Simulation Model of IEEE 802.15.4 in OMNeT++, 2006.
3.1.4 Feng Chen, Isabel Dietrich, Reinhard German and Falko Dressler, An Energy Model for
Simulation Studies of Wireless Sensor Networks using OMNeT++, 2007.
The papers [3] and [4], describe the necessity of simulation software by designing a framework of IEEE
802.15.4 compatible with a network simulation software namely OMNeT++. In this paper, the authors
describe how the INET Framework was designed and what were the elements in each phase of the
Framework. The Framework accurately allows evaluate the energy performance of sensor networks, taking
into account the energy consumptions of both the radio transceiver and the CPU.
3.1.5 Feng Chen, Nan Wang, Reinhard German and Falko Dressler, Performance Evaluation of
IEEE 802.15.4 LR-WPAN for Industrial Applications, 2008.
The application scenario of WSNs in the industrial sector holds great importance for control applications since
sensor network technology is increasingly demanded in this domain
3.1.6 Fabrizio Granelli, Dzmitry Kliazovich and Nelsom L. S. Da Fonseca, Performance

Limitations of IEEE 802.15.4 Networks and Potential Enhancements, 2007.
The IEEE 802.11 standard is a significant milestone in the provisioning of network connectivity for mobile
users. However, due to the time-variant characteristics of wireless links, interference from other devices and
terminal mobility, 802.11-based WLANs suffer from performance drawbacks in relation to wired networks.
Wireless networks are becoming increasingly popular due to the growing use of mobile access to network
services.
As a consequence, significant efforts have been devoted to providing reliable data delivery for a wide variety
of applications over a variety of wireless infrastructures. From the analysis of existing improvements to the
IEEE 802.11 standards, it is clear that there is no single best solution for all deployment scenarios.
13
Link layer solutions work on the wireless link without affecting higher-level protocols, but they increase the
complexity of the base station and require the modification of the MAC protocol on the wireless link (usually
implemented in the hardware). Transport layer solutions aim at adapting the transport protocol to the
characteristics of the wireless network, thus implying modification of the transport protocol in the protocol
stack at both the sender and receiver ends. An alternate novel approach can be achieved by cross-layer
solutions, which establish inter-dependence and collaboration between protocols in different layers of the
stack.
3.1.7 Nicky van Frost, Simulating Queuing Networks with OMNeT++, January 23rd, 2004.
OMNeT++ is a great tool for simulation of any sort of network since the behaviour of the systems is
programmed in normal C++ language, which in turn provides the user more flexibility. The programming style
of OMNeT++ makes it a very versatile tool.
3.1.8 C. Mallanda, A. Suri, V. Kunchakarra, S. S. Iyengar, R. Kannan and A. Durresi, Simulating

Wireless Sensor Networks with OMNeT++, 2005.
Before emerging technologies such as sensor networks and the underlying node-level architectures such as
the even-driven architecture of TinyOS can be incorporated as subsystems in mainstream engineering
technologies, it is necessary to demonstrate the efficiency and robustness of these sub systems through
comprehensive simulations that involve the dynamics of both the application and the sensor network.
Such simulation studies must explore the effects of scale, density, node-level architecture, energy efficiency,
failure modes at node and communication media levels. It is not sufficient enough to simulate the behaviour
of the sensor network in the isolation because of the tight and ubiquitous coupling between the sensor
network and its applications.
3.1.9 E. Egea-Lpez, J. Vales-Alonso, A. S. Martnez-Sala, P. Pavn-Mario and J. Garca-Haro,

Simulation Tools for Wireless Sensor Networks, Summer Simulation Multiconference
SPECTS 2005.
The most critical part of simulating any network is the selection of Framework. There are four main things to
expect from a good WSN simulator are namely, Reusability and Availability, Performance and Scalability;
Support for rich-semantics scripting languages; graphical debug and trace support.
3.1.10 Tao Shu and Marwan Krunz, Coverage-Time Optimization for Clustered Wireless Sensor
Networks: A Power-Balancing Approach, IEEE/ACM Transactions on Networking, Vol.
18, No. 1, February 2010.
Clustered Wireless Network Topology is one of the most energy consuming topologies in the WSNs, not to
mention the most efficient since, every cluster has its head, and all the heads can relate and relay the traffic
from one node to another intelligently.
3.1.11 Deborah Estrin, Ramesh Govindan, John Heidemann and Satish Kumar, Next Century
Challenges: Scalable Coordination in Sensor Networks, 1999.
Networked sensors those that coordinate amongst themselves to achieve a larger sensing task will
revolutionize information gathering and processing both in urban environments and in inhospitable terrain.
The sheer numbers of these sensors and the expected dynamics in these environments present unique
challenges in the design of unattended autonomous sensor networks. These challenges lead us to hypothesize
that sensor network coordination applications may need to be structured differently from traditional network
applications.
14
Chapter 3 Related Work
3.1.12 Sajjad Hussain Shah, Kashif Naseer, Wajid Ali, Sohail Jabbar, Abid Ali Minhas, Prolonging
the Network Lifetime in WSN through Computational Intelligence, Proceedings of the
World Congress on Engineering and Computer Science 2011 Vol I, WCECS 2011, October
19-21, 2011, San Francisco, USA.
Computational Intelligence (CI) is the natures supremacy of being the ultimate intelligent optimizer of human
made solutions. This topic has emerged as quite important due to the fact of emergence of new and improved
electronics. WSN is the domain that is the target of such CI to optimize energy aware routing. Implementation
of CI would increase Adaptation, High Computational Speed, Versatility, the Self-Organizing and the Self-
Learning characteristic of a WSN.
3.1.13 Pablo Suarez, Carl-Gustav Renmarker, Adam Dunkels and Thiemo Voigt, Increasing
ZigBee Network Lifetime with X-MAC, April 2008.
The ZigBee standard builds on the assumption that infrastructure nodes have a constant power supply. ZigBee
therefore does not provide any power-saving mechanisms for routing nodes, which limits the lifetime of
battery-powered ZigBee networks to a few days. This short lifetime drastically restricts the possible
application scenarios for ZigBee. To expand the usefulness of ZigBee, the authors present a ZigBee
implementation where they replace the default ZigBee MAC protocol with the power-saving MAC protocol X-
MAC.
Results show that X-MAC reduces the power consumption for ZigBee routing nodes with up to 90%, leading to
a ten-fold increase in network lifetime at the price of a slight increase in network latency.
3.1.14 Myung-Gon Park, Kang-Wong Kim and Chan-Gun Lee, A Holistic Approach for
Optimizing Lifetime of IEEE 802.15.4/ZigBee Networks with Deterministic Guarantee of
Real-Time Flows, 2009.
The author proposes a holistic approach to optimally configuring the IEE 802.15.4/ZigBee cluster-tree
configuration. Once a cluster-tree is configured, the duty-cycle of scheduling of the clusters such that each
node in the cluster can send a packet using a guaranteed time slot (GTS) within the clusters active period
called a superframe duration (SD), which periodically comes at every beacon interval (BI).
15
16
Chapter 4 Problem Statement
CHAPTER 4
PROBLEM STATEMENT
4.1 ENERGY EFFICIENCY
One of the central tenets of sensor networks has been the need to keep nodes as simple as possible and
careful in their energy consumption.
For an example, we cannot implement the full TCP/IP stack on the sensor networks, for that would be a
complete waste of resources and energy, all because the nature of communication is quite different.
4.2 PROBLEM STATEMENT
The main idea behind Sensor Networks in that they sense the network around them, which makes
configuring the largest possible network quite easy. Since no physical connection is needed, a mote scans its
relative radius for devices and configures itself to receive from it. The same is happening in all the devices
connected in the network. All this information is stored in the routing table of the ZigBee Router or the ZigBee
Cluster, whichever is given preference in the network.
But what is not stored in the routing table is are the current energy levels of the device which is one hop away
from the device which is keeping the routing table.
If we look at the ZigBee stack, the PHY layer has a parameter called the Link Quality Indicator (LQI). It
measures the LQI of a given channel and makes this information available for the upper layers to use. But this
information is neither stored in the routing table, nor it is transmitted.
The NWK Layer decides routes based on LQI. But since there is no information regarding Battery Level of the
hopping node, the decision by the NWK layer may be unjust.
17
18
Chapter 5 Proposed Solution
CHAPTER 5
PROPOSED SOLUTION
5.1 PROPOSED SOLUTION
If we look at the ZigBee stack, the PHY layer has a parameter called the Link Quality Indicator (LQI). It
measures the LQI of a given channel and makes this information available for the upper layers to use. But this
information is neither stored in the routing table, nor it is transmitted.
To solve this problem, the NWK layer of the ZigBee stack has to be modified in order to make sure that the LQI
is inserted into the frame of the packet and then transmitted WITH the packet or while network discovery.
The link quality indicator (LQI) is an indication of the quality of the data packets received by the receiver. The
received signal strength (RSS) can be used as a measure of the signal quality. The RSS is a measure of the total
energy of the received signal. The ratio of the desired signal energy to the total in-band noise energy (the
signal-to-noise ratio, or SNR) is another way to judge the signal quality.
If this information is stored by the NWK layer as a log file to monitor the one hop members, it can efficiently
route the packets according to an energy aware path.
Since this is a processor intensive job, we would be limiting this only to the Cluster Heads which have an
unlimited power supply. What we have to do is that configure the devices in the highlighted area to transfer
the Energy status (Battery life, sleep mode) to the nearest ZigBee Coordinator. The ZigBee coordinator would
store this information as a log file, as mentioned above.
When a packet would arrive at the cluster head, to be forwarded, the CH would determine the following
factors and determine through which path to send the packet:
If the CH is connected to two routers, and one of them is sleeping, the CH would route the frame
through the other Router.
If this has been repeated a certain number of times, the CH would wake the other router and let
the previous one sleep and save its battery.
If both of them are asleep, the CH would look at the time they have been sleeping and the battery
life they have remaining with them and wake the one who has been asleep the longest with more
battery life.
If both of them are awake, the CH would determine who has the longest uptime and the least
battery remaining of the two, and would put that node to sleep and send the packet through the
other router.
This would help the network store energy since all the processing load has been transferred to then nodes
with unlimited battery life, making this a far efficient approach than to conventional methods.
This would also help the network to achieve a higher network uptime, since packets are being routed
thorough energy efficient paths, instead of a guessing which path to take, which is normally what sensor
network do.
5.2 PROPOSED SCENARIO
We have a certain area of land, for suppose 3 acres that is being used for cultivation. Here:
1 acre = 4046.85642m2
19
In this area of land, certain specifications are being monitored:
Humidity
Wind Speed
Soil Acidy
Wild Life Presence, etc.
To help us achieve monitoring success, we have installed a huge (>10,000 nodes) wireless sensor network
based upon ZigBee.
Three ZigBee technologies would be at work here:
1. ZigBee Coordinator
The ZigBee Coordinator would be a type of base station which is plugged so that it has unlimited battery life.
Its main job is to coordinate packets of information from one point to another.
2. ZigBee Router
The ZigBee Router would have a battery life according to the ZigBee Alliance, up to 2 years. It has the job of
routing the packets from the End devices to either routers or coordinators. ZigBee routers are intelligent
devices, or a FFD (Forward Function Device). They are also called motes in general terminology.
3. ZigBee End Device
The ZigBee End Device has the simplest of job, which is only one sided communication since it is an RFD
(Reduced Function Device) in our allotted scenario. It has the job of taking the packet of information as a
sensor and forwarding it to the router, which forwards it through a complex network topology consisting of
routers and coordinators which end up at the monitoring station.
Each packet of information starts at the sensor of the network and terminates at the Monitoring Station after
traversing the whole network as shown in Figure 5.1
20
Chapter 5
21
Figure 5.1: Proposed Scenario
Proposed Solution
5.3 TOOLS USED
We would simulate the ZigBee Transceiver on an open source Network Simulator called OMNeT++. Then we
would integrate two frameworks into OMNeT++, namely INET and MiXiM, because the wireless component
models that we require for simulation and experimentation of the ZigBee transceiver are present in these two
frameworks combined.
These three frameworks would also allow us to verify other authors results to ensure our results are up to the
standards.
5.3.1 OMNET++
OMNeT++ is a discrete event simulation environment. Its primary application area is the simulation of
communication networks, but because of its generic and flexible architecture, is successfully used in other
areas like the simulation of complex IT systems, queuing networks or hardware architectures as well.
OMNeT++ provides a component architecture for models. Components (modules) are programmed in C++,
and then assembled into larger components and models using a high-level language (NED). Reusability of
models comes for free. OMNeT++ has extensive GUI support, and due to its modular architecture, the
simulation kernel (and models) can be embedded easily into your applications.
OMNeT++ provides the basic machinery and tools to write simulations, but itself it does not provide any
components specifically for computer network simulations, queuing network simulations, system architecture
simulations or any other area. Instead, these application areas are supported by various simulation models
and frameworks such as INET/INETMANET, MiXiM or Castalia. These models are developed completely
independent of OMNeT++, and follow their own release cycles.
OMNeT++ would be our network simulator as a base for frameworks such as INET and MiXiM. Later,
we use the help of the frameworks to simulate ZigBee networks.
5.3.2 INET FRAMEWORK
The INET Framework is an open-source communication networks simulation package for

the OMNeT++ simulation environment. The INET Framework contains models for several wired and wireless
networking protocols, including:
UDP,
TCP,
SCTP,
IP,
IPv6,
Ethernet,
PPP,
802.11,
MPLS,
OSPF and many others.
5.3.3 MIXIM
MiXiM is an OMNeT++ modelling framework created for mobile and fixed wireless networks (wireless sensor
networks, body area networks, ad-hoc networks, vehicular networks, etc.). It offers detailed models of radio
wave propagation, interference estimation, radio transceiver power consumption and wireless MAC protocols
(e.g. ZigBee).
22
Chapter 5 Proposed Solution
The INET and MiXiM would provide the necessary components which are predefined for use in this project. All
that would be needed would be to configure those component architectures specific to our cause and to re-
implement them using OMNeT++. In this way, we can simulate our entered parameters and get results using
the built-in graphing utilities.
5.4 SIMULATION SETUP
As mentioned in the previous segments of this document, the base of our simulations would be OMNeT++.
We would first start of by downloading the OMNeT++ files from http://omnetpp.org and extracting them in a
non-space directory. After the extraction, we would build the program files and adjust dependencies.
Next we would incorporate the INET framework followed by the MiXiM Framework into OMNeT++ by first
downloading them from http://inet.omnetpp.org and http://mixims.sourceforge.net respectively, and
extracting them from their respective .tar.gz files. This is followed by showing OMNeT++ to the respected files
and importing them for use in the OMNeT++ IDE.
5.5 DRAWING RESULTS
OMNeT++ has a built-in graphing utility to enable its user to plot scatter graphs and histograms by filtering the
results we are interested in and hiding the variables we do not need for the time being.
Through this project, we are trying to second our research that if we would introduce the required intelligence
in the Cluster Heads or the ZigBee Coordinators, by modifying the NWK layer of the ZigBee stack we can
achieve an increase in Network Lifetime.
In our results, we will show a graph showing how a regular network work without any modification and a
network with the modifications that we propose in this project behaves in the simulation. The graph would
show the average energy status of the network decaying with respect to time.
5.6 INTERPRETING RESULTS
Here, we would discuss whether the results that we drew in the previous segment were quantitatively and
qualitatively enough, and how do we interpret them.
If our findings, research are correct and our simulations sides with our findings, we should see that the
network in the proposed scenario would last at least 10% longer than the network that does not support our
said modifications.
Note that the first network in which the first node dies is the loser.
23
24
Chapter 6 Simulation Setup
CHAPTER 6
SIMULATION SETUP
6.1 INSTALLATION
Before we can simulate any network, we need to install OMNeT++ and integrate the INET Framework and
MiXiM onto it.
6.1.1 SETUP OF OMNET++
1. Download OMNeT++ from <http://omnetpp.org>

2. Extract the latest version of OMNeT++ on the disk.
3. Run the bash terminal.
WARNING: Do not install OMNeT++ on any directory which has a space in its name, otherwise the
bash terminal would register an error.
4. Type ./configure and press Enter.
5. After the process is over, type make and press Enter. This is a time consuming process.
6. After the process is over, type omnetpp to run OMNeT++.
7. If the need to log out arises, type exit and press Enter.
6.1.2 SETUP OF INET FRAMEWORK
1. Download the latest version of INET <http://inet.omnetpp.org>.

2. Open OMNeT++.
3. Go to File-> Import.
4. Select the .tar.gz file and press import.
5. After the import process completes, press CTRL+B to build all configurations and to append INET to
OMNeT++. This is a time consuming process.
6. Now, all the modules of INET have been integrated on to OMNeT++ for use.
6.1.3 INSTALLATION OF MIXIM
1. Download the latest version of MiXiM <http://mixim.sourceforge.net>.

2. Open OMNeT++.
3. Go to File-> Import.
4. Select the .tar.gz file and press import.
5. After the import process completes, press CTRL+B to build all configurations and to append MiXiM to
OMNeT++. This is a time consuming process.
6. Now, all the modules of MiXiM have been integrated on to OMNeT++ for use.
25
6.2 SIMULATION SETUP
As now we have a full installation set up, our screen should look like Figure 6.1.
Figure 6.1: OMNeT++ Main Window
We can clearly see the INET and MiXIM folders in the project explorer. At this point, let us start off in creating
a new simulation file by going to File -> New -> OMNeT++ Project as shown in Figure 6.2.
26
Figure 6.2: New OMNeT++ Project...
27
Figure 6. 3: Naming the Project File
The wizard asks for a name for the Project.
Enter a name, in this case fyp0703 instead of nameofproject.
A thing to note is that the name should be non-capitalized, as OMNeT++ prefers it this way.
Press Next.
28
Figure 6. 4: Defining MiXiM as the framwork
This window shows if we want to link it to an already installed framework.
Go under MiXiM and choose Basic MiXiM network. As we installed INET, the OMNeT++ would automatically
make the INET Framework available through MiXiM.
Press Next.
29
Figure 6. 5: NIC Configuration
Be cautious to choose exactly the same settings as shown in figure 6.5.
In the application layer, we need to select a SENSOR APPLICATION LAYER because we are working on sensor
networks.
In the network layer, choose WISE ROUTE because we are testing a network that already routes information
effectively.
In the NIC Protocol, choose CSMA 802.15.4 as the pre-defined protocol because we are exploring the IEEE
standard 802.15.4 and ZigBee runs CSMA (Collision Sense Multiple Access).
Since we are not interested in moving our nodes, we would choose STATIC in the Mobility Module.
Also, we are not interested in viewing a graphic intense environment that would put unnecessary load on the
system that we are using to simulate our project, we would choose a 2-DIMENSIONAL playground.
Press Next and the Wizard would create the necessary files with configurations and put in the folder named
fyp0703 as shown in Figure 6.6.
30
Figure 6. 6: The created project files
As we can see in figure 6.6, we have selected the omnet.ini file to show the location of nodes as highlighted in
the figure. As the scenario depicts 10,000 nodes, we would enter 10,000 after the syntax, that is:
**.numNodes = 10000
This is a fairly long file depicting the status of all the nodes, and is available in the Appendix of this report.
A thing to be defined here at this instance is that simulation of 10,000 nodes is impossible for any system if it
is not a mainframe. So we experimented with different number of nodes and the result was that the
maximum number of nodes that can be processed in OMNeT++ without causing any crashes or hang-ups is
around 50, so we would stick to the number 50 for easier evaluation and easy manipulation of results.
Next we develop the NWK layer files and insert the files in the MiXiM sub-folder
C:\omnetpp-4.1\MiXiM\modules\netw
The files are WiseRoute.cc, WiseRoute.h, and WiseRoute.ned
All of these files are already developed but we needed to modify these to get our results. The edited files are
attached in the appendix.
First we would simulate the files without any modifications as to get a baseline reading.
Then we would append the modified files into the above mentioned directory, and re-run the simulation after
building the project to get the new results.
A factor to note is that even if there is a slight change, when building the project, it takes a lot of time to build
the whole directories and dependencies which can go up to 15 minutes or more depending on the changes
and or errors generated.
A lot of time is also associated with running the simulation since we need a lot of simulated time to figure out
the results. Due to the intensity of the nodes, and the files associated with the single file, it takes at least 15
minutes to simulate 20 seconds of simulated time, so we need to be cautious in selecting runtime for
simulation.
31
32
Chapter 7 Results
CHAPTER 7
RESULTS
7.1 OBSERVED RESULTS
In figure 7.1, we see how the packets originate from one randomly decided node and start to be broadcasted
to all nodes in the vicinity.
In figure 7.2, we see the Network Nodes uptime of the 50 nodes that we simulated.
Notice the difference between the baseline and the modified NWK layer results.
33
Figure 7.1: Network Sequence Chart
34
Chapter 7 Results
35
36
Chapter 8 Discussion of Results
CHAPTER 8
DISCUSSION OF RESULTS
8.1 REVIEW OF RESULTS
As we saw the results derived from the built-in graphing utility in OMNeT++, we saw how the packets
propagated within the network and how did the energy dissipation look after some time in a 50 node
network.
8.2 DISCUSSION OF RESULTS
For the results, they conclusively show that the modified NWK layer is doing a good job in maintaining the
energy levels of the ZigBee routers.
A thing to note here is that since we couldnt simulate more than 50 nodes due to limited processing power
and some limitations of OMNeT++, there is huge difference in the two runs. This is because the nodes are few
and they are grouped together and they run each others energy out sooner. If there would have been more
than 1000 nodes, these results would have at least shown some deviation from the results as were earlier
shown in the previous chapter.
We reckon that at least the networks lifetime is increased by 10 15% if we are allowed to simulate all
10,000 nodes.
37
38
Chapter 9 Conclusion
CHAPTER 9
CONCLUSION
9.1 CONCLUSION
After the whole simulation and analysis of the results, there is an expected increase of 10 15% in the
networks lifetime after the modified NWK layer is put into place.
9.2 ADVANTAGES
The advantages of network life prolongation are numerous. Out of them, a few are listed below:
1. A node can remain active for a longer period of time.

2. Can relay information more efficiently.
3. Due to an increases in the lifetime of a single node, the whole network experiences a bonus in the
network uptime.
4. The size of a sensor node network can be further explored to a higher magnitude.
9.3 LIMITATIONS
The limitations of these enhancements are rare and few. But since they exist, they need to be brought into
consideration:
1. These enhancements have to go through a lot more simulations and data recordings to enable them
to uncover any loose links to this strategy, thus implementation would take time.
2. The nodes need to be made more intelligent, thus meaning more processing power is needed per
node.
3. There may be certain occasions when this strategy can prove to be expensive.
39
40
Chapter 10 Future Works
CHAPTER 10
FUTURE WORKS
10.1 FUTURE WORKS
If this project be given some extra time and resources, there would have been more areas in which this
project would have traversed.
Some factors worth doing in the future are:
1. A larger sample size.

2. Doing this whole project on another simulator to remove any offset, if any exists.
3. Trying to remove limitations of the project.
4. Developing any work around ways to counter the same problem in a different approach
41
42
Chapter 11 List of References
CHAPTER 11
LIST OF REFERENCES
[1] Andrew Jennings and Daud A. Channa, Annealing Sensor Networks, Lecture Notes in Computer
Science, Volume 3684, Aug 2005, Pages 581 - 586.
[2] Arun S., Seminar Report on ZigBee, September 2008.
[3] Feng Chen and Falko Dressler, A Simulation Model of IEEE 802.15.4 in OMNeT++, 2006.
[4] Feng Chen, Isabel Dietrich, Reinhard German and Falko Dressler, An Energy Model for Simulation
Studies of Wireless Sensor Networks using OMNeT++, 2007.
[5] Feng Chen, Nan Wang, Reinhard German and Falko Dressler, Performance Evaluation of IEEE
802.15.4 LR-WPAN for Industrial Applications, 2008.
[6] Fabrizio Granelli, Dzmitry Kliazovich and Nelsom L. S. Da Fonseca, Performance Limitations of IEEE
802.15.4 Networks and Potential Enhancements, 2007.
[7] Nicky van Frost, Simulating Queuing Networks with OMNeT++, January 23rd, 2004.
[8] C. Mallanda, A. Suri, V. Kunchakarra, S. S. Iyengar, R. Kannan and A. Durresi, Simulating Wireless
Sensor Networks with OMNeT++, 2005.
[9] E. Egea-Lpez, J. Vales-Alonso, A. S. Martnez-Sala, P. Pavn-Mario and J. Garca-Haro, Simulation
Tools for Wireless Sensor Networks, Summer Simulation Multiconference SPECTS 2005.
[10] Tao Shu and Marwan Krunz, Coverage-Time Optimization for Clustered Wireless Sensor Networks: A
Power-Balancing Approach, IEEE/ACM Transactions on Networking, Vol. 18, No. 1, February 2010.
[11] Deborah Estrin, Ramesh Govindan, John Heidemann and Satish Kumar, Next Century Challenges:
Scalable Coordination in Sensor Networks, 1999.
43
[12] Sajjad Hussain Shah, Kashif Naseer, Wajid Ali, Sohail Jabbar, Abid Ali Minhas, Prolonging the Network
Lifetime in WSN through Computational Intelligence, Proceedings of the World Congress on
Engineering and Computer Science 2011 Vol I, WCECS 2011, October 19-21, 2011, San Francisco, USA.
[13] Pablo Suarez, Carl-Gustav Renmarker, Adam Dunkels and Thiemo Voigt, Increasing ZigBee Network
Lifetime with X-MAC, 2008.
[14] Myung-Gon Park, Kang-Wong Kim and Chan-Gun Lee, A Holistic Approach for Optimizing Lifetime of
IEEE 802.15.4/ZigBee Networks with Deterministic Guarantee of Real-Time Flows, 2009.
[15] LAN/MAN Standards Committee of the IEEE Computer Society, IEEE Standard for Information
technology Telecommunications and information exchange between systems Local and
metropolitan area networks Specific requirements Part 15.4: Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks
(WPANs), 2006.
[16] Holger Karl and Andreas Willig, Protocols and Architectures for Wireless Sensor Networks, 2005
John Wiley & Sons, Ltd. ISBN: 0-470-09510-5.
[17] Shahin Farahini, ZigBee Wireless Networks and Transceivers, 30 September, 2008, NewNes
Publishers, ISBN: 0-750-68393-7.
[18] Andrs Varga, OMNeT++ User Guide for v4.2b2, May 5th, 2011.
[19] INET Framework for OMNeT++ Manual, 2011.
[20] The ZigBee Alliance, <http://www.zigbee.org/>.
[21] OMNeT++ in a Nutshell, <http://www.omnetpp.org/pmwiki/index.php?n=Main.OmnetppInNutshell>
[22] MiXiM, <http://mixim.sourceforge.net>
44
APPENDIX
45
1 //WiseRoute.ned
2
3 package org.mixim.modules.netw;
4 import org.mixim.base.modules.BaseNetwLayer;
5
6 simple WiseRoute extends BaseNetwLayer
7 {
8 parameters:
9 bool debug = default(false);
10 bool trace = default(false);
11 bool useSimTracer = default(false);
12
13 int sinkAddress = default(0);
14
15 double rssiThreshold @unit(dBm) = default(-50 dBm);
16 double routeFloodsInterval @unit(s) = default(0 s);
17 @display("i=block/fork");
18 @class(WiseRoute);
19 }
20
21
-1-
1 //WiseRoute.h
2
3 #ifndef wiseroute_h
4 #define wiseroute_h
5
6 #include <omnetpp.h>
7
8 #include <BaseNetwLayer.h>
9 #include <BaseMobility.h>
10 #include <fstream>
11 #include "WiseRoutePkt_m.h"
12 #include "MacPkt_m.h"
13 #include "BaseMacLayer.h"
14 #include "SimTracer.h"
15 #include "NetwControlInfo.h"
16 #include "NetwToMacControlInfo.h"
17 #include "MacToNetwControlInfo.h"
18
19 #include <map>
20 #include <list>
21 #include <math.h>
22
23 using namespace std;
24
25 class WiseRoute : public BaseNetwLayer
26 {
27 public:
28 virtual void initialize(int);
29 virtual void finish();
30
31 ~WiseRoute();
32
33 protected:
34 enum messagesTypes {
35 UNKNOWN=0,
36 DATA,
37 ROUTE_FLOOD,
38 SEND_ROUTE_FLOOD_TIMER
39 };
40
41 typedef enum floodTypes {
42 NOTAFLOOD,
43 FORWARD,
44 FORME,
45 DUPLICATE
46 } floodTypes;
47
48
49 typedef struct tRouteTableEntry {
50 int nextHop;
51 double rssi;
52 } tRouteTableEntry;
53
54 typedef map<int, tRouteTableEntry> tRouteTable;
55 typedef multimap<int, unsigned long> tFloodTable;
56
57 tRouteTable routeTable;
58 tFloodTable floodTable;
-1-
59
60 int headerLength;
61 int macaddress;
62 int sinkAddress;
63 bool useSimTracer;
64 double rssiThreshold;
65 double routeFloodsInterval;
66 unsigned long floodSeqNumber;
67
68 SimTracer *tracer;
69 cMessage* routeFloodTimer;
70
71 long nbDataPacketsForwarded;
72 long nbDataPacketsReceived;
73 long nbDataPacketsSent;
74 long nbDuplicatedFloodsReceived;
75 long nbFloodsSent;
76 long nbPureUnicastSent;
77 long nbRouteFloodsSent;
78 long nbRouteFloodsReceived;
79 long nbUnicastFloodForwarded;
80 long nbPureUnicastForwarded;
81 long nbGetRouteFailures;
82 long nbRoutesRecorded;
83 long nbHops;
84
85 cOutVector receivedRSSI;
86 cOutVector routeRSSI;
87 cOutVector allReceivedRSSI;
88 cOutVector allReceivedBER;
89 cOutVector routeBER;
90 cOutVector receivedBER;
91 cOutVector nextHopSelectionForSink;
92
93 bool trace, stats, debug;
94
95 virtual void handleUpperMsg(cMessage* msg);
96 virtual void handleLowerMsg(cMessage* msg);
97 virtual void handleSelfMsg(cMessage* msg);
98 virtual void handleLowerControl(cMessage* msg);
99 virtual void updateRouteTable(int origin, int lastHop, double rssi, double ber);
100
101 cMessage* decapsMsg(WiseRoutePkt *msg);
102 floodTypes updateFloodTable(bool isFlood, int srcAddr, int destAddr, unsigned
long seqNum);
103
104 int getRoute(int destAddr, bool iAmOrigin = false);
105 };
106
107 #endif
108
-2-
1 //WiseRoute.cc
2
3 #include <limits>
4 #include <algorithm>
5 #include "WiseRoute.h"
6 #include <cassert>
7
8 Define_Module(WiseRoute);
9
10 WiseRoute::~WiseRoute()
11 {
12 cancelAndDelete(routeFloodTimer);
13 }
14
15 void WiseRoute::handleLowerControl(cMessage *msg)
16 {
17 delete msg;
18 }
19
20 int WiseRoute::getRoute(int destAddr, bool iAmOrigin)
21 {
22 tRouteTable::iterator pos = routeTable.find(destAddr);
23 if (pos != routeTable.end())
24 return pos->second.nextHop;
25 else
26 return L3BROADCAST;
27 }
28
29 void WiseRoute::handleUpperMsg(cMessage* msg)
30 {
31 int finalDestAddr;
32 int nextHopAddr;
33 unsigned long nextHopMacAddr;
34 WiseRoutePkt* pkt = new WiseRoutePkt(msg->getName(), DATA);
35 NetwControlInfo* cInfo = dynamic_cast<NetwControlInfo*>(msg->removeControlInfo());
36 int ipBcastAddr = L3BROADCAST;
37
38 pkt->setByteLength(headerLength);
39
40 if ( cInfo == 0 ) {
41 EV << "WiseRoute warning: Application layer did not specifiy a destination
L3 address\n"
42 << "\tusing broadcast address instead\n";
43 finalDestAddr = ipBcastAddr;
44 }
45 else {
46 EV <<"WiseRoute: CInfo removed, netw addr="<< cInfo->getNetwAddr() <<endl;
47 finalDestAddr = cInfo->getNetwAddr();
48 delete cInfo;
49 }
50
51 pkt->setFinalDestAddr(finalDestAddr);
52 pkt->setInitialSrcAddr(myNetwAddr);
53 pkt->setSrcAddr(myNetwAddr);
54 pkt->setNbHops(0);
55
56 if (finalDestAddr == ipBcastAddr)
57 nextHopAddr = ipBcastAddr;
-1-
58 else
59 nextHopAddr = getRoute(finalDestAddr, true);
60 pkt->setDestAddr(nextHopAddr);
61 if (nextHopAddr == ipBcastAddr) {
62 nextHopMacAddr = L2BROADCAST;
63 pkt->setIsFlood(1);
64 nbFloodsSent++;
65 floodTable.insert(make_pair(myNetwAddr, floodSeqNumber));
66 pkt->setSeqNum(floodSeqNumber);
67 floodSeqNumber++;
68 nbGetRouteFailures++;
69 }
70 else {
72 nbPureUnicastSent++;
73 nextHopMacAddr = arp->getMacAddr(nextHopAddr);
74 }
75 pkt->setControlInfo(new NetwToMacControlInfo(nextHopMacAddr));
76 assert(static_cast<cPacket*>(msg));
77 pkt->encapsulate(static_cast<cPacket*>(msg));
78 sendDown(pkt);
79 nbDataPacketsSent++;
80 }
81
82 void WiseRoute::handleSelfMsg(cMessage* msg)
83 {
84 if (msg->getKind() == SEND_ROUTE_FLOOD_TIMER) {
85 int macBcastAddr = L2BROADCAST;
86 int ipBcastAddr = L3BROADCAST;
87 WiseRoutePkt* pkt = new WiseRoutePkt("route-flood", ROUTE_FLOOD);
88 pkt->setByteLength(headerLength);
89 pkt->setInitialSrcAddr(myNetwAddr);
90 pkt->setFinalDestAddr(ipBcastAddr);
91 pkt->setSrcAddr(myNetwAddr);
92 pkt->setDestAddr(ipBcastAddr);
93 pkt->setNbHops(0);
94 floodTable.insert(make_pair(myNetwAddr, floodSeqNumber));
95 pkt->setSeqNum(floodSeqNumber);
96 floodSeqNumber++;
98 pkt->setControlInfo(new NetwToMacControlInfo(macBcastAddr));
99 sendDown(pkt);
100 nbFloodsSent++;
101 nbRouteFloodsSent++;
102 scheduleAt(simTime() + routeFloodsInterval + uniform(0, 1), routeFloodTimer);
103 }
104 else {
105 EV << "WiseRoute - handleSelfMessage: got unexpected message of kind " << msg
->getKind() << endl;
106 delete msg;
107 }
108 }
109
110
111 void WiseRoute::handleLowerMsg(cMessage* msg)
112 {
113 int macBcastAddr = L3BROADCAST;
114 int bcastIpAddr = L2BROADCAST;
-2-
115 WiseRoutePkt* netwMsg = check_and_cast<WiseRoutePkt*>(msg);
116 int finalDestAddr = netwMsg->getFinalDestAddr();
117 int initialSrcAddr = netwMsg->getInitialSrcAddr();
118 int srcAddr = netwMsg->getSrcAddr();
119 double rssi = static_cast<MacToNetwControlInfo*>(netwMsg->getControlInfo())->
getRSSI();
120 double ber = static_cast<MacToNetwControlInfo*>(netwMsg->getControlInfo())->
getBitErrorRate();
121 floodTypes floodType = updateFloodTable(netwMsg->getIsFlood(), initialSrcAddr,
finalDestAddr,
122 netwMsg->getSeqNum());
123 if(trace) {
124 allReceivedRSSI.record(rssi);
125 allReceivedBER.record(ber);
126 }
127 if (floodType == DUPLICATE) {
128 nbDuplicatedFloodsReceived++;
129 delete netwMsg;
130 }
131 else {
132 if (netwMsg->getKind() == ROUTE_FLOOD)
133 updateRouteTable(initialSrcAddr, srcAddr, rssi, ber);
134
135 if (finalDestAddr == myNetwAddr || finalDestAddr == bcastIpAddr) {
136 WiseRoutePkt* msgCopy;
137 if (floodType == FORWARD) {
138
139 msgCopy = check_and_cast<WiseRoutePkt*>(netwMsg->dup());
140 netwMsg->setSrcAddr(myNetwAddr);
141 netwMsg->removeControlInfo();
142 netwMsg->setControlInfo(new NetwToMacControlInfo(macBcastAddr));
143 netwMsg->setNbHops(netwMsg->getNbHops()+1);
144 sendDown(netwMsg);
145 nbDataPacketsForwarded++;
146 }
147 else
148 msgCopy = netwMsg;
149 if (msgCopy->getKind() == DATA) {
150 sendUp(decapsMsg(msgCopy));
151 nbDataPacketsReceived++;
152 }
153 else {
154 nbRouteFloodsReceived++;
155 delete msgCopy;
156 }
157 }
158 else {
159 if (floodType == FORWARD) {
162 netwMsg->setControlInfo(new NetwToMacControlInfo(macBcastAddr));
166 nbUnicastFloodForwarded++;
167 }
168 else {
169 int nextHop = getRoute(finalDestAddr);
-3-
170 if (nextHop == bcastIpAddr) {
171 nextHop = finalDestAddr;
172 nbGetRouteFailures++;
173 }
175 netwMsg->setDestAddr(nextHop);
177 netwMsg->setControlInfo(new NetwToMacControlInfo(arp->getMacAddr(
nextHop)));
181 nbPureUnicastForwarded++;
182 }
183 }
184 }
185 }
186
187
188
189 void WiseRoute::initialize(int stage)
190 {
191 BaseNetwLayer::initialize(stage);
192
193 if(stage == 1) {
194
195 EV << "Host index=" << findHost()->getIndex() << ", Id="
196 << findHost()->getId() << endl;
197
198
199 EV << " host IP address=" << myNetwAddr << endl;
200 EV << " host macaddress=" << arp->getMacAddr(myNetwAddr) << endl;
201 macaddress = arp->getMacAddr(myNetwAddr);
202
203 sinkAddress = par("sinkAddress"); // 0
204 headerLength = par ("headerLength");
205 rssiThreshold = par("rssiThreshold");
206 routeFloodsInterval = par("routeFloodsInterval");
207
208 stats = par("stats");
209 trace = par("trace");
210 debug = par("debug");
211 useSimTracer = par("useSimTracer");
212 floodSeqNumber = 0;
213
214 nbDataPacketsForwarded = 0;
215 nbDataPacketsReceived = 0;
216 nbDataPacketsSent = 0;
217 nbDuplicatedFloodsReceived = 0;
218 nbFloodsSent = 0;
219 nbPureUnicastSent = 0;
220 nbRouteFloodsSent = 0;
221 nbRouteFloodsReceived = 0;
222 nbUnicastFloodForwarded = 0;
223 nbPureUnicastForwarded = 0;
224 nbGetRouteFailures = 0;
225 nbRoutesRecorded = 0;
226 nbHops = 0;
-4-
227 receivedRSSI.setName("receivedRSSI");
228 routeRSSI.setName("routeRSSI");
229 allReceivedRSSI.setName("allReceivedRSSI");
230 receivedBER.setName("receivedBER");
231 routeBER.setName("routeBER");
232 allReceivedBER.setName("allReceivedBER");
233 nextHopSelectionForSink.setName("nextHopSelectionForSink");
234
235 routeFloodTimer = new cMessage("route-flood-timer", SEND_ROUTE_FLOOD_TIMER);
236 if (routeFloodsInterval > 0 && myNetwAddr==sinkAddress)
237 scheduleAt(simTime() + uniform(0.5, 1.5), routeFloodTimer);
238
239 if(useSimTracer) {
240 const char *tracerModulePath = "sim.simTracer";
241 cModule *modp = simulation.getModuleByPath(tracerModulePath);
242 tracer = check_and_cast<SimTracer *>(modp);
243 }
244 BaseMobility * mobility;
245 mobility = check_and_cast<BaseMobility*>(getParentModule()->getSubmodule(
"mobility"));
247 }
248 }
249 }
250
251
252
253 void WiseRoute::finish()
254 {
255 if (stats) {
256 recordScalar("nbDataPacketsForwarded", nbDataPacketsForwarded);
257 recordScalar("nbDataPacketsReceived", nbDataPacketsReceived);
258 recordScalar("nbDataPacketsSent", nbDataPacketsSent);
259 recordScalar("nbDuplicatedFloodsReceived", nbDuplicatedFloodsReceived);
260 recordScalar("nbFloodsSent", nbFloodsSent);
261 recordScalar("nbPureUnicastSent", nbPureUnicastSent);
262 recordScalar("nbRouteFloodsSent", nbRouteFloodsSent);
263 recordScalar("nbRouteFloodsReceived", nbRouteFloodsReceived);
264 recordScalar("nbUnicastFloodForwarded", nbUnicastFloodForwarded);
265 recordScalar("nbPureUnicastForwarded", nbPureUnicastForwarded);
266 recordScalar("nbGetRouteFailures", nbGetRouteFailures);
267 recordScalar("nbRoutesRecorded", nbRoutesRecorded);
268 recordScalar("meanNbHops", (double) nbHops / (double) nbDataPacketsReceived);
269 }
270 }
271
272 void WiseRoute::updateRouteTable(int origin, int lastHop, double rssi, double ber)
273 {
274 tRouteTable::iterator pos;
275
276 pos = routeTable.find(origin);
277 if(trace) {
278 receivedRSSI.record(rssi);
279 receivedBER.record(ber);
280 }
281 if (pos == routeTable.end()) {
282 if (rssi > rssiThreshold) {
283 tRouteTableEntry newEntry;
-5-
284 newEntry.nextHop = lastHop;
285 newEntry.rssi = rssi;
286 if(trace) {
287 routeRSSI.record(rssi);
288 routeBER.record(ber);
289 }
290 routeTable.insert(make_pair(origin, newEntry));
292 tracer->logLink(myNetwAddr, lastHop);
293 }
294 nbRoutesRecorded++;
295 if (origin == 0 && trace) {
296 nextHopSelectionForSink.record(lastHop);
297 }
298 }
299 }
300 else {
301 }
302 }
303
304 cMessage* WiseRoute::decapsMsg(WiseRoutePkt *msg)
305 {
306 cMessage *m = msg->decapsulate();
307 m->setControlInfo(new NetwControlInfo(msg->getSrcAddr()));
308 nbHops = nbHops + msg->getNbHops();
309 delete msg;
310 return m;
311 }
312
313 WiseRoute::floodTypes WiseRoute::updateFloodTable(bool isFlood, int srcAddr, int
destAddr, unsigned long seqNum)
314 {
315 if (isFlood) {
316 tFloodTable::iterator pos = floodTable.lower_bound(srcAddr);
317 tFloodTable::iterator posEnd = floodTable.upper_bound(srcAddr);
318
319 while (pos != posEnd) {
320 if (seqNum == pos->second)
321 return DUPLICATE;
322 ++pos;
323 }
324 floodTable.insert(make_pair(srcAddr, seqNum));
325 if (destAddr == myNetwAddr)
326 return FORME;
327 else
328 return FORWARD;
329 }
330 else
331 return NOTAFLOOD;
332 }
-6-
To appear in KES Invited Session on Evolutionary and Self-Organizing Sensors, Actua-
tors and Processing Hardware. Jennings A. and Channa D., Melbourne, 2005
Annealing Sensor Networks
Andrew Jennings & Daud Channa
Electrical & Computer Engineering School,

RMIT University, Melbourne, Australia
{ajennings@rmit.edu.au, S3047387@student.rmit.edu.au}
Abstract. With a continuing improvement in the capabilities of intelligence per

unit of energy, we should reconsider the organisation of sensor networks. We
contend that solutions should be model-free, locally based and need to be
highly dynamic in nature. Here we propose an approach inspired by simulated
annealing. In the context of several application scenarios we explore the poten-
tial for adding intelligence to sensor networks.
1. Introduction
Sensor networks [1] are envisioned to become an integral part of our lives. These
networks are being applied to provide various tasks such as surveillance and monitor-
ing systems for commercial and military applications. Applications are being devel-
oped to gather process and utilize the information from the surrounding environment
as required. These requirements have kept challenging researchers in the design of
better architectures and protocols for sensor networks. We now have some early de-
ployment of sensor networks, showing that we have successfully established the basic
protocols. These follow two main directions: clustering of nodes [2], and synchronised
sleep cycle networks with a flatter structure [3]. Now the main challenge is to estab-
lish a wide range of application systems. To deploy applications we need methods of
coordination that are efficient both in delivering services and conserving energy.
The growth and advancements in technologies and the constant reduction in the
size and cost of Micro Electro Mechanical Systems (MEMS) have given rise to a
whole new dimension of networking which involves sensors and actuators that are
quickly deployable and self organizing. They have resulted in a new dimension in
network computing, namely pervasive sensing and control. The ongoing rapid ad-
vancements, developments, and research in the sensor and actuator networks only
leaves one to foresee that they will soon intervene and associate into all living habitats
of humans and their surrounding environment.
In most scenarios the network must be functional over long periods of time, it is
crucial for the operation, management and continued lifespan of the network to con-
trol the behaviour/reaction of the sensors and actuators to the different occurrences of
events in the network. The sensors in these networks are limited in energy, memory
and computational facilities, while generally the actuators have an ample supply of
resources as their mobility can enable them to recharge thus utilizing their resources to
the fullest without energy constraint.
The deployment and maintenance of the nodes must be cost effective, because it
will be unfeasible to configure these large networks of small devices. The sensor
nodes along with the actuators must be self organizing and provide a means of pro-
gramming and managing the network as a whole, rather than administering individual
nodes and actuators.
2 Status & scenarios
Although it is not yet clear which applications are viable for sensor networks, we
have selected three scenarios to motivate our work. They serve to highlight the issues
that we now face. We aim to create solutions for these situations.
2.1 Pedestrian Crossing Guard
Fig. 1. A proposal for an instrumented pedestrian crossing
We aim to improve the safety of pedestrian crossings using sensor networks. How
might we prevent the running down of pedestrians?
One possible solution is to use an array of pressure sensors on the roadway surface
to detect pedestrians walking. This would be in addition to proximity sensors and vis-
ual surveillance [5], as illustrated in Figure 1. Through combination of sensor read-
ings, we can improve the accuracy of recognition. If we want to make use of the sen-
sor readings then we need confidence that there is a low probability of false positives -
otherwise car drivers will not accept the system.
With a reliable method of pedestrian detection, we can perhaps move to the next
level with these systems. If we can reliably detect a car traveling at a speed likely to
result in a collision, then the crossing system can intervene and communicate with the
car - potentially it could also override car braking systems. This would bring the car to
a halt. We have the possibility of eliminating the possibility of cars contacting pedes-
trians at crossings. There may also be a role for coordinating with robot teams to en-
able more active monitoring of pedestrians here we need development of team be-
haviour [6]
2.2 Animal Counting
Environmental monitoring was one of the earliest motivations for exploring sensor
networks. A typical task is the estimation of animal populations. We would like to
know how many of a particular type of animal are within a geographic area. In con-
trast to urban applications, this setting is very demanding in terms of energy manage-
ment. Note that the estimation of populations is more difficult than simply tracking
animals - we need some confidence of the identity of animals. Is the set of readings for
a single animal, or two that are within the same area?
2.3 Perimeter Surveillance
This is a classical application of sensory technology. We have a perimeter that we

wish to patrol, with video and movement surveillance. To augment this, we would like
to deploy proximity sensors to improve accuracy. These scenarios can give us a
framework to consider sensor network application approaches. They provide chal-
lenges and a range of difficulties. All are real applications that may have some pros-
pect of widespread deployment. At this stage of development of the field, it is impor-
tant to focus on feasible applications to focus the research.
3 Energy and Intelligence
One of the central tenets of sensor networks has been the need to keep nodes simple
and careful in their use of energy. We could not, for example, implement the full
TCP/IP stack on sensor nodes. This would be a waste of energy, since the nature of
the communication is quite different.
Progress in battery technology is painful and very slow. But when we consider in-
telligence per unit of energy, then progress is quite dramatic. So we should be more
open to incorporating intelligence in the sensor node, as long as that results in signifi-
cant energy conservation.
3.1 Local Resolution
Fig. 2. Directed diffusion (network wide) versus local resolution
One of the original proposals for sensor network protocols was "directed diffusion"
(DD) [4]. It is a robust protocol that can work in very tough environments. Even with
extensive network breakages, it will continue to operate. As Figure 2 illustrates, "in-
terests" are propagated to areas of the network, and "gradients" are used to reinforce
the successful delivery of packets across the network.
Given the constraints placed on directed diffusion, it is an appealing solution. But

how might it change if we allowed local processing, rather than propagating results
across the broader sensor network? DD assumes that we have to send this outside the
sensor network, but with local processing we can avoid the energy consumption of
network wide reporting.
This creates both a need for local algorithms that can actually resolve sensor data,
and also a means of coordination. There are clear energy advantages in local resolu-
tion.
Similar difficulties arise in the location of mobile sensor nodes. The author in [7]
has presented the use of simulated annealing for this problem. Here we are concerned
with organisation and messaging for fixed nodes.
3.2 Model Based, or Model Free?
If we want to improve monitoring, then perhaps a more accurate model of the con-
text will help? In the case of the pedestrian crossing, we could develop a tracking
model. For example, Kalman filtering could aid following an individual through the
network. But if we incorporate this model, what will happen in non-modelled cases?
How will our model-based approach react when a person falls over, and lies stationary
on the crossing? In the worst case, we might decide that the crossing is clear, and let
the cars proceed.
Similarly, in surveillance of a perimeter, we might improve accuracy by statistical

training to detect people walking across the field. But will we detect somebody crawl-
ing across the space?
Once we fix a model for the sensing environment, defining the range of possible
targets, then the task of constructing the sensor network is reduced to optimisation.
There is no need for further intelligence. So the real challenge for sensor networks is
how to deal with unusual data. Consider surveillance when a bunch of leaves falls to
the ground. Do we raise an alarm or simply log the event for further processing? If we
log it, what priority do we give to the event?
This is a familiar problem in AI, bringing us to the very familiar challenges of se-
mantics. How do we deal with images that do not have familiar content? How can we
go beyond simple statistical pattern matching? These are very difficult, but also very
important problems.
3.3 Dynamics
Consider the problem of tracking (and identifying) an animal that gives us unusual
readings. Perhaps it is of a size that we have not encountered, or it genuinely is a new
entry to the region. Clearly this is important, and we would like to track its trajectory.
But in order to do this, we need to estimate velocities and alert the relevant part of the
sensor network. Once we have lost contact, it will be difficult to sustain the identity.
Remember, we are interested in counting animals, so identity is important. Clearly we
need application protocols that can deal effectively with highly dynamic situations.
4 Annealing Sensor Networks
The simulated annealing algorithm is a successful method of searching for optimal

solutions in complex spaces. Most importantly, it is model free : any problem can be
formulated as an annealing process. In analogy with the process of annealing crystals,
it has an associated temperature. At high temperature, large parameter changes are
possible, but as the process cools only smaller changes are possible.
Fig. 3. Activation cycles (sleep cycles) for a single node

We propose an approach to organising sensor networks that is inspired by simu-
lated annealing. Regions have a temperature, which indicates the intensity of sensing.
Figure 3 illustrates the sleep cycle of a single node. At a low temperature, the nodes
cycle only at A, but as the temperature increases we also cycle at B,C,D progressively.
Since these cycles are divisions of the fundamental cycle (the A cycle), these sched-
ules do not conflict.
Fig. 4. Network temperature heating process
In the event that a node encounters an unexpected stimulus, it can cause a local rise
in temperature. If several nodes in a region send this message, then a rapid rise in lo-
cal temperature can take place. We can allow this temperature to spread rapidly in
space if we desire, or rapidly decay. In accordance with the physical analogy, local
heating cannot spread vast distances without decay. Figure 4 illustrates the process.
To effectively make use of annealing sensor networks, we need local resolution of

sensor information. For example, in the case of animal tracking, a local decision is
needed on the temperature response. Note that an identification is not needed, but only
local decision making. We are investigating how to provide this on the typical proces-
sors used for sensor nodes. It certainly seems possible to accomplish this computation
on the nodes. Of course over time, we can expect the intelligence/energy quotient to
continue to grow.
Annealing sensor networks (ASN) are a development of directed diffusion net-

works. There are some important differences. The adaptive sleep cycle provides for
rapid response. Local resolution of control is an important difference. Where directed
diffusion incorporates routing, ASN's only advise routing.
5 Discussion
We have proposed an approach to model-free local behaviour for sensor networks.

Given that we have no local model of expected behaviour, how can we achieve local
resolution? Each node can keep a statistical database of patterns it has encountered.
When patterns within a statistical tolerance appear, this can trigger the appropriate
behaviour.
Fully distributed control of sensor networks in this manner raises some important
new issues. How do we maintain the currency of statistical data? How can we make
changes to behaviour whilst ensuring network stability?
It is interesting that classical problems of semantics come to the forefront when we
want to further explore sensor networks. Here the resources we have to bring to the
problem are limited. We have an unlimited source of data, through lifelong observa-
tion of the world through the network sensors. Potentially we can bring vast computa-
tion to the task, through recording and processing offline. But we are limited in human
intervention. This leads us to explore computationally intensive approaches. Perhaps
we should consider the task as data mining for sensor organisation methods.
References
1. Deborah Estrin, Ramesh Govindan, John Heidemann and Satish Kumar Next Century
Challenges: Scalable Coordination in Sensor Networks In Proceedings of the Fifth An-
nual International Conference on Mobile Computing and Networks (MobiCOM '99),
August 1999, Seattle, Washington.
2. Wendi Heinzelman, Anantha Chandrakasan, and Hari Balakrishnan Energy-Efficient
Communication Protocols for Wireless Microsensor Networks, Proc. Hawaiian Int'l
Conf. on Systems Science, January 2000.
3. Wei Ye and John Heidemann and Deborah Estrin An Energy-Efficient MAC Protocol
for Wireless Sensor Networks Proceedings 21st International Annual Joint Conference
of the IEEE Computer and Communications Societies, 2002
4. Chalermek Intanagonwiwat, Ramesh Govindan and Deborah Estrin Directed Diffusion:
A Scalable and Robust Communication Paradigm for Sensor Networks In Proceedings
of the Sixth Annual International Conference on Mobile Computing and Networks
(MobiCOM 2000), August 2000, Boston, Massachusetts.
5. Christian Wohler Autonomous in situ training of classification modules in real-time vi-
sion systems and its application to pedestrian recognition Pattern Recognition Letters
Volume 23 , Issue 11 Pages: 1263 - 1270 (September 2002)
6. H. Van Dyke Parunak, Sven. A. Bruekner & James Odell Swarming pattern detection
in Sensor and Robot Networks Altarium Institute, Working Document
7. Martinson E. and Payton D. Lattice Formation in Mobile Autonomous Sensor Arrays,
HRL Laboratories, LLC. 2003-2004

FYP0703 With Appendix

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FYP0703 With Appendix

Uploaded by

Copyright:

Available Formats

IEEE 802.15.

4/ZigBee Network Lifetime Optimization

Usman M. Nooruddin 07-0039

Department of Electrical Engineering

Usman M. Nooruddin 07-0039

Dated: December 2011

CHAPTER 2 IEEE 802.15.4 / ZigBee 3

CHAPTER 03 RELATED WORK 13

CHAPTER 04 PROBLEM STATEMENT 17

CHAPTER 05 PROPOSED SOLUTION 19

CHAPTER 06 SIMULATION SETUP 25

CHAPTER 08 DISCUSSION OF RESULTS 37

CHAPTER 10 FUTURE WORKS 41

CHAPTER 11 LIST OF REFERENCES 43

5.1 Proposed Scenario 21

6.1 OMNeT++ Main Window 26

IEEE 802.15.4/ZIGBEE NETWORK LIFETIME OPTIMIZATION

1.2 DEFINING THE PROBLEM

1.2.1 PROJECT AIMS

1.2.2 PROJECT GOALS

1.3 TOOLS USED

1.3.2 INET FRAMEWORK:

The INET Framework is an open-source communication networks simulation package for

1.4 PROFESSIONAL STANDARDS:

This project complies with the standards set by:

2.1.1 EVOLUTION OF LOW-RATE WIRELESS PERSONAL AREA NETWORK (LR-WPAN)

2.1.2 ZIGBEE AND IEEE 802.15.4

2.1.3 WHY IS IT CALLED ZIGBEE?

2.2 IEEE 802.15.4 WPAN

2.2.1 GENERAL DESCRIPTION

2.2.2 ZIGBEE CHARACTERISTICS

2.4GHz and 868/915 MHz dual PHY modes.

Allocated 16 bit short or 64 bit extended addresses.

2.2.3 DEVICE TYPES

2.2.4 NETWORK TOPOLOGIES

2.2.4.1 STAR TOPOLOGY

Figure 2.1: Star Topology Network

2.2.4.2 PEER-TO-PEER (AD-HOC) TOPOLOGY

Figure 2.2: Peer-to-Peer Topology

2.2.4.3 CLUSTER-TREE TOPOLOGY

Figure 2.3: Cluster Network

2.2.4.4 MESH TOPOLOGY

Figure 2.3: Mesh Network

Figure 2.4: ZigBee Networking Protocol Layers

2.3.1 NETWORK AND APPLICATION SUPPORT LAYER:

The ZigBee Device Object (ZDO)

2.3.2 PHYSICAL (PHY) LAYER:

2.3.3 MEDIA ACCESS CONTROL (MAC) LAYER:

2.4.1 TYPES OF APPLICATIONS

FUNCTION APPROXIMATION AND EDGE DETECTION

2.4.2 APPLICATION EXAMPLES

DISASTER RELIEF APPLICATIONS

ENVIRONMENT CONTROL AND BIODIVERSITY MAPPING

MACHINE SURVEILLANCE AND PREVENTIVE MAINTENANCE

MEDICINE AND HEALTH CARE

3.1 RELATED WORK

3.1.2 Arun S., Seminar Report on ZigBee, September 2008.

3.1.6 Fabrizio Granelli, Dzmitry Kliazovich and Nelsom L. S. Da Fonseca, Performance

3.1.8 C. Mallanda, A. Suri, V. Kunchakarra, S. S. Iyengar, R. Kannan and A. Durresi, Simulating

3.1.9 E. Egea-Lpez, J. Vales-Alonso, A. S. Martnez-Sala, P. Pavn-Mario and J. Garca-Haro,

[This page is intentionally left blank]

4.1 ENERGY EFFICIENCY

4.2 PROBLEM STATEMENT