INTEGRATING WIRELESS SENSOR - Ain Shams Universitycsys.cis.asu.edu.eg/kemara/files/wsnipthesis.pdf · INTEGRATING WIRELESS SENSOR ... I.4 Introduction to OMNeT++ ... Figure @4.5:

INTEGRATING WIRELESS SENSOR

NETWORKS WITH IP-BASED NETWORK

a thesis submitted as a partial fulfillment of the requirements for the

degree of Master of Science in Computer and Information Sciences.

By

Karim Ahmed Awad El Sayed Emara

B.Sc. in Computer and Information Sciences, Demonstrator at Computer Systems Department,

Faculty of Computer and Information Sciences, Ain Shams University.

Under Supervision of

Prof. Dr. Taha El Areef Prof. of Computer Science,

Computer Science Department, Faculty of Computer and Information Sciences,

Ain Shams University.

Prof. Dr. Mohammad Hashem Head of Information Systems Department,

Information Systems Department, Faculty of Computer and Information Sciences,


Dr. Mohammad Abdeen Lecturer,

Computer Science Department, Faculty of Computer and Information Sciences,


Cairo 2009

Computer Science Department Faculty of Computer & Information Sciences Ain Shams University

Acknowledgement IV

Acknowledgement

All praise and thanks to ALLAH, who provided me the ability to

complete this work. I hope to accept this work from me.

I am grateful of my parents and my family who are always providing

help and support throughout the whole years of study. I hope I can

give that back to them.

I also offer my sincerest gratitude to my supervisors, Prof. Dr. Taha

Al Areef, Prof. Dr. Mohammad Hashem, and Dr. Mohammad Abdeen

who have supported me throughout my thesis with their patience,

knowledge and experience.

I sincerely acknowledge and express my appreciation to Prof. Dr.

Mohammad Essam Khalifa, the Dean of the faculty of Computer and

Information Sciences, Ain Shams University, Prof. Dr. Said

Ghoniemy, the ex-Head of Computer Systems Department, and Dr.

Hossam Faheem, the Director of Egyptian Universities Network, for

their support, concern and thankful help.

Finally, I would thank my friends and all people who gave me

support and encouragement.

Abstract V

Abstract

Wireless sensor networks (WSN) envision a ubiquitous computing

future in many fields, like environmental monitoring, military

surveillance, and inventory tracking. Wireless sensor networks are

composed of large numbers (up to thousands) of tiny radio-

equipped sensors. Every sensor node has a small microprocessor

with enough power to allow the sensors to autonomously form

networks through which sensor information is gathered. Sensor

nodes in such networks are ad hoc deployed, self-configurable and

battery powered. A set of special protocols are developed for such

networks to fit their specific characteristics.

Many wireless sensor network applications cannot run in

complete isolation; the sensor network must be connected to

monitoring and controlling entities through known wireless/wired

networks like IP-based networks. Such interconnection achieves

many advantages and increases sensor networks benefits such as:

• Controlling and monitoring sensor networks remotely.

• Integrating data collected from sensor networks into data

repositories.

• Ability to collapse multiple remote sensor networks into

one virtual sensor network.

A few approaches recently manipulate this issue and they

are categorized into two main approaches: gateway-based and

network overlay. The first approach uses a gateway node to

interconnect both networks and bring data from WSN to the IP

network. It so allows choosing WSN communication protocols

Abstract VI

freely. The second approach overlays the protocol stack of one

network by the protocol stack of the other network. Overlaid nodes

become an intersection area among both networks through which

they are integrated.

In this thesis, an integration technique is proposed. This

technique supports both address-centric and data-centric WSNs. It

uses a low-level gateway node to translate packets from one

network to the other. Thus, it allows choosing WSN communication

protocols that are most suitable for the sensor network application.

Furthermore, it depends on a simple translation operation and does

not require modification to be made in protocols running in either

network. Therefore, it can be used in different applications with no

need to modify the gateway logic. Moreover, this technique

provides transparent communication between both networks

which allows interconnection with no need to know details about

the protocols of the other side.

The proposed technique is implemented on the OMNeT++

simulator for both address-centric and data-centric paradigms.

Experimental results show that it supports accessing individual

sensor nodes from IP hosts with high request rates without

significantly influencing the network performance. For example,

when an IP host sends requests to sensor nodes up to 150 requests

per second, the average of overhead delay is about 0.25

milliseconds with 0.5% average increase in the packet loss. On the

other hand, it also supports accessing data-centric WSN with

different sizes and through simultaneous queries (interests). For

example, when an IP host propagates up to 20 simultaneous

Abstract VII

interests, the median overhead delay is about 4.3 milliseconds with

6.5% decrease in the delivery ratio at maximum. The proposed

integration technique, however, suffers from bottleneck and single

point of failure problems which should be investigated in future

work.

Table of Contents VIII

Table of Contents

Acknowledgement ................................................................................................. I

Abstract ................................................................................................................... II

Table of Contents ................................................................................................... V

List of Tables ........................................................................................................ VII

List of Figures .................................................................................................... VIII

List of Abbreviations .......................................................................................... XI

List of Publications ............................................................................................. XII

1 Introduction .................................................................................................. 1

1.1 Overview ............................................................................................................ 1

1.1.1 Wireless Sensor Network (WSN) ................................................. 1

1.1.2 Applications ........................................................................................... 3

1.1.3 Sensor Node Architecture ............................................................... 7

1.1.4 WSN Protocols ................................................................................... 11

1.2 WSN and IP network Integration ......................................................... 18

1.3 Motivation ...................................................................................................... 23

1.4 Objectives ....................................................................................................... 24

1.5 Thesis Outline ............................................................................................... 24

2 IP-WSN Integration Techniques .......................................................... 27

2.1 Application Level Gateway ..................................................................... 28

2.2 Virtual IP (VIP) Bridge .............................................................................. 31

2.3 WSN Overlays TCP/IP network ............................................................ 36

2.4 TCP/IP network Overlay ......................................................................... 42

2.5 Delay Tolerant Network (DTN) ............................................................ 48

2.6 Discussion ...................................................................................................... 51

3 Proposed Integration Technique ........................................................ 55

3.1 Design Considerations .............................................................................. 55

3.2 The Design of Proposed Technique .................................................... 58

3.2.1 Direct Access to Sensor Nodes ................................................... 60

3.2.2 Data Centric WSN ............................................................................. 64

3.3 Gateway Architecture ............................................................................... 67

3.3.1 Direct Access to Sensor Nodes ................................................... 68

3.3.2 Data Centric WSN ............................................................................. 72

Table of Contents IX

3.4 Discussion ...................................................................................................... 75

4 Implementation ........................................................................................ 79

4.1 Simulators Review ...................................................................................... 79

4.1.1 NS-2 ........................................................................................................ 80

4.1.2 GloMoSim ............................................................................................. 82

4.1.3 OPNET ................................................................................................... 83

4.1.4 OMNeT++ ............................................................................................. 84

4.1.5 Simulator Selection ......................................................................... 86

4.2 Simulation Environment ......................................................................... 87

4.3 Direct Access to Sensor Nodes ........................................................... 101

4.3.1 Generic Node Module .................................................................. 102

4.3.2 Application Module ...................................................................... 103

4.4 Data-centric WSN ..................................................................................... 104

4.4.1 Directed Diffusion Protocol ...................................................... 104

4.4.2 Generic Node Module .................................................................. 106

4.4.3 Application Module ...................................................................... 108

5 Experiments and Evaluation .............................................................. 111

5.1 Evaluation Methodology ....................................................................... 111

5.2 Evaluating Direct Access to Sensor Nodes .................................... 112

5.3 Evaluating Data Centric WSN ............................................................. 123

6 Conclusion and Future Work .............................................................. 131

6.1 Conclusion ................................................................................................... 131

6.2 Future Work ............................................................................................... 132

Appendix I: OMNeT++ Simulator ................................................................. 136

I.1 Compiling OMNeT++ 3.3 ....................................................................... 135

I.2 Compiling INET Framework ............................................................... 137

I.3 Porting and Compiling Castalia 2.1 .................................................. 138

I.4 Introduction to OMNeT++ .................................................................... 141

References .......................................................................................................... 147

Arabic Summary .................................................................................................... ١

List of Tables X

List of Tables

Table @1.1: Key differences between traditional IP-based networks and

wireless sensor networks ............................................................................................... 19

Table @2.1: Comparison among the integration approaches ............................. 54

Table @3.1: Virtual address mapping tables for the network shown in Figure

@3.1 .............................................................................................................................................. 61

Table @3.2: The mapping table of a data-centric network .................................. 64

Table @3.3: Comparison between proposed technique and the related work

.................................................................................................................................................... 78

Table @5.1: Direct access to sensor nodes in different request rates (trafEic

within sensor network only) ......................................................................................... 114

Table @5.2: Direct access to sensor nodes in different request rates (trafEic

across IP and sensor networks) ................................................................................... 115

Table @5.3: Direct access to sensor nodes vs. number of requesting nodes

(sensor network only) ...................................................................................................... 119

Table @5.4: Direct access to sensor nodes vs. number of requesting hosts (IP

and sensor networks) ....................................................................................................... 119

Table @5.5: Experimental results for data-centric WSN in several network

sizes .......................................................................................................................................... 124

Table @5.6: Experimental results for data-centric WSN with multiple interests

.................................................................................................................................................... 127

List of Figures XI

List of Figures

Figure @1.1: Wireless sensor network - collaborative sensor nodes 2

Figure @1.2: The components of sensor node ............................................ 7

Figure @1.3: Sensor node Mica mote (evolved out at the University of

California at Berkeley) ....................................................................................... 11

Figure @1.4: The sensor network protocol stack ...................................... 12

Figure @1.5: Internetworking between sensor nodes and user through

Internet or satellite network. .......................................................................... 16

Figure @1.6: Wireless sensor network connected with Internet through

a gateway ................................................................................................................ 18

Figure @2.1: Integration approaches taxonomy ........................................ 27

Figure @2.2: Application-level Gateway ........................................................ 29

Figure @2.3: Communication Architecture using a gateway ................ 29

Figure @2.4: A WSN identiEied by a single IP address ............................. 30

Figure @2.5: Packet mapping in single IP framework ............................. 31

Figure @2.6: The VIP Bridge packet format and translation operations

..................................................................................................................................... 33

Figure @2.7: WSN Overlay TCP/IP network ................................................ 38

Figure @2.8: EIA Protocol stack ........................................................................ 41

Figure @2.9: Using TCP/IP within and outside sensor networks ....... 43

Figure @2.10: Architecture of tiny TCP/IP protocol stack ..................... 45

Figure @2.11: The bundle layer overlay in DTN ......................................... 50

Figure @2.12: DTN Gateway architecture ..................................................... 50

Figure @3.1: The proposed interconnection technique between WSN

and IP network ..................................................................................................... 59

Figure @3.2: (Top) A TCP/IP packet originating from Host A to Node X

as in Figure @3.1. (Bottom) The same packet after packet translation

..................................................................................................................................... 63

Figure @3.3: (Top) A WSN packet originating from Node X to Host A as

in Figure @3.1. (Bottom) The same packet after packet translation . 64

List of Figures XII

Figure @3.4: The interconnection technique with data-centric WSN

..................................................................................................................................... 65

Figure @3.5: Virtual IP address request for a given Interest. ............... 66

Figure @3.6: (Top) A TCP/IP packet originating from Host A querying

about an interest as in Figure @3.4. (Bottom) The same packet after

translation .............................................................................................................. 67

Figure @3.7: (Top) A WSN data message. (Bottom) The same packet

after packet translation ..................................................................................... 67

Figure @3.8: Gateway Architecture for direct access mode .................. 68

Figure @3.9: Protocol stack for the gateway in direct access mode .. 69

Figure @3.10: Packet translation for direct access to a sensor node . 71

Figure @3.11: Gateway architecture in data-centric WSN ..................... 73

Figure @3.12: Protocol stack for the gateway in data-centric WSN ... 73

Figure @4.1: The simulation network topology using OMNeT++

simulator ................................................................................................................. 87

Figure @4.2: The IP host structure in INET framework .......................... 89

Figure @4.3: The internal structure of sensor node in Castalia ........... 95

Figure @4.4: The modiEied structure for sensor nodes and gateway 96

Figure @4.5: An example of interest diffusion in sensor network ...... 105

Figure @5.1: Simulation environment ............................................................ 111

Figure @5.2: Average delay versus requests rate - direct access to

sensor nodes .......................................................................................................... 116

Figure @5.3: Packet loss percentage versus request rate - direct access

to sensor nodes ..................................................................................................... 117

Figure @5.4: The total throughput versus requests rate - direct access

to sensor nodes ..................................................................................................... 118

Figure @5.5: Average delay versus number of nodes - direct access to

sensor nodes .......................................................................................................... 120

Figure @5.6: Packet loss percentage versus number of nodes - direct

access to sensor nodes ...................................................................................... 121

Figure @5.7: Total throughput versus the number of nodes - direct

access to sensor nodes ...................................................................................... 122

List of Figures XIII

Figure @5.8: Average delay versus number of nodes - data centric WSN

..................................................................................................................................... 125

Figure @5.9: Distinct event delivery ratio versus number of nodes -

data centric WSN ................................................................................................. 126

Figure @5.10: Average delay versus number of interests - data centric

WSN ........................................................................................................................... 128

Figure @5.11: Median delay versus number of interests - data centric

WSN ........................................................................................................................... 129

Figure @5.12: Distinct event delivery ratio versus number of interests -

data centric WSN ................................................................................................. 129

List of Abbreviations XIV

List of Abbreviations

µIP A light weight TCP/IP protocol stack

6LoWPAN IPv6 over Low power Wireless Personal Area

Networks

ADC Analog to Digital Converter

BS Base Station

CPU Central Processing Unit

DTC Distributed TCP Caching

DTN Delay Tolerant Networking

EIA Extensible Interworking Architecture

EML EIA Management Layer

EQL EIA Query Layer

ETL EIA Tunneling Layer

GPS Global Positioning System

HVAC Humidity, Ventilation, Air Conditioning

IETF Internet Engineering Task Force

IP Internet Protocol

NGN Next Generation Network

OGN Overlay Gateway Node

OSN Overlay Sensor Network

PDA Personal Digital Assistant

QoS Quality of Service

SIP Session Initiation Protocol

VIP Bridge Virtual IP Bridge

VSN Virtual Sensor Node

WSN Wireless sensor network

List of Publications XV

List of Publications

Karim A. Emara, Mohammad Abdeen, Mohammad Hashem, “A

gateway-based framework for transparent interconnection between

WSN and IP network”, EUROCON 2009, IEEE, 18-23 May 2009,

Pages: 1775 – 1780, St. Petersburg, Russia

Karim A. Emara, Mohammad Abdeen, Mohammad Hashem,

“Generic Technique for Interconnection between WSN and IP

Network”, International Journal of Intelligent Computing &

Information Science (IJICIS), Vol. 10, No. 2, Faculty of Computer and

Information Sciences, Ain Shams University, Cairo, Egypt, July 2010

(To be appeared)

Introduction 1

1 Introduction

1.1 Overview

1.1.1 Wireless Sensor Network (WSN)

Wireless sensor networks (WSN) are dense wireless networks of

small, low-cost sensor nodes, which collect and disseminate

environmental data. WSNs facilitate monitoring and controlling of

physical environments from remote locations with better accuracy

than other known monitoring systems such as remote sensing @[6].

These tiny sensor nodes leverage the idea of sensor networks based

on collaborative effort of a large number of nodes @[7]. Sensor

networks represent a significant improvement over traditional

sensors. As they have the capabilities to route data back by a multi-

hop infrastructureless architecture to the base station or sink,

which is the entity where information is required, as shown in

Figure @1.1. In this figure, sensor nodes from B to E sense the

existing of an animal and determine its relative location. They

report the animal location to the sensor node A. The node A finds

that the data received from other nodes points to the same location

approximately. Therefore, it sends a summarized packet to the base

station instead of sending individual packets to minimize

communication and save power. Thus, the sensor nodes collaborate

together to collect desired information from the environment by

performing in-network data processing and aggregation (data

diffusion).

Introduction

is the low power consumption requirement. Sensor nodes carry

limited, generally irreplaceable, power sources. Therefore, while

traditional networks aim to achiev

provisions, sensor network protocols focus primarily on

conservation

design often employs

processing, multi

techniques to extend the network lifetime.

be resilient to failures due to different reasons such as physical

destruction

need to be overcome to have ubiquitous deployment of sensor

networks. These

heterogeneity,

manufacturing qua

from other wireless ad

protocols and

wireless ad hoc networks are not well suited for WSN

Introduction

Figure @@@@1.1:

One of the most important constraints on sensor





conservation @[7]

sign often employs

processing, multi



destruction of nodes or energy depletion. Several challenges


networks. These

heterogeneity,

manufacturing qua

These design challenges

from other wireless ad

protocols and


: Wireless sensor






[7]. In addition to

sign often employs some approaches

processing, multi-hop communication, and density control



of nodes or energy depletion. Several challenges


networks. These challenges include dynamic topology, device

lack of quality of service, application support,

manufacturing quality, and ecological

design challenges

from other wireless ad-hoc or mesh networks.

protocols and algorithms have been proposed for traditional


Wireless sensor network -




traditional networks aim to achieve high quality of service (QoS)


In addition to energy

some approaches

communication, and density control





challenges include dynamic topology, device


lity, and ecological issues

design challenges make sensor networks different

hoc or mesh networks.

algorithms have been proposed for traditional


- collaborative sensor nodes




e high quality of service (QoS)


energy-aware techniques

some approaches such


techniques to extend the network lifetime. Moreover






issues @[5].

make sensor networks different

hoc or mesh networks.



collaborative sensor nodes

One of the most important constraints on sensor networks





aware techniques, the WSN

such as, in-network


Moreover, WSNs should







hoc or mesh networks. Therefore, the


wireless ad hoc networks are not well suited for WSN @[7].

2

collaborative sensor nodes

networks




provisions, sensor network protocols focus primarily on energy

he WSN

network


WSNs should


of nodes or energy depletion. Several challenges still





Therefore, the


Introduction 3

1.1.2 Applications

On the basis of nodes that have such sensing facilities, in

combination with computation and communication abilities, many

different kinds of applications can be constructed. In this section,

some popular application types are listed as described in @[1].

Disaster relief applications

One of the most often mentioned application types for WSN are

disaster relief operations. A typical scenario is wildfire 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 wildfire, 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 firefighters 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

wildfires. 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 floor; an understanding of its erosion processes is

Introduction 4

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 inefficient Humidity,

Ventilation, Air Conditioning (HVAC) usage. A better, real-time,

high-resolution monitoring of temperature, airflow, 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. Improved energy efficiency as well as

improved convenience is some goals of “intelligent buildings”, for

which currently wired systems like BACnet, LonWorks, or KNX are

under development or are already deployed; these standards also

include the development of wireless components or have already

incorporated them in the standard.

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

Introduction 5

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 retrofitted 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 vehicle’s position and alert security personnel – this

application shares 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.

Introduction 6

Precision agriculture

Applying WSN to agriculture allows precise irrigation and fertilizing

by placing humidity/soil composition sensors into the fields. A

relatively small number is claimed to be sufficient, about one sensor

per 100 m × 100 m area. Similarly, pest control can profit from a

high-resolution surveillance of farm land. Also, livestock breeding

can benefit from attaching a sensor to each pig or cow, which

controls the health status of the animal (by checking body

temperature, step counting, or similar means) and raises alarms if

given thresholds are exceeded.

Medicine and health care

Along somewhat similar lines, the use of WSN in health care

applications is a potentially very beneficial, but also ethically

controversial, application (controversial as it collects and uses

personal data without exact user knowledge about where and how

this data will be used). 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 life saving.

While most of these applications are, in some form or

another, possible even with today’s technologies and without

wireless sensor networks, all current solutions are “sensor

starved”. Most applications would work much better with

information at higher spatial and temporal resolution about their

Introduction 7

object of concern than can be provided with traditional sensor

technology. WSNs are to a large extent about providing the required

information at the required accuracy in time with as little resource

consumption as possible.

1.1.3 Sensor Node Architecture

The basic unit of sensor network is the sensor node on which the

whole network depends to perform its tasks. Sensor node is made

up of four basic components as shown in Figure @1.2: a sensing unit,

a processing unit, a transceiver unit and a power unit. They may

also have application dependent additional components such as a

localization unit, a power generator and a mobility unit @[7].

Sensing units are usually composed of two subunits:

sensors and analog to digital converters (ADCs). The analog signals

produced by the sensors based on the observed phenomenon are

converted to digital signals by the ADC, and then fed into the

processing unit. There are diverse types of sensors however they

can be categorized into; passive and active sensors. Passive sensors

Power Unit

Sensing Unit

Processing Unit

Transceiver Unit

Mobility Unit

Localization Unit

Power Generator

Figure @@@@1.2: The components of sensor node

Introduction 8

can measure a physical quantity at the point of the sensor node

without actually manipulating the environment by active probing –

in this sense, they are passive. Typical examples for such sensors

include thermometer, light sensors, vibration, and microphones.

Active sensors probe the environment, for example, a sonar or

radar sensor or some types of seismic sensors, which generate

shock waves by small explosions. These are quite specific and

require quite special attention @[1].

The processing unit or the controller manages the

procedures that make the sensor node collaborate with the other

nodes to carry out the assigned tasks. The controller is the core of a

wireless sensor node. It collects data from the sensors, processes

this data, decides when and where to send it, receives data from

other sensor nodes, and decides on the sensor’s behavior. It has to

execute various programs, ranging from time-critical signal

processing and communication protocols to application programs;

it is the Central Processing Unit (CPU) of the node. Such a variety of

processing tasks can be performed on various controller

architectures, representing trade-offs between flexibility,

performance, energy efficiency, and costs. Along with the controller,

a memory is always associated with the controller in the processing

unit. Evidently, there is a need for RAM to store intermediate sensor

readings, packets from other nodes, and so on. Program code can be

stored in ROM, EEPROM or flash memory to be preserved even in

the absence of the power @[1].

A transceiver unit is a combined transmitter and receiver

that connect the node to the network. Its essential task is to convert

Introduction 9

a bit stream coming from the processing unit and convert them to

and from radio waves. Usually, half-duplex operation is realized

since transmitting and receiving at the same time on a wireless

medium is impractical in most cases (the receiver would only hear

the own transmitter anyway). A range of low-cost transceivers is

commercially available that incorporate all the circuitry required

for transmitting and receiving – modulation, demodulation,

amplifiers, filters, mixers, and so on. The choice of the suitable

transceiver depends on many characteristics such as power

consumption in different states (idle, sleeping, transmitting, or

receiving), state change time, data rates, modulation and coding,

and coverage range @[1].

One of the most important components of a sensor node is

the power unit which provides all other parts by the required

energy. Power units may be supported by a power scavenging unit

such as solar cells. However, the most common case is that the

power unit is not chargeable and so other units have to reduce its

power consumption as much as possible.

There are also other subunits, which are application

dependent such as localization and mobility units. In many

circumstances, it is useful or even necessary for a node to be aware

of its location in the physical world. For example, tracking or event-

detection functions are not particularly useful if the WSN cannot

provide any information where an event has happened. To do so,

usually, the reporting nodes’ location has to be known. Manually

configuring location information into each node during deployment

is not an option. Similarly, equipping every node with a Global

Introduction 10

Positioning System (GPS) receiver fails because of cost and

deployment limitations (e.g. does not work indoors). Thus, there

are various techniques of how sensor nodes can learn their location

automatically, either fully automatically by relying on means of the

WSN itself or by using some assistance from external infrastructure

@[1].

A mobility unit may sometimes be needed to move sensor

nodes when it is required to carry out the assigned tasks. Mobility

can appear in three forms. First, node mobility is used where the

application requires individual nodes to be mobile in its area. In the

face of node mobility, the network has to reorganize itself

frequently enough to be able to function correctly. Second, sink

mobility is a special case of node mobility but sinks can be

considered as a separate part from sensor network, for example, a

human user requested information via a PDA while walking in an

intelligent building. Finally, in applications like event detection and

in particular in tracking applications, the cause of the events or the

objects to be tracked can be mobile. This is called event mobility

which the nodes and sinks are stationary but the tracked objects or

events are mobile.

All of these subunits may need to fit into a tiny-sized

module as shown in Figure @1.3. The required size may be smaller

than even a cubic centimeter which is light enough to remain

suspended in the air. Due to sensor node architecture and its

characteristics, they need special protocols to fit with architectural

constraints and to allow them to operate together in energy-

efficient manner to accomplish the required task.

Introduction 11

Figure @@@@1.3: Sensor node Mica mote (evolved out at the University of California

at Berkeley)

1.1.4 WSN Protocols

Although the sensor nodes communicate through the wireless

medium, protocols and algorithms proposed for traditional wireless

ad hoc networks may not be well suited for sensor networks. As

previously explained, sensor networks are application specific, and

the sensor nodes work collaboratively together. In addition, the

sensor nodes are energy constrained compared to traditional

wireless ad hoc devices. Thus, the differences between sensor

networks and ad hoc networks should be studied to give a general

idea how the WSN protocols will be. The differences between both

networks @[4] can be summarized in the following main points:

• The number of sensor nodes in a sensor network can be

several orders of magnitude higher than the nodes in an ad

hoc network.

• Sensor nodes are densely deployed.

• Sensor nodes are prone to failures.

• The topology of a sensor network changes very frequently

due to failure and duty cycles of nodes.

Introduction 12

• Sensor nodes mainly use a broadcast communication

paradigm whereas most ad hoc networks are based on

point-to-point communications.

• Sensor nodes are limited in power, computational

capacities, and memory.

• Sensor nodes may not have global identification (ID)

because of the large amount of overhead and large number

of sensor nodes.

• Sensor networks are deployed with a specific sensing

application in mind; ad hoc networks are mostly

constructed for communication purposes.

With these differences, the design of communication

protocols for sensor networks requires specific attention @[4]. The

protocol stack used by sensor nodes is given in Figure @1.4. This

protocol stack combines power and routing awareness, integrates

data with networking protocols, communicates power-efficiently

through the wireless medium, and promotes cooperative efforts of

sensor nodes. The protocol stack consists of the application layer,

Po

we

r Ma

na

ge

me

nt

Mo

bility

Ma

na

ge

me

nt

Ta

sk M

an

ag

em

en

t

Application Layer

Transport Layer

Network Layer

Data Link Layer

Physical Layer

Figure @@@@1.4: The sensor network protocol stack

Introduction 13

transport layer, network layer, data link layer, physical layer, power

management plane, mobility management plane, and task

management plane @[7].

Depending on the sensing tasks, different types of

application software can be built and used on the application layer.

Sensor nodes can be used for continuous sensing, event detection,

event identification and location sensing. The concept of

microsensing and wireless connection of these nodes promise many

new application areas. This results in a wide range of application

layer protocols.

The transport layer helps to maintain the flow of data if the

sensor networks application requires it. In general, the main

objectives of the transport layer are (1) to bridge application and

network layers by application multiplexing and demultiplexing; (2)

to provide data delivery service between the source and the sink

with an error control mechanism; and (3) to regulate the amount of

traffic injected into the network via flow and congestion control

mechanisms. Nevertheless, the required transport layer

functionalities to achieve these objectives in the sensor networks

are subject to significant modifications in order to accommodate

unique characteristics of the sensor network paradigm. For

example, conventional end-to-end, retransmission-based error

control mechanisms adopted by transport control protocol (TCP)

may not be feasible for the sensor network domain and thus may

lead to waste of scarce resources. On the other hand, the specific

objective of the sensor network also influences the design

requirements of the transport layer protocols. For example, the

Introduction 14

sensor networks deployed for different applications may require

different reliability levels as well as different congestion control

approaches. Consequently, development of transport layer

protocols is a challenge because the limitations of the sensor nodes

and the specific application requirements primarily determine

design principles of transport layer protocols @[2].

The network layer takes care of routing the data supplied by

the transport layer. Sensor nodes may be scattered densely in an

area to observe a phenomenon. As a result, they may be very close

to each other. In such a scenario, multi-hop communication may be

a good choice for sensor networks with strict requirements on

power consumption and transmission power levels. As the sensor

nodes consume much less energy when transmitting a message

because the distances between sensor nodes are shorter. As

mentioned previously, ad hoc routing techniques already proposed

in the literature do not usually fit requirements of the sensor

networks. As a result, the network layer of the sensor networks is

usually designed according to the following principles:

• Energy efficiency is always an important consideration.

• Sensor networks are mostly data centric.

• An ideal sensor network has attribute-based addressing and

location awareness.

• Data aggregation is useful only when it does not hinder the

collaborative effort of the sensor nodes.

• The routing protocol is easily integrated with other

networks, e.g., Internet.

Introduction 15

These design principles serve as a guideline when designing

a routing protocol for sensor networks. First, the routing protocol

must be energy efficient because the network lifetime depends on

the nodes’ energy consumption when relaying messages. As a

result, energy efficiency plays an important role in various protocol

stack layers in addition to the network layer. Second, information

or data in sensor networks may be described by using attributes. In

order to integrate tightly with the information or data, a routing

protocol may be designed according to data-centric techniques. A

data-centric routing protocol requires attribute-based naming

which is used to carry out queries by using the attributes of the

phenomenon. In essence, the users are more interested in the data

gathered by the sensor networks in the phenomenon rather than by

an individual node. They query the sensor networks by using

attributes of the phenomenon that they want to observe. For

example, the users may send out a query such as, “find the locations

of areas where the temperature is over 70F.” Third, a data-centric

routing protocol should also utilize the design principle of data

aggregation – a technique used to solve the implosion and overlap

problems in data-centric routing. As shown in the example in

section @1.1.1, the sink queries the sensor network to observe the

ambient condition of the phenomenon. The sensor network used to

gather the information can be perceived as a reverse multicast tree,

where the nodes within the area of the phenomenon send the

collected data toward the sink. Data coming from multiple sensor

nodes are aggregated as if they are about the same attribute of the

phenomenon when they reach the same routing node on the way

back to the sink. Also, care must be taken when aggregating data

because the specifics of the data, e.g., the locations of reporting

Introduction 16

sensor nodes, should not be left out. Such specifics may be needed

by certain applications @[2].

One of the design principles for the network layer is to

allow easy integration with other networks such as the satellite

network and the Internet. As shown in Figure @1.5, the sinks are the

basis of a communication backbone that serves as a gateway to

other networks. The users may query the sensor networks through

the Internet or the satellite network, depending on the purpose of

the query or the type of application the users are running. This

point is discussed next section in detail.

Figure @@@@1.5: Internetworking between sensor nodes and user through Internet

or satellite network.

In general, the data link layer is primarily responsible for

multiplexing data streams, data frame detection, medium access,

and error control; it ensures reliable point-to-point and point-to-

Introduction 17

multipoint connections in a communication network. Nevertheless,

the collaborative and application-oriented nature of the sensor

networks and the physical constraints of the sensor nodes, such as

energy and processing limitations, determine the way in which

these responsibilities are fulfilled @[2].

The physical layer is mostly concerned with modulation and

demodulation of digital data; this task is carried out by transceivers.

In sensor networks, the challenge is to find modulation schemes

and transceiver architectures that are simple, low cost, but still

robust enough to provide the desired service.

In addition to protocol layers, the power, mobility, and task

management planes monitor the power, movement, and task

distribution among the sensor nodes. These planes help the sensor

nodes coordinate the sensing task and lower the overall power

consumption. The power management plane manages how a sensor

node uses its power. For example, the sensor node may turn off its

receiver after receiving a message from one of its neighbors. This is

to avoid getting duplicated messages. Also, when the power level of

the sensor node is low, the sensor node broadcasts to its neighbors

that it is low in power and cannot participate in routing messages.

The remaining power is reserved for sensing. The mobility

management plane detects and registers the movement of sensor

nodes, so a route back to the user is always maintained, and the

sensor nodes can keep track of who are their neighbor sensor

nodes. By knowing who the neighbor sensor nodes are, the sensor

nodes can balance their power and task usage. The task

management plane balances and schedules the sensing tasks given

Introduction 18

to a specific region. Not all sensor nodes in that region are required

to perform the sensing task at the same time. As a result, some

sensor nodes perform the task more than the others depending on

their power level. These management planes are needed, so that

sensor nodes can work together in a power efficient way, route data

in a mobile sensor network, and share resources between sensor

nodes. Without them, each sensor node will just work individually.

From the whole sensor network standpoint, it is more efficient if

sensor nodes can collaborate with each other, so the lifetime of the

sensor networks can be prolonged @[7].

1.2 WSN and IP network Integration

For practical deployment, a sensor network does not work in

isolation. For many important applications, however, it is required

to integrate these sensor networks to the existing Internet Protocol

(IP) networks. An in-depth study of applying wireless sensor

networks in a real-world habitat monitoring application is

presented in @[23].

In this project, Berkeley sensor nodes (which known as

motes) were deployed in the Great Duck Island, off the coast of

Maine, to monitor the microclimates in and around nesting burrows

Internet

Gateway

Remote User

Figure @@@@1.6: Wireless sensor network connected with Internet through a gateway

Introduction 19

used by the Leach’s Storm Petrel bird. The nodes would periodically

sample and relay their sensor readings to a gateway connected to

the Internet through a satellite link, allowing researchers around

the world to access real-time environmental data, see Figure @1.6.

Table @@@@1.1: Key differences between traditional IP-based networks and

wireless sensor networks

Traditional IP-Based

Networks Wireless Sensor

Networks

Networking Mode

Application-independent

Application-specific

Routing Paradigms

Address-centric Data-centric, Location-centric

Typical Data Flow

Arbitrary, One to one To/from querying sink, One-to-many and many-to-one

Data Rates High (Mbps) Low (kbps)

Resource constraints

Bandwidth

Energy (battery-operated nodes), Limited processing and memory

Network Lifetime

Long (years-decades) Short (days-months)

Operation Attended, administered

Unattended, Self-configuring

The task of connecting WSN to the existing Internet brings with it

several challenges @[19]. Any network wishing to be connected to

the Internet needs to address the question of how it will interface

with the standard protocols like the IP. The characteristics of WSN

make them different from traditional IP-based networks as

summarized in Table @1.1. The chief among these are that WSN are

large-scale unattended systems consisting of resource-constrained

nodes that are best-suited to application-specific, data-centric

Introduction 20

routing. Such characteristics form a set of challenges on the

interconnection approaches as explained next:

• Limited capabilities of WSN nodes. Sensor nodes have

limited capabilities in processing, memory, storage, and

most importantly in power supply. As opposed to TCP/IP,

energy consumption is an important metric in WSN

protocols.

• Possibility of absence of global unique IDs. Sensor nodes

do not usually have predefined global unique IDs/addresses

as in IP networks. For example, the Directed Diffusion

protocol @[24] performs data-centric querying and routing

without the use of globally unique IP-like addresses.

• Different routing protocols in both networks. WSN

essentially uses specific routing protocols that are suitable

for its nature and are different from the Internet protocol.

Therefore, WSN routing protocols use addressing schemes

that are not IP-compliant.

• Data centric routing rather than address-centric. It is

common in WSN to issue a query to many “unknown” nodes

by using named data. In contrast, the majority of TCP/IP

transactions assume prior knowledge of location of data

and hence the destination address.

• Data flow pattern. The most common data flow in TCP/IP

networks is one-to-one addressable flow. In WSN, other

data flow patterns are very common. For example, a user

can issue a query by broadcasting it from sink to some or all

sensor nodes (i.e. one-to-many). However, retrieving query

results takes a different pattern. This is due to many sensor

Introduction 21

nodes have the queried information and so send the

required results to the sink in many-to-one flow pattern.

There are several integration approaches. Each approach

tries to consider these challenges and overcome them to achieve

the best compromise among the WSN constraints and the

standardization of TCP/IP protocols. Next, these approaches are

quickly reviewed and discussed in detail later in the next chapter.

As shown above, sensor networks are often intended to run

specialized communication protocols, thereby making it impossible

to directly connect the sensor network with a TCP/IP network. The

most commonly suggested way to get the sensor network to

communicate with a TCP/IP network is to deploy a gateway

between the sensor network and the TCP/IP network @[8]. The

gateway is able to communicate with both the sensors in the sensor

network and hosts on the TCP/IP network. Therefore, it is able to

either relay the information gathered by the sensors to internet

hosts and in this case it acts as application-level gateway or to act as

a front-end for the sensor network (i.e. front-end proxy). In the

later case, internet hosts can query this proxy for the collected data

using common query language.

Virtual IP (VIP) Bridge approach @[18] is a similar approach

for application-level gateway but it uses a lower-level gateway

(bridge) for interconnection. It virtually assigns IPv6 addresses to

sensor nodes. However, the IP addresses are not physically

deployed on the sensor nodes but they are mapped from/to node

ID/location in the bridge. The bridge translates packets from one

Introduction 22

network to the other and maps addresses according to mapping

tables. It allows also integrating multiple sensor networks into a

single virtual WSN through TCP/IP network rather than connecting

the sensor network to IP network only.

On the other hand, a different approach is adopted to

interconnect both networks. It is the network overlay approach.

There are two kinds of overlay-based approaches: sensor networks

overlay TCP/IP and TCP/IP overlay sensor networks @[16]. The first

approach constructs an overlay WSN over the Internet as proposed

in @[16] and @[17]. This approach extends the data-centric routing

protocol in WSNs into the Internet via overlay networking in the

application layer. When the packets originated from WSNs arrive at

the gateway, they are encapsulated within typical TCP/IP packets

and then delivered to a specific destination IP host. As the WSN

protocol is deployed in this host, the TCP/IP packet is passed up to

this stack after it reaches the application layer in TCP/IP stack.

The TCP/IP overlay sensor networks approach runs the

TCP/IP protocol suite in the sensor network directly. In this case, it

would be possible to connect the sensor network and the TCP/IP

network without requiring proxies or gateways. In a TCP/IP sensor

network, sensor data could be sent using the best-effort transport

protocol UDP, and the reliable byte-stream transport protocol TCP

would be used for administrative tasks such as sensor configuration

and binary code downloads @[8]. Due to the power and memory

restrictions of the small 8-bit micro-controllers in the sensor nodes,

it is often assumed that TCP/IP is not possible to run in sensor

Introduction 23

networks. However, there are many trials that successfully

deployed the TCP/IP protocol stack on 8-bit micro-sensor nodes

such as in @[11] and @[13].

Finally, Delay Tolerant Networking (DTN) @[10] is a

communication model for environments where the communication

is characterized by long or unpredictable delays and potentially

high bit-error rates. Examples include mobile networks for

inaccessible environments, satellite communication, and certain

forms of sensor networks. DTN creates an overlay layer on top of

the Internet and uses late address binding in order to achieve

independence of the underlying bearer protocols and addressing

schemes. TCP/IP and sensor network interconnection could be

done using a DTN overlay on top of the two networks @[8]. Although

DTN proposes a whole communication model, it is considered to be

a hybrid approach from gateway-based and network overlay

approaches. This is because it deploys an intermediate layer in

protocol stacks of both networks and also utilizes one or more

gateway node to interconnect between them @[16].

1.3 Motivation

Many applications of WSN need to interconnect with organizational

networks and cannot operate in complete isolation. Also, sensor

data is required to be accessible remotely without the need for in-

field sink whether static or mobile. As TCP/IP is the most common

protocol suite for Internet as well as most local area networks, the

interconnection between WSN and IP networks is a crucial topic to

achieve the following:

Introduction 24

• Monitor and control sensor networks remotely.

• Integrate data collected from sensor networks into the

current data repositories.

• Interconnect multiple remotely-located sensor networks

into a single virtual sensor network.

1.4 Objectives

The objective of this thesis is to develop a technique for integrating

WSN and IP network that is applicable with common WSN

protocols to achieve flexible deployment. Also it should support

different communication paradigms such as data centric paradigm.

In addition, it should be consistent with Next Generation Network

(NGN) to support pervasive computing. This objective will be

achieved after surveying and studying current approaches for

integrating WSN and IP networks. Also, the developed technique

will be evaluated to ensure its applicability and measure its

performance.

1.5 Thesis Outline

The rest of the thesis is organized as follows. The second chapter

gives the basic concepts and background for integrating WSN with

IP networks. It gives a detailed survey for the current approaches

and methods for integration. Also, it discusses the advantages and

disadvantages of each approach as a comparison among them.

The third chapter introduces a proposed gateway-based

integration technique. It shows the detailed operations and

scenarios for both address-centric and data-centric WSNs. It then

presents the gateway architecture and its components in each case.

Introduction 25

Finally, it compares the proposed technique with the other

integration approaches.

The fourth chapter provides the implementation details of

the proposed technique. It first surveys possible simulators to

implement this technique and why the OMNeT++ simulator is

selected. Then, it gives details of simulation environment and its

modules. The fifth chapter explains the experiments used to test

the proposed technique and results extracted from them.

@

The sixth chapter summarizes the conclusions of the

conducted research and presents directions for future work. In the

simulator appendix, details for installing OMNeT++ simulator and

its extensions are presented. It gives also a simple example for how

to use it.

In summary, this chapter is an introductory for the thesis. First, an

overview is given for wireless sensor network (WSN) and its

applications. Also, the architecture of sensor nodes is given

combined with its protocol stack. Then, the integration between

WSN and IP network is introduced with a brief overview for

different known approaches. Finally, the motivation, objectives and

outline of this thesis are presented.

IP-WSN Integration Techniques

2

As shown in chapter 1,

sensor networks cannot operate

be a way for a monitoring entity to gain

by the sensor network. By connecting the sensor network to an

existing

area network, or a private

network can be achieved. Gi

become the de

Internet but also for local

to look at methods

networks.

gateway

approach

@2.1.

Application

WSN Integration Techniques






existing network infrastructure such as the global Internet, a local



become the de

Internet but also for local

to look at methods

networks.

Fi

There are

gateway-based

approach uses overlay layer and gateways

. There are many techniques in each approach

Gatewaybased

Application-level

Gateway







network infrastructure such as the global Internet, a local



become the de-facto networking standard, not only for the global

Internet but also for local-

to look at methods for interconnecting sensor networks and TCP/IP

Figure @@@@2.1: Integration approaches taxonomy

There are two main approaches for interconnection:

and network overlay

uses overlay layer and gateways

here are many techniques in each approach

Gateway-based

Virtual IP Bridge



As shown in chapter 1, for most sensor network applications,

sensor networks cannot operate in complete isolation; there must




intranet, the

network can be achieved. Given that the TCP/IP

facto networking standard, not only for the global

-area networks, it is of particular interest

for interconnecting sensor networks and TCP/IP

: Integration approaches taxonomy

main approaches for interconnection:

network overlay

uses overlay layer and gateways


Integration Approaches

Virtual IP WSN

overlay TCP/IP


ost sensor network applications,

in complete isolation; there must

be a way for a monitoring entity to gain access to the



the remote access to the sensor

ven that the TCP/IP


area networks, it is of particular interest




network overlay-based; along with a

uses overlay layer and gateways as illustrated in


Integration Approaches

Network Overlay-

based

WSN overlay TCP/IP

overlay




access to the data produced



remote access to the sensor

protocol suite has






along with a

as illustrated in

here are many techniques in each approach which differ in

TCP/IP overlay

WSN

27



data produced


network infrastructure such as the global Internet, a local-

remote access to the sensor

protocol suite has





hybrid

as illustrated in Figure

which differ in

Hybird

Delay Tolerant Network

IP-WSN Integration Techniques 28

their operations. In the gateway-based approach, there are

application-level gateway and Virtual IP (VIP) Bridge techniques.

For the network overlay approach, there are WSN overlay TCP/IP

and TCP/IP overlay WSN. Finally, Delay Tolerant Network (DTN) is

a hybrid technique as it embeds (overlays) a bundle layer within

the protocol stack of each node and uses gateway(s) to interconnect

networks together.

In this chapter, the different techniques are presented. In

section @2.1, the application level gateway technique is discussed. In

section @2.2, the VIP Bridge approach is shown. The overlay

approach is discussed in sections @2.3 and @2.4. In section @2.5, the

DTN concept and architecture is discussed. Finally, a discussion and

comparison among different approaches is explained in section @2.6.

2.1 Application Level Gateway

A gateway is a network node equipped with interfaces compatible

with both networks IP network and WSN to exchange data between

them as illustrated in Figure @2.2 and Figure @2.3. In application level

gateway approach, a gateway node is used to interconnect between

both networks. The gateway can operate in either of two ways: as a

front-end proxy or as a relay. In front-end proxy case, the data

collected from sensor nodes is stored in it (i.e. act as a proxy

server). Then, IP hosts can query this data using SQL or web

services. In the second case, the gateway simply relays data comes

from sensor nodes to specific IP hosts. IP clients should register for

data interest to receive packets about it @[8]. There are several


techniques that use the gateway for interconnection. We show next

some of these techniques.

integrate sensor networks with Internet.

applicable in homogenous

capabilities).

information continuously, the gateway acts as a web server and the

collected data can be displayed in dynamic web pages.




Authors in



capabilities). In si



Figure




Figure @@@@2.2:

Authors in @[19] propose



In simple sensor networks where nodes are providing



Figure @@@@2.3: Communication



: Application-

propose an application


applicable in homogenous networks

mple sensor networks where nodes are providing



Communication Architecture using a gateway


-level Gateway

an application

integrate sensor networks with Internet. The proposed

networks (i.e. all nodes have the same




Architecture using a gateway


level Gateway

an application-level gateway

roposed technique

des have the same




Architecture using a gateway

29


level gateway to

technique is

des have the same




In more sophisticated networks, the gateway acts as an

interface to a distributed database where users can issue queries to

the sensor network. In heterogeneous WSN, they recommend to use

an overlay IP network instead.

Another framework uses gateways is proposed in @[20]. In

this framework, each WSN is identified by an IP address (the

gateway IP) as shown in Figure @2.4. Sensor nodes are identified by

node ID and endpoint ID (endpoint ID identifies the application

within a node). IP hosts can access a sensor node through the IP

address of WSN and a specific port number assigned to it at the

gateway. Sensor nodes can access IP host whether by an endpoint

ID within the gateway node (if there are a limited number of

accessible IP nodes) or through a node ID and an endpoint ID

assigned to that IP host at the gateway.

Packets from each side are reformed when reach the

gateway to the destination network as shown in Figure @2.5. When

the gateway receives an UDP message from IP network, it creates a

packet confirming to the protocol used in that WSN. The UDP

payload maps to the payload of this new packet and its header is

Figure @@@@2.4: A WSN identified by a single IP address

WSN IP Address: xx.xx.xx.xx

IP Network

Gateway

Gateway

IP Address +

Port Number

Node ID +

Endpoint ID


constructed using mapped WSN addresses. Similarly, when gateway

receives a packet from WSN destined to an IP destination, it creates

a UDP packet. The packet payload maps to the UDP payload. UDP

and IP header is constructed using mapped IP addresses and port

numbers too. By these operations, the gateway works in a lower

level rather than application level.

IP Header UDP Header Payload

WSN Header Payload

Figure @@@@2.5: Packet mapping in single IP framework

There are a set of assumptions to allow applying this

framework. First, WSN must have one or more gateway nodes. Also,

UDP is used in IP network at transport layer. In addition, the

maximum payload less than or equal to the smallest maximum

payload supported by UPD and protocol used in WSN.

2.2 Virtual IP (VIP) Bridge

Virtual IP (VIP) Bridge @[18] is a modified gateway-based technique

that interconnects WSN with Internet using a low-level bridge

(rather than application level gateway). Based on node or location

centric communication paradigm, the label or location of node is

mapped to an IP address virtually assigned in the bridge. The IP

address will not be physically deployed on the sensor node, but just

stored in the bridge as a virtual IP address for Internet hosts use.

Packets that come from one side will be translated into the


corresponding packet format of the other side and sent by the

bridge. Moreover, using such virtual IP addresses, different sensor

networks can be integrated into one virtual sensor networks.

In the VIP Bridge, there are two major components to

translate packets for both sides as shown in Figure @2.6:

• TCP/IP Network to Sensor Networks (T->S) Packet

Translation, translating packets from TCP/IP network into

the packet format of sensor networks;

• Sensor Networks -> TCP/IP Network (S->T) Packet

Translation, translating packets from sensor networks into

the packet format of TCP/IP network.

The symbol T->S Packet represents a packet comes from TCP/IP

network. The S->T Packet represents a packet that comes from

sensor networks.

The packet format of original T->S Packet has four major fields:

1. User IP, used to represent the IP address of user’s who

sends this packet;

2. Sensor IP/Bridge IP, used to represent the destination of

this packet, which can be the bridge IP address or some

special sensor node’s IP address;

3. Q/O, used to represent packet type: Query Command or

Operation Command;

4. Complicated/Simple Data Request / Operation

Command, used to represent the real content that is carried

by this packet.


Figure @@@@2.6: The VIP Bridge packet format and translation operations

While the packet format of created T->S Packet has the following

four major fields:

1. Bridge ID/Location, used to represent the ID or location

address of Bridge, which sends the packet to sensor

networks;

2. Sensor ID/Location, used to represent the ID or location of

data source;

3. Q/O, used to represent packet type: Query Command or

Operation Command;

4. Complicated/Simple Data Request / Operation

Command, used to represent the real content that is carried

by this packet.

The Query Command is used to request data from sensor networks,

it can be as simple as query data just from one special sensor node,


or it can be as complicated as query data from many sensor nodes

at the same time. Operation Command is used to remote control

one special sensor node’s working status.

Similarly, the packet format of S->T Packet also has four major

fields:

1. Sensor ID/Location, used to represent the ID or location of

data source;

2. Bridge ID/Location, used to represent the ID or location

address of Bridge, which is the destination of this packet;

3. D/A, used to represent packet type: Data Packet or

Acknowledgement Packet;

4. Data/Acknowledgement, used to represent real content

carried by this packet.

The packet format of created S- >T Packet has the following four

major fields:

1. Bridge IP, used to represent the IP address of Bridge, which

sends the packet to TCP/IP network;

2. User IP, used to represent the IP address of receiver’s;

3. D/A, used to represent packet type: Data Packet or

Acknowledgement Packet;

4. Data/Acknowledgement, used to represent real content

carried by this packet.

The Data Packet corresponds to the Query Command, and the

Acknowledgement Packet corresponds to the Operation Command.

A Node ID/Location Address is the node ID or location address of a

sensor node. A Data Information is a description about what kind of

data can be provide by this sensor node. An IPv6 Address is the

assigned IP address for this special sensor node. VIP Bridge will


actively collect Node ID/Location Address, Data Information for all

sensor nodes, and also actively assign IPv6 Address for these sensor

nodes. All these information are stored in a database which

physically located in the VIP Bridge. Furthermore, bridge will map

these three different kinds of information with each other.

The translation of TCP/IP packet to sensor network packet

is as follows. After receiving packets from TCP/IP network, there

are two ways to translate them into the packet format that used by

sensor networks: Data Information Based Discovery or IPv6 Address

Based Discovery. The bridge will analyze these received packets

based on the field “Q/O” to categorize them into Query Command

and Operation Command. If a packet is an Operation Command, then

bridge can base on the Sensor IP to search the database to find out

the corresponding Node ID/Location Address of this sensor node

through the mapping between IPv6 Address and Node ID/Location

Address. If a packet is a Query Command, then bridge can base on

Complicated/Simple Data Request to search the database to find out

the corresponding Node ID/Location Address of this sensor node

through the mapping between Data Information and Node

ID/Location Address. After knowing Node ID/Location Address of

this sensor node, the new packet can be created for sensor

networks. Before sending new created packet to sensor networks,

this new T->S packet is backed up, and mapped with the original T-

>S packet in bridge. These saved packets will be used when

translating packets that come from sensor networks into the packet

format of TCP/IP network.


The translation of sensor packet to TCP/IP network packet

is as follows. After receiving the S->T Packet from sensor networks,

the bridge first bases on packet’s Sensor ID/Location to find out the

created T->S Packet, then through the mapping between the created

T->S Packet and the original T->S Packet, bridge can find out the

original T->S Packet. By analyzing the original T->S Packet, bridge

can get the User IP, and then create the new S->T Packet. Before

sending this new S->T Packet, bridge will delete the corresponding

original and created T->S Packets to save the storage space of the

database.

2.3 WSN Overlays TCP/IP network

This approach constructs an overlay WSN over the Internet.

Authors in @[17] proposed such approach to unify sensor networks

with the Internet. It decouples the relationship between the API-

enforced database view and the gateway, making the gateway more

general by introducing application-level overlay networking into

the gateway. The gateway here is meant by the node that has an

interface connected to each network. In this approach, sensor

network packets, rather than being stopped at the gateway, are

instead encapsulated into IP packets, and then directed from the

gateway to any number of interested applications and services

residing remotely on the Internet. The basic encapsulation

procedure forms an application overlay of the sensor network over

the Internet. Instead of being restricted by a database API, all

applications will have direct access to a networking API that allows

them to query and interact with the sensor network directly via a

largely transparent gateway. Applications that still desire a

database view of the WSN can still query the WSN through a


database API. Thus, this approach of transforming the gateway into

primarily an application-level packet relay encouraging

proliferation of new applications and services.

This architecture reconciles address-less and address-based

routing by extending address-less sensor network routing into the

Internet as an application overlay. As sensor network packets reach

the border with the Internet world, these packets will be

encapsulated within TCP/IP (or UDP/IP) packets and will then be

sent as an application layer packet over the Internet to the

appropriate application end point on a remote IP host. Effectively,

each layer on the sensor network protocol stack (application,

transport and network) sits above or overlays the Internet protocol

stack. The gateway only needs to understand the “lowest” level, e.g.

network layer, of the sensor network as well as how to handle the

differences between IP and WSN routing.

The major components include the virtual nodes running

over the Internet and the overlay gateway. The sensor overlay

permits a rich and versatile environment for the interconnection of

virtual nodes, which collectively form a virtual sensor network.

A virtual node is defined as any entity that communicates

with peer entities on a real sensor network through a common set

of protocols, network layer and above. Virtual nodes route packets

the same way that physical sensor nodes route packets. Each virtual

node therefore functions at least as an application level router of

sensor network packets over the Internet. They also interpret

transport layer packets in the same manner that physical sensor


nodes interpret them. This is all possible because the entity that

interconnects the two worlds, namely the overlay gateway,

preserves sensor network layer headers and payloads destined for

the Internet, encapsulating the entire sensor network packet within

a TCP/UDP/IP packet. Figure @2.7 shows the specific operation of an

overlay gateway.

Figure @@@@2.7: WSN Overlay TCP/IP network

Packets that arrive at the overlay gateway from the sensor

network will have MAC(M), network(N), transport(T), and

application(A) layer headers specific to the sensor network. The

overlay gateway will then propagate the packet’s network layer and

above headers (N,T,A) and application payload to the Internet,

encapsulating them within TCP/UDP/IP packets. The overlay

gateway effectively translates the sensor network’s protocol stack,

formerly layer 3 and above, to the application layer and above on

the Internet. Virtual nodes therefore form a virtual sensor network


that operates as an application-level overlay of the Internet. The

overlay gateway itself is also a virtual node that participates in

sensor network routing decisions. Unlike application-level

gateways that require semantic knowledge of each application in

order to make a routing decision, the overlay gateway routes based

on sensor network layer information. It is expected that the number

of sensor network layer protocols will be far smaller than the

number of applications and application layer protocols and will not

change rapidly. The overlay gateway is tasked with executing this

small, relatively well-known and stable set of sensor network layer

protocols. Meanwhile, the number of applications can proliferate

freely above the network layer, without the overlay gateway posing

a bottleneck to innovation. As defined by the application-level

overlay, the user-level network stack, and the common sensor

networking API, the virtual sensor network is quite general. Virtual

nodes can run on any distributed combination of IP hosts. Thus,

applications that are far from the physical deployment can directly

interact with an in-situ sensor network remotely. Multiple virtual

nodes can run on the same IP host.

Authors in @[16] proposed an architecture called Extensible

Interworking Architecture (EIA) which utilizes the WSN overlay

TCP/IP technique. The EIA architecture specifies WSN and an

overlay sensor network (OSN). The OSN emulates a WSN over

Internet. There are two types of nodes in OSNs: overlay gateway

node (OGN) and virtual sensor node (VSN). EIA is designed for

WSNs deployed in a large-scale area, so that multiple OGNs and

VSNs are assumed. The OGN provides an interface between WSNs

and OSNs, while the VSN deals with routing query and response


messages. The VSN implements protocols for WSNs over TCP/IP

protocol stack. On the other hand, the OGN has a dual protocol stack

for interworking between WSNs and OSNs. All of these nodes are

designed based on the concept of open system architecture.

Therefore, a new WSN application can easily be added without any

changes in OGNs and VSNs.

The EIA defines three layers: EIA Query Layer (EQL), EIA

Management Layer (EML), and EIA Tunneling Layer (ETL). Figure

@2.8 shows the EIA protocol stack supporting directed diffusion and

Zigbee, which are representative sensor network protocols. When a

new WSN application needs to be supported, EIA can be easily

extended by defining interfaces between three layers. The main

functions of three layers are as follows.

• EQL: To support a variety of WSNs and applications, EIA

provides a common query processing layer, which is

defined as similar to SQL.

• EML: In EIA, a user initiates its query through the EIA user

interface (i.e., Web interface). The query is transformed into

a specific target query message (e.g., Zigbee, directed

diffusion), and the target query message is delivered to

neighbor VSNs or OGNs. The EML handles these procedures

between EQL and ETL.

• ETL: EIA supports a distributed caching algorithm, so that

an additional header is added for distributed caching at the

ETL. Also, query routing is performed at the ETL.


Figure @@@@2.8: EIA Protocol stack

The goal of data gathering system is to collect some

interesting information from physical worlds. To this end, data

centric routing protocols such as directed diffusion are widely

accepted in WSNs. To support data centric routing in OSNs, each

VSN constructs an ALG. For WSNs, the data dissemination graph is

constructed when the query is propagated or an event of interest

occurs. Namely, the reactive method is widely used because of

dynamics in wireless networks. On the contrary, since OSNs are

built over the wired Internet, dynamics are not serious constraints.

Therefore, the proactive ALG construction gives more advantages in

terms of OSN maintenance overhead. In addition, the ALG should be

scalable and self-organizable. Since EIA can be deployed in an

incremental manner, the ALG should be re-organized with minimal

overhead when a new VSN is added or removed. To meet these

requirements, P2P overlay networking can be utilized.


2.4 TCP/IP network Overlay

Because of the success of the Internet, the TCP/IP protocols have

become the de-facto standard protocol stack for large scale

networking. Conventional wisdom states that TCP/IP is inherently

unsuitable for communication within wireless sensor networks,

because of the extreme communication conditions in sensor

networks @[8]. For example, authors in @[19] argue that the

implementation of the full IP stack on sensor networks may not be

feasible due to the limited computational and memory resources of

sensor nodes. Sensor networks are, in many ways, different from

traditional IP-based networks. For these reasons, all-IP large-scale

sensor networks are neither desirable nor feasible. However, they

still recommend using the overlay IP network on heterogeneous

WSN, where a set of capable nodes act as cluster-heads. These

nodes may be IP addressable and can be connected together. To

establish such connection, a tunneling mechanism is needed as

these nodes may not be adjacent to each other.

In spite of this criticism, there are many researches study

the applicability of TCP/IP protocol stack in sensor networks. The

main advantage of using TCP/IP in WSN is the direct

interoperability with Internet nodes without protocol converters or

proxies, see Figure @2.9. Researchers in this area try to find a light-

weight TCP/IP implementation that is suitable for limited

capabilities of sensor nodes. Also it should not be tailored for a

specific application (like HTTP) to provide generality in

communication with other TCP/IP implementations @[14].


Figure @@@@2.9: Using TCP/IP within and outside sensor networks

Authors in @[8], @[9] and @[13] presented the groundwork for

exploring the use of TCP/IP for wireless sensor networks. They first

proposed in @[13] a compatible interoperable tiny TCP/IP

implementation –called µIP- that is suitable for constrained

embedded systems such as sensor nodes. In @[8], the main problems

in using TCP/IP protocol stack with sensor networks are stated as

follows:

• IP addressing architecture: IP addresses are whether

automatically assigned by DHCP, for example, or they are

manually configured. Both alternatives are not suitable for

sensor networks due to expensive communication and

inapplicability in large scale networks respectively.

• Header Overhead: TCP/IP packet header is very large

relative to the amount of data sent by sensor nodes

• Address Centric Routing: rather than data centric routing

preferably used in sensor networks

• Limited nodes capabilities while TCP/IP is often assumed

to be heavy-weight protocol suite.


• TCP performance and energy inefficiency. TCP has

serious performance problems in sensor networks due to

end-to-end acknowledgement and retransmission scheme

which requires retransmissions along every hop.

Although of these problems, it is possible to achieve a

reasonable performance in energy efficiency and data throughput

by applying some optimization mechanisms. Authors of [8] propose

solutions for such problems as discussed next:

• IP addressing can be assigned by spatial IP address

assignment mechanism. In this mechanism, each sensor

node uses its spatial location to construct an IP address

(assuming that nodes are aware of their spatial location

which is common in WSN applications). However, assigned

IP addresses may not be unique as multiple adjacent nodes

can obtain the same location coordinates and so the same IP

address.

• Header Overhead can be reduced by header compression

techniques.

• Data Centric Routing can be supported by application

overlay network. In general, overlay networks are

constructed in order to permit routing messages to

destinations not specified by an IP address. Authors believe

that UDP datagrams sent using link local IP broadcast is a

suitable mechanism for implementing an application

overlay network on top of the physical sensor network

structure

• Limited nodes capabilities while TCP/IP is often assumed

to be heavy-weight protocol suite. Authors could implement


configurable (modular) TCP/IP stack for sensor networks. Also,

they proposed a reduced version from Session Initiation Protocol

(SIP) to be able to w


a light weight TCP/IP protocol stack (

sensor nodes.

• TCP performance and energy inefficiency

scheme called distributed TCP caching (DTC) that uses

segment caching and local retransmissions to reduce energy

consumption required by TCP. In DTC, each node caches

small number of TCP segments

If a negative ACK is received by a node and it caches a

packet to be retransmitted, it retransmits this cached packet

locally with no need to return the ACK message to the

sender to retransmit the lost packet. (However, they assu

symmetric and relatively stable routes which it is not a

common case in sensor networks)

Figure

In @[15]



(SIP) to be able to w



nodes.

TCP performance and energy inefficiency











Figure @@@@2.10: Architecture of tiny TCP/IP protocol stack

[15], authors proposed a



(SIP) to be able to work on the proposed TCP/IP Stack and support














Architecture of tiny TCP/IP protocol stack

authors proposed a



ork on the proposed TCP/IP Stack and support






small number of TCP segments and monitor ACK messages.








authors proposed another technique for a




a light weight TCP/IP protocol stack (µIP) suitable for

TCP performance and energy inefficiency is dealt by a




and monitor ACK messages.







nother technique for a




45

IP) suitable for

is dealt by a




and monitor ACK messages.




sender to retransmit the lost packet. (However, they assume



nother technique for a





mobility and flexible naming for sensor nodes as shown in Figure

@2.10. They worked to reduce protocol modules in each layer to be

suitable with nodes functionalities and capabilities. They show that

its implementation requires few hundred of bytes of memory. They

also used spatial IP address assignment mechanism as in @[8].

The adopted reduction process of IP is some of IP options

are eliminated from the IP header and made a limitation on

fragmentation reassembly process on sink nodes only. For the

reduction process of TCP, they removed unnecessary states such as

CLOSED and SYN_SENT. Also, they used header compression

mechanisms. On the other hand, they kept the simple mechanism

such as congestion control and flow control to guarantee the

statbility of transmission. On the application layer, they studied

HTTP, SNMP and TFTP. In HTTP reduction, they used the simple

request type; “GET” method only. Concerning the SIP

implementation, it runs over UDP and the sink node works as the

proxy server. Therefore, mobile node can be queried and controlled

using the newest registration information using SIP. The advantage

of this approach is its support for node mobility with reasonable

performance in energy efficiency.

On the other hand, 6LoWPAN (IPv6 over Low power

Wireless Personal Area Networks) is a working group in the

internet area of the Internet Engineering Task Force (IETF). The

6LoWPAN group has defined encapsulation and header

compression mechanisms that allow IPv6 packets to be sent to and

received from over IEEE 802.15.4 based networks, such as sensor


networks @[21]. So far, two working group RFCs are available. The

Eirst RFC [21] describes the assumptions, problem statement, and

goals for transmitting IP over IEEE 802.15.4 networks. The second

one @[22] describes the frame format for transmission of IPv6

packets and the method of forming IPv6 link-local addresses and

statelessly autoconEigured addresses on IEEE 802.15.4 networks.

Till the writing of this thesis, there is no standard have been

published yet but the group still works in neighbor discovery,

header compression and security mechanisms.

There are trial implementations for 6LoWPAN in sensor

networks. For example, authors of @[12] present the design of a

complete IPv6-based network architecture for wireless sensor

networks. They validate the architecture with a production-quality

implementation that incorporates many techniques pioneered in

the sensor network community, including duty-cycled link

protocols, header compression, hop-by-hop forwarding, and

efficient routing with effective link estimation. In addition to

providing interoperability with existing IP devices, this

implementation was able to achieve an average duty-cycle of

0.65%, average per-hop latency of 62ms, and a data reception rate

of 99.98% over a period of 4 weeks in a real-world home-

monitoring application where each node generates one application

packet per minute. Their results outperform existing systems that

do not adhere to any particular standard or architecture @[12].


2.5 Delay Tolerant Network (DTN)

The DTN approach proposes an architecture to be deployed on

different networks to be interoperable @[10]. It shows that the IP

protocol has a set of assumptions in the underlying links to achieve

its service which are continuously connected in end-to-end, low-

delay paths between source and destination, low error rates and

relatively symmetric bidirectional data rates. These assumptions

are not valid in challenged networks such as sensor networks.

Challenged networks have distinct characteristics that may

limit its performance and so the proposed architecture should

accommodate them. These characteristics may be under one of the

following categories:

• Path and link characteristics. Challenged networks have

high latency and low data rate. Also, they suffer from

frequent disconnection (i.e. Intermittent Connectivity)

because of faults, mobility or low-duty cycle (for saving

consumed power). Moreover, long queuing time may be

extremely large by comparison to traditional networks.

• Network Architectures. Protocols running in challenged

networks are not designed with interoperability

consideration. Also, security approaches that only involve

the endpoints are not very attractive.

• End System characteristics. Nodes in challenged networks

are most likely to last early due environmental conditions

or power exhaustion. Therefore, duty-cycle operation is

commonly low due to required efficient methods for power

consumption like scheduled sleep and active cycles. On the


other hand, they are limited in memory resources and

processing capacity.

Therefore, connecting different challenged networks

together needs the intervention of an agent that can translate

between incompatible networks characteristics and act as a buffer

for mismatched network delays. A delay-tolerant network (DTN) is

a network of regional networks (i.e. regional network is that with

homogenous characteristics). It is an overlay on top of regional

networks, including the Internet. DTNs support interoperability of

regional networks by accommodating long delays between and

within regional networks, and by translating between regional

network communication characteristics. It overcomes problems of

challenged networks by using store-and-forward message

switching.

The DTN implements store-and-forward mechanism by

overlaying a new protocol layer –called Bundle layer- on top of

heterogeneous region-specific lower layers (i.e. over the transport

layer). A single bundle-layer protocol is used across all networks

(regions) that make up a DTN, see Figure @2.11. It stores and

forwards the entire bundles (messages) between nodes. Addressing

in DTN follows a scheme of region ID and entity ID to identify

nodes. Routing within region is based on entity ID only. However,

routing between regions is based on region ID only. This provides

late-bind addressing feature. Late binding allows the flexibility in

choosing the entity IDs structure without concerning its meaning to

other regions. This is different from DNS-style naming which


requires complete translation before any transaction can be made

@[11].

Figure @@@@2.11: The bundle layer overlay in DTN

DTN nodes can be host, router or gateway. They all must

have a bundle layer which overlays their own protocol stack and a

persistent storage in which queues inbound bundles. Host node

sends and/or receives data but does not forward them. Router can

forward message within the same region (network). Gateway

forwards messages between different networks, see Figure @2.12.

Figure @@@@2.12: DTN Gateway architecture


The bundle layer isolates the delay in different networks as

it terminates the effect of the underlying transport protocol.

Therefore, DTNs support node-to-node retransmission at both

transport and bundle layers. However, end-to-end reliability is

implemented in bundle layer only as there is no common transport

protocol across the DTN. Node-to-node retransmission is supported

by means of custody transfers. Such transfers are arranged between

bundle layers in successive nodes. In custody transfer, the bundle

custodian stores the bundle till another node accepts custody or the

bundle’s time to live is expired. Once another node accepts the

custody, it will take the responsibility of custody transfer to another

node and so on till the bundle reaches its destination.

2.6 Discussion

The methods for connecting sensor networks to TCP/IP networks

presented are in some respects orthogonal. It is possible to make

combinations such as a partially TCP/IP-based sensor network with

a DTN overlay connected to the global Internet using a front-end

proxy [9]. It is therefore not possible to make a direct comparison

of the methods. Instead, the merits and drawbacks of each approach

are stated with comments on situations in which each method is

suited.

The gateway-based approach allows WSN protocols to be

chosen freely. This is crucial for the applications that need custom

optimization to fit their constraints. On the other hand, the gateway

node provides a good place to implement security mechanisms such

as user authentication, since all access to the sensor network goes

through it. However, the gateway implementation is typically on the


application level. This means that a special gateway is required for

each application running in WSN. Also, the gateway node has to be a

powerful device to be able to store collected data or to relay large

information from the whole sensor network to the Internet hosts.

Moreover, it does not allow direct access to sensor nodes as both

networks are totally decoupled. Finally, this approach suffers from

single point of failure and bottleneck problems. If the gateway node

is down, then no intercommunication between both networks can

be accomplished.

The VIP Bridge technique can be considered as a gateway-

based approach but it takes some advantages from IP-enabled WSN.

First, it uses a low-level bridge for interconnection, so it can be

implemented in less capable sensor nodes. Second, it provides

consistency with NGN as it allows Internet hosts to interact with

sensor nodes using IPv6 addresses. However, it does not support

data centric WSN which is common in sensor network applications.

Also, it suffers from single point of failure and bottleneck problems.

WSN overlay TCP/IP network approach is not commonly

used approach in the interconnection as it loses the consistency

with next generation network (NGN). Also, deploying the WSN

protocol stack on Internet host is not feasible when there is a need

to communicate with many WSNs. In this case, all protocol stacks

must be deployed on the hosts which brings more protocol header

overhead to TCP/IP network.

From an interconnectivity perspective, running native

TCP/IP in the sensor networks is the most convenient way to


connect the sensor network with a TCP/IP network. One or more

sensor nodes would simply be attached to the TCP/IP network, and

the two networks could exchange information through any of those

nodes. However, the full implementation for TCP/IP on limited

capability sensor nodes still needs more research. The Internet

protocol (IPv4 and IPv6) is successfully implemented in typical

sensor nodes but it is not the case for the upper layer protocols

such as TCP. Also, implementing standard protocols in sensor

networks prevents the desirable flexibility and optimization

required in some applications. Moreover, it will be hard to provide

security in this approach. It will not be feasible, for example, to

configure user authentication rules in the individual sensor nodes.

Thus, security must be implemented externally in this case.

The Delay Tolerant Networks (DTN) approach is similar to

the gateway-based approach but some of merits can be gained

when using the DTN architecture rather than the gateway. DTN

inherently allows for multiple DTN gateways in a DTN region,

which removes the single point of failure problem. Also, DTN

provides general mechanisms and an interface that can be used for

a large number of occasions instead of a single application in the

gateway approach. However, DTN architecture has some of

drawbacks. First, deploying the bundle layer in each sensor node

needs much effort and cost. Second, the custody transfer and store

and forward mechanisms may not fit the limited capabilities of

sensor nodes as they need sufficient storage and processing

capabilities that are not necessary to be supported in sensor nodes.

Table @2.1 shows a comparison among the integration approaches.


Table @@@@2.1: Comparison among the integration approaches

App-level

Gateway

VIP

Bridge

WSN

Overlay

IP

IP

Overlay

WSN

DTN

Application

independent

No Yes Yes Yes Yes

Direct access No Yes Yes Yes Yes

Data centric

support

Yes No Yes Yes Yes

Transparency No Yes Yes Yes Yes

Security support Yes Yes No No Yes

Minimizing

Modification/

overhead

Yes No No No No

Energy efficient

in WSN

Yes Yes Yes No No

Scalability Normal Normal Normal High High

In summary, this chapter discusses the different approaches

for integrating WSN with IP network. There are mainly five

techniques discussed: application-level gateway, DTN, WSN overlay

TCP/IP, TCP/IP overlay, and VIP Bridge. Each technique is

explained in detail. A discussion about the merits and drawbacks of

each approach is presented at the end of the chapter. In next

chapter, a proposed integration technique is presented.

Proposed Integration Technique 55

3 Proposed Integration Technique

3.1 Design Considerations

Based on the discussion given in the previous chapter, we can

conclude the desirable design principles for integration techniques.

Such principles are essential to guarantee the applicability and

efficiency of the technique to be used in a wide range of sensor

network applications. These design principles are:

• Application independent: the integration technique

should allow different and several applications to run

without change needed in the running protocols in both

networks. This eliminates the need to use or deploy

multiple techniques to gain access to the different

applications supported by the WSN. For example, the

application-level gateway approach is application

dependent as it requires knowing application details to be

able to collect data from sensor nodes. Thus, if WSN

supports multiple applications, then multiple gateways are

needed, one for each application.

• Communication paradigms support: WSN has several

communication paradigms other than address-centric such

as data-centric and location-centric paradigms. Integration

technique should support applicability with these

paradigms especially the data-centric as it is commonly

used in many applications.

• Transparency: when using an interconnection node, it

should be transparent for the communicating entities.

Transparent interconnection techniques provide services


from one network to the other independent from the

underlying protocols in either network. Overlay integration

approaches support transparency by default as it deploys

the protocol stack of one network on the other. Thus, nodes

of one network communicate with nodes in the other

network transparently.

• Consistency: integrated sensor network should be

consistent with the next generation network (NGN) and so

it should be IP addressable.

• Security support: Integration technique should support

basic security mechanisms to grant access for the

authenticated IP users and prevent intruders and to

determine the authority of each user.

• Minimizing the overhead or modification required in

sensor nodes. Eliminating the modification required in

sensor nodes increases the flexibility of the integration

technique. It allows integration with even sensor networks

already deployed without infeasible reconfiguration or

reprogramming for sensor nodes.

• Energy efficiency: Integration technique should support

energy efficient protocols running in WSN. For example,

TCP/IP overlay WSN approach forces deploying the internet

protocol in the sensor nodes. The IP is not always the best

efficient protocol for many hard-constrained WSN.

• Scalability: As WSN is typically dense networks, the

integration technique should handle networks of large

number of nodes. Also, it should expect a large number of IP

hosts as well to ensure pervasive accessing to sensor

network.


According to these principles, it can be identified that VIP

bridge technique fits many of them except few of them. First, it fits

the other design principles. It works in low level and so it supports

multiple applications. Also, it is consistent with NGN as it addresses

sensor nodes using IPv6 addresses. It supports energy efficiency in

sensor networks according decoupling from IP network and WSN

protocols are chosen freely. Furthermore, it supports security

mechanisms to be deployed and centralized in the bridge.

Although such merits, it requires modifying protocols

deployed in sensor nodes. It needs sensor nodes to register to

bridge first to obtain virtual IP addresses. Also, packet translation

process in VIP Bridge depends on specific fields that are not

necessary supported in the deployed protocols; and so the running

protocols need to be modified to interact with the bridge. Second, it

supports address-centric and location-centric WSN only. This poses

a great limitation on its applicability on data-centric WSN which is

commonly used in many applications. On the other hand, VIP bridge

depends storing incoming packets from IP hosts to be matched later

with their replies from sensor nodes. This matching is required to

return a reply to the requesting host. This requires extra storage

and processing capabilities in the bridge. Also, this procedure

violates the scalability principle.

Thus, the VIP bridge is carefully studied to overcome

limitations and enhance its operation and to propose a modified

technique that solve its drawbacks.


3.2 The Design of Proposed Technique

The proposed interconnection technique is gateway-based and uses

the idea of VIP Bridge as mentioned previously. It assumes that

WSN and IP network have their own protocol stacks. It allows

direct accessing to individual sensor nodes in address-centric

networks and network-based querying for data-centric networks.

The direct access is usually used in reprogramming or configuration

of specific nodes. While data query is often targeting multiple

unknown nodes and this is a typical communication paradigm in

most sensor networks. It uses a low-level gateway node to translate

traffic from one network to the other. Thus, it allows freely

choosing WSN communication protocols that are suitable for the

sensor network applications. Furthermore, it depends on a simple

translation operation and does not require modification to be made

in protocols running in either network. Therefore, it can be used

with different applications with no need to modify the gateway

logic. Moreover, this technique provides transparent

communication between both networks. In other words, IP hosts

communicate with sensor nodes using virtual IP addresses and

sensor nodes communicate with IP hosts using virtual sensor node

IDs as well. It works with the following entities as shown in Figure

@3.1:

• Sensor Node: Sensor network consists of many sensor

nodes. They have limited capabilities in computing and

energy. These nodes run a WSN routing protocol that may

be address-centric or data-centric. The proposed technique

does not require modifications in the running protocols of

sensor nodes.


• IP Host: There are a set of IP hosts that need to

communicate with WSN. They may access individual sensor

nodes or send interest-based queries to data-centric WSN.

The proposed technique does not require modifications in

IP hosts too.

• Gateway Node: is a capable node that is connected to WSN

and IP network and has their own protocol stacks, as shown

in Figure @3.1. However, a filter layer is embedded before

network layer to filter the traffic forwarded to virtual

addresses, as explained later. If a packet is targeting a

virtual IP address or a virtual ID, the filter layer forwards it

directly to the gateway application. Otherwise, the packet

goes normally in its protocol stack. The gateway application

performs the virtual address assignment and packet

translation components

Sensor Node Gateway Node IP Host

Application

T

N

M

Gateway App

T UDP

N IP

Gateway Filter

M MAC

Application

UDP

IP

MAC

Figure @@@@3.1: The proposed interconnection technique between WSN and IP

network


Next, the technique operations are explained in both direct

accessibility to individual nodes and network querying for data-

centric WSN.

3.2.1 Direct Access to Sensor Nodes

The proposed integration technique is divided into two main

operations: virtual address assignment and packet translation. In

the virtual address assignment, the gateway node assigns a virtual

IP address for each sensor node. This address assignment process

happens when the gateway receives a packet from this node or

when an IP host requests to communicate with it. In the later case,

the gateway just assigns a free IP address from the virtual address

space with no need to check the existing of this node.

The gateway node performs the same operation with sensor

nodes when they want to communicate with IP hosts. It assigns

virtual IDs to IP hosts when it receives packets from them.

However, it is assumed that the sensor node does not initiate the

connection but it replies to a previous packet received from an IP

host. This is a typical request flow pattern initiated by a sink (i.e. an

IP host) to a source (i.e. a sensor node) while the data flows in the

reverse direction as a response. This assumption is useful in that

nodes will not ask the gateway about the virtual ID of an IP host and

so protocols in sensor need not to change. Moreover, the virtual

address assignment is controlled by a leased time to ensure

scalability. The leased time is a design parameter determined by a

tradeoff between the size of the virtual address space and the

stability of the interconnection between both networks.


Table @@@@3.1: Virtual address mapping tables for the network shown in Figure

@@@@3.1

Host IP Virtual ID

11.0.0.1 Host A

12.0.0.1 Host B

Sensor ID Virtual IP

Node X 10.0.0.1

Node Y 10.0.0.2

The virtual IP addresses and virtual IDs are not assigned

physically in nodes or hosts. However, they are stored in mapping

tables maintained by the gateway such as those shown in Table @3.1.

When hosts and nodes communicate together, they use virtual

addresses as destination in their packet. The IP host puts the virtual

IP address of the sensor node in the destination field of IP header.

Also, the sensor node puts the virtual ID of the IP host in the

destination field of the WSN packet header.

The traffic targeting virtual addresses, must reach to the

gateway node to be translated to appropriate addresses. For the IP

network, the router behind the gateway should be configured to

forward such packets to the gateway. For the sensor network, the

routing protocol used in the network is responsible to reach those

packets to the gateway. This is done normally as the packets of

virtual IDs originated previously from the gateway node and the

replied traffic returns to it. When the gateway node receives a

packet targeting a virtual address, it is filtered and forwarded to the

gateway application. The gateway application translates the packet

addresses to the corresponding ones using mapping tables. It does

not change or translate the payload of the packet but it copies the

payload to a new packet. It is assumed that the packet payload is

understandable by the both networks.


This technique suggests UDP as a transport protocol in IP

network because of the suitability with delayed, high error rate of

the sensor networks. However, it can operate theoretically with

TCP too, but more research is required in this point to handle issues

such as how to prohibit non-data packets from bypassing to sensor

nodes and how to extend reliable transmission to the sensor nodes.

The operations of this integration technique can be well-

illustrated by scenarios of sending a packet from an IP host to a

sensor node and receiving a reply from this sensor node to the IP

host as shown next. These scenarios work on the network shown in

Figure @3.1 and their mapping tables given in Table @3.1.

Scenario 1: Packet flow from an IP host (Host A) to sensor node

(Node X):

Initially, the mapping tables of the gateway are empty. The gateway

assigns a virtual IP address for each sensor node, the time it

receives a WSN packet from a sensor node or a request from an IP

host to communicate with this sensor node. Also, it generates a

virtual ID for each IP host, once it receives an IP packet from it. The

gateway stores the assigned virtual IP addresses and IDs in

mapping tables as shown in Table @3.1. It also publishes assigned

virtual IP addresses to IP hosts upon their request. Next, the steps

for sending a packet from IP host to a sensor node are explained.

1. Host A builds an IP packet containing its IP address as the

source address and the virtual IP address of Node X as the

destination address. The payload of this packet should follow

the format specification of the application layer protocol

running in WSN.


2. The packet is routed to WSN and arrives at the gateway.

3. The gateway maps the source and destination addresses of this

packet to the virtual ID of Host A and the ID of Node X

respectively, see Figure @3.2

4. The gateway then builds a WSN packet with the mapped IDs

and the same content specified in the IP packet. This new

packet is delivered to Node X using WSN routing protocol.

11.0.0.1 10.0.0.1 WSN-specific Data

�

Host A Node X WSN-specific Data

Figure @@@@3.2: (Top) A TCP/IP packet originating from Host A to Node X as in

Figure @@@@3.1. (Bottom) The same packet after packet translation

Scenario 2: Packet flow from a sensor node (Node X) to an IP

host (Host A):

This scenario explains the steps for sending a packet from a sensor

node to IP host.

1. Node X builds a WSN packet with its ID as the source and the

virtual ID of Host A as the destination. It knows the virtual ID of

Host A from a previous connection from this host.

2. The packet is routed to the gateway node using WSN routing

protocol.

3. The gateway maps the source and destination IDs to the virtual

IP of Node X and the IP of Host A respectively, see Figure @3.3

4. It builds a new IP packet with the mapped IP addresses and the

same content specified in the WSN packet.


Node X Host A WSN-specific Data

�


Figure @@@@3.3: (Top) A WSN packet originating from Node X to Host A as in

Figure @@@@3.1. (Bottom) The same packet after packet translation

3.2.2 Data Centric WSN

Sensor networks are usually data-centric networks in which the

data is requested based on certain attributes and the sensor nodes

lack fabrication-time identifiers @[26]. Therefore, it is not compatible

with address-centric IP network. The proposed interconnection

technique is modified in this case to address data queries rather

than individual sensor nodes. When an IP host wants to request a

query from the sensor network, it sends the query to the gateway.

The gateway caches the query, assigns it a virtual IP address and

replies the host by this virtual IP address. It also keeps the

addresses of the requesting hosts in the mapping table as shown in

Table @3.2.

Table @@@@3.2: The mapping table of a data-centric network

Attribute-based Query Virtual IP Registered Hosts

type=…,interval=…, rect={…}, temperature = …

10.0.0.1 11.0.0.1, 12.0.0.1, …

type=…,rect={…}, humidity = …

10.0.0.2 11.0.0.1, …

It assigns a lease time for that virtual address whether till

the query expiry time or for a preconfigured time. It then

broadcasts the query to sensor network according to the routing

protocol of the senor network. When data is disseminated back to

the gateway, it forwards data to the registered IP hosts. The source


address of such data messages is then the virtual IP address of that

query.


Application

T

N

M

Application Gateway App

T UDP

N IP

Filter Layer

M MAC

Application

UDP

IP

MAC

Figure @@@@3.4: The interconnection technique with data-centric WSN

Thus, the gateway will act as a sink in such case but receives

its queries externally from IP network, see Figure @3.4. Therefore, it

has the application of the sensor network to handle received

queries accordingly. When another IP host wants to register for a

query or change values of its attributes, it can send that query using

its virtual IP address. When the gateway receives a packet targeting

a virtual address, the payload of the packet is forwarded directly to

the application and the source IP address (i.e. the address of IP

host) is added to the mapping table in the registered hosts.

Next, two scenarios for sending a request from an IP host to

a data-centric WSN and receiving a reply on that request are


explained. They use the network shown in Figure @3.4 and mapping

table given in Table @3.2.

Scenario 1: The flow of a query packet (an interest) from an IP

host (Host A) to data-centric WSN with named data:

1. Host A sends a query packet to the gateway to obtain a virtual

IP address for it as shown in Figure @3.5. The gateway assigns a

virtual IP address for this query and sends it back to Host A.

2. When Host A issues or updates this query, it builds an IP packet

with its IP address as source and the virtual IP address of this

query as destination. The payload of this packet (if any) should

follow the format specification of the application layer protocol

running in WSN.

3. The IP packet is routed to the WSN and reaches the gateway.

The gateway maps the destination IP address to its

corresponding query and updates it if modified. It also stores

the source IP address (Host A) in the registered hosts of that

query in the mapping table as shown in Table @3.2. Those

registered hosts will receive data messages about this query

later on.

4. The gateway caches the query and forwards it to through the

sensor network after translation as shown in Figure @3.6.

11.0.0.1 172.16.1.2 What is the IP of (type = …, rect =

{…}, humidity = …)? Figure @@@@3.5: Virtual IP address request for a given Interest.



�

type=…,rect={…}, humidity=… WSN-specific Data

Figure @@@@3.6: (Top) A TCP/IP packet originating from Host A querying about an

interest as in Figure @@@@3.4. (Bottom) The same packet after translation

Scenario 2: The flow of a data message packet from data-

centric WSN to an IP host (Host A):

1. Sensor nodes match their data with the propagated query. If

they are matched, they reply the source of the query (i.e. the

gateway) by the queried data.

2. The gateway maps the received data messages to the virtual IP

address assigned to its original query.

3. The gateway builds an IP packet with the mapped IP address of

this query and the same content specified in the WSN packet as

shown in Figure @3.7. It then forwards this data message to the

registered hosts of this query specified in the mapping table.

type=…, rect={…}, humidity=… Reply Data

�

10.0.0.2 11.0.0.1 Reply Data

Figure @@@@3.7: (Top) A WSN data message. (Bottom) The same packet after

packet translation

3.3 Gateway Architecture

According to the specifications given above, the gateway

architecture and the operations of its components are discussed

next in both modes: direct access to sensor nodes and data-centric

WSN.


3.3.1 Direct Access to Sensor Nodes

The gateway architecture is divided into two main components;

Gateway Filter and Gateway Application components as illustrated

in Figure @3.8.

The gateway filter component resides above the data link

layers of the gateway while the gateway application is above the

transport layers of both protocol stacks as shown in Figure @3.9. The

gateway filter component assigns virtual addresses and maintains

the mapping tables. Also, it filters received packets according their

destination address. If the packet targets a virtual address, it

forwards it to packet translation module; otherwise it forwards

packets to gateway control module. The gateway application

component handles the received packets and takes the proper

Gateway Filter

Virtual

Address

Assignment

Packet Filter

Gateway Application

Packet

Translation

Gateway

Control

Mapping

Received Packets

Figure @@@@3.8: Gateway Architecture for direct access mode


action towards them whether to translate or process. Next, a

detailed description is given for each component.


Application

T

N

M

Gateway App

T UDP

N IP

Gateway Filter

M MAC

Application

UDP

IP

MAC

Figure @@@@3.9: Protocol stack for the gateway in direct access mode

Virtual Address Assignment Component

This component is responsible for the virtual addresses. When it

receives a WSN packet, it assigns a free virtual IP address for its

source node if it is not already assigned to a virtual IP address. Also,

when it receives an IP packet, it assigns a free virtual ID for its

source host if it is not already assigned to a virtual ID. The Assigned

address are stored in mapping tables and it is controlled by leased

time.

The leased time should be configured carefully to utilize the

virtual address pools efficiently. For IP addresses, it is not

concerned if IPv6 is used. The stateless address auto-configuration

feature in IPv6 allows assigning addresses to very large WSNs.

However, the address space of WSN is usually limited due to the

few number of bits assigned to address fields in packets. Therefore,

the leased time of WSN ID assignment should be carefully chosen.

For example, if it is expected that the size of IDs pool fits the

number of the connecting IP hosts, then long leased time is better as

it achieves interconnection stability and unneeded reassignment for

virtual IDs. But if the number of IP hosts is larger than the size of


IDs pool, then shorter leased time fits better. The leased time can be

small as the maximum round trip time of both WSN and IP network

to guarantee delivering at least a single reply to the requesting IP

host.

Packet Filter Component

This component filters packets according to their destination

address. If a packet is targeting a virtual address, it will be

forwarded directly to the gateway application to be translated and

routed to the other network. Otherwise, it will be forwarded to

upper layer till reach the gateway control layer in the gateway

application, see Figure @3.9. This component resides above the data

link layer because the network layer will drop packets targeting a

virtual address as it is different from the local address.

The packet filter component will be more complex if the

transport layer protocol is connection oriented and uses non-data

packets during session, such as TCP. In this case, this component

should not forward such packets to packet translation component

as they are meaningless for sensor nodes. This issue is crucial and

needs further investigation.

Packet Translation Component

This component extracts application layer data from packets

targeting virtual addresses and construct new packets to be

forwarded to the other network. The addresses of these new

packets are translated based on the mapping tables. The packet

translation can be summarized in the following steps:


1- Extract the application-layer data from the received packet

and fill it in a new packet.

2- Check the destination virtual address. If it does not exist in

the mapping table, drop the packet

3- Otherwise, obtain the real address of this virtual address

and fill it in the destination field of the new packet

4- Check the source address and obtain its virtual address. If it

does not exist in the mapping table, assign a free virtual

address for it.

5- Fill the source virtual address in the source field of the new

packet.

6- Send the new packet to the other network

Figure @3.10 shows the translation steps for a packet forwarded

from an IP host to a sensor node by its virtual IP address. The same

steps are followed for translating packets forwarded to IP hosts by

their virtual IDs.

Source Dest Payload

11.0.0.1 10.0.0.1 Application Data

Host IP Virtual ID

11.0.0.1 Host A

12.0.0.1 Host B

Sensor ID Virtual IP

Node X 10.0.0.1

Node Y 10.0.0.2

Host A Node X Application Data

Source Dest Payload

Figure @@@@3.10: Packet translation for direct access to a sensor node

New WSN packet

IP packet


Gateway Control Component

This component controls the gateway behavior and interacts with

IP hosts to provide virtual IP addresses of sensor nodes to them. In

addition, it is used to assign virtual IP addresses for sensor nodes

from IP hosts. Basically, the gateway assigns a virtual IP address to

a sensor node when it receives a packet from it. However, this may

take long time to assign virtual addresses to most nodes. Therefore,

IP hosts can ask the gateway control component to assign a virtual

IP address to a specific sensor node given its ID. In this case, the

gateway assigns a virtual IP address to it without checking the

existing of such ID for fast assignment.

3.3.2 Data Centric WSN

In data-centric WSN, the gateway architecture is modified to be able

to work with address-less sensor nodes. The gateway in this case

assigns virtual addresses to users’ queries or interests. As the

gateway works with the interests, it should have the WSN

application to operate as a sink which receives queries externally

from the IP network. Therefore, the gateway architecture is divided

in this case into three main components; Gateway Filter, Gateway

Application and WSN Application as shown in Figure @3.11 and

Figure @3.12.

The gateway filter component just filters the received

packets according to their destination address. The received packet

is filtered whether to the packet translation component if it targets

a virtual address; otherwise it is forwarded to the gateway control

component. The virtual address assignment is moved up to the


gateway application component as it is based on the query itself

and other application-layer options. The gateway application

component handles packets and coordinates with the WSN

application to receive queries from IP network and to send back

data messages to hosts. Next, the detailed description of each

component is given.


Application

T

N

M

Application Gateway

App

T UDP

N IP

Gateway Filter

M MAC

IP

Application

UDP

IP

MAC

Figure @@@@3.12: Protocol stack for the gateway in data-centric WSN

Gateway Application

Gateway Filter

WSN Application

Packet Filter

Query

Updating

Gateway

Control

Mapping

Received

Figure @@@@3.11: Gateway architecture in data-centric WSN


Packet Filter Component

This component is the same as that in the direct access to sensor

nodes case explained in the previous section. However, it is limited

to filter virtual IP addresses as no virtual addresses are assigned to

IP hosts. If a packet is targeting a virtual IP address, it will be

forwarded directly to the query updating component to refresh and

update the attributes of the query to which this virtual IP address is

assigned. Otherwise, it will be forwarded to upper layer till reach

the gateway control component in the gateway application as

shown in Figure @3.11.

Query Updating Component

This component extracts the application layer data (i.e. query) from

the packet targeting a virtual address. If the virtual address does

not exist in the mapping table, the packet is dropped. Otherwise, the

source IP address is registered in the mapping table to that virtual

address if it was not already registered. Then, the query is

forwarded to the WSN application to update values of this query in

the mapping table if any.

Gateway Control Component

This component controls the gateway behavior and interacts with

IP hosts to provide virtual IP addresses of the requested queries to

them. When an IP host requests a query to WSN, it sends this query

targeting the gateway IP address. It will be forwarded to the

gateway control component which assigns it a virtual IP address

and adds it to the mapping table. This assignment is controlled by a

lease time to efficiently utilize the IP addresses pool. Also, the

gateway control component should know how to identify distinct


queries to avoid assigning multiple virtual IP addresses to the same

query. It then adds the IP address of the IP host to the registered

hosts of that query. It also replies the IP host by the virtual IP

address to be used in query updates and data messages received

from the sensor network. On the other hand, it forwards the query

to the WSN application which in turn sends the query to the sensor

network according to the specification of its application protocol.

When data messages are disseminated to the WSN application of

the gateway, they are forwarded to the gateway control which in

turn sends them to the registered IP hosts.

WSN Application Component

In data-centric WSN, the integration technique depends on the

queries sent to the gateway. Therefore, the WSN application must

be included in the gateway architecture to handle queries and its

mapping to IP addresses. This component forwards the queries to

the sensor network and receives data messages. It informs the

gateway control by the reply reached to be sent to IP hosts.

3.4 Discussion

As shown in section @2.6, each integration approach has its own

merits and drawbacks. In this section, the proposed integration

technique is discussed and compared with the other approaches

against the design considerations stated in section @3.1.

Application independent. In direct access to sensor nodes mode,

the proposed technique can work with several applications

simultaneously as it relays packets received from the IP hosts after

simple address translation to sensor nodes. Therefore, no pre-


knowledge for the application used is required. However, in data-

centric WSN, the WSN application is deployed in the gateway to be

able to work with queries. If multiple applications supported in

such network, then they should be deployed in the gateway too. The

gateway control component must be able to distinct between

queries and to forward them according to the appropriate

application.

Communication paradigms support. The proposed integration

technique supports both address-centric and data-centric WSNs. It

so solves the drawback of the original VIP Bridge technique.

Transparency and Consistency. The operations of the gateway

node allow transparent communication from one network to the

other. The IP hosts can communicate with sensor network, whether

address-centric or data-centric, using IP addresses which ensures

consistency with NGN as well. Also, in direct access case, the sensor

nodes communicate with IP hosts using sensor IDs. This provides

transparency to sensor network side too. In data-centric WSN,

queries and their replies are forwarded to/from WSN without

modification and so the integration technique guarantees full

transparency and consistency with NGN.

Security support. The proposed integration technique uses a

gateway node for interconnection, so it is a suitable place to apply

security rules as all packets go through this node. If the gateway

node is not capable enough to perform complex access rules, it can

use an external server through its connection to IP network to


handle such rules. Thus, the proposed technique supports security

mechanisms.

Overhead and modification minimization. As shown in its

previous description, the proposed technique does not require any

modification in protocols of nodes of either network. This feature is

desirable as it gives the flexibility in integration and applicability

with diverse WSN protocols. Also, the technique overhead is less

than that of application-level gateway as it depends on simple

translation and address assignment processes.

Energy efficiency. Using the proposed technique, WSN protocols

are chosen freely. Thus, it is possible to select the most suitable

protocol for the WSN application in hand which achieves the

desired energy efficiency.

Scalability. The proposed technique is scalable and works with

dense networks to some extent. By using IPv6 stateless addresses

and its auto configuration, the gateway can theoretically addresses

any number of sensor nodes. However, it needs a powerful gateway

node to handle such large number of nodes along with their traffic.

Also, in case of direct accessing, it assigns virtual sensor IDs to IP

hosts with lease time control. This ensures efficient utilization for

the reserved IDs pool. However, it is still suffer from bottleneck

problem as it depends on a single node for communication. This

limitation exists in gateway-based approaches which uses single

interconnection node. Table @3.3 shows a comparison between the

integration approaches and the proposed technique.


Table @@@@3.3: Comparison between proposed technique and the related work

Ap

p-l

evel

Gate

way

DT

N

WS

N

Over

lay I

P

IP

Over

lay

WS

N

VIP

Bri

dge

Pro

pose

d

Tec

hn

iqu

e

Application

independent

No Yes Yes Yes Yes Yes1

Direct access No Yes Yes Yes Yes Yes

Data centric

support

Yes Yes Yes Yes No Yes

Transparency No Yes Yes Yes Yes Yes

Security

support

Yes Yes No No Yes Yes

Minimizing

Modification/

overhead

Yes No No No No Yes

Energy efficient

in WSN

Yes No Yes No Yes Yes

Scalability Normal High Normal High Normal Normal

In summary, this chapter discusses the proposed

integration in detail. First, the design considerations and principles

to be taken into account to integrate WSN with IP network are

explained. Then, the details of the proposed integration are

described. Also, the gateway architecture used in the proposed

technique is illustrated. Finally, a discussion and comparison

between integration approaches and the proposed technique are

shown and analyzed. Next, details of its implementation are

discussed.

1 In direct access to sensor nodes mode only

Implementation 79

4 Implementation

4.1 Simulators Review

The proposed integration technique is implemented to prove its

applicability and efficiency. There are two options for

implementation; using a hardware WSN testbed or using a network

simulator. The testbed option requires multiple sensor nodes along

with a gateway node which can be connected to IP network. This

option costs a lot and there was no access to such testbed in the

faculty in that time; therefore the integration technique is

implemented on a simulator. However, there are several network

simulators for sensor networks. Each simulator has strong and

weak points and the most suitable should be selected carefully.

For this reason, we stated a set of criteria required in the

selected simulator to be able to fit in the implementation. First, the

simulator must support protocols of both WSN and IP network. It is

a crucial feature as the gateway node needs to be connected to a

WSN and an IP network to integrate them together. Second, it

should have realistic wireless channel and radio models for WSN to

ensure valid results that are near to those produced by real

hardware testbeds. Finally, it is desirable to be recognizable in

research to indicate its accuracy, open source to support adding

new protocols and well-documented to facilitate its learning.

There are surveys for sensor network simulators such as

those presented in @[28] and @[29]. We excluded simulators that do

not support IP networks from these surveys and compared the rest

Implementation 80

to select the most suitable one. Surveys include NS-2, GloMoSim,

OPNET, SensorSim, OMNeT++, TOSSIM, ATEMU and Avrora

simulators. SensorSim is no longer available for public. The TOSSIM,

ATEMU and Avrora are emulators rather than simulators designed

to run applications on MICA Motes (a sensor node platform).

Generally, a simulator is more useful when looking at things from a

high view. The effect of routing protocols, topology, and data

aggregation can be seen best at a top level and would be more

appropriate for simulation. Emulation is more useful for fine-tuning

and looking at low-level results. Emulators are effective for timing

interactions between nodes and for fine tuning network level and

sensor algorithms @[29]. Therefore, emulation tool is not suitable to

test the proposed integration technique. Thus, the NS-2, GloMoSim,

OPNET and OMNeT++ simulators are investigated in detail to select

the most suitable one.

4.1.1 NS-2

NS-2 @[33] is the most popular simulation tool for networks in

general and sensor networks too. It began as NS (Network

Simulator) in 1989 with the purpose of general network simulation.

NS-2 is an object-oriented discrete event simulator; its modular

approach has effectively made it extensible. Simulations are based

on a combination of C++ and OTcl. In general, C++ is used for

implementing protocols and extending the NS-2 library. OTcl is

used to create and control the simulation environment itself,

including the selection of output data. Simulation is run at the

packet level, allowing for detailed results @[28].

Implementation 81

NS-2 sensor network simulation is a modification of the

mobile ad hoc simulation tools, with a small number of add-ons.

Support is included for many of the features that make sensor

networks unique, including limited hardware and power. An

extension developed allows for external phenomena to trigger

events. NS-2 extensibility is perhaps what has made it so popular

for sensor networks. In addition to the various extensions to the

simulation model, the object-oriented design of NS-2 allows for

straightforward creation and use of new protocols; however it is

hard according disorganization or relationships among extensions.

The popularity of NS-2 has ensured that a high number of different

protocols are publicly available, despite not be included as part of

the simulator's release. Its status as the most used sensor network

simulator has also encouraged further popularity, as developers

would prefer to compare their work to results from the same

simulator.

NS-2 does not scale well for sensor networks. This is in part

due to its object-oriented design. While this is beneficial in terms of

extensibility and organization, it is a hindrance on performance in

environments with large numbers of nodes. Every node is its own

object and can interact with every other node in the simulation,

creating a large number of dependencies to be checked at every

simulation interval, leading to an n2 relationship. Another drawback

to NS-2 is the lack of customization available. Packet formats,

energy models, MAC protocols, and the sensing hardware models

all differ from those found in most sensors. One last drawback for

NS-2 is the lack of an application model. In many network

environments this is not a problem, but sensor networks often

Implementation 82

contain interactions between the application level and the network

protocol level.

4.1.2 GloMoSim

GloMoSim @[31] was developed in 1998 for mobile wireless

networks. It is written in Parsec, which is an extension of C for

parallel programming. The ability to use GloMoSim in a parallel

environment distinguishes it from most other sensor network

simulators. Because of communication that must take place

between simulated nodes on different machines, parallel network

simulation is difficult. The use of a wireless model further

complicates things; communication between simulated nodes is

more complicated and computationally intensive than in a wired

simulated network. Additionally, the use of broadcast

communication protocols, common in mobile networks, leads to

significantly more traffic between computers on the distributed

network @[28].

Like NS-2, GloMoSim is designed to be extensible, with all

protocols implemented as modules in the GloMoSim library. The

GloMoSim architecture is composed of a number of different layers.

Each layer uses a different set of protocols and has an API defined

to communicate with the surrounding layers. GloMoSim uses an

object-oriented approach. However, the designers realized that a

purely object-oriented approach would not be scalable. Instead,

GloMoSim partitions the nodes, and each object is responsible for

running one layer in the protocol stack of every node for its given

partition. This helps to ease the overhead of a large network.

Implementation 83

GloMoSim still contains a number of problems. While

effective for simulating IP networks, it is not capable of simulating

any other type of network. This effectively ensures that many

sensor networks cannot be simulated accurately. Additionally,

GloMoSim does not support phenomena occurring outside of the

simulation environment, all events must be generated from another

node in the network. Finally, GloMoSim stopped releasing updates

in 2000. Instead, it is now updated as a commercial product called

QualNet.

4.1.3 OPNET

OPNET is another discrete event, object oriented, general purpose

network simulator. It uses a hierarchical model to define each

aspect of the system. The top level consists of the network model,

where topology is designed. The next level is the node level, where

data flow models are defined. A third level is the process editor,

which handles control flow models. Finally, a parameter editor is

included to support the three higher levels. The results of the

hierarchical models are an event queue for the discrete event

simulation engine and a set of entities representing the nodes that

will be handling the events. Each entity in the system consists of a

finite state machine which processes the events during simulation.

OPNET is capable of recording a large set of user defined results

Unlike NS-2 and GloMoSim, OPNET supports the use of

modeling different sensor-specific hardware, such as physical-link

transceivers and antennas. OPNET can also be used to define

custom packet formats. The simulator aids users in developing the

Implementation 84

various models through a graphical interface. The interface can also

be used to model, graph, and animate the resulting output.

OPNET suffers from the same object-oriented scalability

problems as NS-2. It is not as popular as NS-2 or GloMoSim, at least

in research being made publicly available, and thus does not have

the high number of protocols available to those simulators.

Additionally, OPNET is only available in commercial form.

4.1.4 OMNeT++

OMNeT++ @[34] is a component-based discrete event simulator.

OMNeT++ uses building blocks called modules to implement their

simulation. Modules are connected in a hierarchical nested fashion,

where each module can contain several other modules. Modules can

be defined as being either simple or compound. Simple modules are

used to define algorithms, and make up the bottom of the hierarchy.

Compound modules are a collection of simple modules which

interact with one another, using messages. Regarding simulation of

WSN and IP networks, OMNeT++ relies on external extensions. The

two most prominent ones are the INET Framework for IP network

and Castalia for WSN.

The INET Framework contains models for several Internet

protocols: UDP, TCP, SCTP, IP, IPv6, Ethernet and several other

protocols. Protocols are represented by simple modules. These

modules can be freely combined to form hosts and other network

devices using script language called NED language. Not all modules

implement protocols though. Protocol headers and packet formats

are described in message definition files which are translated

automatically into C++ classes by OMNeT++'s special tool.

Implementation 85

Castalia @[35] is a simulator for WSN based on OMNeT++

simulator. It includes realistic wireless channel and radio models,

with a realistic node behavior especially relating to access of the

radio. Castalia can also be used to evaluate different platform

characteristics for specific applications, since it is highly

parametric, and can simulate a wide range of platforms. The main

features of Castalia are:

• Advanced channel model based on empirically measured

data

o Model defines a map of path loss, not simply

connections between nodes

o Complex model for temporal variation of path loss

o Fully supports mobility of the nodes

o Interference is handled as received signal strength,

not as separate feature

• Advanced radio model based on real radios for low-power

communication

o Probability of reception based on SINR, packet size,

modulation type. PSK FSK supported, custom

modulation allowed by defining SNR-BER curve

o Multiple TX power levels with individual node

variations allowed

o States with different power consumption and delays

switching between them

o Flexible carrier sensing (polling-based and

interrupt-based)

• Extended sensing modeling provisions

• Highly flexible physical process model

• Sensing device noise, bias, and power consumption

Implementation 86

• Node clock drift, CPU power consumption.

• MAC and routing protocols available

• Designed for adaptation and expansion.

Although the flexibility of OMNeT++ and its extensions, the

INET framework and Castalia are separate from each other.

Therefore, to simulate the proposed technique, it is necessary to

find a way to connect or embed one in the other.

4.1.5 Simulator Selection

Based on the previous investigation, the suitable simulator should

be selected. First, GloMoSim (or QualNet) and OPNET are

commercial products and we do not have access to use them in the

faculty. Thus, NS-2 and OMNeT++ are remaining for selection. In

fact, each one has a strong point which does not exist in the other.

The NS-2 simulator is the most dominate simulator used in the

whole networking research and so it contains a lot of supported

protocols. On the other hand, the OMNeT++ is well-designed

component-based simulator which will make protocol modification

and extension much simpler than if it is made in NS-2. It is known

about NS-2 simulator that its learning curve is steep and needs

much effort to understand how to modify a piece of protocol.

However, it is not the case in OMNeT++ according to its organized

structure and component based model. Also, OMNeT++ is

recognizable in research, not as NS-2, but it is still known and used

by many researchers worldwide.

According to the previous discussion, the OMNeT++

simulator is selected to implement the proposed integration

Implementation

technique using INET framework and Castalia simulator.

version of OMNeT++ is 3.3. The INET framework version is

20061020. Castalia 1.3 is initially used then upgraded to version

2.1.

Append

4.2

As mentioned

IP and sensor networks. However,

simulator

is not

Castalia

framework

can be done are explained in Appendix I.

Figure

Implementation

echnique using INET framework and Castalia simulator.



. An introduction for OMNeT++, INET and Castalia is given in

Appendix I with illustrative examples.

4.2 Simulation Environment

As mentioned previously


simulators are separate extensions for OMNeT++.

is not supported for Windows Operating Systems

Castalia is ported to Windows and

framework to be able to use them in simulation


Figure @@@@4.1: The simulation network topology using OMNeT++ simulator

Implementation




An introduction for OMNeT++, INET and Castalia is given in

ix I with illustrative examples.

Simulation Environment

previously, the simulation requires protocols of both


are separate extensions for OMNeT++.

supported for Windows Operating Systems

ported to Windows and

to be able to use them in simulation


: The simulation network topology using OMNeT++ simulator





ix I with illustrative examples.


the simulation requires protocols of both

IP and sensor networks. However, the INET framework and Castalia



ported to Windows and

to be able to use them in simulation









the INET framework and Castalia



ported to Windows and integrated into

to be able to use them in simulation. Details of how this



echnique using INET framework and Castalia simulator. The used






are separate extensions for OMNeT++. Also, the Castalia

supported for Windows Operating Systems. Therefore, the

integrated into the INET

. Details of how this


87

The used






Also, the Castalia

Therefore, the

the INET

. Details of how this


Implementation 88

The simulation network can be formed as shown in Figure

@4.1. It consists of IP network components from INET framework

and sensor network components from Castalia simulator. For the IP

network, several IP hosts (HostA – HostE) are connected to a router

(Router1) which is connected to the gateway node in the sensor

network. For WSN, an array of sensor nodes (represented as a cloud

in the figure; node[numNodes]) are communicating together using

a wireless channel and sense the simulated environment

represented in physicalProcess module. The WSN part may include

a configuration module (WSNConfig) to set IDs to sensor nodes as

explained below. This environment is used in testing both case

studies: direct access to sensor nodes and data centric WSN.

However, there are some customizations are applied in each case.

Next, the general description of each component is explained while

the customizations are shown in the next two sections.

IP Host

In INET framework, IP host is represented by a compound module

called StandardHost as shown in Figure @4.2. It includes a PPP

interface and an Ethernet interface in network access layer, an IP

module in internet layer, and UDP and TCP modules in transport

layer. The TCP or UDP applications can be specified from the

configuration file. We developed a UDP application for each case

study to test its operations.

Implementation

Router

In INET framework, router is represented by

that

connected to all IP hosts and to the gateway too.

adding

a router is needed to forward packets targeting virtual IP addresses

from IP hosts to the gateway. Therefor

forward those packets to the interface the gateway connected to.

Wireless Channel

directly but through the wireless

has a packet to se

Implementation

Router


that supports any number of interfaces.


adding routes in




Wireless Channel

In Castalia,


has a packet to se

Figure

Implementation


supports any number of interfaces.


routes in its routing table




Wireless Channel

In Castalia, the sensor


has a packet to send, this goes to the wireless channel which then

Figure @@@@4.2: The IP host structure in INET framework


supports any number of interfaces.


its routing table from the configuration file




sensor nodes do not connect to each other

directly but through the wireless channel module(s). When a

this goes to the wireless channel which then

The IP host structure in INET framework

In INET framework, router is represented by a compound module

supports any number of interfaces. In our simulation, i


from the configuration file


from IP hosts to the gateway. Therefore, a static route is added to


nodes do not connect to each other

channel module(s). When a



compound module

In our simulation, i

connected to all IP hosts and to the gateway too. It allows statically

from the configuration file. In fact,


e, a static route is added to



channel module(s). When a



89

compound module

In our simulation, it is

statically

. In fact,


e, a static route is added to



channel module(s). When a node


Implementation 90

decides which nodes should receive the packet @[32]. In sensor

nodes, the Castalia realistic wireless channel is used trying to get

near real results. The word “realistic” here is used in the sense that

the simulator is making the necessary provisions to capture various

important features of the wireless channel. One important aspect of

the wireless channel modeling is to estimate the average path loss

between two nodes, or in general, two points in space. For WSN,

where the separation of nodes is from a couple of meters to a

hundred meters, the lognormal shadowing model has been shown

to give accurate estimates for average path loss. This is the formula

that returns path loss in dB as a function of the distance between

two nodes and a few parameters

PL(d) is the path loss at distance d, PL(d0) is the known path loss at

a reference distance d0, η is the path loss exponent, and Xσ is a

Gaussian zero-mean random variable with standard deviation σ.

The four parameters in italics and bold, are defined as parameters

of the wireless@ channel module, having a “SN.wirelessChannel.”

prefix.

Based on the power loss and the transmission power of a

transmitter, the power of the signal received at a receiver can be

calculated. By also knowing the noise (or more generally

interference) at this receiver, the Signal to Noise Ratio (SNR)

(sometimes called signal to interference ratio, SIR) can be

calculated. From this quantity and parameters of the radio, the

packet reception probability at a receiver from a specific

transmitter can be calculated too. Thermal noise is one constant

Implementation 91

level of interference (i.e., the noise floor, now a parameter of the

radio). Multiple concurrent transmissions can also act as

interference to each other. So if nodes A, B, C are transmitting,

nodes B and C might interfere with node’s A transmission, nodes A

and C with node’s B transmission and so on. In Castalia,

interference from different transmitting nodes are dynamically

calculated and thus calculating dynamically the SNRs and the

resulting packet reception probabilities. The additive interference

model is computed where transmissions from other nodes are

calculated as interference by linearly adding their effect at the

receiver. Another parameter that the user can work with is

SN.wirelessChannel.allBidirectionalLinks. If set to “true” then if a

link is good (PRR >95%) in one direction then it is forced to have

the same quality in the opposite direction. If set to false then there

is no correlation and the fading is chosen independently. In reality,

link qualities between a pair of nodes are not completely

uncorrelated but there is still great variation. The user can make the

wireless channel even simpler by making the

SN.wirelessChannel.sigma (the standard deviation of the path loss

variation) equal to zero. This way all nodes at a certain distance

form a transmitter get the exact same signal strength. Also, as a side

effect, all links are bidirectional (since there is no random

variation). If we provide sharp thresholds for the radio reception

too (i.e., perfect reception of a packet or no reception at all) then we

do have the simple unit disk model. Indeed, there are special cases

of the popular radios are provided in the .ini files where they are

defined as ideal (i.e., with sharp thresholds). In @[32], more

information about their models can be found.

Implementation 92

Those parameters are already initialized in Castalia

configuration file “WChannel_Realistic.ini” by the following values:

SN.wirelessChannel.pathLossExponent = 2.4

SN.wirelessChannel.PLd0 = 55

SN.wirelessChannel.d0 = 1

SN.wirelessChannel.collisionModel = 2

SN.wirelessChannel.sigma = 4

SN.wirelessChannel.allBidirectionalLinks = false

Radio Model

The Radio Model tries to capture many features of a real generic

low power radio, one that is likely to be used in wireless sensor

network platforms. As such, it supports multiple states (transmit,

receive/listen, sleep) with different consumption powers and delays

for transitions from one state to another. It supports multiple

transmission power levels. It also supports carrier sensing (with

help from the wireless channel module). The user can work with

the data rate and other parameters that affect the probability of

packet reception given a Signal to Interference Ratio. The main

parameters are discussed next.

The dataRate parameter affects the speed of a packet’s

transmission. The noiseFloor is thermal noise in the absence of

other interference which depends mainly on temperature and

bandwidth used. The receiverSensitivity parameter, although a

radio parameter, is actually used by the wireless channel module to

make its computations more efficient. The rxPower, listenPower,

sleepPower give the power consumption in mW of respective

states. Transmission is somewhat more complicated. The

txPowerLevels parameter gives the different power output per tx

level in dBm. This parameter is used mostly by the wireless channel

Implementation 93

as well. txPowerConsumptionPerLevel gives the overall radio

power consumption when this tx level is used and the radio is

transmitting. The txPowerLevelUsed sets the current power level

used. If not deEined properly, it takes the default value of 0. The

txModeUsed parameter specifies how transmission of a packet is to

be carried out. The packet can be either 1) sent or, 2) check the

carrier sense signal once and if clear send the packet otherwise

discard it, or 3) persistently check for a clear channel (which means

the radio should persistently be in listen mode) and then send the

packet. The simple first option is used since the carrier sensing is

done separately at the MAC level (using sleeping backoff intervals).

Also, real radios (e.g., CC2420) usually provide a “Channel Clear”

pin that can inform upper layers implemented in the processor if a

carrier signal is sensed or not. The radio has to be in listen mode

(for at least some minimum time) in order for the signal to be valid.

There is a separate pin that is used to signal if the Channel Clear pin

is valid.

Most radios have internal transmit buffers. In Castalia, it is

possible to define the size of the buffer (in terms of packets/frames

it can hold) as well as the frame size and overhead. This is done

with the bufferSize, maxPhyFrameSize, and phyFrameOverhead

parameters. The next parameters define the delays for all possible

transitions of the states listen, sleep, Tx (there is no real transition

from listen to/from receive). Finally, the parameter delayCSValid

gives the delay for the Carrier Sense signal to become valid once the

radio enters the listen state.

In the experiments, the TelosB ideal modulation is used

which define the following values for Radio model parameters:

Implementation 94

SN.node[*].networkInterface.Radio.dataRate = 250 # kbps

SN.node[*].networkInterface.Radio.noiseBandwidth = 194 #in KHz

SN.node[*].networkInterface.Radio.noiseFloor = -100 #dBm

SN.node[*].networkInterface.Radio.modulationType = "IDEAL"

SN.node[*].networkInterface.Radio.encodingType = 0 #NRZ

SN.node[*].networkInterface.Radio.receiverSensitivity = -95 #dBm

SN.node[*].networkInterface.Radio.rxPower = 62 #mW

SN.node[*].networkInterface.Radio.listenPower = 62 #mW

SN.node[*].networkInterface.Radio.sleepPower = 1.4 # mW

SN.node[*].networkInterface.Radio.txPowerLevels = "0 -1 -3 -5 -7 -

10 -15 -25" # in dBm

SN.node[*].networkInterface.Radio.txPowerConsumptionPerLevel =

"57.42 55.18 50.69 46.2 42.24 36.3 32.67 29.04"

SN.node[*].networkInterface.Radio.txPowerLevelUsed = 0

SN.node[*].networkInterface.Radio.txModeUsed=0#NoCarrierSense

SN.node[*].networkInterface.Radio.bufferSize = 16

SN.node[*].networkInterface.Radio.maxPhyFrameSize=127 #bytes

SN.node[*].networkInterface.Radio.phyFrameOverhead = 6# bytes

SN.node[*].networkInterface.Radio.delaySleep2Listen=0.194 #ms

SN.node[*].networkInterface.Radio.delayListen2Sleep = 0.05 #ms

SN.node[*].networkInterface.Radio.delayTx2Sleep = 0.05 #ms

SN.node[*].networkInterface.Radio.delaySleep2Tx = 0.194 #ms

SN.node[*].networkInterface.Radio.delayListen2Tx = 0.01 #ms

SN.node[*].networkInterface.Radio.delayTx2Listen = 0.01 #ms

SN.node[*].networkInterface.Radio.delayCSValid = 0.128 #ms

Physical Process

The sensor nodes are linked through the physical processes that

they monitor. For one physical process there is one truth (one

module) which the nodes sample in space and time to get their

sensor readings. There can be multiple physical processes,

representing the multiple sensing devices (multiple sensing

modalities) that a node has, as well as multiple wireless channels to

represent the multiple radios (operating in an orthogonal manner,

e.g., different frequencies or different codes) that a node might have

@[32].

Implementation 95

Sensor Node and Gateway

In Castalia, the sensor node module is actually a composite one as

shown in Figure @4.3. The solid arrows signify message passing and

the dashed arrows signify an interface between the modules with

simple function calling. For instance, most of the modules call a

function of the resource manager to signal that energy has been

consumed.

Figure @@@@4.3: The internal structure of sensor node in Castalia

The Application module is the one that the user will most

commonly change, usually by creating a new module to implement

a new algorithm. The communications MAC, Routing and Radio

modules are grouped into the network interface module. The radio

module is responsible to interact with the wireless channel to send

and receive packets according to the applied communication model.

The sensing device manager module is connected to the physical

process module to provide the application by the samples that the

sensor should read. The resource manager module counts

Implementation

resources (e.g. CPU, memory, an

modules. Mobility module allows nodes to change their location

according to the configured path and so affecting the wireless

channel behavior.

parameters

node.

the same type of nodes

not possible to make the gateway node has the TCP/IP protocol

stack and communicate with other sensor nodes

two different

for all nodes to have

the

interface is deactivated for all

Implementation




channel behavior.

parameters @[32]

Figure @@@@4.4: The modified structure for sensor nodes and gateway

The sensor nodes need to be connected to the gateway

node. However, the

the same type of nodes



two different types of modules

for all nodes to have

the gateway structure


Implementation




channel behavior. All existing modules are highly tuneable by many

[32].

: The modified structure for sensor nodes and gateway


However, the wireless channel assumes that all nodes share

the same type of nodes (i.e. the same module type)



types of modules

for all nodes to have the TCP/

gateway structure as shown in


resources (e.g. CPU, memory, and energy) consumed by all other



All existing modules are highly tuneable by many



wireless channel assumes that all nodes share

(i.e. the same module type)



types of modules. Thus, the node structure is modified

the TCP/IP protocol stack and be the same as

as shown in

interface is deactivated for all sensor nodes while it is activated

d energy) consumed by all other







(i.e. the same module type)



the node structure is modified

protocol stack and be the same as

as shown in Figure @4.4.

sensor nodes while it is activated








(i.e. the same module type). Therefore,


stack and communicate with other sensor nodes as this will make



. However, t

sensor nodes while it is activated

96








. Therefore, it is


as this will make



However, the IP

sensor nodes while it is activated and

Implementation 97

connected to the router in the gateway node. This structure maps to

the gateway architecture given in section @3.3.

For the WSN side, the network interface module is modified

to let the MAC sub-module connect to the gateway filter module

rather than the network sub-module directly. Also, the network

sub-module is connected to the gateway filter rather than the MAC

sub-module. On the other hand, the gateway application module is

embedded between the network interface and the application

modules.

The Medium Access Control (MAC) is an important part of

the node’s behavior, thus there is a separate module that defines it.

The initial motivation in building Castalia was to test a highly

tunable MAC protocol in realistic channel radio conditions. This

highly tunable protocol is provided with the standard distribution

of Castalia because it can approximate several protocols out there.

However it should be noted that this protocol was built with

broadcast communication in mind (i.e., no unicast) thus it does not

currently support acknowledgments. Next, the parameters that

affect the behavior of the MAC are discussed.

dutyCycle. This is the fraction of time that the node stays on

listening to the channel. For (1-duty Cycle) fraction of the time the

node sleeps. This is probably the most important parameter which

affects energy consumption as it can drastically reduce listen time.

listenInterval. This is the time the node stays on listening.

Knowing the duty cycle we can then define the time the node sleeps.

After we had one listen and one sleeping interval, the cycle starts

again. We would like the listen interval to be small so we the

Implementation 98

sleeping interval for a given duty cycle is small too thus latency in

data delivery is minimized. If we make the listen interval too small

though the data needed to be transmitted in it won’t get a fair

chance to get transmitted (remember there is no alignment of slots

between nodes, so there is randomness.

BeaconIntervalFraction. When we have a duty cycle we need a

way to get the attention of a sleeping node before we transmit our

data. A standard method is to use a train of beacons before our

transmitted data. If we need to guarantee that a receiving node will

wake up, we should make the train of beacons at least as long as the

sleeping interval. But imagine you have many neighbors and you do

not need all of them to wake up. Assume that you want

(statistically) half of them to wake up. Then you should make the

beacon interval half of the sleeping interval. This parameter

expresses the fraction of the maximum beacon 31 interval (=

sleeping interval) that our beacon interval actually is. The smaller

this is the less energy we spend, but the less chance we have to

wake up a neighbor.

numTx. Number of transmissions. For each piece of data needed

to be transmitted how many times do we try to transmit it.

Obviously the larger this parameter is the more energy is spent but

more performance (reached nodes) can be achieved.

reTxInterval. Retransmission Interval. The interval between

retransmissions. With this parameter we can effectively spread out

our expected transmissions.

probTx. Probability of Transmissions. When a piece of data needs

to be transmitted (or retransmitted) we perform the action with a

certain probability; often assumed by many protocols to be 1. This

value combined with the number of retransmissions can create any

Implementation 99

expected number of transmissions per node, even non integer values.

For example if we have 6 retransmissions (so 7 transmissions in

total) and probability of transmission 0.5, then we end up with 3.5

expected transmissions per node per data value we want to

transmit.

randomTxOffset. Random Transmission Offset. When we decide to

transmit something we do not do it immediately but we wait a

random time uniformly distributed in [0..Random Transmission

Offset]. This randomness significantly helps to avoid collisions that

could be very common in a broadcast type scenario. If a node

transmits its data and four of its neighbors receive it and decide to

retransmitted immediately then we are bound to have collisions.

Adding the randomness in transmission time we can avoid such

collisions. This value does not even have to be large provided that

the nodes are performing carrier sense before transmitting (i.e.,

they are applying CSMA).

backoffType. This parameter has to do with carrier sensing. As we

mentioned earlier, carrier sensing is performed normally by the

MAC (the carrierSense parameter has to be “true”). This means that

whenever the MAC needs to transmit a packet, and before starting

transmitting potential beacons, it checks with the radio to see if the

channel is clear. If the channel is not clear is the transmission is

backed off for some time and the MAC puts the radio to sleep mode

(to save energy). The backoff type parameter specifies how is this

backing off interval determined. If set to 0, then we back off for the

duration of a sleeping interval. If set to 1 we back off for a constant

time backoffBaseValue. If set to 2 then it depends on the consecutive

times we found the channel not to be clear. We back off for

(backoffBaseValue) · (times). If we set the parameter to 3 then again

Implementation 100

it depends on the 32 consecutive times we found the channel not to

be clear. We back off for (backoffBaseValue)times.

backoffBaseValue. This is the parameter we used above in

expressing how long we are backing off for each different backing

off type.

The rest of the parameters are defining how many bytes a data

frame is, how much is the overhead, how large a beacon is, and an

ack frame is (although not currently used). WE also define the size

of the MAC buffer and finally if the MAC is performing carrier

sensing.

Next, the values of the previous parameters used in the

experiments.

SN.node[*].networkInterface.MAC.dutyCycle = 1

SN.node[*].networkInterface.MAC.listenInterval = 10 # ms

SN.node[*].networkInterface.MAC.beaconIntervalFraction = 0

SN.node[*].networkInterface.MAC.probTx = 1

SN.node[*].networkInterface.MAC.numTx = 1

SN.node[*].networkInterface.MAC.randomTxOffset = 10

SN.node[*].networkInterface.MAC.reTxInterval = 0

SN.node[*].networkInterface.MAC.backoffType = 1

SN.node[*].networkInterface.MAC.backoffBaseValue = 16

SN.node[*].networkInterface.MAC.randomBackoff = true

SN.node[*].networkInterface.MAC.maxMACFrameSize = 80

SN.node[*].networkInterface.MAC.macFrameOverhead = 14

SN.node[*].networkInterface.MAC.beaconFrameSize = 14

SN.node[*].networkInterface.MAC.ACKFrameSize = 14

SN.node[*].networkInterface.MAC.macBufferSize = 32

SN.node[*].networkInterface.MAC.carrierSense = true

For the TCP/IP side, the gateway filter module is embedded

between data link module (Ethernet or PPP) and the network layer

module (IP). Also, the gateway application is connected to the UDP

Implementation 101

module. The gateway filter is connected also to the gateway

application to forward packets targeting virtual addresses. There

are other modules included but not essentially used like the Ping

application and TCP modules.

WSN Configuration

The WSN configuration module is a simple module that is used in

direct access to sensor nodes mode. It helps to map network

addresses to MAC addresses of sensor node as Castalia assumes

they are the same. In the simulation, it is required to assign virtual

sensor IDs that are not exist in the WSN nodes. Using the same

addresses for MAC and network layers does not allow packets of

virtual IDs reach the gateway. Therefore, we have to use network

addresses and some kind of mapping to translate the assigned

addresses to the real addresses used by the simulator. In real

implementation, this module is not needed as nodes will already be

identified by the assigned addresses. Also, packets of virtual

addresses as destination return to the gateway as original packets

are previously sent from the gateway and these addresses as

source. And so, routing paths are formed to route packets of virtual

addresses to the gateway.

Next, details of implementations in direct access to sensor

nodes and data centric WSN modes are explained. Differences are

concentrated in the modules of gateway node and the application

modules used in each case.

4.3 Direct Access to Sensor Nodes

As mentioned in the previous section, the sensor node and gateway

is represented by the same module to allow communication

Implementation 102

between nodes and gateway. Some of sub-modules of this generic

node module are modified to work as required such as the Routing

module. Also, there are new sub-modules developed from scratch

such as gateway filter, gateway application and application

modules. Next, details of implementation of these sub-modules are

explained.

4.3.1 Generic Node Module

Routing Module

Since version 1.2 of Castalia, network (routing) module was

supported but no protocol is implemented in that version @[32]. For

this reason, a simple routing protocol is built in this module. For

simplicity, nodes learn their routes from the configuration file. Also,

some routes are included to forward packets of virtual addresses to

the gateway node. Using configurable static routes will not affect

the simulation results as the integration technique does not depend

on the operations of the routing module.

Gateway Filter Module

This module is active in the gateway node only. It is transparent in

sensor nodes and just forwards packets from upper layer to the

lower layer and vice versa. In the gateway node, it assigns a virtual

IP address for sensor node and a virtual ID for IP host once it

receives a packet from a node or a host respectively. It stores such

addresses in two hash tables to accelerate retrieving their real IP

addresses or sensor IDs. After assigning a virtual address, it

schedules an event (self-message) for the leased time of this entry.

Implementation 103

When this event is fired, this entry is deleted from the hash table

and returns to the free addresses pool.

In addition, this module filters received packets such that it

forwards packets of virtual addresses to the gateway application

module directly. It recognizes a virtual address or virtual ID by

checking the existing of them in hash tables.

Gateway Application Module

This module receives packets of virtual addresses and translates

them to corresponding packets to the other network. It asks the

gateway filter module to map these virtual addresses to their real

addresses. It also receives packets from IP hosts to assign a virtual

IP address for a specific node. In this case, it asks the gateway filter

module to add this entry in its hash table and then it replies the

requesting IP host by the assigned virtual address. This module is

also active in the gateway node only like the gateway filter module.

4.3.2 Application Module

To test the proposed integration technique, we developed an

application module that matches with the accessibility mode. In

direct access to sensor nodes, the suitable application is on-demand

querying sensor data. The requesting sink sends a query to a sensor

node which replies by its sensed data sample. For IP hosts, the same

application is used but it is supported by the mechanisms that

retrieve virtual IP addresses from the gateway node.

Implementation 104

4.4 Data-centric WSN

Data centric WSN does not use unique addresses for sensor nodes

to route packets within network. However, the sink sends queries

to certain regions and waits for data from the sensors located in the

selected regions. Since data is being requested through queries,

attribute-based naming is necessary to specify the properties of

data. SPIN @[25] is the first data-centric protocol, which considers

data negotiation between nodes in order to eliminate redundant

data and save energy. Later, Directed Diffusion @[24] has been

developed and has become a breakthrough in data-centric routing.

Then, many other protocols have been proposed either based on

Directed Diffusion or following a similar concept @[27]. As Castalia

does not include any data-centric routing protocol, we implemented

the Directed Diffusion to test the proposed technique in this case.

Next, the Directed Diffusion protocol is introduced.

4.4.1 Directed Diffusion Protocol

Directed diffusion is a data-centric (DC) and application-aware

paradigm in the sense that all data generated by sensor nodes is

named by attribute-value pairs. The main idea of the DC paradigm

is to combine the data coming from different sources enroute (in-

network aggregation) by eliminating redundancy, minimizing the

number of transmissions; thus saving network energy and

prolonging its lifetime. Unlike traditional end-to-end routing, DC

routing finds routes from multiple sources to a single destination

that allows in-network consolidation of redundant data. In directed

diffusion, sensors measure events and create gradients of

information in their respective neighborhoods. The base station

Implementation 105

(BS) requests data by broadcasting interests. Interest describes a

task required to be done by the network. Interest diffuses through

the network hop-by-hop, and is broadcast by each node to its

neighbors. As the interest is propagated throughout the network,

gradients are setup to draw data satisfying the query towards the

requesting node @[26].

Each sensor that receives interest, it setups a gradient

toward the sensor nodes from which it receives the interest. This

process continues until gradients are setup from the sources back

to the BS. More generally, a gradient specifies an attribute value and

a direction. The strength of the gradient may be different towards

different neighbors resulting in different amounts of information

flow. At this stage, loops are not checked, but are removed at a later

stage.

Figure @@@@4.5: An example of interest diffusion in sensor network

Figure @4.5 shows an example of the working of directed

diffusion ((a) sending interests, (b) building gradients, and (c) data

Implementation 106

dissemination). When interests fit gradients, paths of information

flow are formed from multiple paths and then the best paths are

reinforced so as to prevent further flooding according to a local

rule. In order to reduce communication costs, data is aggregated on

the way. The goal is to find a good aggregation tree which gets the

data from source nodes to the BS. The BS periodically refreshes and

resends the interest when it starts to receive data from the

source(s). This is necessary because interests are not reliably

transmitted throughout the network.

All sensor nodes in a directed diffusion based network are

application-aware, which enables diffusion to achieve energy

savings by selecting empirically good paths and by caching and

processing data in the network. Caching can increase the efficiency,

robustness and scalability of coordination between sensor nodes

which is the essence of the data diffusion paradigm. Other usage of

directed diffusion is to spontaneously propagate an important

event to some sections of the sensor network. Such type of

information retrieval is well suited only for persistent queries

where requesting nodes are not expecting data that satisfy a query

for duration of time. This makes it unsuitable for one-time queries,

as it is not worth setting up gradients for queries, which use the

path only once @[26].

4.4.2 Generic Node Module

Routing Module

The Directed Diffusion is implemented in the node application

module rather than the network module because it handles the

Implementation 107

interests and their attributes which are application specific so it is

better to put it in the application module. The routing module so is

limited to bypassing packets to MAC module. The implementation

of directed diffusion is explained in application module.

Gateway Filter Module

This module is active in the gateway node only. It is transparent in

sensor nodes and just forwards packets from upper layer to the

lower layer and vice versa. In gateway, the functionality of this

module is limited to packet filtering which forwards packets of

virtual IP addresses to gateway application module. Otherwise, the

packet is passed normally to the upper layer.

Gateway Application Module

This module receives interests from IP hosts and passes them to the

WSN application module. It caches the distinct received interests

and assigns them virtual IP addresses. It replies the IP host by this

virtual IP address for further interest updates or data messages. It

also registers the requesting IP hosts for each interest to return

data messages back. When another IP host requests a previously

cached interest, it passes the interest to WSN application too but

returns the virtual IP address already assigned to it. Assignment of

the virtual IP addresses is controlled by a lease time which is the

expiry duration of the interest. This module is active in the gateway

node only like the gateway filter module.

Implementation 108

4.4.3 Application Module

WSN Application Module

This module handles data centric communication among sensor

nodes using Directed Diffusion protocol. It is put in the application

layer rather than network layer as it handles interests and their

attributes which are application-specific. The interest attributes

used in the implementation are shown next.

Interest

{

int X; int Y; int W; int H;

double Interval;

double ReqInterval;

double TimeStamp;

double ExpireAt;

double data;

string Key;

};

The X, Y, W and H attributes specify the rectangle of this interest.

All sensor nodes have its location within this rectangle (i.e. matched

nodes) should report their data. The Interval and

ReqInterval attributes determine the data reporting and

interest refreshment rates in seconds respectively. Matched nodes

should report their data every Interval seconds. Also, interests

should be refreshed periodically every ReqInterval seconds as it

is not guaranteed they reach aimed nodes. The TimeStamp

attribute expresses when this interest originated from the sink. The

ExpireAt attribute determines when this interest should be

Implementation 109

removed from node cache and stops reporting data about it. The

data attribute carries the information sensed by the node. As the

temperature sensor is used in the implementation, its data fits in

single attribute. Other sensor types can provide more advanced

data in more than single attribute. The Key attribute is used to

distinguish among different received interests. It is assumed that

distinct interests have different keys and vice versa. Such keys can

be constructed from other attributes in the interest itself such as

the rectangle and expiry time.

When a sink has an interest to be queried to the network, it

caches this interest. Once an interest is cached, it is forwarded to

the node’s neighbors. When a node receives an interest, it caches

this interest if it is not already cached and sends it to its neighbors.

If the received interest matches with node’s attributes, the node

starts to send its sensed data to the reinforced gradient of this

interest towards the sink. The interest matches with the node

attributes when its location is within the interest rectangle. For

simplicity, the reinforced gradients are configured statically in

nodes. When a node receives a data message, it re-sends this

message to the gradient of the related interest. It is not necessary to

resend every data message. It may not resend a received message if

it has just sent a similar message. Data messages continue to

propagate from node to another till it reaches the sink.

Nodes keep sending interests and data messages by interest

refreshment and data reporting intervals respectively till the expiry

time of this interest. Once the interest is expired, it is removed from

node cache and so stopping reporting data about this interest.

Implementation 110

IP Host Application Module

The application module deployed on the IP hosts forwards interests

to the gateway node. The gateway node in turn acts as a sink and

sends the interest to its neighbors by its WSN application module.

Data collected by the WSN application module in gateway node is

returned back to IP hosts requesting its interest. This module

includes also interaction mechanisms with gateway to request

virtual IP addresses for interests.

In summary, this chapter shows the details of

implementation for the integration technique. First, a brief survey

for suitable software simulators is presented. Second, the simulator

selection methodology is explained which concluded to use

OMNeT++ simulator. Then, the simulation environment and its

entities and modules are discussed. Finally, the implementation

details of each module in both direct access to sensor nodes and

data centric WSN modes are discussed. Next, the evaluation of the

integration technique is discussed.

Experiments and Evaluation 111

5 Experiments and Evaluation

5.1 Evaluation Methodology

The proposed integration technique is evaluated to measure its

validity. The evaluation methodology used is to measure the

overhead of the gateway in different scenarios to ensure it is

bounded by an acceptable margin. To measure the gateway

overhead, multiple experiments are performed where each

experiment is run twice. The first run is made within the sensor

network only. The second run is made over both IP and sensor

networks using the integration technique. The performance of both

runs is compared to indicate the gateway overhead. The similarity

of the environment setup and configuration in both runs is taken

into consideration to ensures that the results are not influenced by

other hidden parameters. For example, the sink which initiates or

requests data from sensor nodes in the first run acts as the gateway

in the second run to generate the same traffic flow in both cases.

Figure @@@@5.1: Simulation environment


As shown in section @4.2, the simulation environment

consists of a set of sensor nodes forming a sensor network

connected to an IP network through a gateway node. The number of

hosts in IP network and nodes in WSN vary from an experiment to

another. The number of sensor nodes ranges from 10 to 290 nodes

organized in a grid with constant density as shown in Figure @5.1.

The constant density of nodes is important because the connectivity

of a sensor field is a function of the average density. If the sensor

field area is kept constant but increased network size, the

performance may be affected not only due to the larger number of

nodes but also due to increased connectivity. The CSMA/CA is used

as the MAC protocol with the parameters specified in section @4.2.

The routing protocol is whether static hop-by-hop routing or

Directed Diffusion used according to the tested mode of the

integration technique. For the IP network, number of hosts ranges

from 2 to 5 hosts which use a UDP application to communicate with

the gateway node. All simulations run for 10 seconds.

Next, the experiments are discussed with their results in

both direct access to sensor nodes and data centric WSN cases.

5.2 Evaluating Direct Access to Sensor Nodes

Experiment 1: The effect of request rate

The first experiment tests the effect of the request rate on the

gateway performance. In this experiment, a node is configured to

query two specific sensor nodes with several data rates range from

10 to 150 requests per second. Once the sensor node receives a

request, it replies by its sensed value. This experiment is run twice;


the first run operates in sensor network only where a sink (i.e. a

sensor node) requests samples from another two sensor nodes. The

second run works across IP and sensor networks. In this case, the

sink, used in the first run, acts as a gateway node while an IP host is

configured to query the same two sensor nodes used in the first

run. The WSN size is 10 nodes. Results of both runs are given in

Table @5.1 and Table @5.2.

Experimental results are measured by several metrics:

average end-to-end delay, total throughput, and packet delivery

ratio. Average end-to-end delay is the average time it takes a data

packet to reach its destination. The average delay indicates how

much time the gateway can process a packet. Throughput is the

total number of delivered data packets divided by the total duration

of simulation time. This metric indicates how much packets the

gateway can handle specially with heavy traffic. Packet delivery

ratio is calculated by dividing the number of packets received by

the destination through the number of packets originated by the

application layer of the source. This metric indicates if the gateway

is reliable and does not increase the packet loss by its operations.

In Table @5.1, the sent requests column is the total number of

requests sent by the sink. The received requests column is the total

number of requests received by both queried sensor nodes. The

received replies column expresses the total number of replies

received by the sink from both sensor nodes. The packet loss is the

percentage of the lost requests (ReqS – ReqR) to the total requests

originally sent by the sink (ReqS). The average delay is the average

time (in milliseconds) the request takes from the sink to reach the


sensor node. The total throughput is the total number of received

requests and replies (ReqR + RepR) divided by the simulation

time.

Table @@@@5.1: Direct access to sensor nodes in different request rates (traffic

within sensor network only)

Re

qu

est

s

Ra

te p

er

Se

con

d

Se

nt

Re

qu

est

s

[Re

qS

]

Re

ceiv

ed

Re

qu

est

s [

Re

qR

]

Re

ceiv

ed

Re

pli

es

[Re

pR

]

Pa

cke

t L

oss

(%

)

Av

era

ge

De

lay

(ms)

To

tal

Th

rou

gh

pu

t

(pa

cke

t/s)

10 95 95 95 0.00 10.94 19.00

30 264 264 263 0.00 10.64 52.70

50 407 406 406 0.25 10.97 81.20

70 534 529 524 0.94 11.38 105.30

90 638 634 629 0.63 11.37 126.30

110 733 726 714 0.95 11.41 144.00

130 812 806 796 0.74 11.53 160.20

150 881 871 855 1.14 11.53 172.60

Table @5.2 shows the same results but for the second run

where traffic is across IP and sensor networks. The sent requests

column is the total number of requests sent by the IP host. The

received requests column is the total number of requests received

by both sensor nodes. The received replies column expresses the

total number of replies received by the IP from both sensor nodes.

The packet loss is the percentage of the lost requests (ReqS –

ReqR) to the total requests originally sent by the IP host (ReqS).

The average delay is the average time (in milliseconds) the request


takes from the IP host to reach the sensor node. The total

throughput is the total number of received requests and replies

(ReqR + RepR) divided by the simulation time.

Table @@@@5.2: Direct access to sensor nodes in different request rates (traffic

across IP and sensor networks)

Re

qu

est

s

Ra

te p

er

Se

con

d

Se

nt

Re

qu

est

s

[Re

qS

]

Re

ceiv

ed

Re

qu

est

s

[Re

qR

] R

ece

ive

d R

ep

lie

s

[Re

pR

]

Pa

cke

t L

oss

(%

)

Av

era

ge

De

lay

(ms)

To

tal

Th

rou

gh

pu

t

(pa

cke

t/s)

10 93 93 93 0.00 11.40 18.60

30 262 262 262 0.00 10.87 52.40

50 404 403 401 0.25 11.15 80.40

70 525 523 520 0.38 11.52 104.30

90 633 625 614 1.26 11.71 123.90

110 726 714 700 1.65 11.71 141.40

130 808 792 770 1.98 11.80 156.20

150 885 864 834 2.37 11.74 169.80

The results of both runs are compared against each other to

show the overhead of the integration technique. The following

charts show the metrics of both runs. In these charts, the solid line

shows the results of WSN local traffic (the first run) while the

dashed line shows the results of IP-WSN traffic across the IP and

sensor networks (the second run).


In Figure @5.2, the average end-to-end delay is shown for

both runs. We can see that the delay of IP-WSN case is greater than

the local WSN case by a nearly constant value. This difference

includes the IP network delay plus the integration technique

latency to process and forward incoming packets. It is clear that the

overhead of the integration technique is almost constant even with

high data rates.

Figure @@@@5.2: Average delay versus requests rate - direct access to sensor nodes

In Figure @5.3, the packet loss percentage is shown for both

runs. Initially, the packet loss is almost the same for both runs in

common data rates (less than 70 request/second). In 70 requests

rate, the packet loss of local WSN traffic is greater than that of IP-

WSN traffic. This increase does not indicate that the integration

technique enhances the packets delivery, but it only results from

10.00

10.20

10.40

10.60

10.80

11.00

11.20

11.40

11.60

11.80

12.00

10 30 50 70 90 110 130 150

Av

era

ge

En

d-t

o-E

nd

De

lay

(m

s)

Number of requests per second

WSN Local Traffic IP-WSN Traffic


random failures in some packets in the first run. As shown in the

above tables for 70 requests rate, there are only 3 lost requests in

local WSN traffic over those happened in the IP-WSN traffic which

is a small difference in packet loss. In higher request rates, packet

loss of IP-WSN traffic becomes greater than that of local WSN

traffic. The difference in packet loss is in range of 1% - 2% which is

acceptable specially in WSN communication. However, it indicates

that the packet loss is increased in the integrated network. This

may be resultant from the single gateway node that cannot afford to

handle all requests which indicates to a bottleneck problem.

Figure @@@@5.3: Packet loss percentage versus request rate - direct access to

sensor nodes

In Figure @5.4, the total throughput of both runs is shown.

Both throughputs are almost the same even in high requests rates.

This is expected as both runs work in the same requests rates with

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

9.00

10.00

10 30 50 70 90 110 130 150

Pa

cke

t Lo

ss (

%)




the same network configuration of the gateway place and the

requested sensor nodes.

Figure @@@@5.4: The total throughput versus requests rate - direct access to sensor

nodes

Experiment 2: The effect of number of hosts

The second experiment tests the effect of the number of requesting

IP hosts on the integration technique performance. In this

experiment, a set of nodes are configured to query random sensor

nodes with constant data rate of 50 requests per second. This

experiment is run twice too; the first run operates in sensor

network only where sinks requests samples from other sensor

nodes. The second run works across IP and sensor networks. In this

case, a number of IP hosts are configured to query random sensor

nodes in WSN. The WSN size is 16 nodes. The number of

hosts/nodes range from 1 to 5. Experimental results are measured

0.00

20.00

40.00

60.00

80.00

100.00

120.00

140.00

160.00

180.00

200.00

10 30 50 70 90 110 130 150

Th

rou

gh

pu

t (p

ack

et/

s)




by the same metrics used in the previous experiment; average end-

to-end delay, total throughput, and packet delivery percentage.

Results of both runs are given in Table @5.3 and Table @5.4. Columns

definitions are the same as those used in the previous experiment

too.

Table @@@@5.3: Direct access to sensor nodes vs. number of requesting nodes

(sensor network only)

Nu

mb

er

of

req

ue

stin

g n

od

es

Se

nt

Re

qu

est

s

[Re

qS

]

Re

ceiv

ed

Re

qu

est

s

[Re

qR

] R

ece

ive

d R

ep

lie

s

[Re

pR

]

Pa

cke

t L

oss

(%

)

Av

era

ge

De

lay

(ms)

To

tal

Th

rou

gh

pu

t

(pa

cke

t/s)

1 404 404 404 0.00 10.74 80.80

2 813 788 752 3.08 11.85 154.00

3 1222 1132 1055 7.36 13.19 218.70

4 1632 1482 1331 9.19 14.43 281.30

5 2034 1766 1498 13.18 15.44 326.40

Table @@@@5.4: Direct access to sensor nodes vs. number of requesting hosts (IP

and sensor networks)

Nu

mb

er

of

req

ue

stin

g h

ost

s

Se

nt

Re

qu

est

s

[Re

qS

]

Re

ceiv

ed

Re

qu

est

s

[Re

qR

]

Re

ceiv

ed

Re

pli

es

[Re

pR

]

Pa

cke

t L

oss

(%

)

Av

era

ge

De

lay

(ms)

To

tal

Th

rou

gh

pu

t

(pa

cke

t/s)

1 404 404 403 0.00 11.10 80.70

2 813 805 783 0.98 11.75 158.80

3 1210 1175 1111 2.89 12.01 228.60

4 1629 1589 1450 2.46 12.59 303.90

5 2021 1958 1700 3.12 12.84 365.80


In Figure @5.5, the average delay of both runs is shown. It

surprisingly shows that the delay of local WSN traffic is higher than

that in IP-WSN traffic. We have a single explanation for this which is

that sinks in the first run request samples from multiple nodes

simultaneously which makes the medium busy with their packets.

As nodes use CSMA/CA MAC protocol, then they wait every time

they send a packet which delays transmitting the packet. On the

other hand, in IP-WSN case, the gateway is the only node that

requests samples on behalf of IP hosts. This makes the medium

somehow free than the first run and so allows the gateway to send

its packets faster. This network congestion becomes higher with the

increasing number of sending nodes, which increases the average

delay but it increases more in local WSN traffic for the reason we

mentioned.

Figure @@@@5.5: Average delay versus number of nodes - direct access to sensor

nodes

0.00

2.00

4.00

6.00

8.00

10.00

12.00

14.00

16.00

18.00

1 2 3 4 5

Av

era

ge

En

d-t

o-E

nd

De

lay

(m

s)

Number of requesting nodes



The packet loss of both runs is plotted in Figure @5.6.

Again, the packet loss of local WSN traffic is surprisingly higher

than that of IP-WSN traffic. It can be explained by the interference

happens among nodes when sinks send their requests in local WSN

case. Such interference increases the failure of packets reception at

sensor nodes. On the other hand, in IP-WSN traffic, the gateway is

the only requesting node in WSN which makes the interference

much less than that in the first run. This increases the chances for

the packets to reach their destination and so decreases the packet

loss in IP-WSN than that in local WSN traffic case.

Figure @@@@5.6: Packet loss percentage versus number of nodes - direct access to

sensor nodes

In Figure @5.7, the total throughput of both runs is compared.

The local WSN traffic throughput is decreased slightly in higher

number of nodes although both runs operate on the same request

0.00

5.00

10.00

15.00

20.00

25.00

30.00

35.00

40.00

45.00

50.00

1 2 3 4 5

Pa

cke

t Lo

ss R

ati

o (

%)




rate and the same number of nodes. It is expected according to the

higher packet loss happened in the first run.

Figure @@@@5.7: Total throughput versus the number of nodes - direct access to

sensor nodes

Based on the results of those experiments, we can conclude the

following:

• The integration technique supports accessing individual

sensor nodes from multiple hosts and even with different

request rates.

• The average delay and packet loss of the integration

technique is a linear function of number of hosts and their

request rates. This indicates that a single gateway node for

complete and scalable integration may not be sufficient and

propose investigation in supporting multiple gateways.

0.00

50.00

100.00

150.00

200.00

250.00

300.00

350.00

400.00

1 2 3 4 5

Th

rou

gh

pu

t (p

ack

et/

s)




• Requesting sample values by multiple hosts connected to

WSN through a single gateway gives a better performance

than requesting by multiple sensor nodes within WSN.

Performance here is meant by average delay and packet loss

ratio.

5.3 Evaluating Data Centric WSN

Experiment 1: The effect of network size

This experiment tests the effect of sensor network size on the

performance of the gateway in data-centric mode. The gird size of

sensor network ranges from 7x7 to 17x17 nodes (i.e. 49 – 289

nodes). Again, this experiment is run twice. In the first run, a sensor

node (i.e. sink) populates an interest matching the farthest node in

the network with a refreshment rate one second. The matching

node replies by their data messages with interval of 50

milliseconds. The interest expires at the end of the simulation. In

the second run, an IP host is configured to query WSN with the

same interest used in the first run. Also, the sink node acts as a

gateway node in this run to ensure the same network configuration

and settings of both runs. We tried initially to use 20, 10 and 5

interests to be used instead of a single interest. However, each

interest generates a large number of packets in the network

according to its recursive broadcasting to neighbors with periodical

refreshment which causes network congestion. For example, when

using 5 simultaneous interests in the sink, no interest delivery

achieved in even medium-sized networks (i.e. a 13x13 network).

Therefore, we chose to use a single interest in this experiment to

test large network sizes.


The experimental results are measured by average delay

and distinct event delivery ratio. Average delay measures the

average one-way latency observed between transmitting an event

from the source and receiving it at the sink. The distinct-event

delivery ratio is the ratio of the number of distinct events received

to the number originally sent. These metrics were used in @[24] to

evaluate the performance of directed diffusion. The results of both

runs are given in Table @5.5. The first two columns indicate the

network size. Next, the average delay for the first and second runs

is shown in the third and fourth columns respectively. Finally, the

distinct event delivery ratio for the first and second runs is given in

fifth and sixth columns respectively.

Table @@@@5.5: Experimental results for data-centric WSN in several network

sizes

Grid

Size

Number

of

Nodes

Average Delay

(seconds)

Distinct Event

Delivery Ratio (%)

Local

WSN IP-WSN Local WSN IP-WSN

7 49 0.14 0.14 84.31 82.35

9 81 0.18 0.18 78.43 78.43

11 121 0.23 0.23 70.59 72.55

13 169 0.27 0.27 66.67 66.67

15 225 0.31 0.33 70.59 68.63

17 289 0.35 0.36 54.90 49.02

Regarding the average delay, results are compared together

as shown in Figure @5.8. It can be inferred that the integration


technique does not add delay to the network even in large network

sizes. This result is expected according to transmitting a single

interest. However, the delay of integration technique will not be

comparable with sensor network delay even with multiple

interests. This is according to the limited processing made on each

interest in the gateway specially if compared with the delay of

sensor network.

Figure @@@@5.8: Average delay versus number of nodes - data centric WSN

The distinct delivery ratio of both runs is presented in

Figure @5.9. The ratio of both runs is almost the same in different

network sizes. At the largest network size, the delivery ratio is

decreased slightly in the IP-WSN run but it does not indicate it is

caused by the gateway because it happens accidently in a single

sample. Also, it is expected that the difference between delivery

ratios of both runs will take a similar pattern even with more

0

0.05

0.1

0.15

0.2

0.25

0.3

0.35

0.4

49 81 121 169 225 289

Av

era

ge

De

lay

(se

con

d)

Number of nodes

Local WSN Traffic IP-WSN Traffic


interests. This is inferred by the fact that this single interest is

already sent many times during the interest refreshment made by

the requesting node. Also, the matching nodes (i.e. sources) reply by

their data messages repeatedly every data interval. Therefore, the

given delivery ratio is based on multiple requests and replies which

simulate multiple interests but with less data reporting interval and

refreshment rate. Thus, we expect the same pattern with multiple

interests too but of course both graphs will decrease according to

more packets exchanged among nodes.

Figure @@@@5.9: Distinct event delivery ratio versus number of nodes - data

centric WSN

In conclusion, this experiment shows that the size of sensor

network does not affect the performance of integration technique

whether in average delay nor the distinct event delivery ratio.

0

10

20

30

40

50

60

70

80

90

49 81 121 169 225 289

Dis

tin

ct E

ve

nt

De

liv

ery

Ra

tio

(%

)

Number of nodes



Experiment 2: The effect of transmitting multiple interests

This experiment tests the effect of the number of interests sent to

the network on the performance of the gateway in data-centric

mode. The interests are targeting random different nodes scattered

over the network. The data reporting interval range from 50

milliseconds to 0.5 second. The refreshment rate of interests ranges

from 0.5 to 5 seconds. All interests expire at the end of the

simulation. The network size is 11x11 grid of sensor nodes (i.e. 121

nodes). Again, this experiment is run twice. In the first run, a

sensor node (i.e. sink) populates the interests to sources. In the

second run, multiple of IP hosts are configured to query WSN with

the same interests used in the first run. Also, the sink node used in

the first run acts as a gateway node in this run to ensure the same

network configuration and settings of both runs. Results of this

experiment are shown in Table @5.6. They are measured using the

same metrics used in the previous experiment.

Table @@@@5.6: Experimental results for data-centric WSN with multiple interests

Number

of

Interests

Average Delay (ms) Distinct Event Delivery

Ratio (%)

WSN only IP-WSN WSN only IP-WSN

4 62.39 61.72 79.76 73.17

8 82.79 91.47 47.19 44.00

12 135.19 152.71 13.47 16.62

16 139.36 134.36 11.56 11.11

20 159.55 230.14 4.74 3.82


Figure @@@@5.10: Average delay versus number of interests - data centric WSN

Regarding the interest average delay, results of both runs

are compared as shown in Figure @5.10. The delay of IP-WSN

communication is almost the same or slightly greater than local

WSN communication in cases up to 16 interests. In 20 interests’

case, the delay of IP-WSN communication is increased greatly. By

investigating the details of the experiments, it is found that there

are two interests which are successfully received in the second run

(IP-WSN) but with high delay. These two outliers increased the

average value so much. For this reason, we calculated the median

delay for both runs to reinforce our analysis. Figure @5.11 shows the

median delay of both runs. We can see that both graphs became

almost the same with minor differences using the median delay

instead of the average.

0.00

50.00

100.00

150.00

200.00

250.00

4 8 12 16 20

Av

era

ge

De

lay

(m

s)

Number of interests



Figure @@@@5.11: Median delay versus number of interests - data centric WSN

Figure @@@@5.12: Distinct event delivery ratio versus number of interests - data

centric WSN

0

20

40

60

80

100

120

140

160

180

200

4 8 12 16 20

Me

dia

n D

ela

y (

ms)

Number of interests


0.00

10.00

20.00

30.00

40.00

50.00

60.00

70.00

80.00

90.00

4 8 12 16 20

Dis

tin

ct-E

ve

nt

De

liv

ery

Ra

tio

(%

)

Number of interests



Regarding the distinct event delivery ratio, results of both

runs are shown in Figure @5.12. It is clear that the delivery ratio is

decreasing radically with increasing number of interests. This

happens due to the huge number of data reporting and interest

refreshment packets exchanged continuously among nodes. Also, it

is clear that the delivery ratio of IP-WSN traffic is almost the same

as the WSN-only traffic. This indicates that the integration does not

affect the delivery ratio even with large number of interests.

Based on the results of the previous experiments, we can conclude

the following:

• The integration technique supports accessing data centric

WSNs by allowing IP hosts to send interests to WSN and

receiving data messages from it.

• The integration technique does not the affect the

performance of the data-centric WSN if it is integrated with

an IP network. Reviewing previous results proposes that the

performance of the integrated network is almost the same

of the data-centric WSN with minor differences.

Performance here is measured in terms of average delay

and distinct event delivery ratio.

In summary, this chapter evaluates the proposed

integration technique. First, the evaluation methodology is

presented showing the simulation environment. Second, the

experiments for evaluating direct access to sensor nodes are

explained with its results and conclusion. Finally, the experiments

for evaluating the data-centric WSN are shown with its results too.

Conclusion and Future Work 131

6 Conclusion and Future Work

6.1 Conclusion

Wireless Sensor Network (WSN) envisions ubiquitous computing

future in many fields, such as environmental monitoring, military

surveillance, and inventory tracking. These applications need - in

many cases - to interconnect with IP networks. The fact that the

WSN has its own application-specific non-standardized protocols

presents a significant challenge to establish such interconnection.

In this thesis, a gateway-based technique is presented for

WSN-IP network interconnection. This technique allows access to

individual sensor nodes and enables network-based query for data-

centric WSN. It also provides transparent access from one network

to the other without modifying protocols running in either network.

This work concludes the following:

• The integration approaches are mainly categorized into two

approaches: gateway-based and network overlay. There are

several implementations for each approach that are

surveyed and evaluated in this thesis.

• An integration technique is proposed that exploits the

desirable features of both approaches. These features are:

o Decoupling both networks. Thus, specialized

communication protocols are allowed to be

implemented in WSN to fit the application

requirements and constraints.

o No modification or overlay is required in the

protocol stacks of either network.


o Support direct accessibility to individual sensor

nodes for address-centric WSNs.

o Support querying networks or unknown nodes in

data-centric WSNs

o Support multiple applications to run in WSN

without change in the gateway logic.

o Consistency with Next Generation Network (NGN)

as it uses IP addresses to communicate with sensor

nodes or with data-centric WSN

• The proposed integration technique is implemented and

evaluated. Its evaluation shows that it does not add

significant overhead on the delay, the packet delivery ratio

or the network throughput.

• The proposed integration technique depends on a single

gateway node in interconnection. This node is considered to

be a bottleneck and prevents the interconnection to scale to

large networks or heavy traffic.

• Also, the gateway node is a single point failure which

prevents any inter-communication if it is failed.

6.2 Future Work

Based on the conclusion given in the previous section, we propose

some points for future work as shown next.

• Support multiple gateways for integration to eliminate

bottleneck and single point of failure problems. This issue

will provide scalability for the integration which allows

more nodes and hosts to communicate together

• Investigate the applicability of the integration technique

with TCP protocol. It is desirable to support several


application types which are based on TCP rather than UDP.

Such investigation should propose how to filter non-data

packets to WSN along with handle connection

establishment with virtual IP addresses.

• Evaluate the integration technique on real hardware and

compare its performance with that of commercial gateways.

This is crucial to increase the evidence in the results shown

in this thesis which is based on simulation only.

• Compare the integration technique with 6LoWPAN on real

hardware. The 6LoWPAN is a prospective standard

communication protocol for sensor networks that supports

inherited integration with IP networks.

• Investigate the applicability of the integration technique in

other network configuration such as mobile networks and

heterogeneous networks.

Appendix I: OMNeT++ Simulator 135

Appendix I: OMNeT++ Simulator

I.1 Compiling OMNeT++ 3.3

OMNeT++ 3.3 allows users to download precompiled version of its

libraries to use predefined modules. However, it is required to have

the OMNeT++ source code and compile it to be able to add our

customized and new modules. There is a compilation manual with

the OMNeT++ but we found some difficulty according to missing

some important steps to successfully compile it. Next, the

compilation steps on Windows XP and using Visual Studio 2005 are

shown.

Prerequisites for compilation

• Install Visual Studio C++ 2005

• Download OMNetpp3.3 and copy it into C:\omnetpp-3.3 (for

example)

• Download Tcl (ActiveTcl) and Perl (ActivePerl) and install

them in C:\Tcl and let the ActivePerl to add perl installation

path into PATH environment variable. You can download

them from http://www.activestate.com

• Download BLT and install it into TCL path (c:\tcl). The BLT

Toolkit is an extension to Tcl and Tk. It adds new commands

and widgets to the Tcl interpreter. Included widgets are 2D

graph, barchart, stripchart, tab not

• Download LibXML and put it in a (new) directory

C:/omnetpp-3.3/util/ and

ICONV from and put it in a (new) directory C:/omnetpp-


3.3/util/. You can download them from

http://www.zlatkovic.com

• Copy libxml directory from C:/omnetpp-3.3/util/libxml2-

2.6.30.win32\include to C:\omnetpp-3.3\src\nedxml

• Modify C:\omnetpp-3.3\configuser.vc file as follows:

1. OMNETPP_ROOT=C:/omnetpp-3.3

2. TK_DIR=C:/Tcl

3. ICONV_DIR=C:/omnetpp-3.3/util/iconv-

1.9.2.win32

4. LIBXML_DIR=C:/omnetpp-3.3/util/libxml2-

2.6.30.win32

5. (optional) Comment the flags of release and

Uncomment the flags of debug configurations (if you

want enabling debugging your code)

#CFLAGS=$(CFLAGS_RELEASE)

#LDFLAGS=$(LDFLAGS_RELEASE)

CFLAGS=$(CFLAGS_DEBUG)

LDFLAGS=$(LDFLAGS_DEBUG)

6. Add /MDd or MTd flags for CFlags to enable linking in

C++ 2005, as the following:

!if "$(LIB_SUFFIX)"==".dll"

CFLAGS_DEBUG=$(CFLAGS_DEBUG) /MDd

CFLAGS_RELEASE=$(CFLAGS_RELEASE) /MD

!else

CFLAGS_DEBUG=$(CFLAGS_DEBUG) /MTd

CFLAGS_RELEASE=$(CFLAGS_RELEASE) /MT

!endif


Compiling OMNeT++ 3.3

1. Open Cmd prompt and change directory to C:/omnetpp-3.3

2. Run C:\Program Files\Microsoft Visual Studio

8\Common7\Tools\vsvars32.bat

3. Type @set path=C:\omnetpp-3.3\bin;%path%

4. Type nmake -f Makefile.vc. It should compile and

link OMNeT

I.2 Compiling INET Framework

INET framework is a framework that contains all common TCP/IP

protocols. We worked with INET20061020 which was the latest

version in that time. The compilation was straight forward as

specified in the manual. Next, the steps for compiling INET

framework are shown next.

1. You should have a working install of OMNeT++ 3.3

2. Open cmd prompt

3. Type SET PATH=%PATH%;C:\omnetpp-3.3\bin;

4. Type makemake

5. Modify make.bat as follows:

call "C:\Program Files\Microsoft Visual

Studio 8\VC\vcvarsall.bat"

cd %~dp0

if not exist Makefile.vc call makemake.cmd

pause

nmake -f Makefile.vc %*

6. Save make.bat and run it


I.3 Porting and Compiling Castalia 2.1

Castalia framework is not supported on Windows by default.

However, there is a perl script that converts it to be windows

portable. This script can be downloaded from the Castalia mailing

group. However, this script is for version 1.3 not 2.1. So the

following modifications should be made first.

SensorDevMgrModule.cc

Add the following lines:

#include <math.h>

#define lrint(x) (floor(x+((x>0) ? 0.5 : -0.5)))

WirelessChannel.cc

1. Add definition of function double erf(double x);

and double erfc(double x); as specified in perl

script

2. In lines 278-280, cast parameter of floor function into

double

3. In lines 379, 380, 384, 385, 869, 1176 and 1178, cast

parameters of pow function into double

4. In parsefloat function (line 1231), replace strtof

function as follows

int ret = sscanf_s(c,"%f", dst);

if (ret == 1) return 1;

WirelessChannelTemporal.cc

1. Add macro #define lround(x) floor(x+0.5)

2. Replace lines 177 and 178 by


float result;

int res = sscanf_s(str, "%f", &result);

if (res == 1) { return result; }

}

Castalia Build Steps:

1. Copy convert_make2nmake.pl Eile in Castalia root.

2. Open previous perl file and add use Cwd; under use

File:Find; and replace `pwd` by getcwd(). Also, find a

line $config{"env"}= "TkEnv"; modify it to

be $config{"env"}="Tkenv"; (yes, just replace capital

E by small e. This in case you want to build simulator with

GUI support)

3. Change the ROOT variable in \config\castalia.config to be

ROOT=C:/omnetpp-3.3/Castalia-2.1

4. Open cmd prompt

5. Type SET PATH=%PATH%;E:\Master\omnetpp-

3.3\bin;

6. cd C:\omnetpp-3.3\Castalia-2.1

7. Type "C:\Program Files\Microsoft Visual Studio

8\VC\vcvarsall.bat" to VS 2005 variables

8. Type perl convert_make2nmake.pl

Porting Castalia into INET

To include Castalia modules into INET, follow these steps:

1- Copy all *.cc, *.h, *.msg and *.ned files in Castalia folders into

a folder under INET folder named say INETCastalia.

2- Modify the INET makemake file to include INETCastalia

folder as follows:


a. Add this line: ALL_CASTALIA_INCLUDES =-

I$(ROOT)/ INETCastalia just before

ALL_INET_INCLUDES=... line

b. Add "$(ALL_CASTALIA_INCLUDES)" without quotes

at the end of line starts with cd bin &&

$(MAKEMAKE) $(OPTS) ...

c. Add this line: cd INETCastalia && $(MAKEMAKE)

$(OPTS) -n -r $(ALL_CASTALIA_INCLUDES)

before line starts with cd Applications && $...

3- Now you are ready to compile INET with Castalia. You can

do as normally as discussed in the previous section.

To test it works properly, make a joint simulation that uses both

framework. First make a folder for the simulation. Then copy

omnetpp.ini file from valuePropagation folder and make the

following modifications to it (see comments for full version of

omnetpp.ini file):

1- In general section, make preload-ned-files = *.ned

@../../omnetpp-3.3/INET-

20061020/nedfiles.lst

2- Add debug-on-errors = true

3- Copy all parameters from INET omnetpp.ini file and paste it

in the new omnetpp.ini

4- Next, copy Sensornetwork.ned file from Castalia\src

directory to the simulation directory. It will be the

simulation ned file.

5- Add import and submodules sections defined in ned file of

INET example to the sensornetwork.ned file.


6- At last, copy info1.irt and info2.irt Eiles from INET example

as they are needed in INET modules. Then you can run

simulation normally like INET simulations.

I.4 Introduction to OMNeT++

This section gives a brief introduction for how to develop a simple

simulation using OMNeT++. It introduces basic information to

create a new simulation network from scratch. It also gives a

background for main components in OMNeT++ such as ned

language and message files. This simulation is a simple tictoc

simulation in which 2 nodes send a message to each other inEinitely.

For a start, let us begin with a "network" that consists of two nodes.

The nodes will do something simple: one the nodes will create a

packet, and the two nodes will keep passing the same packet back

and forth. We'll call the nodes "tic" and "toc".

Here are the steps you take to implement your first simulation from

scratch. First, create a working directory called tictoc, and cd to this

directory.

1. Write Topology File ned file

Describe your example network by creating a topology file. A

topology file is a text file that identifies the network's nodes and the

links between them. You can create it with your favorite text editor.

Let's call it tictoc1.ned:

simple Txc1 gates: in: in; out: out; endsimple


module Tictoc1 submodules: tic: Txc1; toc: Txc1; connections: tic.out --> delay 100ms --> toc.in; tic.in <-- delay 100ms <-- toc.out; endmodule network tictoc1 : Tictoc1 endnetwork

The file is best read from the bottom up. Here's what it says:

a) We deEine a network called tictoc1, which is an instance the

module type Tictoc1 (network..endnetwork);

b) Tictoc1 is a compound module, which is assembled from two

submodules, tic and toc. tic and toc are instances of the same

module type called Txc1. We connect tic's output gate

(named out) to toc's input gate (named in), and vica versa

(module..endmodule). There will be a 100ms propagation

delay both ways;

c) Txc1 is a simple module type (which means it is atomic on

NED level, and will be implemented in C++). Txc1 has one

input gate named in, and one output gate named out

(simple..endsimple).

2. Implement the simulation functionality

We now need to implement the functionality of the simple module

Txc1. This is achieved by writing a C++ Eile txc1.cc:

#include <string.h> #include <omnetpp.h> class Txc1 : public cSimpleModule


{ protected: // The following redefined virtual function holds the algorithm. virtual void initialize(); virtual void handleMessage(cMessage *msg); }; // The module class needs to be registered with OMNeT++ Define_Module(Txc1); void Txc1::initialize() { // Initialize is called at the beginning of the simulation. // To bootstrap the tic-toc-tic-toc process, one of the modules needs // to send the first message. Let this be `tic'. // Am I Tic or Toc? if (strcmp("tic", name()) == 0) { // create and send first message on gate "out". "tictocMsg" is an // arbitrary string which will be the name of the message object. cMessage *msg = new cMessage("tictocMsg"); send(msg, "out"); } } void Txc1::handleMessage(cMessage *msg) { // The handleMessage() method is called whenever a message arrives // at the module. Here, we just send it to the other module, through // gate òut'. Because both `tic' and `toc' does the same, the message // will bounce between the two. send(msg, "out"); }


The Txc1 simple module type is represented by the C++ class Txc1,

which has to be subclassed from cSimpleModule, and registered in

OMNeT++ with the Define_Module() macro. We redefine two

methods from cSimpleModule: initialize() and handleMessage().

They are invoked from the simulation kernel: the first one only

once, and the second one whenever a message arrives at the

module.

In initialize() we create a message object (cMessage), and send it

out on gate out. Since this gate is connected to the other module's

input gate, the simulation kernel will deliver this message to the

other module in the argument to handleMessage() -- after a 100ms

propagation delay assigned to the link in the NED file. The other

module just sends it back (another 100ms delay), so it will result in

a continuous ping-pong.

Messages (packets, frames, jobs, etc) and events (timers, timeouts)

are all represented by cMessage objects (or its subclasses) in

OMNeT++. After you send or schedule them, they will be held by the

simulation kernel in the "scheduled events" or "future events" list

until their time comes and they are delivered to the modules via

handleMessage().

Note that there is no stopping condition built into this simulation: it

would continue forever. You will be able to stop it from the GUI.

(You could also specify a simulation time limit or CPU time limit in

the configuration file, but we don't do that in the tutorial.)


3. Compile Simulation

We now create the Makefile which will help us to compile and link

our program to create the executable tictoc: opp_nmakemake

This command should have now created a Makefile in the working

directory tictoc.

Let's now compile and link our very first simulation by issuing the

make command: nmake -f Makefile.vc.

4. Run Simulation

If you start the executable now, it will complain that it cannot find

the file omnetpp.ini, so you have to create one. omnetpp.ini tells the

simulation program which network you want to simulate (yes,

several networks can live in the same simulation program), you can

pass parameters to the model, explicitly specify seeds for the

random number generators etc.

Create the following very simple omnetpp.ini:

[General] network = tictoc1

Press the Run button on the toolbar to start the simulation. What

you should see is that tic and toc are exchanging messages with

each other.

The main window toolbar displays the simulated time. This is

virtual time, it has nothing to do with the actual (or wall-clock) time

that the program takes to execute. Actually, how many seconds you

can simulate in one real-world second depends highly on the speed

of your hardware and even more on the nature and complexity of

the simulation model itself. Note that it takes zero simulation time

for a node to process the message. The only thing that makes the


simulation time pass in this model is the propagation delay on the

connections.

You can work with slowing down the animation or making it faster

with the slider at the top of the graphics window. You can stop the

simulation by hitting F8 (equivalent to the STOP button on the

toolbar), single-step through it (F4), run it with (F5) or without

(F6) animation. F7 (express mode) completely turns off tracing

features for maximum speed. Note the event/sec and simsec/sec

gauges on the status bar of the main window. You can exit the

simulation program by clicking its Close icon or choosing File|Exit.

For the details of the complete example, check the OMNeT++

manual.

References 147

References

[1] H. Karl and A. Willig, Protocols and architectures for wireless

sensor networks, 1st ed. Wiley, June 2005.

[2] M. Ilyas and I. Mahgoub, Handbook of Sensor Networks:

Compact Wireless and Wired Sensing Systems. CRC, July

2004.

[3] Martin Haenggi, “Opportunities and Challenges in Wireless

Sensor Networks”, in Handbook of Sensor Networks Compact

Wireless and Wired Sensing Systems, CRC Press, 2005.

[4] W. Su, E. Cayirci, and O. B. Akan, “Overview of Communication

Protocols for Sensor Networks”, in Handbook of Sensor

Networks Compact Wireless and Wired Sensing Systems, CRC

Press, 2005.

[5] Azzedine Boukerche, Eduardo F. Nakamura, and Antonio A. F.

Loureiro, “Algorithms for Wireless Sensor Networks: Present

and Future”, in Algorithms and Protocols for Wireless Sensor

Networks, Wiley-IEEE Press, 2009.

[6] M. Tubaishat and S. Madria, "Sensor networks: an

overview," Potentials, IEEE, vol. 22, no. 2, pp. 20-23, 2003.

[7] I. F. Akyildiz, W. Su, Y. Sankarasubramaniam, and E. Cayirci,

"Wireless sensor networks: a survey" Computer Networks,

IEEE, vol. 38, pp. 393-422, 2002

[8] A. Dunkels, T. Voigt, and J. Alonso. “Making TCP/IP Viable for

Wireless Sensor Networks”. In Proceedings of the First

European Workshop on Wireless Sensor Networks (EWSN

2004), work-in-progress session, Berlin, Germany, Jan. 2004.

[9] A. Dunkels, T. Voigt, J. Alonso, H. Ritter, and J. Schiller.

“Connecting Wireless Sensornets with TCP/IP Networks”. In

References 148

Proceedings of the Second International Conference on

Wired/Wireless Internet Communications (WWIC2004),

Frankfurt (Oder), Germany, February 2004.

[10] K. Fall, “A Delay-Tolerant Network Architecture for

Challenged Internets”, SIGCOM, Karlsruhe, Germany, August

2003

[11] Forrest Warthman, “Delay-Tolerant Networks (DTNs), A

Tutorial”. Delay-Tolerant Network Architecture, DTN

Research Group Internet Draft, March 2003.

[12] J. W. Hui and D. E. Culler, "IP is dead, long live IP for wireless

sensor networks," in SenSys '08: Proceedings of the 6th ACM

conference on Embedded network sensor systems. New York,

NY, USA: ACM, 2008, pp. 15-28

[13] A. Dunkels. “Full TCP/IP for 8-bit architectures”. In

Proceedings of The First International Conference on Mobile

Systems, Applications, and Services (MOBISYS `03), San

Francisco, California, May 2003.

[14] Adam Dunkels, “Towards TCP/IP for WSN”, Master's Thesis,

Malardalen University, March 2005

[15] Guangjie Han; Maode Ma, “Connecting sensor networks with

IP using a Configurable tiny TCP/IP protocol stack”.

Information, Communications & Signal Processing, Dec. 2007

[16] Min Zhang, Sangheon Pack, Kideok Cho, Dukhyun Chang,

Yanghee Choi, and Taekyoung Kwon, "An Extensible

Interworking Architecture (EIA) for Wireless Sensor

Networks and Internet," in Proc. Asia-Pacific Network

Operations and Management Symposium (APNOMS) 2006

Poster Sessions, Busan, Korea, September 2006

References 149

[17] H. Dai and R. Han, “Unifying Micro Sensor Networks with the

Internet via Overlay Networking,” in Proc. IEEE Emnets-I, Nov.

2004.

[18] L. Shu, J. Cho, L. Zhang, and M. Hauswirth, “VIP Bridge:

Leading Ubiquitous Sensor Networks to the Next Generation”,

Journal of Internet Technology (JIT), July 15, 2007

[19] Z. Z. Marco, K. Bhaskar, “Integrating Future Large-scale

Wireless Sensor Networks with the Internet”, USC Computer

Science Technical Report CS 03-792, 2003.

[20] Mohanty, Pradeep K., “A FRAMEWORK FOR

INTERCONNECTING WIRELESS SENSOR AND IP

NETWORKS”, Personal, Indoor and Mobile Radio

Communications, 2007. PIMRC 2007. IEEE 18th International

Symposium.

[21] N. Kushalnagar, G. Montenegro, C. Schumacher, "IPv6 over

Low-Power Wireless Personal Area Networks (6LoWPANs):

Overview, Assumptions, Problem Statement, and Goals",

RFC4919, August 2007

[22] G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler,

"Transmission of IPv6 Packets over IEEE 802.15.4 Networks",

RFC4944, Sept 2007

[23] Alan Mainwaring, Joseph Polastre, Robert Szewczyk, David

Culler, John Anderson, “Wireless Sensor Networks for Habitat

Monitoring,” In the 2002 ACM International Workshop on

Wireless Sensor Networks and Applications. WSNA ’02, Atlanta

GA, September 28, 2002.

[24] C. Intanagonwiwat, R. Govindan and D. Estrin, “Directed

Diffusion: A Scalable and Robust Communication Paradigm

for Sensor Networks,” ACM/IEEE International Conference on

References 150

Mobile Computing and Networks (MobiCom 2000), August

2000, Boston, Massachusetts

[25] W. Heinzelman, J. Kulik, and H. Balakrishnan, “Adaptive

protocols for information dissemination in wireless sensor

networks,” in the Proceedings of the 5th Annual ACM/IEEE

International Conference on Mobile Computing and networking

(MobiCom’99), Seattle, WA, August 1999.

[26] J. N. Al-Karaki and A. E. Kamal, "Routing techniques in

wireless sensor networks: a survey," IEEE Wireless

Communications, vol. 11, no. 6, pp. 6-28, 2004

[27] K. Akkaya and M. Younis, "A survey on routing protocols for

wireless sensor networks," Ad Hoc Networks, vol. 3, no. 3, pp.

325-349, May 2005.

[28] David Curren, "A Survey of Simulation in Sensor Networks",

Technical Report, Department of Computer Science,

University of Binghamton, 2007

[29] Johannes Lessmann, Peter Janacik, Lazar Lachev, Dalimir

Orfanus, "Comparative Study of Wireless Network

Simulators," ICN, pp.517-523, Seventh International

Conference on Networking (ICN 2008), 2008

[30] Philip Levis, Nelson Lee, Matt Welsh, and David Culler.

“TOSSIM: Accurate and Scalable Simulation of Entire TinyOS

Applications”. in Proceedings of SenSys’03, First ACM

Conference on Embedded Networked Sensor Systems, 2003.

[31] Xiang Zeng, Rajive Bagrodia, Mario Gerla. "GloMoSim: A

Library for Parallel Simulation of Large-scale Wireless

Networks" Workshop on Parallel and Distributed Simulation,

1998.

References 151

[32] Athanassios Boulis, “Castalia User Manual”, Version 2.1,

NICTA, July 2009

[33] The Network Simulator – NS-2.

http://www.isi.edu/nsnam/ns.

[34] The OMNeT++ Simulator. http://www.omnetpp.org/

[35] The Castalia Simulator. http://castalia.npc.nicta.com.au/

@ @@ @@ @@ @

QQQQ@ @@ @@ @@ @

˜ƒÜß@òÛb�‹Ûa

Û@ õbàÜÈÛa@ ÉÓìníòîØÜ�ýÛa@ ŠbÈ“n�üa@ pbØj“@ýjÔn�ß@‹èjß@ apübª@ À@

‡–‹Ûa@Ýrß@Lñ‡Ç@æŒbƒ¾a@Éjnmë@òí‹Ø�ÈÛa@òjÓa‹¾aë@ï÷îjÛa@Në@pbØj“Ûa@ê‰ç@á›m

c@ñ�j×@a†a‡ÇI‡Ó@@Ý—mgŁa@¶ÒüH@@åß@ñ�èucŠbÈ“n�üa@òÔîÓ‡Ûa@@ñ�èudi@ñ†ë�¾a

ìí†a‹Ûa@Þb—mýÛ@ïØÜ�ýÛa@ëÕîÓ†@�bÈß@pbîãbØßüa@Éšaìnß@¶g@kãbu@òíŠbĐi@

ç†ë�m@ñ�Ì–b@òÓbĐÛa@åß@óÐØí@b·N@ÙÛ‰ië@óä�ní@ê‰�@þa@ñ�èuåíìØm@@pbØj’

ŠbÈ“n�a@îØîmbßìmëcb@�Ûaë@åß@b�ý‚@ŽíåØà@pbßìÜÈ¾a@Éîà¤@åß@ê‰ç@þa@ñ�èu

¶g@æŒb¬@pbßìÜÈ¾a@ Na‰ç@åßë@áçc@˜öb—‚@pbØj’@bèãc@ ŠbÈ“n�üa@Žm@ ‹räÀ@

òÔĐäß@ÝàÈÛa@òÔí‹Đi@Lòîöaì“Ç@üë@xbn¥@¶g@pa†a‡Çg@òíë‡í@ Na‰�ë@�@áîà—m@

Û@pbØj“Ûa@ÙÜnÛ@ò–b©a@püì×ìmë�Ûa@åß@òÇìàªnk�bän@@Éß˜öb—©a@ê‰ç@

ñ†ë‡�aN@ @

‡äÇë@‹ÄäÛa@¶g@a‰ç@pbÔîjĐm@ÊìäÛa@åß@pbØj“Ûa@‡−@æc@åß@ ‡í‡ÈÛa@@ê‰ç

@ pbÔîjĐnÛai@ Ý—ní@ æc@ k°pbØj“Ûb@[òî�îö‹Ûa@sîy@@ k°c@òĐjm‹ß@ æìØm@ æ

ñ�èudi@pbØj“Ûa@Þý‚@åß@áØznÛaë@ òjÓa‹¾a@òîØÜ�Ûa@ëc@òîØÜ�ýÛa@@òÏë‹È¾a

�Ûa@ pbØj“Ûa@ Ýrß@ÝàÈm@@ Þì×ìmë�ioã�ãüaN@æg@@ŠbÈ“n�üa@ pbØj’@ wß†

îØÜ�ýÛaò@Éß@pbØj“Ûa@òÜßbÈÛa@@bía�¾a@ åß@ ‡í‡ÈÛa@ ÕÔ±@ oã�ã⁄a@ Þì×ìmë�i

Žíë‡í�@åß@ŠbÈ“n�üa@pbØj’@‡öaìÏ@éuëc@ñ‡Ç@óÏ@ÝrßZ@ @

� @òîãbØßgë@òjÓa‹¾aÛaáØzn@À@‡Èi@åÇ@ŠbÈ“n�üa@pbØj’@ @

� wß†@óÜÇ@ñŠ‡ÔÛa@pbßìÜÈ¾a@òÈà�a@åß@pbØj’@ŠbÈ“n�üa@À@pbÇ†ìn�ß@

bîÛby@ñ†ìuì¾a@pbãbîjÛa@N

� @ ñ‡Ç@ wß†@ òîãbØßg@ pbØj’@òØj’@ À@ bè›Èi@ åÇ@ ñ‡îÈi@ ŠbÈ“n�a

òîša�Ïa@ñ‡yaë@ŠbÈ“n�aN

@ @@ @@ @@ @

RRRR@ @@ @@ @@ @

@ @a‹‚ûß@ wèã@ ‡Óë@ÝîÜÓ@åß@µrybjÛa@ñ‡Ç@Ö‹�@@ ê‰ç@ xýÈÛòÛd�¾a@@óÏ@ á�Ôäm

Þb—müa@pbiaìi@óÜÇ@‡ànÈí@Þëþa@[µ�îöŠ@µvèäß@¶g@‘b�þa@@ÝÔã@ bèäØº@�Ûa

pbßìÜÈ¾a@ŠbÈ“n�üa@òØj’@åß@¶g@pbØj“Ûa@@ô‹‚þa÷ØÈÛaëN@@‹‚Ła@wèäÛa@bßc

@ â‡ƒn�íÛaüì×ìmë�@òØj“Ûa@ pý×ìmë‹i@ ÖìÏ@ µnØj“Ûa@ ô‡yhi@ ò–b©a@ p

@åØº@áq@åßë@µnØj“Ûa@µi@óÓým@òÔĐäß@|j—m@a‰èië@ñ�èuþa@�Èi@óÏ@ô‹‚þa

pbãbîjÛa@Þ†bjm@ @

À@ê‰ç@òÛb�‹ÛaL@�@�a�Óa@òÔí‹�@wß‡ÜÛ@áÇ‡m@pbØj’@ŠbÈ“n�üa@paˆ@

åíëbäÈÛa@ë@pbØj“Ûa@òíŠì«@pbãbîjÛa@óÜÇ@‡y@õaì�@Nëmâ‡ƒn�@ê‰ç@òÔí‹ĐÛa@òiaìi@

ÝàÈm@óÏ@ôìn�ß@�Ðƒäß@ò»�Û@pbãbîjÛa@òÜ�‹¾a@åß@òØj’@¶g@ô‹‚c@NïÛbnÛbië@L@

éãhÏ@|à�í@Šbîn‚a püì×ìmë‹i@Þb—müa@óÏ@pbØj’@ŠbÈ“n�üa@òí‹¢@sî¢@

nmk�bä@Éß@˜öb—‚@ÛaÔîjĐnpb@†a‹¾a@bèßa‡ƒn�a@NñëýÇë@óÜÇ@LÙÛˆ@èãhÏb@m‡ànÈ@

óÜÇ@ò�b�i@òîÜàÇ@Ûaò»�@üë@xbn¥@¶g@Ýí‡Èm@À@püì×ìmë‹i@Þb—müa@À@

Øj“Ûaµn@NLÙÛ‰Ûë@éãhÏ@åØº@bèßa‡ƒn�a@óÏ@pbÔîjĐm@ñ‡í‡Ç@æë†@òubä@¶g@

Ýí‡Èm@òÔí‹�@ÝàÇ@òiaìjÛa. bà×@æg@‰çê@òÔí‹ĐÛa@|à�m@Þb—müa@iòîÏbÐ“@µi@

µnØj“Ûa@sîy@m|în@Ái‹Ûa@bàèäîi@æë†@òubä@òÏ‹È¾@Ýî–bÐm@püì×ìmë�Ûa@

ò–b©a@ikãb§b@‹‚ŁaN@ @

ë@‡ÔÛ�@ÕîjĐm@ê‰ç@òÔí‹ĐÛa@óÜÇ@wßbã‹i@ñb×b�a OMNeT++ ýØÛ@åß@

pbØj’@ŠbÈ“n�üa@paˆ@åíëbäÈÛa@ë@pbØj“Ûa@òíŠì«@pbãbîjÛa@ N‡Óë@cp‹èÃ@

wöbnäÛa@cæ@ê‰ç@òÔí‹ĐÛa@pü‡È·@ ŠbÈ“n�þa@ ñ�èuc@¶g@ Þì–ìÛa@ |înm@kÜ�@@òîÛbÇ

òØj“Ûa@õa†c@óÜÇ@bÃìzÜß@a�qdm@‹qûm@æc@æë†@N@âìÔm@bß‡äÇ@LÞbr¾a@Ýîj�@óÜÈÏc@‡y

@oã�ãüa@ñ�èuc@¶g@Ý—í@Þ‡È·@ŠbÈ“n�üa@ñ�èuc@¶g@pbjÜ�@Þb�ŠhiQUP@@óÏ@kÜ�

@†ë‡y@óÏ@Àbšþa@�‚dnÛa@Á�ìnß@æìØí@òîãbrÛaPLRU@@Þ‡Èß@óÏ@ñ†bíŒë@òîãbq@óÜß

@ @@ @@ @@ @

SSSS@ @@ @@ @@ @

@òj�äi@pbãbîjÛa@‡ÔÏPLU@E@ÁÔÏÁ�ìn¾a@óÏ@N@wß‡Ûa@òÔí‹�@|înm@Lô‹‚c@òîybã@åßë

@Òýn‚a@ óÜÇ@ pbãbîjÛa@ òíŠì«@ ŠbÈ“n�üa@ pbØj’@ ¶g@ Þì–ìÛa@ åß@ òy�Ô¾a

@ bèßbvycòäßa�n¾a@ püúb�nÛa@ †‡Èmë@ Nbß‡äÇ@ LÞbr¾a@ Ýîj�@ óÜÈÏ@@ñ�èuc@ ‡yc@ âìÔm

@ óny@ Þb�Šhi@ oã�ãüaRP@�üa@ òØj’@ ¶g@ üúb�m@�‚dnÛa@ Á�ëc@ æìØí@ ŠbÈ“n

@†ë‡y@óÏ@ÀbšþaT~S@@òj�äi@|ubäÛa@Ýî–ìnÛa@Þ‡Èß@óÏ@æb—Ôã@Éß@òîãbq@óÜßV~U@@E

‹r×þa@óÜÇ@ NÉßë@LÙÛˆ@æhÏ@òiaìjÛa@@ ê‰ç@wß‡Ûa@ òÔí‹�@óÏ@òß‡ƒn�¾a�nÈm@òĐÔã@

Öbän‚a@Þb—mýÛ@ëïÌjäí@æc@szjŽm@ýjÔn�ß@áÇ‡Û@ÝîÌ“m@@óÏ@Þb—mýÛ@pbiaìi@ñ‡Ç

@‡yaë@æeòÜØ“¾a@ê‰ç@óÜÇ@kÜÌnÜÛN

@ @

@ @@ @@ @@ @

á�Ó@âìÜÇ@k�bä@@ @îÜ×�ò@�bä�jpb@ë@ÜÈ¾a�ßì�pb@ @

Èßbu�ò@µÇ@÷�

îØÜ�ýÛa@ŠbÈ“n�üa@pbØj’@wß†îØÜ�ýÛa@ŠbÈ“n�üa@pbØj’@wß†îØÜ�ýÛa@ŠbÈ“n�üa@pbØj’@wß†îØÜ�ýÛa@ŠbÈ“n�üa@pbØj’@wß†òòòò@@@@ÉßÉßÉßÉß@@@@pbØj“ÛapbØj“ÛapbØj“ÛapbØj“Ûa@@@@òÜßbÈÛaòÜßbÈÛaòÜßbÈÛaòÜßbÈÛa@@@@@Þì×ìmë�i@Þì×ìmë�i@Þì×ìmë�i@Þì×ìmë�ioã�ãüaoã�ãüaoã�ãüaoã�ãüa

éÛb�Š@éß‡Ôß@õbÐîn�ü@Þì—ä@óÜÇ@òuŠ†@�n�ub¾a@óÏ@pbj�bä@ë@pbßìÜÈ¾a@ @

†a‡Çg†a‡Çg†a‡Çg†a‡Çg

ñŠbàÇ@‡î�Ûa@�ìÇ@‡¼c@áí‹×

�bä@‘ìíŠìÛbØiLpbßìÜÈ¾a@ë@pbj@ @@@Lpbj�bä@áÄã@á�Ôi@‡îÈß@ @

LpbßìÜÈ¾a@ë@pbj�bä@òîÜ×@ @÷�@µÇ@òÈßbuN@

Òa‹’g@o¥Òa‹’g@o¥Òa‹’g@o¥Òa‹’g@o¥

cN†@OÑí‹ÈÛa@é�@ @k��b�ä@âìÜ�Ç@ˆbn�c@ @

Ü×�òî@�bä�pbj@È¾aë�ßìÜ�pb@@ @ßbu�òÈ@Ç�µ@’�÷à

cN†@O�í�ÈÛa@‡jÇ@á’bç@‡à«@ @pb�ßìÜ�È¾a@áÄã@á�Ó@÷îöŠ


†@Oåí‡ibÇ@‡à«

k��b�ä@âìÜ�Ç@á��Ó


ñ‹çbÔÛañ‹çbÔÛañ‹çbÔÛañ‹çbÔÛa @@@@RPPYRPPYRPPYRPPY@ @@ @@ @@ @

@ @@ @@ @@ @

@

Documents

INTEGRATING WIRELESS SENSOR - Ain Shams Universitycsys.cis.asu.edu.eg/kemara/files/wsnipthesis.pdf · INTEGRATING WIRELESS SENSOR ... I.4 Introduction to OMNeT++ ... Figure @4.5: