NAVAL

POSTGRADUATE
SCHOOL

MONTEREY, CALIFORNIA



THESIS


Approved for public release; distribution is unlimited
A PERFORMANCE ANALYSIS OF AN AD-HOC OCEAN
SENSOR NETWORK

by

Kwang Yong Lim

December 2006

Thesis Advisor: John C. McEachen
Thesis Co-Advisor: Gurminder Singh




















THIS PAGE INTENTIONALLY LEFT BLANK
i

REPORT DOCUMENTATION PAGE
Form Approved OMB No. 0704-0188
Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing
instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection
of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including
suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215
Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction
Project (0704-0188) Washington DC 20503.
1. AGENCY USE ONLY (Leave blank)

2. REPORT DATE
December 2006
3. REPORT TYPE AND DATES COVERED
Master’s Thesis
4. TITLE AND SUBTITLE A Performance Analysis of Ad-hoc Ocean Sensor
Network
6. AUTHOR(S) Kwang Yong Lim
5. FUNDING NUMBERS

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)
Naval Postgraduate School
Monterey, CA 93943-5000
8. PERFORMING ORGANIZATION
REPORT NUMBER
9. SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES)
N/A
10. SPONSORING/MONITORING
AGENCY REPORT NUMBER
11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the
official policy or position of the Department of Defense or the U.S. Government.
12a. DISTRIBUTION / AVAILABILITY STATEMENT
Approved for public release; distribution is unlimited
12b. DISTRIBUTION CODE

13. ABSTRACT (maximum 200 words)

This thesis presents the simulation results and performance analysis of IEEE 802.15.4 in an
oceanic environment. The 802.15.4 standard allows simple sensors and actuators to co-exist in a single
wireless platform. The simulation is performed using Network Simulator, version 2 (NS2) which is an open-
source network simulator tool. NS2 is an event driven network simulator developed at UC Berkeley that
simulates a variety of networks. Leveraging on the capabilities of NS2, the performance of the IEEE
802.15.4 protocol has been studied based on variations in node density, mobility as well as loading
conditions. The mobility model selected for the simulation has considered the ocean effects on the mobile
nodes, in particular the surface current. However, the available mobility models (Random Waypoint,
Gauss-Markov, Manhattan Grid and Reference Point Group) do not represent the real life mobility in an
oceanic environment scenario. As a result, actual data of surface measurement in the Monterey bay area
is used to generate the node movements. The results from this analysis provide insights into the
performance of IEEE 802.15.4 and its suitability for operating in an oceanic environment.





15. NUMBER OF
PAGES
123
14. SUBJECT TERMS
Ad-hoc networks, Wireless Networks, Mobile Networks, Network Simulation, Performance
Evaluation.
16. PRICE CODE
17. SECURITY
CLASSIFICATION OF
REPORT
Unclassified
18. SECURITY
CLASSIFICATION OF THIS
PAGE
Unclassified
19. SECURITY
CLASSIFICATION OF
ABSTRACT
Unclassified
20. LIMITATION OF
ABSTRACT

UL
NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)
Prescribed by ANSI Std. 239-18
ii





















THIS PAGE INTENTIONALLY LEFT BLANK
iii

Approved for public release; distribution is unlimited


A PERFORMANCE ANALYSIS OF AD-HOC OCEAN SENSOR NETWORK

Kwang Yong Lim
Civilian, Singapore Technologies Dynamics Pte Ltd
Bachelor of Engineering (Hons), University of Sheffield, United Kingdom, 1999

Submitted in partial fulfillment of the
requirements for the degree of


MASTER OF SCIENCE IN COMPUTER SCIENCE


from the


NAVAL POSTGRADUATE SCHOOL
December 2006



Author: Kwang Yong Lim



Approved by: John C. McEachen
Thesis Advisor



Gurminder Singh
Co-Advisor



Peter Denning
Chairman, Department of Computer Science

iv





















THIS PAGE INTENTIONALLY LEFT BLANK
v

ABSTRACT
This thesis presents the simulation results and performance analysis of IEEE
802.15.4 in an oceanic environment. The 802.15.4 standard allows simple sensors
and actuators to co-exist in a single wireless platform. The simulation is performed
using Network Simulator, version 2 (NS2) which is an open-source network
simulator tool. NS2 is an event driven network simulator developed at UC Berkeley
that simulates a variety of networks. Leveraging on the capabilities of NS2, the
performance of the IEEE 802.15.4 protocol has been studied based on variations in
node density, mobility as well as loading conditions. The mobility model selected for
the simulation has considered the ocean effects on the mobile nodes, in particular
the surface current. However, the available mobility models (Random Waypoint,
Gauss-Markov, Manhattan Grid and Reference Point Group) do not represent the
real life mobility in an oceanic environment scenario. As a result, actual data of
surface measurement in the Monterey bay area is used to generate the node
movements. The results from this analysis provide insights into the performance of
IEEE 802.15.4 and its suitability for operating in an oceanic environment.



vi





















THIS PAGE INTENTIONALLY LEFT BLANK
vii

TABLE OF CONTENTS
I. INTRODUCTION............................................................................................. 1
A. GENERAL............................................................................................ 1
B. MOTIVATION....................................................................................... 2
C. OBJECTIVE AND SCOPE................................................................... 2
D. THESIS OUTLINE................................................................................ 3
II. THEORETICAL BACKGROUND ................................................................... 5
A. IEEE 802.15.4 ...................................................................................... 5
1. OVERVIEW OF IEEE 802.15.4 ................................................. 6
2. Network Topologies and Device Architecture....................... 7
3. Functional Features................................................................. 9
4. PHY Layer............................................................................... 11
5. MAC Sub-layer ....................................................................... 12
B. MOBILE AD HOC ROUTING PROTOCOLS ..................................... 13
1. Zigbee Routing Protocols..................................................... 14
2. Ad Hoc On Demand Distance Vector (AODV) Protocol ...... 14
3. Cluster Tree Protocol ............................................................ 16
a. Single Cluster Network............................................... 17
b. Multi-Cluster Network................................................. 18
C. OCEAN EFFECTS ON MOBILE NODES.......................................... 20
1. Ocean Surface Current.......................................................... 20
a. Coriolis Deflection ...................................................... 20
b. Wind Drag.................................................................... 21
c. Pressure Gradients..................................................... 22
d. Ekman Spiral ............................................................... 22
2. Tidal Current .......................................................................... 23
D. MOBILITY MODELS.......................................................................... 25
1. Overview of Mobility Models................................................. 25
2. Mobility Models in BonnMotion............................................ 25
a. Random Waypoint Mobility Model............................. 26
b. Gauss-Markov Mobility Models ................................. 27
c. Manhattan Grid Model ................................................ 28
d. Reference Point Group Mobility Model ..................... 29
3. Summary ................................................................................ 30
III. NS2 SIMULATION ENVIRONMENT ............................................................ 31
A. NETWORK SIMULATOR................................................................... 31
1. NS2 Architecture.................................................................... 32
2. Simulation Environment........................................................ 33
3. NS2 Mobile Node Model ........................................................ 35
4. Setting User Parameters in NS2........................................... 37
5. Post Analysis ......................................................................... 38
B. GENERATING OCEAN ENVIRONMENT SCENARIOS.................... 42
1. Near Real-Time Monterey Bay Surface Currents ................ 42
2. Determining Mobility Using Actual Measurements ............ 43
viii

3. Generating Movement Pattern File....................................... 45
4. Generating Communication Pattern File ............................. 47
C. PERFORMANCE METRICS .............................................................. 47
1. Packet Delivery Ratio ............................................................ 48
2. Average Network Delay......................................................... 48
3. Network Throughput ............................................................. 49
IV. SYSTEM SIMULATION AND RESULTS...................................................... 51
A. SPECIFIC TRANCEIVER PARAMETERS......................................... 51
1. Transmitted Power (Pt_)........................................................ 51
2. Receiver Threshold (RXThresh_) ......................................... 52
3. Carrier Sensing Threshold (CSThresh_).............................. 52
4. Capture Threshold (CPThresh_)........................................... 52
5. Antenna Height ...................................................................... 53
6. Propagation............................................................................ 53
B PERFORMANCE ANALYSIS ............................................................ 54
1. Simulation Setup and Parameters........................................ 54
2. Influence of Node Density..................................................... 56
3. Influence of Network Loading............................................... 59
4. Influence of Mobility.............................................................. 63
5. Drop Packet Analysis............................................................ 66
C. SUMMARY......................................................................................... 67
V CONCLUSIONS, RECOMMENDATIONS AND FUTURE WORK................ 69
A. CONCLUSIONS................................................................................. 69
B. FUTURE RESEARCH AREAS .......................................................... 70
1. Vertical Node Movement in Oceanic Environment ............. 70
2. Propagation Model ................................................................ 70
3. Node Energy Consumption................................................... 71
4. Security Considerations for Network................................... 71
5. Guaranteed Time Slot Management..................................... 71
APPENDIX A – INSTALLATION OF NS2............................................................... 73
APPENDIX B – MOVEMENT PATTERN SCRIPT .................................................. 75
APPENDIX C – COMMUNICATION PATTERN SCRIPT........................................ 79
APPENDIX D – SAMPLE TCL SCRIPT.................................................................. 85
APPENDIX E – SAMPLE TRACE FILE FORMAT.................................................. 91
APPENDIX F – SAMPLE AWK SCRIPTS .............................................................. 93
APPENDIX G – NODES POSITION AT VARIOUS TIME INTERVAL..................... 99
LIST OF REFERENCES........................................................................................ 103
INITIAL DISTRIBUTION LIST............................................................................... 107




ix


LIST OF FIGURES
Figure 1 – Wireless Networking (from ref. [3]) ........................................................... 5
Figure 2 – ISO-OSI Reference Model and IEEE 802 Model (from ref. [6])................. 6
Figure 3 – IEEE 802.15.4 Network Topologies (from ref. [6]) .................................... 7
Figure 4 – LR-WPAN Device Architecture (from ref. [6])............................................ 8
Figure 5 – A Typical Superframe Structure (from ref. [3]) .......................................... 9
Figure 6 – Path Discovery, Forward and Reverse Path (from ref. [10]) ................... 16
Figure 7 – Typical Cluster Tree Network.................................................................. 17
Figure 8 – Typical Multi-Cluster Network ................................................................. 19
Figure 9 – Surface Ocean Currents (from ref. [15]).................................................. 21
Figure 10 – Ekman Spiral in Northern Hemisphere (from ref. [16]) .......................... 23
Figure 11 - Upwelling Effect and Downwelling Effect (from ref. [17]) ....................... 23
Figure 12 – Ebb current at low tide and Flood current at high tide (from ref. [20]) ... 24
Figure 13 – RWM model scenario (from ref. [25]).................................................... 26
Figure 14 – Gauss-Markov mobility model scenario (from ref. [25])......................... 27
Figure 15 – Manhattan Grid model scenario (from ref. [25]) .................................... 28
Figure 16 – RPGM model scenario (from ref. [25]) .................................................. 29
Figure 17 – Architecture of NS2............................................................................... 32
Figure 18 – NS2 Event Scheduler (from ref. [29]).................................................... 33
Figure 19 – Flow Diagram for Running Scenario in NS2 ......................................... 34
Figure 20 – NS2 Mobile Node Model (from ref. [30]) ............................................... 35
Figure 21 – NAM Application Window...................................................................... 38
Figure 22 – Data points of Monterey Bay................................................................. 43
Figure 23 – Node movements in Monterey Bay....................................................... 45
Figure 24 – Process of Generating Mobility File ...................................................... 46
Figure 25 – Initial Coverage with 9, 16 and 25 Nodes ............................................. 56
Figure 26 - Results of Varying Node Density with (a) PDR (b) Average network delay
and (c) Network Throughput ................................................................ 58
Figure 27 - Results of Packet Delivery Ratio with Varying Data Rate...................... 61
Figure 28 - Results of Average Network Delay with Varying Data Rate................... 62
Figure 29 - Results of Network Throughput with Varying Data Rate........................ 62
Figure 30 – Node Movements after 1 hour .............................................................. 63
Figure 31 – Results of Packet Delivery Ratio with Node Movement in Time ........... 64
Figure 32 – Results of Network Delay & Throughput with Node Movement in Time 65
Figure 33 – Positions of 9 Nodes Configuration at the 9
th
Hour. .............................. 66







x





















THIS PAGE INTENTIONALLY LEFT BLANK
xi

LIST OF TABLES
Table 1. IEEE 802.15.4 Operating Frequencies.................................................. 11
Table 2. Simulation Parameters.......................................................................... 37
Table 3. NS2 Trace Format for Wireless Packet................................................. 39
Table 4. NS2 New Trace Format for Wireless Packet......................................... 40
Table 5. ARP Trace Format ................................................................................ 41
Table 6. AODV Trace Format ............................................................................. 41
Table 7. CBR Trace Format ................................................................................ 41
Table 8. Simulation Parameters.......................................................................... 55
Table 9. Simulation Parameters for Node Density Analysis................................ 57
Table 10. Simulation Parameters for Network Loading Analysis........................... 60

xii





















THIS PAGE INTENTIONALLY LEFT BLANK
xiii

ACKNOWLEDGMENTS
I would like to take this opportunity to express my sincere gratitude to those
who have lent their support in my master study.

Firstly, to my beloved wife, Fern, who has continuously encourage and been
most supportive in my studies. And for her dedication and patience which have been
the driving forces of my determination and achievement.

My appreciation to both my advisors, Professor John McEachen and
Professor Gurminder Singh, in giving me advices and guidance for the completion of
this thesis.

Also, to senior lecturer Guest Arlene for her patience in teaching and advising
on the movement patterns of Oceanography.


xiv





















THIS PAGE INTENTIONALLY LEFT BLANK
1

I. INTRODUCTION
A. GENERAL

Mobile Ad-hoc NETworks (MANETs) advocate self-configuration and
adaptation of wireless links between communication devices (mobile nodes) that
operate autonomously or as an extension to a wired infrastructure. The wireless
communication links that form the network have to be characterized by a
dynamic topology with no fixed infrastructure since the nodes are highly mobile.
The nodes are equipped with antennas for reception and transmission within the
communication medium through broadcasting. These nodes within MANETs
have salient properties including limited power, relatively short communication
distance, low processing power and limited bandwidth.

Advancements in sensor technology have made MANETs a viable solution for
many commercial as well as military applications. But there has been relatively
limited focus on using MANETs in an ocean environment. A typical scenario
would consist of a collection of nodes, which are ocean buoys containing sensors
that are partially submerged at various positions within a designated operating
area. These nodes would be at various depths and will be drifting slowly towards
as well as apart from each other. An example military application of such a
system in an ocean environment would be for quick deployment for early warning
defense. Wireless networks and large-scale sensors provide information and
sensing dominance for network centric warfare. Such a system needs to be
robust for frequent and unpredictable changes in topology due to the mobility of
ocean buoys. It also has to be able to handle large variations in information load
with the possibility of information transfer being multi-hopped without centralized
control.



2

B. MOTIVATION

Conventional protocols waste energy in collisions and idle listening. IEEE
802.15.4 is a standard that has been designed for low data rate, low power
consumption and low cost which is ideal for MANET applications. There are a
host of technical difficulties for implementing this technology for oceanic
applications. An oceanic system creates a challenging environment where the
ocean current and waves are dynamic and unpredictable which is highly variable
as a function of time and space. These factors would cause interference and bit
errors at the physical level resulting in unreliable and intermittent connectivity and
hence hinder the scalability of protocols. This study focuses on performing the
necessary theoretical research to conduct analysis of the performance of IEEE
802.15.4 in an ocean environment using an open-source network simulator tool.

C. OBJECTIVE AND SCOPE

The objective of this thesis is to perform the necessary research to
conduct analysis on the performance of IEEE 802.15.4 in an oceanic
environment using an open-source tool called network simulator, version 2
(NS2). A simulation model will be built and the various performance behaviors
will be investigated that are relevant to a generic wireless networks (such as
packet delivery ratio, delivery latency, control overhead and transmission
collision) as well as behaviors that are specific to MANETs (such as association,
orphaning and transmission methods).

The experiments for performance analysis are simulated using the latest version
of NS2 2.29 [1]. NS2 is a discrete event simulator that is targeted for networking
research purposes. It provides substantial support for simulation of protocols
over wired and wireless networks. In this thesis, besides the installation of NS2,
an IEEE 802.15.4 extension [2] (contributed code) will be utilized. This code
conforms to IEEE P802.15.4/a18 draft based on the physical layer and the MAC
3

layer behavior of a wireless network. For the performance analysis, an
appropriate mobility model representing the oceanic environment has to be
selected. In essence, this thesis endeavors to answer the following questions:

1. Are the available mobility models in NS2 suitable to simulate the ocean
environment? Currently there are several models that have been used for
research investigation. A few of the models considered are Random
Waypoint, Gauss-Markov, Manhattan Grid and Reference Point Group
mobility model. Each of these models will be examined in details for
suitability to represent node movement in an ocean. If it is determined that
these models are not suitable, what are good alternatives to simulate the
ocean mobility model?
2. With the selected mobility model, how does IEEE 802.15.4 perform in the
oceanic environment? Simulations will be conducted using NS2 and
evaluated against a set of performance metrics.

D. THESIS OUTLINE

This chapter provides the introduction and motivation to the study of IEEE
802.15.4 protocol. Chapter II introduces the theoretical background to this
research. An overview of IEEE 802.15.4 as well as key concepts behind the
ocean effects on mobile nodes is presented. Also, mobility models that are
specific to the simulation are discussed. These mobility models are broadly
classified as independent or group-based. Chapter III will specifically focus on
the methodology in computing node movements from measured data of the
Monterey bay. The computed movement will be used to generate the scenario
file in NS2. Chapter IV is dedicated to the simulation environment and setup with
Chapter V discussing the results of the simulation. Finally, Chapter VI will
conclude these studies and recommend further actions and propose future
studies.

4




















THIS PAGE INTENTIONALLY LEFT BLANK
5

II. THEORETICAL BACKGROUND
This chapter provides an introduction to IEEE 802.15.4 as well as key
concepts and theory relating to this research. The various mobility models used
in simulating the MANET are discussed. Since the mobility models are
determined by the environment, factors that contribute to the movement of nodes
are studied, especially the ocean surface. These ocean effects are taken into
consideration for the selection of mobility models, if applicable. Finally, the
performance matrices used in the evaluation of IEEE 802.15.4 for ocean
environment are detailed.

A. IEEE 802.15.4

The technology for wireless communications has made tremendous
advances, in which most attention has been given to wireless local area networks
(WLANs) and technologies involving the IEEE 802.11 standard. While IEEE
802.11 standard focuses on high-end wireless communication system, the IEEE
802.15.4 standard is designed for low cost, low power applications with less
stringent requirements on throughput and latency (see Figure 1). The primary
objective is to provide reliable data transfer with reasonable battery life for short
range operations while maintaining simple and flexible protocol.














Figure 1 – Wireless Networking (from ref. [3])
6

1. OVERVIEW OF IEEE 802.15.4

The IEEE 802.15.4 standard defines the physical layer (PHY) and medium
access control (MAC) sub-layer specifications for Low Rate - Wireless Personal
Area Networks (LR-WPANs). Currently, the development of the upper layers is
led by the ZigBee™ Alliance through definition of application profiles utilizing the
simplified five layer ISO/OSI reference model shown in Figure 2. The IEEE
standards board approved the IEEE P802.15.4B (D6) Draft Revision [4] in June
of 2006, which defines the detailed specifications. Unlike WLANs having higher
operating range and data-rate, WPANs are designed to function in a personal
operating space which can be extended up to 10m omni-directional. Within a LR-
WPAN, a device can be assigned to either a 16 bit short or a 64 bit extended
address during association. Hence, a single network could potentially
accommodate 65,536 (2
16
) devices.











Figure 2 – ISO-OSI Reference Model and IEEE 802 Model (from ref. [6])

Some of the unique characteristics of a LR-WPAN are:
• Over-the-air data rates of 250 kb/s, 40 kb/s and 20 kb/s.
• Star or peer to peer operation.
• Allocated 16 bit short or 64 bits extended addresses.
• Allocation of guaranteed time sots (GTSs).
• Carrier sense multiple access with collision avoidance (CSMA-CA).
• Full acknowledgement protocol for transfer reliability.
• Low power consumption.
7

• Energy detection (ED).
• Link quality indication (LQI).
• 16 channels in the 2450 MHz band, 10 channels in the 915 MHz
band and 1 channel in the 868 MHz band.
The following sections highlight some important design features [4, 5 & 6] of this
standard.

2. Network Topologies and Device Architecture

Devices that participate in a LR-WPAN can be of 2 types, a full function
device (FFD) or a reduced function device (RFD). Each RFD can only associate
with a single FFD at an instance whereas FFDs can communicate with other
FFDs or RFDs. A FFD contains the complete set of MAC services and is able to
operate as a network coordinator or a network device. On the contrary, a RFD is
simply a network device with a reduced set of MAC services and usually used for
simple applications. Three types of topologies are supported, namely star, peer-
peer and cluster tree as shown in Figure 3. The decision on which topology to
adopt is dependant on the operating distance, typically one-hop star and multi-
hop peer-to-peer or cluster tree topology when communication range exceeds
10m.











Figure 3 – IEEE 802.15.4 Network Topologies (from ref. [6])
Star Topology Network
Peer to Peer Network
Cluster Network
Cluster
Cluster
Cluster
Reduced Function Device
PAN Coordinator
Full Function Device
8

With star topology, communication is established between devices by a single
central controller known as the PAN coordinator. The PAN coordinator (which is
a FFD) acts as a hub that forms direct links to other devices. These devices,
consisting of FFDs or RFDs, form around the PAN coordinator and act as data
terminal locations. In the peer-to-peer topology, each device in the network can
communicate with any devices within its radio range. Although a PAN coordinator
is required somewhere in the network, each device can form multiple links to
other devices, hence increasing redundancy at the expense of complexity. The
cluster tree is similar except that the network hierarchy is more complex. This
topology simplifies routing and reduces direct links at the expense of data traffic
latency.

The architecture of a LR-WPAN device, shown in figure 4, comprises the PHY
layer and MAC sub-layer. The PHY layer consists of an RF transceiver including
a low level control mechanism while the MAC sub-layer provisions for access to
the physical channel for all transfer types. Through the service specific
convergence sub-layer (SSCS) an IEEE 802.2 logical link control (LLC) can
accesses the MAC sub-layer. Each layer will contain services which have the
capability to build functions on the services of lower layers and present them to
the next higher layer. Every event will require passing of service primitives from
a layer to another through a service access point. There are 14 PHY and 35
MAC primitives described in IEEE 802.15.4.













Figure 4 – LR-WPAN Device Architecture (from ref. [6])
Upper Layers
802.2 LLC
SSCS
MAC
PHY

Physical Medium
9

3. Functional Features

In the IEEE 802.15.4 standard, some of the functional features used are
the superframe structure, different data transmission methods, low power
consumption as well as self-configuration and orphaning.

• Superframe structure. The superframe (shown in Figure 5) is a
special network communication architecture introduced for time division
multiplexing. The superframe consists of an active and an inactive period
where beacons in a beacon-enabled network are periodically transmitted
for synchronization. Within the active portion, devices in the network can
transmit with slotted Carrier Sense Multiple Access – Collision Avoidance
(CSMA-CA) in the contention access period (CAP). In the contention free
period, only devices with a guaranteed time slot (GTS) can perform data
transmission. In CSMA-CA, transmitting devices will listen to the channel
for a predetermined time to check for activities on the channel. If the
channel is idle, the device is permitted to transmit and if busy, the station
has to delay its transmission.






Figure 5 – A Typical Superframe Structure (from ref. [3])

• Data transmission methods. Data transfer can occur either from a
device to a coordinator, coordinator to a device or from one peer to
another in a peer-to-peer multi-hop network. In general, the data transfer
process can be classified into direct transmission, indirect transmission
and GTS transmission. Direct data transmission will happen for the three
data transfer cases and depending on whether the network is beacon-
2 0 1 3 4 5 6 7 8 9
10 11 12
13 14 15
GTS GTS Inactive Period
CAP CFP
Beacon
Active Period
10

enabled or beaconless, a slotted or unslotted CSMA-CA is used. Indirect
data transmission applies only to data transfer from a coordinator to its
devices where the coordinator keeps a data frame in a transaction list and
waits for the device to extract data. Devices will check on beacon frames
received from the coordinator to determine if data packets are pending in
the transaction list. Also, it is possible, but unlikely that indirect data
transmission occurs in beaconless mode where unslotted or slotted
CSMA-CA is used in the data extraction procedure. Finally, GTS data
transfer occurs both from a device to its coordinator and from coordinator
to devices. GTS transmission does not require the use of CSMA-CA
protocol.

• Power Consumption. Due to their mobile nature, devices are
usually battery operated and hence power consumption is a vital factor.
Several power-saving mechanisms are incorporated in IEEE 802.15.4 to
prolong device battery life. Most of these mechanisms operate in beacon
enabled mode where the receiver of coordinator or its devices are
disabled for a specific period during direct transmission. Devices can also
be configured to low power (i.e. sleep) state when there is no data
transmission or transmitting GTS data transfer at low duty cycle. Other
inherent properties to reduce power consumption are the small CSMA-CA
back-off period and short transceiver warm-up time.

• Self-configuration and Orphaning. The self-configuration capability
is part of the association and disassociation functions in the MAC sub-
layer. This capability will automatically establish a star network and also
perform self configuration of peer-to-peer network. Orphaning mechanism
provides detection of link or node failures for devices in beacon-enable
mode and is tracking beacons. When a device misses a pre-determined
number of beacons consecutively, the device will perform a re-alignment
procedure to establish link with its coordinator.

11

4. PHY Layer

One of the primary reasons for the failure of several proprietary
technologies is the inability to adapt. However, IEEE 802.15.4 has been
designed to be applied worldwide supporting three different operating frequency
bands, with a different number of supporting channels and at specific data rates
(Table 1).

Frequency band # of channels Data rate (Kbps) Applicability Restrictions
2.4 GHz 16 250 Worldwide Unlicensed
915 MHz 10 40 USA Licensed
868 MHz 1 20 Europe Licensed

Table 1. IEEE 802.15.4 Operating Frequencies.

There are 2 types of frequency bands defined in the PHY layer, the license-free
industrial scientific medical (ISM) 2.4 GHz band and the licensed 868/915 MHz
band. In total, there 27 channels and 3 different data-rates that is specific to the
frequency band. The availability of the ISM band eliminates the need for a
license and allows development of devices to be used anywhere in the world.
With that, investment risk is greatly reduced which results in lower cost devices.
Despite its simplicity, IEEE 802.15.4 also strives to provide flexibility which allows
selection of operating in any one of the channels. The basis for the selection is
usually dependent on availability, congestion state and data rate of each channel
(in terms energy and cost efficiency).

The PHY layer acts as the interface between the MAC sub-layer and the physical
medium and provides both data services and management services accessed
through two service access points. The following tasks are the responsibility of
the PHY layer.
• Activation and deactivation of radio transceiver. Depending on the
requests from the MAC sub-layer, the internal operating state of the
transceiver can be de-activated (sleep mode), transmitting or receiving.
12

• Energy detection (ED) within the current channel. This service
performs the estimation of the received power within the channel
bandwidth and this result can be used in the network layer for channel
selection or for the purpose of clear channel assessment (CCA).
• Link quality indication (LQI) for received packets. This
measurement is derived from receiver ED estimates, signal-to-noise ratio,
or both measures to compute the link quality or strength where packets
are received. The result of this measure is used in the network or
application layer.
• Clear channel assessment (CCA) for CSMA-CA. CCA is performed
by the PHY layer using at least one of three modes of energy, carrier
sense and carrier sense with energy. In energy mode, a medium is
reported busy if any detected energy is above the ED threshold. As for
carrier sense mode, a medium is reported busy when the detected signal
has the modulation and spreading characteristics of IEEE 802.15.4. The
last mode will report a busy medium when both above-mentioned
conditions are met.
• Channel frequency selection. Upon receiving request from MAC
sub-layer, the PHY layer will tune to the selected channel.
• Data transmission and reception. This is the primary task of the
PHY layer where various modulation and spreading techniques are
employed depending on the frequency band.

5. MAC Sub-layer

The MAC sub-layer acts as the interface between the SSCS and the PHY
layer, providing MAC data and management services. The features of MAC sub-
layer includes beacon, network configuration, channel access, guaranteed time
slot (GTS) and link management. The following tasks are the responsibility of the
MAC layer.
13

• Beacon generation for PAN coordinator and synchronization. A
FFD that is designated as a coordinator has the ability to operate in
beaconless or beacon-enabled mode. Beacon-enabled mode allows the
use of superframe that has a structure which is bounded by network
beacons and is divided 16 equal sized slots. Beacons are transmitted
periodically for describing the superframe structure, synchronization of
attached device and identifying the network. Synchronization is required
for data polling, energy saving and detection of orphaning.
• Association and disassociation of network. MAC sub-layer
association and disassociation supports the automatic setup and self-
configuration of star and peer-to-peer network.
• Employing CSMA-CA mechanism for channel access. In
consideration of the low data rate in LR-WPAN, the request-to-send (RTS)
and clear-to-send (CTS) mechanism are not utilized in the CSMA-CA.
• Allocation and management of guaranteed time slot (GTS)
mechanism. While in beacon-enabled mode, GTS allows allocation of
dedicated resource to a particular device within a certain portion of the
superframe.
• Maintain reliable link between two MAC sub-layer entities. Various
mechanisms such as CSMA-CA, CRC data verification, frame
acknowledgement and retransmission, are employed by the MAC layer to
provision for reliable link.

B. MOBILE AD HOC ROUTING PROTOCOLS

Due to the highly dynamic nature of mobile nodes and the absence of a
central controller, traditional routing protocols used for a wired network cannot be
applied directly to a MANET. Some of the considerations required in the design
of MANET routing protocols include the mobility of nodes, unstable channel
states and resource constraints such as power and bandwidth. In a MANET, the
movement of nodes will cause communication between nodes to be disrupted
14

from frequent path breaks and reconnections. Also, the broadcasting of radio
channels can be highly unstable and the network layer has to interact with the
MAC layer for available channels. In addition, power availability is often limited
since the nodes are connected to batteries. Currently, the network and upper
layers of IEEE 802.15.4 is being implemented by the ZigBee Alliance. Details of
Zigbee Routing protocols will be discussed and other ad hoc routing protocols
will not be addressed in this thesis.

1. Zigbee Routing Protocols

The MAC and PHY layers of IEEE 802.15.4 have no notion of node
resources and energy. At the network layer, Zigbee supports node activation,
network discovery, network formation and routing of packets. Similar to IEEE
802.15.4, Zigbee is an industrial standard that is targeted for low data rate, low
power consumption, low cost as well as long life wireless network operations.
Zigbee employs a basic master-slave configuration where each master can
support up to 254 slaves that can be nested to support a hierarchical routing
strategy [7]. In addition, Zigbee provides a unique feature of redundancy in
communication hence eliminating single point of failure in mesh networks. The
routing algorithms defined for use by Zigbee are the Ad Hoc On Demand
Distance Vector (AODV) protocol and the Cluster Tree protocol. Detailed
Documentation for these two protocols is provided in the Zigbee specification [8].

2. Ad Hoc On Demand Distance Vector (AODV) Protocol

The AODV is a pure on-demand acquisition algorithm system that allows
message passing through neighboring nodes to nodes that are unreachable [9 &
10]. Routing is accomplished by discovering the shortest possible route and
ensuring that these routes do not contain loops. AODV also has the ability to
adapt to route changes and can create new routes when error occurs. Individual
mobile nodes operate as a special router where routes are obtained only when
required with minimal reliance on periodic updates. Nodes not within the active
15

paths neither maintain any routing information nor participate in exchanging
routing tables. However, a route needs to be discovered or maintained when
there is communication between two nodes or that the nodes are in the direct
path between the source and destination nodes. In essence, AODV seeks to
minimize the number of control messages sent.

There are several techniques employed for a mobile node to be aware of other
nodes in its vicinity, and one such technique is local broadcasting of “hello”
messages. Routing tables of the neighboring nodes are organized to have
optimized response time for local movements and establishing request of new
routes. The primary objectives of the algorithm are [6]:
• Broadcast discovery packets when necessary
• Distinguish between local connectivity management and general
topology maintenance.
• Disseminate to neighboring mobile nodes that are likely to need the
information about changes in local connectivity.

For the instance where a destination or intermediate node has no routing
information, the Path Discovery process is initiated. Each node keeps track of
neighboring nodes by listening for the “hello” messages that each node
broadcasts at set intervals and by also maintaining two separate counters, the
sequence number and broadcast id. The process begins with the source node
initiating route request (RREQ) packets to the neighboring nodes. The source
address and broadcast id will uniquely identify the RREQ. The broadcast id is
incremented for a new RREQ. When an intermediate node receives a RREQ, it
increases the hop count and rebroadcasts the RREQ to other neighboring nodes.
If that particular node has received a similar RREQ, the redundant RREQ will be
dropped. Along the path from the source to destination node, a reverse path is
automatically set up where every node maintains the record of the neighboring
node that sends the broadcast.

16

In summary, the route to the destination is determined by comparing both
destination sequence number in the node’s route entry and the RREQ. The node
will respond by either rebroadcasts of the RREQ or unicasts a route reply
(RREP) packet back to the node in which request is received. When the RREP
packet routes back to the source, a forward pointer is established on each node
and timeout information is updated. This process will establish a uni-directional
route and is repeated in the reverse direction for a bi-directional route. Due to
movement of nodes, there could be errors during routing of messages. A route
error message (RERR) allows nodes to adjust routes by removing all routes
containing bad nodes from the routing table. This specification is detailed in RFC
3561 [11]. The path discovery process, forward and reverse path are shown in
Figure 6.












(a) (b)

Figure 6 – Path Discovery, Forward and Reverse Path (from ref. [10])


3. Cluster Tree Protocol

The Cluster Tree Protocol utilizes link-state packets to form a single
cluster network or a potentially large cluster tree network. The network is mainly
self-organized and network redundancy is maintained to achieve a high degree
of fault resistance and self-repair. Essentially, nodes form a cluster during the
self-organizing process and these formed clusters will connect to each other.
Within a cluster of nodes, a cluster head is selected which will assign a unique
Destination
Forward
Reverse
Neighboring
node
Source
17

node ID to each individual node member during the cluster formation process.
The connection between clusters is established using the Designated Device
(DD) which assigns a unique cluster ID to each cluster. Basically, the DD is a
node having high computing ability and large memory space. A typical cluster
tree network is shown in Figure 7. Below sub-section details the process for
single and multi cluster network.










Figure 7 – Typical Cluster Tree Network

a. Single Cluster Network

The process of cluster formation begins with the selection of cluster
head, followed by the cluster head expanding links to other node members
forming a cluster. There are several ways to select the cluster head, based on
the initiating node or stored parameters. When a particular node is activated,
that node will listen for “hello” messages (i.e. beacons in the IEEE 802.15.4 MAC
layer) from other nodes. After a certain duration when no messages are received,
the node appoints itself as the cluster head and sends out “hello” messages. If no
connection request is received, the node reverts to its original status. For the
other option, the selection is determined from stored parameters such as
transmission range, power capacity, computing information or location
information.

As the cluster head, the node will periodically broadcast “hello” messages which
consist of a partial MAC address and node ID 0. Neighboring nodes will send a
Cluster Head
Communication range
18

“connection request” message upon receiving the “hello” message. The cluster
head node will in turn reply with a “connection response” message containing the
node ID and the respective node member will acknowledge the receipt of
message. Due to the dynamic mobile nature, all member nodes within the
transmission range of cluster head have a star topology with one hop. This
cluster can also expand to a multi-hop structure with each node having multiple
connections. For the instance where all node IDs have been used or other limits
have been reached, connection requests will be rejected by assigning a unique
node ID. Also, if no update is received from a member node, it is eliminated from
the cluster.

It is possible for a node to receive a “hello” message from another cluster. The
receiving node will include the cluster ID (CID) of the transmitting node and will
update the cluster head through a link state report. This process allows the
cluster head to be aware of the entire topology for better optimization. If there is a
need to change the topology, the cluster head will send a “topology update”
message. In addition, the periodic “link state report” message is used to indicate
the presence of a troubled node. A cluster head in trouble will result in stoppage
of the “hello” messages and member nodes will be re-configured.

b. Multi-Cluster Network

A network having multi-clusters (as shown in Figure 8) will need a
Designated Device (DD) for assigning a unique cluster ID to individual cluster
heads. The DD also serves to calculate the shortest route to clusters and keep
nodes within the network informed. DD is usually the cluster head of cluster 0
and begins by sending “hello” message. Neighboring cluster heads respond by
sending a “connection request” message to join cluster 0 followed by a request
for a CID to the DD. When a cluster head is assigned to a new CID, its member
nodes are informed using the “hello” message. If a node member receives the
“hello” message from the DD, CID0 is added to the neighboring list and updates
19

its cluster. This node will then be selected as the border node for that particular
cluster and the “network connection” message is sent to establish a connection
to the DD resulting in the border node being a member node of cluster 0. A “CID
request” message is then sent and upon receiving a “CID response” message, a
“network connection response” message containing a new CID is sent to the
parent cluster head. Members in the cluster will be informed through “hello”
messages. Other clusters not in the vicinity of the DD utilize intermediate clusters
to obtain the CID. Eventually, the DD should gather the entire tree structure of
the clusters. Individual nodes belonging to a cluster have to maintain a record of
their parent and child clusters as well as the border node ID associated with the
clusters.













Figure 8 – Typical Multi-Cluster Network

Periodic “network link state report” messages are sent by cluster heads to report
link state information to the DD for computing route optimization and to update
network redundancy. In return, results of the updated route are sent through a
“topology update” message from the DD to the cluster. To prevent network
downtime caused by the DD, a backup DD is often assigned. Border routers
connect the clusters by performing relaying functions where messages are
forwarded to border nodes of an adjacent cluster or a destination node that
resides in the cluster. Only the DD can communicate with all nodes in the
CH1
Cluster 1
CH2
DD
Border nodes
Cluster 0
Cluster 2
20

network and the broadcast message is forwarded by the border node from the
parent to the child cluster.

C. OCEAN EFFECTS ON MOBILE NODES

When nodes (devices on a buoy) are deployed in an oceanic environment,
there are various factors that affect their movement. However, the ocean surface
current and tidal waves have the most effect on the mobility of the nodes.

1. Ocean Surface Current

An ocean current can be described as a directed movement of oceanic
water at the ocean’s surface. It can be transient, affecting a small area, or
essentially permanent, extending over a long horizontal distance [12]. Currents
exist at all depths in the ocean. In some regions, two or more currents may flow
in different directions at different depths. Hence, ocean currents can be generally
characterized into two types, surface and sub-surface. Essentially, the current
system is complex with the actual current flow varying both spatially and
temporally. The driving force for ocean currents comes from the atmosphere
(mainly from winds), resulting in generation of surface circulation patterns. Such
pattern is caused by the interaction of Coriolis deflection, wind drag and the
pressure gradient. Wind is air moving across the Earth’s surface and is
generated by asymmetrical heating of Earth by the sun. Although the wind
strongly affects the surface layer, its influence on the ocean is restricted to about
100 meters (325 feet) in depth [13 & 14]. Since this thesis is only concerned with
surface currents which cause movement of the floating nodes, the sub-surface
layer will not be considered.

a. Coriolis Deflection

Coriolis deflection is caused by the rotation of the Earth due to
decreasing velocity at Earth’s surface with increasing latitude. The deflection
21

results in the surface current moving in a clockwise direction (bending to the
right) in the Northern Hemisphere and counter-clockwise in the Southern
Hemisphere (bending to the left). Therefore, the water currents will flow down the
pressure gradient at an angle instead of directly towards the low pressure.

b. Wind Drag

Air at the poles is cooled and hence sinks, creating a region of high
pressure at the surface. Differential heating on the Earth’s surface by the sun
causes air to rise and creates a region of low pressure at the surface of the
equator. These differences in air pressure will give rise to winds. Surface winds
blow in a regular flow pattern and are influenced by the differential heating of air
across Earth’s surface and Coriolis deflection. As the wind blows across the
ocean surface, the air molecules that are dragged along the surface collide with
the surface water molecules and transfer energy through frictional drag. This
process results in momentum being transmitted from the air to the water
molecules, setting the surface water in motion.














Figure 9 – Surface Ocean Currents (from ref. [15])

22

Due to the process being inefficient, the speed of the generated current is only
approximately 3% of the wind speed. As such, the surface current resulting from
wind drag is very much affected by surface winds. Eventually, currents come into
contact with continents and are deflected, creating current loops. This
phenomenon of creating current loops is known as circulation gyres and is shown
in Figure 9.

c. Pressure Gradients

A pressure gradient is a change of pressure across a horizontal
distance. With a greater differential pressure over a specific distance, the
pressure gradient will increase. Ideally, pressure gradient is almost always
balanced by Coriolis force and hence their net result causes no movement.
However, the sea surface is warped into broad mounds and depressions.
Mounds are caused by convergence (i.e. water flows together and sinks) while
depressions are caused by divergence (i.e. water rises to surface and flows
outwards). With the variation in the height on the surface, the pressure gradient
will rise. When water is flowing down pressure gradients (high to low pressure)
on the ocean’s irregular surface, it is deflected (a function of location and speed)
by Coriolis. This forms a sea surface topography affecting surface circulation.

d. Ekman Spiral

While the surface water moves approximately 45°to the right of the
wind in the northern hemisphere, the net transport of water is approximately 90°
off of the wind, and a phenomenon called Ekman Transport occurs. With depth,
the speed is reduced and the direction of the current changes. This flow pattern
is known as the Ekman spiral, as shown in Figure 10.



23


















Figure 10 – Ekman Spiral in Northern Hemisphere (from ref. [16])

Surface currents and the Ekman Transport result in the process of upwelling or
downwelling (see Figure 11) which is an important aspect of effects along the
coasts. When water moves to the right of wind caused by Ekman Transport,
upwelling occurs. This movement of water offshore is replaced by cold water
moving from below to the surface. Similarly, movement of water to the right of the
wind direction caused by Ekman transport will results in downwelling. Water
moved offshore is replaced by waters from below.










Figure 11 - Upwelling Effect and Downwelling Effect (from ref. [17])


2. Tidal Current

Tides are essentially very long-period waves that cause the sea level to
rise and fall in response to the forces exerted by the moon and sun [13 & 18].
24

Tides are phenomena caused by the gravitational pull of the sun and moon, and
counterbalancing that force is inertia. Effectively, gravity and inertia will cause
two major tidal bulges [19]. One of the tidal bulges is from the lunar gravitational
attraction that “draws” the ocean to the side nearer to the moon. Another is on
the opposite side where the inertial force exceeds the gravitational force due to
less gravitational attraction from the moon and hence forms the other bulge. The
size and position of the bulges are very much affected by the sun where there is
a complex interaction between these forces and the lunar forces.

From the horizontal movement caused by the rising and falling of tides, water
currents are generated. There are two kinds of flow from this tidal current, flood
flow and ebb flow. Flood flow occurs when the tidal current is coming towards the
coast or high tide is ensuing (see Figure 12). Ebb flow is where tidal current is
receding to the sea or low tide ensuing. The strongest currents (flood or ebb)
usually occur before or near the time of the high and low tides. The weakest
currents occur between flood and ebb currents, and are known as slack tides. In
the open ocean, tidal currents are relatively weak. The speed of tidal currents
can reach up to several kilometers per hour near coastal regions.













Figure 12 – Ebb current at low tide and Flood current at high tide (from ref. [20])

25

D. MOBILITY MODELS

In order to simulate IEEE 802.15.4 protocol for an ad-hoc network, it is
imperative to use a mobility model that accurately represents the ocean
environment. The mobility model should attempt to represent the movement of
actual mobile nodes floating on the sea surface. Changes in speed and heading
must occur within reasonable time steps.

1. Overview of Mobility Models

Previous work [21] has shown that the chosen models have a great impact
on the results of the simulation and hence the evaluation of the IEEE 802.15.4
protocol. Essentially, such models are categorized into those that are related to
cellular networks or ad-hoc networks. For this thesis, the main focus is on ad-hoc
wireless networks where nodes can move freely within an area of influence. A
route must be established between the intermediary nodes for communication
between a pair of nodes. Hence, the modeling of the node positions is vital as
performance is dependant on the transmission range which is fairly short with
respect to the size of the field. Existing mobility models used in simulations can
be divided into two distinct classes, independent or group-based. In the latter
category, the nodes exhibit a certain relationship between each other and that
relationship will determine the movements within the field. Independent models,
on the contrary, model the movement of each node independently from other
nodes.

2. Mobility Models in BonnMotion

Mobility models are used in NS2 to generate the scenario and such
scenario can be generated by BonnMotion software [22]. BonnMotion software is
a Java program developed within the Communication Systems group at the
26

Institute of Computer Science IV of the University of Bonn, Germany. It is
capable of creating and also providing analysis of mobility scenarios. There are
currently five mobility models, and scenarios generated can then be exported for
NS2. The models [23,24] available in BonnMotion are the Random Waypoint
model, two versions of Gauss-Markov model, Manhattan Grid model and
Reference Point Group Mobility model. An overview of each model is provided
below.

a. Random Waypoint Mobility Model

The Random Waypoint Mobility (RWM) model is a simplistic model
to represent randomness in movement patterns. The required parameters are the
pause time between changes and the direction and/or speed during each
change. The nodes in this model will appear to move randomly within the
confinement of the simulation boundary. Initially, nodes are placed at certain
locations in the simulation area. During the simulation run, each node will remain
stationary for the pause time duration. Upon the expiry of pause time, nodes will
move toward a new arbitrary position determined by a randomly selected speed,
uniformly distributed between a minimum and maximum speed. These nodes will
remain in the new position until the pause time has reached and the process
repeats until the end of simulation. Figure 13 below shows a scenario generated
using RWM model.








Figure 13 – RWM model scenario (from ref. [25])
27

b. Gauss-Markov Mobility Models

Gauss-Markov Mobility Model is designed to adapt various degree
of randomness in the mobility pattern with the use of one tuning parameter.
There are two models implemented, the original Gauss-Markov model and
Gauss-Markov model. A typical scenario generated from Gauss-Markov model is
shown in Figure 14.









Figure 14 – Gauss-Markov mobility model scenario (from ref. [25])

The implementation of the original Gauss-Markov model follows the publication
of B. Liang and Z. Haas [24]. This model assumes that node movement has a
pre-determined destination. Within a short period of time, the change in velocity
will be limited due to physical constraint. Hence, the next location (and velocity)
of a particular node is likely to be correlated to the previous and current position.
The parameters required are a norm and random vector which are assigned to
each mobile node, instead of stating the velocity. A maximum speed can also be
specified. During simulation run, a velocity vector with a larger norm is multiplied
with an appropriate scalar quantity to reduce the speed. When a node is the
approaching boundaries and about to travel beyond the boundaries, the direction
of movement is forced to flip by 180 degree (i.e. mirrored). This keeps the nodes
in the boundary of the simulation area.
28

The Gauss-Markov model is similar to the description from the T. Camp, J
Boleng and V. Davies publication [23]. There are subtle differences in the
implementation of this model. During simulation, the new speed and movement
direction is selected from a normal distribution of previous values, rather than
depending on the velocity at a previous instance and a random variable. The
speed can also be constrained within a specified range. When the speed
exceeds this range, the minimum or the maximum value is selected. As with the
original Gauss-Markov model, nodes can move beyond the simulation
boundaries and the next movement vector is updated with an angle that brings
the node back into the simulation area.

c. Manhattan Grid Model

The Manhattan Grid model is a model where the mobility of nodes
is confined in a pre-defined grid area within a topological infrastructure [26]. This
model specifies that the movement of nodes is only allowed along paths of pre-
defined grid (i.e. parallel movement in the x or y direction). Figure 15 shows the
scenario from a Manhattan Grid model. The parameters that are used to describe
the model include the mean speed, minimum speed (with a defined standard
deviation for speed - normal distribution), probability of speed change at position
update and probability that node will turn at cross junctions.








Figure 15 – Manhattan Grid model scenario (from ref. [25])
29

Such a model is useful in emulating the movement pattern in an urban setup
where grids are composed of a number of horizontal and vertical streets,
intersecting each other. Node movement is somewhat driven by a destination
and physical constraints within the environment. When a mobile node is at an
intersection of a horizontal and a vertical street, it can turn left, right or go straight
depending on a certain probability.

d. Reference Point Group Mobility Model

Reference Point Group Mobility (RPGM) model [27], unlike
previous models, is a group mobility model and allows independent random
motion behavior for each node, in addition to the group motion (see Figure 16).
Nodes are formed into groups where each group will have a logical centre. The
group movements will be based upon the path traveled by a logical center. This
model represents the randomness in movement of groups as well as individual
nodes within the group. Group movement is determined by the group’s logical
centre and the motion of nodes in a group is characterized by the centre direction
and speed. Within a group, individual nodes move depending on a pre-defined
reference point which follows the group movement.









Figure 16 – RPGM model scenario (from ref. [25])

30

This model is parameterized by the number of nodes per group, group change
probability (where nodes migrate from one group to another), maximum distance
to center of group and group size standard deviation. The RPGM model provides
a general and flexible framework for describing mobility patterns that are task
oriented and time restricted. Such a model is suitable for military operation
environment where military forces usually move in groups.

3. Summary

Although the RWM model is simple and widely used, it does not capture
the essence of node movement on the ocean surface. The ocean current is
determined mainly by the wind and not necessarily random in movement pattern.
Both the Gauss-Markov models constrain the movement of nodes to be within a
certain operating environment. Such properties are ideal for simulating a wireless
personal communication service that is restricted by wireless coverage. However
in oceanic environment, nodes could be washed ashore or drift further into the
ocean. The Manhattan mobility model has the properties of high spatial and
temporal dependency with a certain restriction on mobility defined by the grid.
For modeling of ocean surface current, the movement of nodes is not
constrained in any particular fashion except at the coast line. The RPMG is the
most promising among the previous models as the nodes in an ocean
environment could possibly form group since the difference in velocity of adjacent
nodes is small. However, the velocity change is not random but deterministic and
is influenced by surface current depending on the time of day. Hence, the models
in BonnMotion do not accurately represent the ocean environment and cannot be
used to provide meaningful evaluation of IEEE 802.15.4 protocol.
31

III. NS2 SIMULATION ENVIRONMENT
In computer network research, the uses of network simulation techniques
allow simulating network behavior by mathematical calculation of network
interaction. Network simulator (NS2) is such an open source simulation tool that
operates on the UNIX-based operating systems. This chapter describes NS2, the
methodology used to compute node movements, generation of NS2 movement
and traffic pattern scripts as well as the performance matrices for evaluation of
IEEE 802.15.4.

A. NETWORK SIMULATOR

The network simulator, NS2, is a discrete event simulation tool for network
simulation which will be used for evaluating the performance of IEEE 802.15.4.
The NS2 software and documentation is currently maintained by University of
Southern California's Information Sciences Institute (USC/ISI). NS2 began as a
variant of REAL [28] which is a network simulator originally intended for studying
the dynamic behavior of flow and congestion control schemes in packet-switched
data networks. It is open-source and operates on the UNIX-based operating
systems providing substantial support for simulation of routing, multicast
protocols and IP protocols over wired, wireless and satellite networks. In addition,
it has the capability to generate graphical details of network traffic (through the
Network Animator, NAM) and supports several routing and queuing algorithms. It
is also possible to run NS2 on Windows machine using Cygwin application,
which provides a Linux-like environment under Windows, or simply by operating
NS2 through a VMware player. Installation of NS2 can be done by downloading
the all-in-one version or downloading individual components and then compiling
each component in a single directory. Despite its capabilities, NS2 has been built
by various developers and contains several inherent known as well as unknown
bugs.
32

1. NS2 Architecture

NS2 is written in the C++ programming language with the Object Tool
Common Language (OTCL) as the front-end interpreter. A class of hierarchy
supported in C++ is the compiled hierarchy and the interpreter hierarchy for
OTCL. There will be objects that are completely implemented in C++ or OTCL
while some can be implemented in both languages. For objects that are
implemented in both languages, there is a corresponding link between the two
hierarchies. Figure 17 shows the architecture of NS2.










Figure 17 – Architecture of NS2

Basically, the two languages are required to complement both run-time
speed and iteration time. A detailed simulation involving efficient manipulation of
bytes, packet headers and implementing algorithms with large data set will
require run-time speed. The importance of these tasks requires a system
programming language similar to C++ programming. On the contrary, where
certain parameters might need to be varied for research, iteration time is vital. A
scripting language like OTCL is ideal for such a task that allows frequent
configuration changes. A scheduler maintained event timing that determines the
advancement of the simulation, as shown in Figure 18. An event is an objectin
the C++ hierarchy with a unique identity, a scheduled time and a pointer to an
33

object that handles events. For every event created by the network component,
the event will be placed onto an event queue linked to the scheduler. The data
structure is ordered to be synchronized with the executing events invoked by the
event handler. As the simulation progresses, the first event in the queue is
assigned with the appropriate network component and executed.










Figure 18 – NS2 Event Scheduler (from ref. [29])

2. Simulation Environment

The version in use for this thesis is version 2.29, with installation of the all-
in-one package that operates on Redhat 9.0 through VMware server. The
installation process is available in Appendix A. Basically, the scenarios are
implemented with scripts written in TCL that comprise commands and
parameters for simulator initialization, node creation and configuration. There are
three inputs to the simulator; the movement pattern file, the communication
pattern file and the configuration file. The movement pattern file describes all
node movements while the communication pattern file describes the packet
workload presented at the network layer during simulation. These two files
essentially constitute the description of the simulation scenario. The final input is
the configuration file that defines the ad hoc network routing protocol which is
often the main file where the scenario files are called. The results from the
simulation are generated in two separate files, an output trace file (*.tr) and a

Node 1
Event Queue
Node 2 Node 3 Node N

Event
Event
Executing event
Event Event
34

NAM trace file (*.nam). The trace file will contain information on the various
events which occurred, details of node behavior, packet transmissions and
receptions, communication layer, packet drops, etc. Analysis of these packets
can determine the performance effects from parameter variation, routing
protocols and are performed using awk command, perl scripts or available
analysis programs. The nam file contains information on the topology such as
node movement traces and events. It is similar to trace files with the exception of
the syntax that is used by the network animator (NAM) for visual representation
of the simulated scenario. The procedure for running the scenarios is shown in
Figure 19.




















Figure 19 – Flow Diagram for Running Scenario in NS2
Scenario
Parameters
Movement
Generator
Movement
pattern file
(.scn)
Router config. file
(TCL script)
Communication
pattern file
(.traff)
Traffic
Generator
Traffic Pattern
Parameters
NS2
Network
Animator file
(.nam)
Trace file
(.tr)
NAM
Analyzer
(Awk/.java)
Output file
Excel
Topology animator
Performance graph
35

3. NS2 Mobile Node Model

The mobile nodes model is part of CMU’s mobility extension [30] to NS2
where each mobile node operates independently to compute its position and
velocity as a function of time. Mobile nodes are attached to a channel through
network interfaces that carry packets between nodes. Figure 20 shows the
mobile node. As part of the mobility extension, added functionalities like node
movement, transmission and reception on a channel are included to create a
wireless mobile environment.






















Figure 20 – NS2 Mobile Node Model (from ref. [30])
36

Features including node movement, periodic position updates and maintaining
topology boundary are implemented in the C++ portion whereas the network
components (such as classifiers, LL and MAC) are implemented in OTCL.
Applications such as constant bit rate (CBR) packets are bounded to a particular
node and a routing agent. Routing agents are used by the nodes to compute the
routes from source to destination. The packet is then passed to the link layer (LL)
and queued until a signal is received from the MAC layer for transmission on the
channel. During transmission, copies of the packet are distributed by the channel
to all interfaces residing on the channel. Whether a particular interface receives
the packet is determined by each network interface’s information and radio
propagation model that simulate the physical nature of wireless communication.
The simulation parameters for this thesis are described in Table 2. Identifying the
correct parameters for the simulation is essential for realistic analysis of the
study. There are two MAC layer protocols implemented for mobile networks,
802.11 and TDMA. However, the simulation for this thesis is based on IEEE
802.15.4 protocol which is part of the NS2 contributed code.

Traffic parameters
Traffic type Constant Bit Rate (CBR) application based on simple User Datagram
Protocol (UDP). Using CBR allows the network to be tested for
congestion that will affect delivery ratio.
Active flow Active flow is the communication that is established between a node and
the coordinator. Fifteen active flows are used for our simulation.
Packet size This is the payload of a packet that excludes the MAC and PHY layer
headers.
Traffic direction All the traffic flow from various nodes to the PAN coordinator.
Node parameters
No. of nodes There are total of 25 nodes and one of them being the PAN coordinator.
Node movement Two types of scenario will be simulated, stationary nodes and node
movements in ocean environment.
Node position The nodes are placed 15m apart form each other. The PAN coordinator is
the node at the center.
Physical parameters
Radio
Propagation
Model
There are three models supported, Free-space, Two-ray ground and
shadowing model. Given that nodes may not have direct line-of sight and
communication range is limited, the radio propagation model for our
simulation is the Two-ray ground model approximation assuming
reflection off a flat plane.

37

Antenna The antenna used is omni-directional having unity transmitter and
receiver gain.
Path loss The path loss is defines as the attenuation during transmission due to
factors like antenna height, obstruction and etc. It is assumed that there is
no attenuation and hence the path loss is 1.
Routing layer parameters
Queue type DropTail is the queue type employed that implements the “First in First
out” techniques. Packets entering the queue will be executed first and
once the queue limit is reached, last packet entering the queue will be
dropped.
Queue length The queue length of 100 packets is used as the default parameter. With a
WPAN, a large queue length is not required as the data rate is low.

Table 2. Simulation Parameters

4. Setting User Parameters in NS2

For any simulation run, there is a set of control parameters to be specified
by the user as well as output parameters that need to be analyzed. As mentioned
earlier, the scenario which defines the environment is included in the movement
pattern file and communication pattern file (detailed in the following section). The
configuration file is essentially a script that consists of a general format that can
be used to simulate any kind of routing protocol. The script begins with the
definition of the wireless physical medium parameters and initialization of
simulation parameters. After setting up the initial parameters, the simulator
objects will be set up where the simulator instance, trace object for the network
simulator and network animator as well as the General Operations Director
(GOD) will be created. GOD is a simulator object, which is used to store global
information about the state of the environment, network, or nodes. The topology
is also defined where a load_flatgrid object specifies a 2-D terrain. Next, the
properties of individual mobile nodes in the ad hoc network are defined as shown
in table 2. Each node is then attached to the channel with movement and traffic
specified in the movement pattern file and communication pattern file
respectively. Finally, information to end the simulation is included. A sample of
the script used for the simulation is attached in Appendix D.

38

5. Post Analysis

At the end of the simulation, the two generated files can be used for
performance analysis. The Network Animator file (*.nam) is utilized by the
Network Animator (NAM) which is a Tcl/TK based animation tool for viewing
network simulation traces and real world packet traces [31]. It is created to allow
accommodation of large animation data sets and adaptable to different network
visualization situations. Simple animation event commands are read from nam
files to minimize memory usage. NAM supports topology layout, packet level
animation and various data inspection tools. Upon startup, NAM will read the
nam file and create the topology followed by displaying the layout on a window.
Through the user interface, NAM provides several functions to control the
animated simulation. A screenshot of NAM is shown in Figure 21.











Figure 21 – NAM Application Window

There are two types of trace formats that can be used in NS2. The trace files
obtained from the simulation contains the packet dumps between nodes
communication. The old format for wireless simulation traces begins with either
39

one of the characters s, r, D or f to denote sending, receiving, dropping and
forwarding (i.e. node not originator) a packet respectively. The old trace format is
as shown in Table 3.

Event Abbreviation Type Value
%.9f %d (%6.2f %6.2f) %3s %4s %d %s %d [%x %x %x %x]
%.9f _%d_ %3s %4s %d %s %d [%x %x %x %x]
double Time
int Node ID
double X Coordinate (If Logging Position)
double Y Coordinate (If Logging Position)
string Trace Name
string Reason
int Event Identifier
string Packet Type
int Packet Size
hexadecimal Time To Send Data
hexadecimal Destination MAC Address
hexadecimal Source MAC Address
Wireless
Event

Commence
with :
s: Send
r: Receive
D: Drop
f: Forward

hexadecimal Type (ARP, IP)

Table 3. NS2 Trace Format for Wireless Packet

As a part of the effort to merge wireless traces, a new trace format [32] has been
introduced. This revised format supports backward compatibility with previous
trace formats and is divided into the following fields. The type field is used to
differentiate among different types of traces. As with the old format, the new
format has similar field types. Typically, the field type is followed by general flag
(-t) and sets of flag/value pairs with the first alphabet of the flag type
representing node property (N), IP level packet information (I), next hop
information (H), MAC level packet information (M) and packet specific information
(P) shown in Table 4.

40

Event Abbreviation Flag Type Value
-t double Time (* For Global Setting)
Next hop information
-Hs int Hop source node ID
-Hd int
Hop destination Node ID
-1: the packet is a broadcast packet
-2 destination node has not been set
Node properties
-Ni int Node ID
-Nx double Node X Coordinate
-Ny double Node Y Coordinate
-Nz double Node Z Coordinate
-Ne double Node Energy Level
-Nl string Network trace Level (AGT, RTR, MAC, etc.)
-Nw string Drop Reason
Packet information at MAC level
-Ma hexadecimal Duration
-Ms hexadecimal Source Ethernet Address
-Md hexadecimal Destination Ethernet Address
-Mt hexadecimal Ethernet Type
IP Trace
-Is int.int Source Address And Port
-Id int.int Destination Address And Port
-It string Packet Type (cbr, tcp, …)
-Il int Packet Size
-If int Flow ID
-Ii int Unique ID
-Iv int TTL Value
Packet info at Application level
-P string Packet Type (arp, dsr, imep, tora, etc.)
Wireless
Event
s: Send
r: Receive
d: Drop
f: Forward
-Pn string Packet Type (cbr, tcp, …)

Table 4. NS2 New Trace Format for Wireless Packet

Depending on the packet type, the trace may log additional information. For the
simulation performed, there are three packet types, ARP, CBR and AODV. The
format for the ARP, CBR and AODV trace are shown respectively in the tables
below.
41






Table 5. ARP Trace Format










Table 6. AODV Trace Format





Table 7. CBR Trace Format

For analyzing the performance of IEEE 802.15.4, information has to be extracted
to compute the performance parameters from trace files using AWK or Perl
script. AWK is a programming language designed for processing text-based data,
either in files or data streams. Perl is a dynamic programming language that
complements AWK to allow processing of repetitive simulation runs. Both
Event Flag Type Value
-Po string Request or Reply
-Pms int Source MAC Address
-Ps int Source Address
-Pmd int Destination MAC Address
ARP
Trace
-Pd int Destination Address
Event Flag Type Value
-Pt hexadecimal Type
-Ph int Hop Count
-Pb int Broadcast ID
-Pd int Destination
-Pds int Destination Sequence Number
-Ps int Source
-Pss int Source Sequence Number
AODV
Trace
-Pl double Lifetime
-Pc string Operation (REQUEST, REPLY, ERROR, HELLO)
Event Flag Type Value
-Pi int Sequence Number
-Pf int Number Of Times Packet Forwarded
CBR
Trace
-Po int Optimal Number Of Forwards
42

languages are available in standard UNIX environment. Java program can also
be implemented to analyze the trace files.

B. GENERATING OCEAN ENVIRONMENT SCENARIOS

As the above mobility models do not correctly represent the oceanic
environment, there is a need for other means to generate the movement pattern
file. Another alternative is to compute node movements using actual surface
current measurements. In NS2, movement files are generated from mobility
models or by using node movement generator. The node-movement generator
allows configuring of nodes movement at particular time and is available under
~ns/indep-utils/cmu-scen-gen/setdest directory consisting of setdest{.cc,.h} and
Makefile. The setdest function can then be used to create the movement
scenario for NS2. The other part of the scenario is to define and generate the
communication pattern file.

1. Near Real-Time Monterey Bay Surface Currents

Near real-time coastal surface current data of the Monterey Bay
(California) are made available from a collaboration between the Naval
Postgraduate School, University of Delaware and Monterey Bay Aquarium
Research Institute [33]. Four High Frequency (HF) radars at different locations
measure the currents and the measurements are objectively mapped to fill gaps
in space and time. Mapping is required due to environment factors causing
unavailability and spatial coverage of the HF radar measurements. The results of
hourly mapped total vectors will be used for the computation of node movements.
The ASCII data files contains the hourly data of pre-determined locations in
latitude/longitude (lat/long) with the vector speed (cm/s) shown in Figure 22.


43











Figure 22 – Data points of Monterey Bay

2. Determining Mobility Using Actual Measurements

A sample data set (dated 30 January 2005) of the Monterey bay area was
taken to simulate the nodes’ movement. Since the variation is small across each
time step, the hourly velocities are linearly interpolated for the entire day at a time
interval of 10 minutes. Computation was performed for an entire day at a time
interval of ten minutes. Basically, the velocity vectors of the data points nearest
to the node were referenced to provide a random velocity from a normal
(Gaussian) distribution. The randomness was included to account for turbulent
diffusion and was applied to the node. This turbulent motion included the
meandering of the current, tides, waves, and random motion which caused the
nodes to disperse. The next position of the node was computed and the
computation was repeated until the end of the day. The following sub-paragraphs
detail the steps (performed using Microsoft Excel) to compute a node movement
when placed within the Monterey Bay area.

Step 1: The initial position (lat/long) of the node is searched through
the data files for nearest data points beginning at 0000hrs.

44

Step 2: The velocity of the data points nearest to the node were
referenced and a random velocity was generated from a
normal (Gaussian) distribution which was applied to the
node. This velocity then computed the distance and
direction of the next position for a period of 10 minutes.

Step 3: The coordinates of the next position were computed using
the formula [34] given below. The computation repeated
until the boundaries of the bay were exceeded or simulation
time (one day) was reached.

( )
c
t d x d x x Latitude cos sin ' cos cos ' sin arcsin ) ( + = (1)
( ) ( ) π π π − + − = 2 , cos / sin sin arcsin ' mod ) ( x d t y y Longitude
c
(2)

.
, tan
, '
, '
radians in heading course true the is t
radians in ce dis the is d
location current the of longitude the is y
location current the of latitude the is x
where
c


The result of simulating 25 nodes placed 10m apart from adjacent nodes within
the Monterey Bay is shown in Figure 23. Initially, nodes can be seen to be
moving towards the shore and around 1100hrs, nodes start to drift out towards
the ocean. Nodes are gradually dispersing away from each other until the end of
the day. Such a dispersing behavior is consistent with the meandering of the
current, tides, waves, and random motion. Also, since the nodes are within the
bay area, the movements are very much dominated by tidal currents. This
pattern is unique which cannot be correctly modeled by any models. Hence, the
data (node position at various times and speed) obtained from the computation
will be used for the simulation.
45















Figure 23 – Node movements in Monterey Bay


3. Generating Movement Pattern File

A movement pattern file is required as an input to NS2 for the simulation.
An external script (see Appendix B) is implemented to parse the computed
movement data and generate the mobility file. The script is written in Tool
Command Language (TCL) and essentially functions to format the data into the
movement file. The movement file consists of initial position of each node (two
dimensional) and the “setdest” commands for each movement change at
stipulated time. Subsequently, the formatted file can be used to calculate
information for GOD (General Operations Director) object which can also be
present in the movement. The “calcdest" function (found in ~ns/indep-utils/cmu-
scen-gen/setdest/ directory) is used in which information of the GOD object is
computed and loaded into the movement file. The GOD object is initially used to
store global information about the state of the environment, network, or nodes
Initial Position
(Longitude)
(Latitude)
Monterey
Bay
46

but currently stores an array of the shortest number of hops required to reach
from one node to another. The calculation is performed in advance to minimize
computation time required during simulation.






















Figure 24 – Process of Generating Mobility File

Figure 24 depicts the process and results generated from the script. It was
discovered that the nodes had to be arranged in an anti-chronological order for
the correct execution of “calcdest” function. The script below is modified from a
sample script provided by Matthias Budde in the NS forum, customized to our
computed data. This script essentially parses the numerous data generated by
the node movement computation using the “Tclsh” command. “Tclsh” is a shell
like application that reads and evaluates TCL commands from standard input or
a file. Data points are extracted and arranged in the required format of the
Computed data
(tclsh parse.tcl)
(calcdest –n <node #> -t <simulation
time> -I <input file> -o <output file>)
Mobility file
47

movement file. The computed movement data have to be arranged in anti-
chronological order for subsequent computation of GOD object.

4. Generating Communication Pattern File

The communication pattern file essentially describes the packet workload
presented at the network layer during simulation. A TCL script is modified from a
constant bit rate generation script file [35] specifically design for star topology.
The modification includes change to generate traffic at an interval of 10 minutes
which coincide with node movements where nodes will be randomly selected to
transmit data to the PAN coordinator (see Appendix C). The script can be
executed using “ns” command, followed by optional parameters. These
parameters specify the traffic type (cbr or tcp), number of nodes in the scenario,
seed for generating random traffic pattern, maximum traffic flow, traffic rate, start
time, end time and the time gap between consecutive transmissions. The traffic
scenario is then piped to a communication pattern file.

C. PERFORMANCE METRICS

In this thesis, the performance of IEEE 802.15.4, in particular, the Quality
of Service (QoS) is to be evaluated against the oceanic environment. The QoS is
determined by a set of service requirements that the network must fulfill when
transporting packet streams from a source to its intended destination. Due to the
mobility and dynamic nature of the MANET, resources might not always be
available and parameters such as throughput, delay and packet drop have to be
considered. Essentially, two scenarios are used for the simulations, stationary
nodes and mobile nodes floating on the ocean. Three performance metrics will
be used to determine the QoS provided by IEEE 802.15.4. A detailed explanation
of these metrics is as follows:

48

1. Packet Delivery Ratio

Packet Delivery Ratio (PDR) is the quotient resulting from the number of
successful delivered CBR packets to those generated by CBR sources within the
simulation period. It is an important metric which indicates congestion level of the
network. PDR measures the protocol performance from loss ratio experienced at
the network layer that is affected by factors such as packet size, network load
and effects of movement resulting in frequent topological changes. Higher PDR
implies that packet loss rate is lower and protocol is more efficient from the
perspective of data delivery. A point to note is that late packet received could be
deemed useless even with high PDR.

=
packets CBR d transmitte of Number
packets CBR received of Number
PDR veryRatio PacketDeli ) ( (3)


2. Average Network Delay

Network delay is the time delay experienced by a connection between
nodes. This delay includes all possible delays that are caused by route discovery
latency, queuing in the interface queue, retransmission at the MAC layer and
propagation through the environment. This delay can be computed as the
difference in time from transmitting packets from a source to the arrival of
packets at the destination node. All the connection delays are aggregated and
the average network delay is the aggregated delay divided by the number of
connection pairs throughout the simulation.

( )
pairs connection of number Total
Time Time
Delay Network Average
source sent packet dest arrive packet

=
@ @
(4)


49

3. Network Throughput

The network throughput determines the amount of data that is transmitted
from a source to a destination node per unit time (bits per second). While
ignoring the overheads in the network, only the data of the CBR packets are
considered. Node throughput is a measure of the total number of data packets
successfully received at the node, having the total number of bits is computed
over the simulation runtime. The network throughput is then derived from the
average throughput of all nodes involved in the CBR packet transmission.

time Simulation
node by received bits Total
Throughput Node = (5)

nodes of number Total
on transmissi CBR of s Throughput Node
Throughput Network

= (6)






















50






















THIS PAGE INTENTIONALLY LEFT BLANK

51

IV. SYSTEM SIMULATION AND RESULTS
This chapter identifies additional parameters to be used in the simulation
with reference to a Zigbee transceiver as well as the analysis of IEEE 802.15.4
against the performance metrics. The performance metrics are used in deriving
the performance specific to mobility, node density and network loading. The
simulation is reiterated over several runs until certain conclusions can be drawn
to determine the feasibility of employing IEEE 802.15.4 technology in the ocean
environment.

A. SPECIFIC TRANCEIVER PARAMETERS

Besides physical parameters defined in the previous chapter, the
specification of the transceiver plays an important role in determining the
communication range of the nodes. The power parameter is based on the
specification of Crossbow MICAz processor and radio platform (MPR2400CA).

1. Transmitted Power (Pt_)

The transmitted power is the power that is transmitted from the antenna
into space. In Annex F [4], the document states the IEEE 802.15.4 regulatory
requirements that for the ISM band 2.4 GHz operating in United States,
transmitted power of up to 1 watt is provided. Although IEEE 802.15.4 devices
are generally envisioned to operate with a maximum transmit power of
approximately 0 dBm (1mW), a minimum of +10 dBm (0.01W) is allowed in this
band. The crossbow RF transceiver has power of -24 dBm to 0 dBm, hence
1mW for Pt_ will be used in the simulation.
mW dBm Pt 1 0 _ = = (7)

52

2. Receiver Threshold (RXThresh_)

The receiver threshold is the parameter used to specify the
communication range of the wireless nodes and the threshold is the minimal
power of the packet required for successful reception. If a packet reaches a node
with a power level above the receiver threshold, the receiver will be within the
transmission range of the sender. The receiver sensitivity for the crossbow
transceiver is -94 dBm typical. Taking the typical receiver sensitivity, the receiver
threshold is -94 dBm which is equivalent to 3.981 × 10
-13
W.
W dBm RxThresh
13
10 981 . 3 94 _

× = − = (8)

3. Carrier Sensing Threshold (CSThresh_)

The carrier sensing threshold describes the sensing range of a node.
When the received packets have a power level below the receiver threshold but
above the carrier sensing threshold, the receiver is within the carrier sensing
range but decoding of the packet is not guaranteed. The sensing range of a node
is usually greater than the transmission range. Hence, it is assumed that the
carrier sensing threshold value is at least the receiver threshold.
W RxThresh CSThresh
13
10 981 . 3 _ _

× = = (9)

4. Capture Threshold (CPThresh_)

During packet transmission, it is possible that two packets can
simultaneously arrive (i.e. collision) at the receiving node. In NS2, only packets
received in the carrier sensing range of a receiver are considered as potential
sources of packet collisions. The capture threshold determines if a packet is
successfully received by comparing the power ratio of both packets. The packet
with the highest ratio that is greater than the capture threshold is chosen. The
53

capture threshold (CPThreshold) is assumed to be 10 dB in the simulations
which is a common value used in most simulations.
dB CPThresh 10 _ = (10)

5. Antenna Height

For the simulation environment, the antenna of a particular node will be
mounted on a floating buoy. Assuming that the buoy has a diameter of 1 m and is
partially submerged, the antenna will be at a height of approximately 0.5m. In
NS2, the antenna is defined as a set of three dimensional coordinates with the z
dimensional coordinate being antenna height.
m Z
m Y
m X
5 . 0 _
0 _
0 _
=
=
=
(11)

6. Propagation

There are 4 types of models used in NS2 to represent the radio
propagation properties of the environment, namely the free space, two-ray
ground, Ricean, Rayleigh and shadowing models. The free space model is a
large scale model where the received power is dependent on transmitted power,
antenna gains and the range between communicating nodes. The model
essentially accounts for the decrease in power as the range increases. As with
free space model, the two-ray ground model is also a large scale model. The
difference being that the two-ray ground model considers the received power
from both the direct path and a ground reflection path. However, a limitation
posed in NS2 is that both the communicating nodes have to be of the same
height. Both the Ricean and Rayleigh are fading models that describe the
propagation effect of a RF signal in a defined environment. Rayleigh fading is
most applicable when there is no line of sight between communicating nodes
54

while Ricean fading is more applicable if there is a line of sight. Finally, the
shadowing model assumes the average received signal power decreases
logarithmically with distance. A Gaussian random variable is added to the path
loss to account for environmental influences at the sender and the receiver.
Considering the complex ocean environment, the propagation may vary in
different location. For simplicity, the two-ray ground model is selected. According
to the two-ray ground propagation model, the sensing range of the device is
computed to be 112m.

B PERFORMANCE ANALYSIS

In practice, node movements in the ocean will result in the network having
to re-learn optimum routes. Several experiments are conducted to analyze the
behavioral response of the IEEE 802.15.4 network, utilizing a Zigbee transceiver
that is operating at the 2.4 GHz frequency band. Essentially, the influence of
mobility, node density and network loading on the network will be studied. In
particular, the network’s packet delivery ratio, delay and data throughput
performance are measured with varying transmission rates. The performances
resulting from the metrics are presented with moving scenarios. To increase the
confidence level of the results, a set of simulation parameters are performed with
various random seeds for the data transmission. However, running the scenarios
required long simulation hours for node movements within a day.

1. Simulation Setup and Parameters

Wireless networks based on IEEE 802.15.4 are designed for low data rate
and low power consumption devices. Depending on the operating requirements
and environment, there has to be compromises between the node transmission
range, operational lifespan and device cost. The transmission range can be
determined from Friss two-ray ground reflection models which relates the
55

maximum range to the antenna gain, transmit power and receiver sensitivity.
With the Crossbow MICAz processor and radio platform, the maximum range is
computed to be approximately 112m. Since the nodes are highly mobile, this
range will determine if a data packet can successfully arrive at the destination
node. The data traffic type is Constant Bit Rate (CBR) with the application agent
sending at a rate of 20 data packets per second continuously. The nodes used in
the simulation will be placed at predetermined distances from adjacent nodes
covering an area of 40m by 40m. The centre node is designated the PAN
coordinator with all other nodes randomly transmitting data packets to the PAN
coordinator. The speed and heading of each node will vary according to the
generated ocean movement with a maximum simulation runs of 12 hours. The
simulations are conducted with the typical parameters shown in Table 8.

Simulation Parameters
Protocol AODV
Simulation Time 1hr, 3hrs, 6hrs, 9hrs, 12hrs
# of Nodes 9, 16, 25
Map Size 4500m × 4500m
Speed Varying from 0.006m/s-0.47m/s
Mobility Model Actual Measurement Model
Traffic Type Constant Bit Rate (CBR)
Packet Size 20 bytes
Connection Rate 0.05 to 5 packets per second

Table 8. Simulation Parameters

During the simulation, certain behaviors are exhibited by the nodes if
communication cannot be established with the coordinator. When a node losses
synchronization, orphan-scanning is performed to relocate the coordinator. When
coordinator relocation is successful, communication will resume. If relocation of
the coordinator fails, node will subsequently perform active channel scan to send
association request to the PAN coordinator. Upon successful association, the
56

node begins to transmit beacons and start data transmission. Else, non-beacon
mode is enabled for that node.

2. Influence of Node Density

In an ocean environment, the number of nodes providing coverage in an
area of operation will determine the performance of sensors (i.e. detection range)
used in the nodes and ultimately derive the cost of operation. As such, the
performance of the network is measured with varying node densities to ascertain
the impact. In this set of simulations, the node density is increased from 9, 16
and 25 nodes within operational coverage of 40m × 40m. Figure 25 shows the
initial node placement within the operating area.












Figure 25 – Initial Coverage with 9, 16 and 25 Nodes
13 12
11 9
7 6 5 4
3
15 14
10 8
2 1 0
PAN coordinator
16 nodes covering 40m x 40m
8 7 6
5 4 3
2 1 0
9 nodes covering 40m x 40m
PAN coordinator
24 23
22 21 20
19 18
17
16
14 13
12
11
10
9 8
7
6
5
4 3
2 1
0
25 nodes covering 40m x 40m
PAN coordinator
57

Three sets of scenarios, namely the 1, 3 and 6 hours runtimes, will be used as a
basis of comparison with CBR traffic at a data rate of 0.1 packets per second.
For each scenario set, the number of connections is set to 8, 14 and 20
respectively where all nodes are transmitting packets to the PAN coordinator.
The designated PAN coordinator and nodes positions after the respective
simulation runtime are shown in Annex G. The rest of the simulation parameters
remain relatively unchanged. Table 9 summarizes the simulation parameters for
this set of simulations.

Simulation Parameters
Protocol AODV
Simulation Time 1hr, 3hrs, 6hrs
# of Nodes 9, 16, 25
Max Node Connect 8, 14, 20
Map Size 4500m × 4500m
Speed Varying from 0.006m/s-0.47m/s
Mobility Model Actual Measurement Model
Traffic Type Constant Bit Rate (CBR)
Packet Size 20 bytes
Connection Rate 0.1 packets per second

Table 9. Simulation Parameters for Node Density Analysis

In general, due to the highly dynamic nature of node movement, low density may
cause the network to be frequently disconnected resulting in a low throughput.
The experimentation goal is to determine the network scalability rather than to
find the optimal node density. Figure 26 shows the simulation results which
demonstrate the performance metrics using different node densities. An
interesting observation is that after an hour of simulation, the packet delivery ratio
(PDR) remains close to 100% despite the difference in node densities. This is
due to the node transmission range and also the dispersion of nodes since the
movements remains insignificant. As the simulation time approaches three hours,
there is a slight reduction in PDR but still well within the 90
th
percentile range.
58

Ave Network Delay vs Node Density
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
1 3 6
Simulation Time (hours)
(b)
A
v
e

N
e
t
w
o
r
k

D
e
l
a
y

(
s
) 25 nodes
16 nodes
9 nodes
Thereafter, the PDR falls below 90%.


































Figure 26 - Results of Varying Node Density with (a) PDR (b) Average network
delay and (c) Network Throughput
Packet Delivery Ratio vs Node Density
0
20
40
60
80
100
120
1 3 6
Simulation Time (hours)
(a)
P
a
c
k
e
t

D
e
l
i
v
e
r
y

R
a
t
i
o

(
%
)
25 nodes
16 nodes
9 nodes
Network Throughput vs Node Density
0
10
20
30
40
50
60
1 3 6
Simulation Time (hours)
(c)
N
e
t
w
o
r
k

T
h
r
o
u
g
h
p
u
t

(
b
p
s
)
25 nodes
16 nodes
9 nodes
59

An interesting observation is that the density of 16 nodes performs better as
compared to the others, which is unexpected. This could be due to the maximum
number of connections in each scenario. Since all the packets are effectively
sent to the PAN coordinator, the 25-node configuration means that more packets
are sent to the PAN coordinator resulting in collisions. As for the 9-node
configuration, the PDR reduces as the simulation time increases due to the
spreading of node movement. The delay measured is the average transmission
time of all data packets. The 25-node configuration experiences the most delay
since some of the packets are required to be forwarded by adjacent nodes before
reaching the PAN coordinator. Also, as the nodes are much dispersed at the
three hours simulation time, the effect is multiplied resulting in an increased in
average network delay. The throughput effectively determines the amount of
data that is transmitted and successfully received during the simulation time. In
general, the network throughput increases cumulatively as the time increase. At
the 6 hours, the network throughput of the 16-node configuration can be seen to
perform better than the 25-node configuration. This observation reinforced the
earlier PDR observation since more data is received at the destination.
Effectively, the node density directly influences the achievable network
throughput. The above findings have indicated the node density does influence
the performance of 802.15.4. An ideal node configuration has to be determined
considering the operational area as well as the nodes dispersion in the ocean.

3. Influence of Network Loading

In this simulation, the influence of network loading is studied. The emphasis is on
the behavior of the network since IEEE 802.15.4 is primarily designed for low
bandwidth applications. However, depending on the operational needs, a higher
loading might be required in certain situations. The data rate is gradually
increased from 0.005 packets per second to 50 packets per second in the three
60

node configuration scenarios. As in previous simulation, the parameters used
remains are relatively unchanged. Table 10 summarizes the simulation
parameters for this set of simulations.

Simulation Parameters
Protocol AODV
Simulation Time 1hr
# of Nodes 9, 16, 25
Max Node Connect 8, 14, 20
Map Size 4500m × 4500m
Speed Varying from 0.006m/s-0.47m/s
Mobility Model Actual Measurement Model
Traffic Type Constant Bit Rate (CBR)
Packet Size 20 bytes
Connection Rate 0.005 - 50 packets per second

Table 10. Simulation Parameters for Network Loading Analysis

Since all nodes have the PAN coordinator as the destination, the increase in
network loading will increase the probability of collision at the PAN coordinator.
Figure 27, 28 and 29 depict the effects of network loading on the performance
metrics by increasing the connection rate from 0.05 to 50 packets per second.
The packet delivery ratio generally has a declining trend for the three node
configurations when the connection rate is increased. It can be observed that the
packet delivery ratio remain in the 90
th
percentile range till a specific data rate
(approximately 0.3 packets per second, 0.75 packets per second and 1.5 packets
per second for the 25, 16 and 9 nodes scenario). Thereafter, the packet delivery
ratio performance decreases exponentially for higher data rates indicating that
the network is congested. As the data rate increases, more packets will be
dropped due to collision and bad link quality of transmitted packets. The resulting
effect is the exponential increase in re-transmission of packets and hence further
congesting the network. An ideal operating data rate can determine the efficiency
of data delivery. For the above reason, regardless of the operational needs, the
61

Packet Delivery Ratio vs Data Rate
0
10
20
30
40
50
60
70
80
90
100
0 10 20 30 40 50 60
Data Rate (pkts/s)
P
a
c
k
e
t

D
e
l
i
v
e
r
y

R
a
t
i
o

(
%
)

25 nodes configuration
16 nodes configuration
9 nodes configuration
application has to maintain a low data rate. In the worst case scenario, the IEEE
802.15.4 protocol cannot be used for data rates above 0.3 packets per second in
which performance will be unacceptable.













Figure 27 - Results of Packet Delivery Ratio with Varying Data Rate

Theoretically for network delay, the increase in data rate will increase the time for
the data packet to reach the intended destination. However, the average network
delay from Figure 28 can be seen to be generally low, fluctuating between 0 to
0.6 second. The peaks at low data rate experienced by both the 16-node and 25-
node configuration could be due to the time required for packets to be forwarded
from outer modes to the destination. The 9 nodes configuration is not affected
since packets are sent directly to the PAN coordinator. At higher data rates,
collision will occur. However, computation of average network delay does not
consider dropped packets hence the delay reduces. Overall, the 25-node
configuration experiences a higher delay as compared to the other
configurations.

62

Ave Network Delay vs Data Rate
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
0
.
0
0
5
0
.
0
1
0
.
0
5
0
.
1
0
.
2
0
.
3
0
.
5
0
.
6
0
.
8 1 3 5 8
1
0
3
0
5
0
Data Rate (pkts/s)
A
v
e

N
e
t
w
o
r
k

D
e
l
a
y

(
s
)
25 nodes configuration
16 nodes configuration
9 nodes configuration
Network Throughput vs Data Rate
0
50
100
150
200
250
300
350
400
450
0 10 20 30 40 50 60
Data Rate (pkts/s)
N
e
t
w
o
r
k

T
h
r
o
u
g
h
p
u
t

(
b
p
s
)
25 nodes configuration
16 nodes configuration
9 nodes configuration










Figure 28 - Results of Average Network Delay with Varying Data Rate











Figure 29 - Results of Network Throughput with Varying Data Rate

Figure 29 highlights the throughput analysis of the network. The impact on the
throughput is apparent with different node configurations. It is observed that the
network throughput increases linearly as the data rate is increased till a certain
throughput for each configuration. Subsequently, the throughput remains almost
63

stagnant (gradual increase), possibly due to network congestion. The peak
performance can be considered to be in the region of 5 to 8 packets per second.
The 9-node configuration will have the highest throughput since all configurations
has similar data rate but require less time for data to reach the destination.

4. Influence of Mobility

For the analysis of mobility effects on the network, the performance
metrics are measured at various time intervals of the simulation and for the three
node configurations. Since object movements, especially vessels or divers, in an
ocean environment are relatively slow and do not change direction rapidly, a low
data rate is considered. The movement of individual nodes will follow the path as
computed from actual ocean data with the application agent transmitting at 0.01
packets per seconds, which is below the 0.3 packets per second data rate where
the performance is deem acceptable.








Figure 30 – Node Movements after 1 hour

To accommodate the node movements, a map size of 4500m × 4500m is
considered for the simulations. The AODV routing protocol is applied to all
PAN coordinator
64

Packet Delivery Ratio vs Movement in Time
0
20
40
60
80
100
120
1 3 6 9 12 18 24
Simulation Time (hours)
P
a
c
k
e
t

D
e
l
i
v
e
r
y

R
a
t
i
o

(
%
)
25 nodes configuration
16 nodes configuration
9 nodes configuration
scenarios with the simulation runs varied at intervals in the region of 1 to 24
hours. An illustration of node mobility in the Network Animator (NAM) is shown in
Figure 30 where the 25 nodes are dispersed after an hour of simulation. The
node positions at various intervals of the three node configurations are as
appended in Annex G.

The packet delivery ratio for this simulation is shown in Figure 31. The result
shows that both the 25-node and 16-node configurations can achieve a PDR of
approximately 80% and higher throughout the entire simulation. The 25-node
configuration does not perform as well possibly due to more collisions that occur.
Comparatively, the 9 nodes configuration has the worst results where the PDR
reduces from above 80% till about 20% at the end of the 24 hours simulation.
Intuitively, the PDR is expected to drop in the 9 nodes configuration since each
node is required to provide a much larger coverage as the ocean current caused
the nodes to be spread further apart.









Figure 31 – Results of Packet Delivery Ratio with Node Movement in Time

65

Ave Network Delay vs Movement in Time
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1 3 6 9 12 18 24
Simulation Time (hours)
A
v
e

N
e
t
w
o
r
k

D
e
l
a
y

(
s
)
25 nodes configuration
16 nodes configuration
9 nodes configuration
Network Throughput vs Movement in Time
0
5
10
15
20
25
30
1 3 6 9 12 18 24
Simulation Time (hours)
N
e
t
w
o
r
k

T
h
o
u
g
h
p
u
t

(
b
p
s
)
25 nodes configuratin
16 nodes configuration
9 nodes configuration
Figure 32 shows the results for the network delay and throughput. In general, the
network latency for the three configurations is below 0.1 seconds after the three
hour simulation. The latency for the 9-node configuration is much lower since all
nodes transmit directly to the PAN coordinator. An interesting observation is that
in the first hour, the delay of network is comparatively higher in the 16-node
configuration than the 25-node configuration. This behavior is attributed to the
PAN coordinator being placed in an asymmetric position in the 16-node
configuration as well as the distance between adjacent nodes.

















Figure 32 – Results of Network Delay & Throughput with Node Movement in Time
66

The network throughput in general, increases steadily over the entire simulation
time. There is however a reduction in the throughput for the 9-node configuration
scenario at the ninth hour. Since the trace files are too large to be analyzed, a
probable reasoning can be deduced from the node positions. From Figure 33, the
node positions of the 9-node configuration indicate that the PAN coordinator has
drifted away from the other nodes in the ninth hour. Considering the sensing
range, all the packets have to be routed through Node 1 to the PAN coordinator
which results in the throughput reduction.







Figure 33 – Positions of 9 Nodes Configuration at the 9
th
Hour.

5. Drop Packet Analysis

As discussed in the above findings, packet drops will affect the system
performance. Hence, an analysis is performed to study the likely cause for
packets to drop. From certain trace files which are smaller in file size, it was
observed there are two drop reasons that are of interest. In the network, packet
drops are due to IFQ and LQI that occur frequently during data transmissions.
IFQ is prompted when transmission rate exceeds the capacity of the queue.
When that happens, the packets that join the queue first are serviced while the
last is dropped (FIFO). A packet drop caused by LQI indicates that the link quality
of packets arrived at the MAC layer is not within the acceptable threshold of the
8
7
6
5
4
3
2
1
0
9 nodes positions after 9 hrs
PAN coordinator
93.12m
93.59m
67

CPThresh value. Such a drop is mainly caused when nodes have drifted apart.
Hence, to reduce packet drops in the network, the queue length or the
transmission range can be increased. Both queue length and transmission range
is a hardware limitation determine by the buffer size and the transceiver on the
device.

C. SUMMARY

In this chapter, simulations are conducted to analyze the performance of
IEEE 802.15.4 in an ocean environment. The results based on the performance
metrics of node density, network loading and mobility influences are discussed.
In general, the network performance is very much affected by the node
movements in the ocean. However, with the right selection of parameters,
operating IEEE 802.15.4 is possible in ocean environment. However, these
results cannot be applied in general as the mobility model only reflects the ocean
condition at the Monterey Bay. In reality, the mobility of nodes will differ
depending on the location. The next chapter concludes the analysis and the
findings as well as recommendations for future possible research areas.
68






















THIS PAGE INTENTIONALLY LEFT BLANK








69

V CONCLUSIONS, RECOMMENDATIONS AND FUTURE
WORK
A. CONCLUSIONS

This thesis is focused on determining the performance of IEEE 802.15.4
protocol in an ocean environment, in particular the surface current causing
movement of floating nodes. A detailed study on the IEEE 802.15.4 architecture
and the layered structure as well as the simulator environment has been
conducted. All the simulations are conducted using open-source software,
Network Simulator (NS2). Although mobility models are available in NS2, there
are no suitable models to represent node movements in the ocean environment.
Hence, actual measured ocean data of the Monterey Bay area is used as a basis
for computing the movements. As the behavior of surface current differs from
locations, the results from the analysis can only be representative of the
Monterey Bay area.

For the purpose of conducting a near realistic simulation, the Zigbee transceiver
parameters used are based on the specification of Crossbow MICAz processor
and radio platform (MPR2400CA) which operates at 2.4 GHz. All the parameters
are then incorporated into the TCL scripts. A detailed performance study is
performed to determine the performance of IEEE 802.15.4, in particular to the
performance metrics. The simulation results have indicated that the network
performance is very much affected by the node movement in the ocean. Also,
such technology can be successfully deployed for low data rate applications.
However, by selecting an appropriate node configuration and network
parameters such as data rate and transmission power, the network performance
can be further optimized.

70

B. FUTURE RESEARCH AREAS

The results from the simulation have provided some insights into the use
of IEEE 802.15.4/Zigbee wireless technology in an oceanic environment. Due to
the time constraint and learning curve for NS2, certain simulation parameters are
assumed and several features have not been studied. Hence, there are still other
open research problems that are not addressed and also the simulation
parameters in NS2 can still be further improved to represent the actual
environment and deployed devices for more realistic result. The following details
some key areas (non-exhaustive) for future research that can be used in future
thesis research work to either augment the results made in this thesis or
conducted in an independent thesis work.

1. Vertical Node Movement in Oceanic Environment

The current ocean model used in the simulation assumes a flat topology
and only considers the horizontal movement of the nodes. In the actual ocean
environment, the waves could cause lateral movements that result in intermittent
connection due to the line-of-sight between nodes. A 3D mobility model can be
created using the setdest function by defining the z parameter for the nodes.

2. Propagation Model

There is a need to refine the two-ray ground model used in the simulations
to represent the ocean environment. The ocean is a harsh environment for
propagating radio waves due to wave blockage, scattering and reflection of
signals by the ocean surface causing multipath propagation which results in
signal fading or signal loss. The Advanced Refractive Effects Prediction System
(AREPS) model [36] is currently in use by the Navy and can be used to accurate
71

model the RF propagation on the ocean surface. The APEPS model takes into
account factors that affect radio wave propagation in the maritime environment,
including atmospheric refraction and surface reflections.

3. Node Energy Consumption

One of IEEE 802.15.4’s features is the low-power consumption property.
Hence, power consumption of the node is vital which provides another dimension
to measure the performance. This can be accomplished by including an energy
model into the simulation and also implementing or modifying existing codes to
include low power mode. The energy consumption can then be investigated at
the mobile nodes.

4. Security Considerations for Network

There are certain security risks in utilizing IEEE 802.15.4 such as
eavesdropping, packet injection, replay, jamming and application vulnerabilities.
Some of these risks can be eliminated with three security options in IEEE
802.15.4. The confidentiality aspect is addressed through the use a stream
cipher encryption while integrity is addressed using a message integrity code
(MIC) to protect data from being modified without the appropriate cryptographic
key. The replay protection is implemented with the use of sequence number.
Although the inclusion of these security mechanisms is necessary, the impact of
the network performance has to be assessed.

5. Guaranteed Time Slot Management

GTS implementation is particularly effective for application that has timing
constraints where each device is allocated specific time duration for high priority
communication. The performance of IEEE 802.15.4 guaranteed time slot (GTS)
72

management scheme is not investigated in this thesis. Performance such as
bandwidth utilization and data transfer reliability can be investigated.






73

APPENDIX A – INSTALLATION OF NS2
The NS2 is designed to operate on UNIX based operating system but it is
also possible to run NS2 on Windows machine using Cygwin or on a VMware
server. The following detailed the step for installation.
1. Download the all-in-one package (ns-allinone-2.29.tar.gz) from
http://www.isi.edu/nsnam/ns/ns-build.html#allinone. The package contains
the necessary components as well as an install script.
2. A new directory is created (“mk ns”) and the compressed file is extracted
into the new directory (“tar -xzf ns-allinone-2.29.tar.gz”). After extraction,
change directory into ns-allinone-2.29 and run “./install”. The install script
will automatically configure, compile and install the components. If the
installation is successful, the below message will be received.









3. Navigate back to the root directory and there will be a .bashrc file. This is
the file to place the necessary path environment and a backup of this file
is created to allow restoration to original state if anything fails (“cp .bashrc
Please put /root/ns/ns-allinone-2.29/bin:/root/ns/ns-allinone-
2.29/tcl8.4.13/unix:/root/ns/ns-allinone-2.29/tk8.4.13/unix into your
PATH environment; so that you'll be able to run
itm/tclsh/wish/xgraph.
.
.
(1) You MUST put /root/ns/ns-allinone-2.30/otcl-1.12, /root/ns/ns-
allinone-2.30/lib, into your LD_LIBRARY_PATH environment
variable.
If it complains about X libraries, add path to your X libraries
into LD_LIBRARY_PATH.
If you are using csh, you can set it like:
setenv LD_LIBRARY_PATH <paths>
If you are using sh, you can set it like:
export LD_LIBRARY_PATH=<paths>

(2) You MUST put /root/ns/ns-allinone-2.29/tcl8.4.13/library into
your TCL_LIBRARY environmental variable. Otherwise ns/nam will
complain during startup.
74

.bashrc.origin”). Environment variables are variables that Unix keeps track
of at the shell level.
4. The .bashru file can be edited using gedit program and including the
following script (directory can be different depending on where ns2 is
installed) at the end of the file. With the current console window still open,
go to another console window and determining the contents of
environment variables by issuing the echo command.




The echo command in each case (i.e. $PATH, $LD_LIBRARY_PATH and
$TCL_LIBRARY) will return the PATH variable that contains a list of
previously included pathnames that is colon-delimited.
5. Finally, to verify that ns2 has been successfully installed, enter “which ns”
which will return /root/ns/ns-allinaone-2.29/bin/ns and “ns” which will return
the ns command prompt “%” (enter “exit” on the prompt to exit ns). NS2
can then be validate at the ns-2.29 directory with “./validate” command.









PATH=/root/ns/ns-allinone-2.29/bin:/root/ns/ns-allinone-
2.29/tcl8.4.13 /unix:/root/ns/ns-allinone-2.29/tk8.4.13/unix:$PATH

LD_LIBRARY_PATH=/root/ns/ns-allinone-2.29/otcl-1.12:/root/ns/ns-
allinone-2.29/lib:$LD_LIBRARY_PATH

TCL_LIBRARY=/root/ns/ns-allinone-2.29/tcl8.4.13/library:$TCL_LIBRARY

75

APPENDIX B – MOVEMENT PATTERN SCRIPT
The script below is modified from a sample script provided by Matthias
Budde in the NS forum, customized to our computed data. This script essentially
parses the numerous data generated by the node movement computation using
the Tclsh command. Data points are extracted and arranged in the required
format of the movement file. The computed movement data have to be arranged
in anti-chronological order for subsequent computation of GOD object.
































### SCRIPT TO PARSE DATA INPUT AND GENERATE MOVEMENT EVENT FOR NS-2
### Matthias Budde 2006, edited by Lim, Kwang Yong


set infilename "./Nodemove2.txt"
set outfilename "./oceanmovement2.scn"

set infile [open $infilename ]
set outfile [open $outfilename w]


#Procedure to calculate seconds from time
proc gettime {hrs mins} {
puts -nonewline "Transforming time $hrs:$mins to seconds: "
set time [expr ($hrs * 3600) + ($mins * 60)]
puts "$time"
return $time
}

#Main

puts ""
puts "Parsing file \"$infilename\""
puts ""

while { [ gets $infile line ] != -1 } {

# This regular expression looks for a line formatted like
#"N:N N.N N.N" with n being any amount of digits from
#0 to 9 and saving them to the variables a to d

if {[regexp {([0-9]+):([0-9]+)[^0-9]+([-0-9]+.[0-9]+)[^0-
9]+([-0-9]+\.[0-9]+)} $line z a b c d]} {

set newtime [gettime $a $b]
set newx $c
set newy $d

76






















































if {$newtime == 0} {

puts "Setting initial Position for Node $node"
puts $outfile "$node set X_ $newx"
puts $outfile "$node set Y_ $newy"
puts $outfile "$node set Z_ 0.0"
}

set oldx $newx
set oldy $newy

# in the elseif, the node ID is changed if the line doesn't look
like above but has the Word "Node " followed by a number. Also the
time is reset to 0
} elseif {[regexp {Node *([0-9]+)} $line z a]} {

set nodeID [expr $a - 1]
puts "Setting Node ID to $nodeID"
set node "\$node_($nodeID)"
set newtime 0
# in the else, if the line looks any other than the two above, it's
ignored
} else {
# do nothing
}

}

# This while statement reads the inputfile line per line

set infile [open $infilename ]

while { [ gets $infile line ] != -1 } {

# This regular expression looks for a line formatted like
#"N:N N.N N.N" with n being any amount of digits from
#0 to 9 and saving them to the variables a to d

if {[regexp {([0-9]+):([0-9]+)[^0-9]+([0-9]+\.[0-9]+)[^0-
9]+([0-9]+\.[0-9]+)[^0-9]+(.|[0-9]+\.[0-9]+)} $line z a b c d e ]} {

set newtime [gettime $a $b]
set newx $c
set newy $d

if {$newtime > 0} {

set speed $e
puts $outfile "\$ns_ at $newtime.0 \"$node setdest
$newx $newy $speed\""

}

77



















# in the elseif, the node ID is changed if the line doesn't look
like above but has the Word "Node " followed by a number. Also the
time is reset to 0
} elseif {[regexp {Node *([0-9]+)} $line z a]} {

set nodeID [expr $a - 1]
puts "Setting Node ID to $nodeID"
set node "\$node_($nodeID)"
set newtime 0
# in the else, if the line looks any other than the two above, it's
ignored
} else {
# do nothing
}

}
puts ""
puts "DONE. Output has been written to \"$outfilename\". "

78






















THIS PAGE INTENTIONALLY LEFT BLANK

















79

APPENDIX C – COMMUNICATION PATTERN SCRIPT
The traffic connection pattern script is modified from a modification
(Vaddina Prakash Rao) of the original constant bit rate generation script file by
University of Southern California that is specifically designed for a star topology.
The script is modified to generate traffic at an interval of 10 minutes which
coincide with node movements. Nodes will be randomly selected to transmit data
to the PAN coordinator.

#The copyright for the original script lies with the following author.
#Copyright (c) 1999 by the University of Southern California
#All rights reserved.
#Previous modified by Vaddina Prakash Rao

#Modified by:
#Lim Kwang Yong

#Traffic source generator from CMU's mobile code.

#Program to generate random traffic sources from nodes to coordinator.
# Traffic is generated every ten minutes customized to ocean node movement.

# ===========================================================================
# Default Script Options, following default values are used when not provided
# ===========================================================================

set opt(nn) 0 ;# Number of Nodes
set opt(seed) 0.0 ;# Random number generator seed value
set opt(mc) 0 ;# Number of sources
set opt(pktsize) 70 ;# Packet size

set opt(rate) 0 ;# Datarate
set opt(interval) 0.0 ;# inverse of rate
set opt(type) "" ;# Traffic type
set opt(starttime) 20.0 ;# Traffic start time (need WPAN to
establish)
set opt(endtime) 86400.0 ;# Traffic end time (1 day)
set opt(timegap) 30.0 ;# Default traffic gap time

# ======================================================================

set opt(outfilename) "./cbr/trafficpattern.traff"
set opt(outfile) [open $opt(outfilename) w]
80













































#================================================
# Procedure telling users the optional parameters
#================================================
proc usage {} {
global argv0

puts "\nusage: $argv0 \[-type cbr|tcp\] \[-nn nodes\] \[-seed seed\]
\[-mc connections\] \[-rate rate\] \[-starttime st\] \[-endtime et\] \[-
timegap tg\]\n"
}

#=====================================
# Procedure to get optional parameters
#=====================================
proc getopt {argc argv} {
global opt
lappend optlist nn seed mc rate type starttime timegap

for {set i 0} {$i < $argc} {incr i} {
set arg [lindex $argv $i]
if {[string range $arg 0 0] != "-"} continue

set name [string range $arg 1 end]
set opt($name) [lindex $argv [expr $i+1]]
}
}

#==============
# CBR Procedure
#==============
proc create-cbr-connection { src dst stime } {
global rng cbr_cnt opt
puts $opt(outfile) "#\n# $src connecting to $dst at time $stime\n#"
puts $opt(outfile) "set udp_($cbr_cnt) \[new Agent/UDP\]"
puts $opt(outfile) "\$ns_ attach-agent \$node_($src)
\$udp_($cbr_cnt)"
puts $opt(outfile) "set null_($cbr_cnt) \[new Agent/Null\]"
puts $opt(outfile) "\$ns_ attach-agent \$node_($dst)
\$null_($cbr_cnt)"
puts $opt(outfile) "set cbr_($cbr_cnt) \[new
Application/Traffic/CBR\]"
puts $opt(outfile) "\$cbr_($cbr_cnt) set packetSize_ $opt(pktsize)"
puts $opt(outfile) "\$cbr_($cbr_cnt) set interval_ $opt(interval)"
puts $opt(outfile) "\$cbr_($cbr_cnt) set random_ 1"
puts $opt(outfile) "\$cbr_($cbr_cnt) set maxpkts_ 10000"
puts $opt(outfile) "\$cbr_($cbr_cnt) attach-agent \$udp_($cbr_cnt)"
puts $opt(outfile) "\$ns_ connect \$udp_($cbr_cnt)
\$null_($cbr_cnt)"

puts $opt(outfile) "\$ns_ at $stime \"\$cbr_($cbr_cnt) start\""

incr cbr_cnt
}
81














































#==============
# TCP Procedure
#==============

proc create-tcp-connection { src dst stime } {
global rng cbr_cnt opt
puts $opt(outfile) "#\n# $src connecting to $dst at time $stime\n#"
puts $opt(outfile) "set tcp_($cbr_cnt) \[\$ns_ create-connection \
TCP \$node_($src) TCPSink \$node_($dst) 0\]";
puts $opt(outfile) "\$tcp_($cbr_cnt) set window_ 32"
puts $opt(outfile) "\$tcp_($cbr_cnt) set packetSize_ $opt(pktsize)"
puts $opt(outfile) "set ftp_($cbr_cnt) \[\$tcp_($cbr_cnt) attach-
source FTP\]"
puts $opt(outfile) "\$ns_ at $stime \"\$ftp_($cbr_cnt) start\""

incr cbr_cnt
}

#=============
# Main Program
#=============

getopt $argc $argv

if { $opt(type) == "" } {
usage
exit
} elseif { $opt(type) == "cbr" } {
if { $opt(nn) == 0 || $opt(seed) == 0.0 || $opt(mc) == 0 || $opt(rate)
== 0 } {
usage
exit
}

set opt(interval) [expr 1.0 / $opt(rate)]
if { $opt(interval) <= 0.0 } {
puts "\ninvalid sending rate $opt(rate)\n"
exit
}
}

puts "#\n# nodes: $opt(nn), max conn: $opt(mc), send rate: $opt(interval),
seed: $opt(seed)\n#"

# Loop to transmit traffic within defined interval
set looptime [expr $opt(endtime)/600]
for {set k 1} {$k < $looptime} {incr k} {


set rng [new RNG]
$rng seed $opt(seed)

82













































set u [new RandomVariable/Uniform]
$u set min_ 0
$u set max_ $opt(nn)
$u use-rng $rng

set cbr_cnt 0
set src_cnt 0
set flag 0
set loopcount $opt(nn)

# Loop till the defined connenction has completed, generated scr number
for {set i 0} {$i < $loopcount } {incr i} {

while {1} {
set x [$u value]
set x [expr $x/0.01]
if {$x < $opt(nn)} {
set src [expr round($x)]
break
}
}

if { $src >= $opt(nn) } {
set src [expr $opt(nn)-1]
}

# Add the generated source to the list unless we already had the
source before
if {[array size sources] == 0} {
set sources(0) $src
} else {
# Comparing each source in list to currently generated source to see
if match
for {set p 0} {$p < [array size sources]} {incr p 1} {
if {$src == $sources($p)} {
set flag 1
break
}
}

if {$src == 12} {
set flag 1
}

# If there is a match, break from the current loop (discard the source)
if {$flag == 1} {
set flag 0
incr loopcount 1
continue
} else {
set size [array size sources]
set sources($size) $src
}
}
83






























# Destination to be node-12 (PAN coordinator).
set dst 12
if { $opt(type) == "cbr" } {
incr src_cnt 1
create-cbr-connection $src $dst $opt(starttime)
} else {
create-tcp-connection $src $dst $opt(starttime)
}

if { $src_cnt == $opt(mc) } {
# You have created the required number of sources. So break now !!
break
} else {
# If required number of sources have not been reached yet.
set temp $loopcount
incr temp -1
if {$i == $temp} {
incr loopcount 1
}
}
# Tx each node at an interval
set opt(starttime) [expr $opt(starttime)+$opt(timegap)]
}

# Tx in the next cycle and reset source array
set opt(starttime) [expr $k*600]
unset sources

}

puts $opt(outfile) "#\n#Total sources: $src_cnt\n#"

84






















THIS PAGE INTENTIONALLY LEFT BLANK










85

APPENDIX D – SAMPLE TCL SCRIPT
The sample TCL script provided is the configuration file for simulation.
Some of the parameters are hard coded which needs to be varied and monitored
to execute different sets of experimentations.





































#############################################
# 802.15.4 (beacon enabled) #
# Copyright (c) 2003 Samsung/CUNY #
# - - - - - - - - - - - - - - - - - - - - - #
# Prepared by Jianliang Zheng #
# (zheng@ee.ccny.cuny.edu) #
# #
# Modified By: Lim Kwang Yong #
# Naval Post-Graduate School #
#############################################

# Ocean movement scenario 25 nodes, 10m apart from adjacent nodes
# ========================================================================
# Set parameters regarding channel, medium, MAC protocol, routing
protocol, energy model ...
# ========================================================================
set val(chan) Channel/WirelessChannel ;# Channel Type
set val(prop) Propagation/TwoRayGround ;# radio-propagation model
set val(netif) Phy/WirelessPhy/802_15_4
set val(mac) Mac/802_15_4
set val(ifq) Queue/DropTail/PriQueue ;# interface queue type
set val(ll) LL ;# link layer type
set val(ant) Antenna/OmniAntenna ;# antenna model
set val(ifqlen) 150 ;# packet in ifq
set val(nn) 25 ;# number of mobilenodes
set val(rp) AODV ;# routing protocol
set val(x) 4500 ;# x dimension topography
set val(y) 4500 ;# y dimension topography
set val(tr) ocean_move_25_3hr.tr ;# trace file
set val(nam) ocean_move_25_3hr.nam ;# nam trace file
set val(move) oceanmove3hr.scn ;# movement scenario
set val(cp) traffic_3hr_pattern.traff ;# connection traffic
#set val(Energy) EnergyModel ;# Evaluate energy

set val(starttime) 5 ;
set val(appTime1) [expr $val(starttime)+20] ;
set appTime2 [expr $val(appTime1)+0.3] ;
set stopTime 10800 ;
86













































#===========================
#read command line arguments
#===========================
proc getCmdArgu {argc argv} {
global val
for {set i 0} {$i < $argc} {incr i} {
set arg [lindex $argv $i]
if {[string range $arg 0 0] != "-"} continue
set name [string range $arg 1 end]
set val($name) [lindex $argv [expr $i+1]]
}
}

getCmdArgu $argc $argv

#=========================================
# Define antenna at node centre of ht 0.1m
#=========================================
Antenna/OmniAntenna set X_ 0
Antenna/OmniAntenna set Y_ 0
Antenna/OmniAntenna set Z_ 0.1
Antenna/OmniAntenna set Gt_ 1.0
Antenna/OmniAntenna set Gr_ 1.0

#============================
# Initialize Global Variables
#============================
set ns_ [new Simulator]

#=========================================================
# Create trace object for ns and nam, use new trace format
#=========================================================
set tracefd [open ./$val(tr) w]
$ns_ trace-all $tracefd
# Statement indicating to simulator about NAM.
set namtrace [open ./$val(nam) w]
$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)
#$ns_ use-newtrace

#========================================================================
# Inform nam that this is a trace file for wpan (special handling needed)
#========================================================================

$ns_ puts-nam-traceall {# nam4wpan #}

Mac/802_15_4 wpanCmd verbose on
Mac/802_15_4 wpanNam namStatus on ;# default = off (should be
turned on before other 'wpanNam'
commands can work)
Mac/802_15_4 wpanNam ColFlashClr black ;# default = gold
87













































#=========================
# For model 'TwoRayGround'
#=========================
Phy/WirelessPhy set CSThresh_ 3.981e-13; #carrier sensing threshold
Phy/WirelessPhy set RXThresh_ 3.981e-13; #receiver threshold
Phy/WirelessPhy set CPThresh_ 10; #capture threshold
Phy/WirelessPhy set freq_ 2.4e+9; #Operating Freq
Phy/WirelessPhy set L_ 1.0; #System loss factor
Phy/WirelessPhy set pt_ 0.001; #Tx power

#====================================
# set up and define topography object
#====================================
set topo [new Topography]
$topo load_flatgrid $val(x) $val(y)

#==========
#Create God
#==========
set god_ [create-god $val(nn)]

set chan_1_ [new $val(chan)]

#===============
# configure node
#===============

$ns_ node-config -adhocRouting $val(rp) \
-llType $val(ll) \
-macType $val(mac) \
-ifqType $val(ifq) \
-ifqLen $val(ifqlen) \
-antType $val(ant) \
-propType $val(prop) \
-phyType $val(netif) \
-topoInstance $topo \
-agentTrace ON \
-routerTrace ON \
-macTrace ON \
-movementTrace ON\
-channel $chan_1_
#========================================
# Parameter req. only when energy logging
#========================================
#-energyModel EnergyModel \
#-initialEnergy 13000 \
#-rxPower 0.0648 \
#-txPower 0.0744 \
#-idlePower 0.00000552 \

88













































#===============================================
# Creates specified node and attached to channel
#===============================================
for {set i 0} {$i < $val(nn) } {incr i} {
set node_($i) [$ns_ node]
$node_($i) random-motion 0 ;# disable random motion
}

#========================='
# Define movement scenario
#=========================
puts "Loading movement pattern ..."
source $val(move)

#===============
# SSCS Interface
#===============
$ns_ at 0.0 "$node_(12) NodeLabel \"PAN Coor\""

# Cmd used to start a new PAN with corresponding node as PAN coordinator
# default <txBeacon=1> <beaconOrder=3> <SuperframeOrder=3>
$ns_ at 0.0 "$node_(12) sscs startPANCoord 0" ;# startPANCoord

# Cmd used to start a device
# default <isFFD=1> <assoPermit=1> <txBeacon=0> <BO=3> <SO=3>
$ns_ at 0.3 "$node_(7) sscs startCTDevice 1 1 1"
$ns_ at 1.3 "$node_(13) sscs startCTDevice 1 1 1"
$ns_ at 1.7 "$node_(17) sscs startCTDevice 1 1 1"
$ns_ at 2.3 "$node_(11) sscs startCTDevice 1 1 1"

$ns_ at 3.3 "$node_(8) sscs startCTDevice 1 1 1"
$ns_ at 3.5 "$node_(18) sscs startCTDevice 1 1 1"
$ns_ at 3.6 "$node_(16) sscs startCTDevice 1 1 1"
$ns_ at 3.8 "$node_(6) sscs startCTDevice 1 1 1"

$ns_ at 4.3 "$node_(2) sscs startCTDevice 1 1 1"
$ns_ at 4.5 "$node_(14) sscs startCTDevice 1 1 1"
$ns_ at 4.8 "$node_(22) sscs startCTDevice 1 1 1"
$ns_ at 5.1 "$node_(10) sscs startCTDevice 1 1 1"

$ns_ at 5.6 "$node_(3) sscs startCTDevice 1 1 1"
$ns_ at 5.8 "$node_(19) sscs startCTDevice 1 1 1"
$ns_ at 6.0 "$node_(21) sscs startCTDevice 1 1 1"
$ns_ at 6.3 "$node_(5) sscs startCTDevice 1 1 1"

$ns_ at 6.8 "$node_(4) sscs startCTDevice 1 1 1"
$ns_ at 7.0 "$node_(24) sscs startCTDevice 1 1 1"
$ns_ at 7.3 "$node_(20) sscs startCTDevice 1 1 1"
$ns_ at 7.7 "$node_(0) sscs startCTDevice 1 1 1"
89













































$ns_ at 8.2 "$node_(1) sscs startCTDevice 1 1 1"
$ns_ at 8.5 "$node_(9) sscs startCTDevice 1 1 1"
$ns_ at 8.8 "$node_(23) sscs startCTDevice 1 1 1"
$ns_ at 9.1 "$node_(15) sscs startCTDevice 1 1 1"

#$ns_ at $appTime2 "$node_(12) sscs stopBeacon"

Mac/802_15_4 wpanNam PlaybackRate 3ms

$ns_ at $val(appTime1) "puts \"\nTransmitting data ...\n\""

#=================================
# Setup traffic flow between nodes
#=================================

puts "Loading traffic pattern ..."
source $val(cp)

# Mac/802_15_4 wpanNam FlowClr [-p <packet_type_name>] [-s <src>] [-d
<dst>] [-c <clrName>]

Mac/802_15_4 wpanNam FlowClr -p AODV -c red
Mac/802_15_4 wpanNam FlowClr -p ARP -c green
Mac/802_15_4 wpanNam FlowClr -p MAC -c navy
Mac/802_15_4 wpanNam FlowClr -p tcp -c blue
Mac/802_15_4 wpanNam FlowClr -p ack -c cyan4

#==================================
# defines the node size (3) in nam
#==================================
for {set i 0} {$i < $val(nn)} {incr i} {
$ns_ initial_node_pos $node_($i) 3
}

#====================================
# Tell nodes when the simulation ends
#====================================
for {set i 0} {$i < $val(nn) } {incr i} {
$ns_ at $stopTime "$node_($i) reset";
}

$ns_ at $stopTime "stop"
$ns_ at $stopTime "puts \"NS EXITING...\n\""
$ns_ at $stopTime "$ns_ halt"

90



proc stop {} {
global ns_ tracefd val(starttime) val env
$ns_ flush-trace
close $tracefd
set hasDISPLAY 0
foreach index [array names env] {
puts "$index: $env($index)"
if { ("$index" == "DISPLAY") && ("$env($index)" != "") } {
set hasDISPLAY 1
}
}
if { ("$val(nam)" == "ocean_move_25_3hr.nam") && ("$hasDISPLAY" == "1")
} {
exec nam ocean_move_25_3hr.nam

}
}

puts "\nStarting Simulation..."

$ns_ run

#==============
# End of script
#==============

91

APPENDIX E – SAMPLE TRACE FILE FORMAT





















s 0.000640000 _12_ MAC --- 0 CM7 8 [0 ffffffff c 0]
s 0.140160000 _12_ MAC --- 0 CM7 8 [0 ffffffff c 0]
s 0.280320000 _12_ MAC --- 0 CM7 8 [0 ffffffff c 0]
s 0.300960000 _7_ MAC --- 0 CM7 8 [0 ffffffff 7 0]
s 0.564960000 _7_ MAC --- 0 CM7 8 [0 ffffffff 7 0]
s 0.828640000 _7_ MAC --- 0 CM7 8 [0 ffffffff 7 0]
s 1.301920000 _13_ MAC --- 0 CM7 8 [0 ffffffff d 0]
r 1.302368026 _12_ MAC --- 0 CM7 8 [0 ffffffff d 0]
s 1.304928026 _12_ MAC --- 0 BCN 11 [0 d c 0]
s 1.564000000 _13_ MAC --- 0 CM7 8 [0 ffffffff d 0]
s 1.702240000 _17_ MAC --- 0 CM7 8 [0 ffffffff 11 0]
r 1.702688033 _12_ MAC --- 0 CM7 8 [0 ffffffff 11 0]
s 1.703968033 _12_ MAC --- 0 BCN 11 [0 11 c 0]
s 1.827360000 _13_ MAC --- 0 CM7 8 [0 ffffffff d 0]
r 1.827808042 _7_ MAC --- 0 CM7 8 [0 ffffffff d 0]
s 1.964640000 _17_ MAC --- 0 CM7 8 [0 ffffffff 11 0]
s 2.091040000 _13_ MAC --- 0 CM1 17 [0 c d 0]
r 2.091776026 _12_ MAC --- 0 CM1 17 [0 c d 0]
s 2.091968026 _12_ MAC --- 0 ACK 5 [0 d c 0]
r 2.092320052 _13_ MAC --- 0 ACK 5 [0 d c 0]
s 2.092960000 _7_ MAC --- 0 CM7 8 [0 ffffffff 7 0]
r 2.093408033 _12_ MAC --- 0 CM7 8 [0 ffffffff 7 0]
s 2.095008033 _12_ MAC --- 0 BCN 11 [0 7 c 0]
s 2.227680000 _17_ MAC --- 0 CM7 8 [0 ffffffff 11 0]
s 2.301920000 _11_ MAC --- 0 CM7 8 [0 ffffffff b 0]
r 2.302368026 _12_ MAC --- 0 CM7 8 [0 ffffffff b 0]
D 2.302368043 _7_ MAC APS 0 CM7 8 [0 ffffffff b 0]
s 2.303648026 _12_ MAC --- 0 BCN 11 [0 b c 0]
s 2.355680000 _7_ MAC --- 0 CM7 8 [0 ffffffff 7 0]
s 2.491680000 _17_ MAC --- 0 CM1 17 [0 c 11 0]
r 2.492416033 _12_ MAC --- 0 CM1 17 [0 c 11 0]
s 2.492608033 _12_ MAC --- 0 ACK 5 [0 11 c 0]
r 2.492960067 _17_ MAC --- 0 ACK 5 [0 11 c 0]
s 2.565280000 _11_ MAC --- 0 CM7 8 [0 ffffffff b 0]
D 2.565728043 _7_ MAC APS 0 CM7 8 [0 ffffffff b 0]



D 27.267808849 _2_ MAC COO 0 BCN 12 [0 ffffffff 13 0]
D 27.267808860 _5_ MAC COO 0 BCN 12 [0 ffffffff 13 0]
D 27.267808863 _1_ MAC COO 0 BCN 12 [0 ffffffff 13 0]
D 27.267808880 _0_ MAC COO 0 BCN 12 [0 ffffffff 13 0]
s 27.268180039 _18_ AGT --- 2 cbr 20 [0 0 0 0] ------- [18:0 12:0 32 0]
[2] 0 1
r 27.268180039 _18_ RTR --- 2 cbr 20 [0 0 0 0] ------- [18:0 12:0 32 0]
[2] 0 1
s 27.268180039 _18_ RTR --- 2 cbr 40 [0 0 0 0] ------- [18:0 12:0 30 12]
[2] 0 1
92






















THIS PAGE INTENTIONALLY LEFT BLANK
93

APPENDIX F – SAMPLE AWK SCRIPTS
This script is modified from the many example scripts provided in the NS2
forum to parse the data from in the trace file format.




















# Lim Kwang Yong

# Usage: awk -f <awk_script.awk> <trace_file.tr>
# Parse a ns2 wireless trace file and generate performance metrics

BEGIN {

droppedRTGpackets=0;
droppedbRTGbytes=0;
droppedMACbytes=0;
droppedMACpackets=0;
droppedbDATAbytes=0;
droppedbDATApackets=0;
droppedIFQpackets=0;
droppedLQIbytes=0;
droppedLQIpackets=0;
droppedIFQbytes=0;
totalDROPPEDpackets=0;
totalDROPPEDbytes=0;
dataSent=0;
dataRecd=0;
sentData=0;
sentDataBytes=0;
TotalsentData=0;
TotalsentDataBytes=0;
recdData=0;
recdDataBytes=0;
sends=0;
recvs=0;
RTGbytes=0;
fwdData=0;
fwdDataBytes=0;
fwdRtg=0;
fwdRtgBytes=0;
fwdMac=0;
fwdMacBytes=0;
highest_packet_id=0; #used to compare with the packet id
highest_time=0
sum=0;
RTG=0;
MACDATA=0;
MACRTG=0;
}

94
























{
#=============================
# Check for the highest packet ID & time
#=============================
action = $1;
time = $2;
node_id = $3
if ($7 =="cbr"){packet_id = $6;};
if ( packet_id > highest_packet_id ) {highest_packet_id = packet_id;};
if ( time > highest_time) {highest_time = time}

#============
# Calculate delay
#============
if ( start_time[packet_id] == 0 ) {start_time[packet_id] = time;};
if ( action != "D" ) {
if ( action == "r" ) {end_time[packet_id] = time;};
}
else {end_time[packet_id] = -1;};

#===========
#Calculate PDF
#===========
if (($1 == "s") && ($7 == "cbr") && ($4 =="AGT")) {
sends++;
dataSent=dataSent+$8;
}
if ( ( $1 == "r") && ( $7 == "cbr" ) && ( $4 == "AGT" ) ) {
recvs++;
dataRecd=dataRecd+$8;
}

#===============
# Calculate RTG load
#===============

if ((( $1 == "s") || ($1=="f") ) && ( $7 == "cbr" ) && ( $4 =="RTR" )) {
sentData++;
sentDataBytes=sentDataBytes+$8;
}
if ( ( $1 == "r") && ( $7 == "cbr" ) && ( $4 == "RTR" ) ) {
recdData++;
recdDataBytes=recdDataBytes+$8;
}

#==============
# RTG protocol pkts
#==============

if ( (($1=="f") || ($1=="s") ) && ($4 == "RTR") && ($7 =="AODV" ) ) {
RTG++;
RTGbytes=RTGbytes+$8;
}
95
























#============
# MAC data pkts
#============
if ( (($1=="f") || ($1=="s") ) && ($4 == "MAC") && ($7 =="cbr" ) ) {
MACDATA++;
}

#=============
# MAC RTG pkts
#=============
if ( (($1=="f") || ($1=="s") ) && ($4 == "MAC") && ($7 =="AODV" ) ) {
MACRTG++;
}

#==============
# Dropped data pkts
#==============
if ( ($1 == "D") && ($7 =="cbr") && ( $4 == "RTR" )){
droppedDATAbytes=droppedDATAbytes+$8 ;
droppedDATApackets=droppedDATApackets+1;
}

#===============
# Dropped MAC pkts
#===============
if ( ($1 == "D") && ($4 == "MAC" )){
droppedMACbytes=droppedMACbytes+$8 ;
droppedMACpackets=droppedMACpackets+1;
}

#===============
# Dropped RTG pkts
#===============
if ( ($1 == "D") && ($4 == "RTR" ) && ($8 == "AODV")){
droppedRTGbytes=droppedRTGbytes+$8 ;
droppedRTGpackets=droppedRTGpackets+1;
}

#==============
# Dropped IFQ pkts
#==============
if (($1 == "D") && ($4 == "IFQ")){
droppedIFQbytes=droppedIFQbytes+$8 ;
droppedIFQpackets=droppedIFQpackets+1;
}

#==============
# Dropped LQI pkts
#==============
if (($1 == "D") && ($4 == "IFQ")){
droppedLQIbytes=droppedLQIbytes+$8 ;
droppedLQIpackets=droppedLQIpackets+1;
}
96
























#==============
# Total dropped pkts
#==============
if ($1 == "D") {
totalDROPPEDpackets++;
totalDROPPEDbytes=totalDROPPEDbytes+$8
}

#==============
# Forward data pkts
#==============
if ( ($1 == "f") && ($7 == "cbr") && ($4 == "RTR" ) ) {
fwdData++;
fwdDataBytes=fwdDataBytes+$8;
}

#==============
# Forward RTG pkts
#==============
if ( ( $1 == "f") && ($7 == "AODV") && ($4 == "RTR") ) {
fwdRtg++;
fwdRtgBytes=fwdRtgBytes+$8;
}

#===============
# Forward MAC pkts
#===============
if ( ( $1 == "f") && ($4 == "MAC" ) ) {
fwdMac++;
fwdMacBytes=fwdMacBytes+$8;
}

#==============
# Total forward pkts
#==============
if ( $1 == "f") {
fwdpackets++;
fwdBytes=fwdBytes+$8;
}

if ($1 == "D") {
droppingnodes= $3;
}
}

END {

for ( packet_id = 0; packet_id <= highest_packet_id; packet_id++ ) {
start = start_time[packet_id];
end = end_time[packet_id];
packet_duration = end - start;
if (start < end) sum= packet_duration+sum;
}
97
























#==========
# Show results
#==========

printf("\n .......Data parsed from trace file with 25
NODES.............\n\n") >> "performance.txt";
printf(" 1. No. of CBR Packets sent = %d PACKETS \n ", sends) >>
"performance.txt";
printf(" 2. No. of CBR Bytes sent = %d BYTES \n", dataSent) >>
"performance.txt";
printf(" 3. No. of CBR Packets received = %d PACKETS \n", recvs) >>
"performance.txt";
printf(" 4. No. of CBR Bytes received = %d BYTES \n", dataRecd) >>
"performance.txt";
printf(" \n .......Routing details.............\n\n") >>
"performance.txt";
printf(" 5. No. of routing packets = %d PACKETS \n",RTG) >>
"performance.txt";
printf(" 6. No. of routing bytes = %d BYTES \n",RTGbytes) >>
"performance.txt";
printf(" \n .......MAC details.............\n\n") >> "performance.txt";
printf(" 7. No. of MAC packets for data sent = %d PACKETS \n", MACDATA)
>> "performance.txt";
printf(" 8. No. of MAC packets for Rtg sent = %d PACKETS \n", MACRTG) >>
"performance.txt";
printf(" 9. Total No. of MAC Packets sent = %d PACKETS \n",
MACRTG+MACDATA) >> "performance.txt";
printf(" \n .......Forwarding details............\n\n") >>
"performance.txt";
printf(" 10. No. of DATA Packets Fwd = %d PACKETS \n", fwdData) >>
"performance.txt";
printf(" 11. No. of DATA Bytes Fwd = %d BYTES \n", fwddataBytes) >>
"performance.txt";
printf(" 12. No. of RTG Packets Fwd = %d PACKETS \n", fwdRtg) >>
"performance.txt";
printf(" 13. No. of RTG Bytes Fwd = %d BYTES \n", fwdRtgBytes) >>
"performance.txt";
printf(" 14. No. of MAC Packets Fwd = %d PACKETS \n", fwdMac) >>
"performance.txt";
printf(" 15. No. of MAC Bytes Fwd = %d BYTES \n", fwdMacBytes) >>
"performance.txt";
printf(" 16. Total No. of Fwd packets = %d PACKETS \n", fwdpackets) >>
"performance.txt";
printf(" 17. Total No. of Fwd Bytes = %d BYTES \n", fwdBytes) >>
"performance.txt";
printf(" \n ........Dropping details............\n\n") >>
"performance.txt";
printf(" 18. Dropping nodes are %d nodes \n", droppingnodes) >>
"performance.txt";
printf(" 19. No. of dropped data (packets) = %d PACKETS
\n",droppedDATApackets) >> "performance.txt";
printf(" 20. No. of dropped data (bytes) = %d BYTES \n",droppedDATAbytes)
>> "performance.txt";
98





















printf(" 21. No. of dropped MAC (packets) = %d PACKETS
\n",droppedMACpackets) >> "performance.txt";
printf(" 22. No. of dropped MAC (bytes) = %d BYTES \n",droppedMACAbytes)
>> "performance.txt";
printf(" 23. No. of dropped RTG (packets) = %d PACKETS
\n",droppedRTGpackets) >> "performance.txt";
printf(" 24. No. of dropped RTG (bytes) = %d BYTES \n",droppedRTGbytes)
>> "performance.txt";
printf(" 25. No. of dropped IFQ (Packets) = %d PACKETS
\n",droppedIFQpackets) >> "performance.txt";
printf(" 26. No. of dropped IFQ (bytes) = %d BYTES \n",droppedIFQbytes)
>> "performance.txt";
printf(" 27. No. of dropped LQI (Packets) = %d PACKETS
\n",droppedLQIpackets) >> "performance.txt";
printf(" 28. No. of dropped LQI (bytes) = %d BYTES \n",droppedIFQbytes)
>> "performance.txt";
printf(" 29. Total No. of Dropped (packets) = %d PACKETS
\n\n",totalDROPPEDpackets) >> "performance.txt";
printf(" 30. Total No. of Dropped (Bytes)) = %d BYTES
\n\n",totalDROPPEDbytes) >> "performance.txt";

printf("\n .............PERFORMANCE METRICES .....................\n\n")
>> "performance.txt";
printf(" 1. Packet Delivery Ratio (PDR %) = %f %\n", (recvs/sends)*100)
>> "performance.txt";
printf(" 2. Average Network delay = %f \n", sum/highest_packet_id) >>
"performance.txt";
printf(" 3. Network Throughput = %f \n", (dataRecd/highest_time)/25) >>
"performance.txt";
printf(" 4. Normalised routing load (Packets %) = %f %\n",
(RTG/sentData)*100) >> "performance.txt";
printf(" 5. Normalised routing load (Bytes %) = %f %\n",
(RTGbytes/sentDataBytes)*100) >> "performance.txt";
printf(" 6. Routing OVERHEAD (Packets %) = %f %\n", (MACRTG/MACDATA)*100)
>> "performance.txt";
printf(" 7. Optimal Hop Count = %f \n\n", MACDATA/sends) >>
"performance.txt";

99

APPENDIX G – NODES POSITION AT VARIOUS TIME INTERVAL









































8
7
6
5
4
3
2
1
0
9 nodes positions after 3 hrs
PAN coordinator
9 nodes positions after 1 hr
8
7
6
5
4
3
2
1
0
PAN coordinator
8
7
6
5
4
3
2
1
0
PAN coordinator
9 nodes positions after 6 hrs
8
7
6
5
4
3
2
1
0
9 nodes positions after 9 hrs
PAN coordinator
8
7
6
5
4
3
2
1
0
9 nodes positions after 12 hrs
PAN coordinator
8
7
6
5
4
3
2
1
0
9 nodes positions after 18 hrs
PAN coordinator
9 nodes positions after 24 hrs
8 7
6
5
4
3
2
1
0
PAN coordinator
100

13
12
9
7
6
5
4
15
14
11
10
8
3
2
1
0
13
12
9
7
6
5
4
15
14
11
10
8
3
2
1
0
13
12
9
7
6
5
4
15
14
11
10
8
3
2
1
0












































16 node positions after 3 hrs
13
12
11
9
7
6
5
4
3
15
14
10
8
2
1
0
PAN coordinator
16 node positions after 1 hr
13
12
9
7
6
5
4
15
14
11
10
8
3
2
1
0
PAN coordinator
16 node positions after 6 hrs
PAN coordinator
16 node positions after 9 hrs
PAN coordinator
16 node positions after 12 hrs
101


25-node Configuration:
Node movements after 12 hrs
15
24
23
22
21 20
19
18
17
16
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Node movements after 9 hrs
15
24
23
22
21
20
19
18
17
16
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Node movements after 6 hrs
16
15
24
23
22
21
20
19
18
17
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Node movements after 3 hrs
16
15
24
23
22
21
20
19
18
17
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
PAN coordinator
PAN coordinator
PAN coordinator
PAN coordinator
102




















THIS PAGE INTENTIONALLY LEFT BLANK
103

LIST OF REFERENCES

1. Wiki for Network Simulator (NS) and Network Animator (NAM),
http://nsnam.isi.edu/nsnam/index.php/Main_Page, accessed on August
21, 2006.

2. Low Rate Wireless Personal Area Networks (LR-WPANs) – NS2
Simulation Platform, http://ees2cy.engr.ccny.cuny.edu/zheng/pub/,
accessed on August 25, 2006.

3. J. Zheng and Myung J. Lee, "Will IEEE 802.15.4 make ubiquitous
networking a reality? – a discussion on a potential low power, low bit rate
standard," IEEE Communications Magazine, Vol. 42, No. 6, pp. 140-146,
June 2004.

4. IEEE Computer Society, “IEEE Standard 802.15.4-2003 (draft), Part 15.4
: Wireless Medium Access Control and Physical Layer Specifications for
Low-Rate Wireless Personal Area Networks”, IEEE Standards, October
2003.

5. J. Zheng and Myung J. Lee, "A comprehensive performance study of IEEE
802.15.4," Sensor Network Operations, IEEE Press, Wiley Interscience,
Chapter 4, pp. 218-237, 2006.

6. José A. Gutierrez, Ed Callaway and Raymond Barrett, “Low-Rate Wireless
Personal Area Networks: Enabling Wireless Sensors with IEEE 802.15.4 “,
IEEE Press, November 2003.

7. Joe Hoffert, Kevin Klues and Obi Orjih, “Configuring the IEEE 802.15.4
MAC Layer for Single-sink Wireless Sensor Network Applications”,
Washington University in St. Louis.

8. ZigBee Alliance, “ZigBee Specification”, ZigBee Document 053474r06,
Version 1.0, December 2004

9. Sinem Coleri Ergen, "ZigBee/IEEE 802.15.4 Summary", September 2004,
http://www.cs.wisc.edu/~suman/courses/838/papers/zigbee.pdf

10. C. E. Perkins and E. M. Royer, “Ad Hoc On-demand Distance Vector
Routing,” in Proc. 2nd IEEE Wksp. Mobile Comp. Sys. and Apps.,
February 1999, pp. 90-100.

104

11. IETF, “Ad hoc On-Demand Distance Vector (AODV) Routing”, RFC 3561,
http://www.ietf.org/rfc/rfc3561.txt, assessed on September 27, 2006.

12. Surface and Subsurface Ocean Currents, http://www.geog.ouc.bc.ca/
physgeog/fundamentals/8q.html, accessed on August 24, 2006.

13. Paul, R. Pinet, “Invitation to Oceanography, 3
rd
edition”, Jones and Bartlett
Publishers Inc., 2003.

14. Ocean Currents, http://www.waterencyclopedia.com/Mi-Oc/Ocean-
Currents.html, accessed on August 25, 2006.

15. Surface Ocean Current, www.nmm.ac.uk/server.php?show=conMedia
File.6569, accessed on August 25, 2006.

16. Ocean World, Currents - Ekman Spiral, http://oceanworld.tamu.edu/
students/currents/currents3.htm), accessed on August 25, 2006.

17. Department of Earth Sciences, University of Southern California,
Upwelling and Downwelling Effect, http://earth.usc.edu/~stott/Catalina/
Oceans.html, accessed on August 25, 2006.

18. Tides and Water Levels, http://www.oceanservice.noaa.gov/education/kits/
tides/tides01_intro.html, accessed on August 27, 2006.

19. Ross, David A., “Introduction to Oceanography”, New York: HarperCollins
College Publishers, 1995.

20. National Oceanic and Atmospheric Administration, Tides and Water
Levels, http://www.oceanservice.noaa.gov/education/kits/tides/tides01_
intro.html, accessed on August 27, 2006.

21. Background (Mobility Models and Data for Wireless Networks),
http://signl.cs.umass.edu/~liberato/wireless_background.html, accessed
on August 28, 2006.
22. BonnMotion, A mobility scenario generation and analysis tool, http://web.
informatik.uni-bonn.de/IV/Mitarbeiter/dewaal/BonnMotion/, accessed on
August 11, 2006.

23. T. Camp, J Boleng, V. Davies, “A Survey of Mobility Models for Ad Hoc
Network Research”, Wireless Communication & Mobile Computing
(WCMC): Special issue on Mobile Ad Hoc Networking: Research, Trends
and Applications, 2002, vol. 2, no. 5, pp. 483-502.

105

24. B. Liang and Z. Haas, “Predictive distance-based mobility management
for PCS networks”, Proceedings of the IEEE INFOCOM 1999,
pp.1377-1384.

25. Laboratory S.A.M.O.V.A.R, Mobility model in ad hoc network, www-
public.int-evry.fr/~gauthier/mobility.html, accessed on September 11,
2006.

26. “Selection Procedures for the Choice of Radio Transmission Technologies
of the UMTS.” Technical Report tr 101 112 v3.2.0, ETSI SMG-5, France,
April 1998.

27. X. Hong, M. Gerla, G. Pei and C.C. Chiang, “A Group Mobility Model for
Ad Hoc Wireless Networks,” Proceeding of the 2nd ACM/IEEE Int.
Workshop on Modeling and Simulation of Wireless and Mobile Systems
(MSWiM'99), 1999, pp. 53-60.

28. REAL 5.0 Overview, http://www.cs.cornell.edu/skeshav/real/overview.html,
accessed on October 22, 2006.

29. NS2 Event Scheduler, http://www.acims.arizona.edu/PUBLICATIONS
/PDF/Thesis_Taekyu.pdf, accessed on October 22, 2006.

30. “The CMU Monarch Project’s Wireless and Mobility Extensions to ns”, The
CMU Monarch Project, Computer Science Department, Carnegie Mellon
University Snapshot Release 1.1.1, August 1999.

31. “The ns Manual (formerly ns Notes and Documentation)”, The VINT
Project, A Collaboration between researchers at UC Berkeley, LBL,
USC/ISI, and Xerox PARC, August 2006.

32. NS-2 Trace Formats, http://nsnam.isi.edu/nsnam/index.php/NS-
2_Trace_Formats#New_Wireless_Trace_Formats, accessed on
November 10, 2006.

33. Near Real-Time Monterey Bay Surface Currents,
http://newark.cms.udel.edu/~brucel/realtimemaps/index.html, accessed on
September 2, 2006

34. Ed Williams, Aviation Formulary V1.43, http://williams.best.vwh.net
/avform.htm#LL, accessed on September 8, 2006.

106

35. Vaddina Prakash Roa, “Master Thesis: The simulative Investigation of
Zigbee/IEEE 802.15.4”, Dresden University of Technology, November
2005.

36. Advanced Refractive Effects Prediction System (AREPS),
http://sunspot.spawar.navy.mil/, accessed on December 1, 2006.

107

INITIAL DISTRIBUTION LIST
1. Defense Technical Information Center
Ft. Belvoir, Virginia

2. Dudley Knox Library
Naval Postgraduate School
Monterey, California

3. Professor Peter Denning
Chairman, Department of Computer Science
Naval Postgraduate School
Monterey, California

4. Professor John C. McEachen
Department of Electrical and Computer Engineering
Naval Postgraduate School
Monterey, California

5. Professor Gurminder Singh
Department of Computer Science
Naval Postgraduate School
Monterey, California

6. Professor Yeo Tat Soon (email: tdshead@nus.edu.sg)
Director, Temasek Defence Systems Institute (TDSI)
National University of Singapore
Singapore

7. Tan Lai Poh (email: tdstlp@nus.edu.sg)
Temasek Defence Systems Institute (TDSI)
National University of Singapore
Singapore

8. Lim Kwang Yong
Singapore Technologies Dynamic Pte Ltd
Singapore

THIS PAGE INTENTIONALLY LEFT BLANK

REPORT DOCUMENTATION PAGE

Form Approved OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188) Washington DC 20503.

1. AGENCY USE ONLY (Leave blank)

2. REPORT DATE 3. REPORT TYPE AND DATES COVERED December 2006 Master’s Thesis 4. TITLE AND SUBTITLE A Performance Analysis of Ad-hoc Ocean Sensor 5. FUNDING NUMBERS Network 6. AUTHOR(S) Kwang Yong Lim 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION REPORT NUMBER Naval Postgraduate School Monterey, CA 93943-5000 9. SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSORING/MONITORING AGENCY REPORT NUMBER N/A 11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the official policy or position of the Department of Defense or the U.S. Government. 12a. DISTRIBUTION / AVAILABILITY STATEMENT 12b. DISTRIBUTION CODE Approved for public release; distribution is unlimited 13. ABSTRACT (maximum 200 words)

This thesis presents the simulation results and performance analysis of IEEE 802.15.4 in an oceanic environment. The 802.15.4 standard allows simple sensors and actuators to co-exist in a single wireless platform. The simulation is performed using Network Simulator, version 2 (NS2) which is an opensource network simulator tool. NS2 is an event driven network simulator developed at UC Berkeley that simulates a variety of networks. Leveraging on the capabilities of NS2, the performance of the IEEE 802.15.4 protocol has been studied based on variations in node density, mobility as well as loading conditions. The mobility model selected for the simulation has considered the ocean effects on the mobile nodes, in particular the surface current. However, the available mobility models (Random Waypoint, Gauss-Markov, Manhattan Grid and Reference Point Group) do not represent the real life mobility in an oceanic environment scenario. As a result, actual data of surface measurement in the Monterey bay area is used to generate the node movements. The results from this analysis provide insights into the performance of IEEE 802.15.4 and its suitability for operating in an oceanic environment.

14. SUBJECT TERMS Ad-hoc networks, Wireless Networks, Mobile Networks, Network Simulation, Performance Evaluation. 17. SECURITY CLASSIFICATION OF REPORT Unclassified
NSN 7540-01-280-5500

15. NUMBER OF PAGES 123 16. PRICE CODE

18. SECURITY CLASSIFICATION OF THIS PAGE Unclassified

19. SECURITY 20. LIMITATION OF CLASSIFICATION OF ABSTRACT ABSTRACT Unclassified UL Standard Form 298 (Rev. 2-89)

Prescribed by ANSI Std. 239-18

i

THIS PAGE INTENTIONALLY LEFT BLANK ii .

distribution is unlimited A PERFORMANCE ANALYSIS OF AD-HOC OCEAN SENSOR NETWORK Kwang Yong Lim Civilian. Singapore Technologies Dynamics Pte Ltd Bachelor of Engineering (Hons). McEachen Thesis Advisor Gurminder Singh Co-Advisor Peter Denning Chairman. Department of Computer Science iii . 1999 Submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE IN COMPUTER SCIENCE from the NAVAL POSTGRADUATE SCHOOL December 2006 Author: Kwang Yong Lim Approved by: John C.Approved for public release. University of Sheffield. United Kingdom.

THIS PAGE INTENTIONALLY LEFT BLANK iv .

actual data of surface measurement in the Monterey bay area is used to generate the node movements.4 protocol has been studied based on variations in node density. v .ABSTRACT This thesis presents the simulation results and performance analysis of IEEE 802. However. Leveraging on the capabilities of NS2.15. version 2 (NS2) which is an open-source network simulator tool. The simulation is performed using Network Simulator. Gauss-Markov.15. the performance of the IEEE 802. The 802. in particular the surface current.15. The results from this analysis provide insights into the performance of IEEE 802. NS2 is an event driven network simulator developed at UC Berkeley that simulates a variety of networks. The mobility model selected for the simulation has considered the ocean effects on the mobile nodes. mobility as well as loading conditions.15.4 and its suitability for operating in an oceanic environment. As a result. Manhattan Grid and Reference Point Group) do not represent the real life mobility in an oceanic environment scenario.4 in an oceanic environment. the available mobility models (Random Waypoint.4 standard allows simple sensors and actuators to co-exist in a single wireless platform.

THIS PAGE INTENTIONALLY LEFT BLANK vi .

.......... MOBILITY MODELS ............................................................................................. Tidal Current ......................15................................... 20 1....... Network Topologies and Device Architecture.......................................................................................... 5 A......... 25 2..... 14 2.....................TABLE OF CONTENTS I.... 42 2..... III..................................... 28 d.... GENERAL ................................................ Multi-Cluster Network ........................................................... 1 A................................ 17 b... 35 4......... 31 A............................... 38 B.. Functional Features....................... 27 c....... 7 3................... PHY Layer....... Simulation Environment.................................... Overview of Mobility Models............ 33 3................... Reference Point Group Mobility Model .. 2 C........... 5 1.............................................. 9 4................. 42 1.. 31 1................................... 25 a......................4 ......................... 11 5.. MAC Sub-layer ... Post Analysis ......................................... MOBILE AD HOC ROUTING PROTOCOLS ....................... THESIS OUTLINE...... 20 b............... 30 NS2 SIMULATION ENVIRONMENT .................................... OBJECTIVE AND SCOPE.......................... Gauss-Markov Mobility Models ................................... Wind Drag ................ MOTIVATION ........... 1 B.............................. 26 b................... NETWORK SIMULATOR............................ OVERVIEW OF IEEE 802............. Pressure Gradients ...........15............................. Random Waypoint Mobility Model......................................... 23 D.................................... 32 2................. 16 a.......... Summary .............. NS2 Mobile Node Model ........................... Coriolis Deflection .... Mobility Models in BonnMotion................... 18 C.......... Determining Mobility Using Actual Measurements ......... Single Cluster Network........................................... 2 D......... INTRODUCTION.....................................................4 .................................... 12 B.............. 14 3.................................................................. 43 vii II............ Zigbee Routing Protocols ...................................................................................................................... OCEAN EFFECTS ON MOBILE NODES ...... 3 THEORETICAL BACKGROUND .............. 22 2.............................. 13 1.............................. GENERATING OCEAN ENVIRONMENT SCENARIOS ... Setting User Parameters in NS2 ..................................... 37 5.................................................................. 22 d..... 6 2............................................................................................. NS2 Architecture..... Cluster Tree Protocol ... Ocean Surface Current.................................. 25 1.................................. 21 c.......... Near Real-Time Monterey Bay Surface Currents ...... Manhattan Grid Model ........................................................................................................................ 29 3............ Ekman Spiral ............................................................................... Ad Hoc On Demand Distance Vector (AODV) Protocol ............................................................... IEEE 802................................................................. 20 a.. ............

........................ 66 C.............. 107 viii .................. Influence of Network Loading....... 52 5............................... 79 APPENDIX D – SAMPLE TCL SCRIPT .............................. 51 A.................................... Node Energy Consumption.......... 71 4................................... 91 APPENDIX F – SAMPLE AWK SCRIPTS .. RECOMMENDATIONS AND FUTURE WORK................. Generating Communication Pattern File ... 56 3......................... 48 2............... CONCLUSIONS ......... 48 3.................. 70 3................................ 75 APPENDIX C – COMMUNICATION PATTERN SCRIPT................................................................................................. 69 B.............................. 51 2........ Generating Movement Pattern File...... SUMMARY.............. Simulation Setup and Parameters......................................................................................... 71 V APPENDIX A – INSTALLATION OF NS2 ................... Drop Packet Analysis ................. 63 5........... Antenna Height ................... 70 1.................................................... 59 4....................... Capture Threshold (CPThresh_)........... 54 1................... Propagation..................................... 3................. Security Considerations for Network.......... 70 2.......................... 53 B PERFORMANCE ANALYSIS . Packet Delivery Ratio ............................................................. Transmitted Power (Pt_)..................................................................... FUTURE RESEARCH AREAS ................ Propagation Model .............................................. 103 INITIAL DISTRIBUTION LIST . 69 A.................. 73 APPENDIX B – MOVEMENT PATTERN SCRIPT .................................. 67 CONCLUSIONS.................................................................................................................... Influence of Mobility .............................................................................................................. Carrier Sensing Threshold (CSThresh_)............................................................. Network Throughput .. 71 5..................................................................................... Guaranteed Time Slot Management............... SYSTEM SIMULATION AND RESULTS.......................... 49 IV............... Average Network Delay..............C................ 52 3............. 47 1.... Vertical Node Movement in Oceanic Environment ............................... 85 APPENDIX E – SAMPLE TRACE FILE FORMAT ........................ Receiver Threshold (RXThresh_) ........... 51 1......................................................................... 47 PERFORMANCE METRICS ........ 93 APPENDIX G – NODES POSITION AT VARIOUS TIME INTERVAL....................................... 52 4........................................................................ Influence of Node Density.............................. 99 LIST OF REFERENCES................................................. 45 4.. 54 2........................................................................ SPECIFIC TRANCEIVER PARAMETERS........... 53 6.........................................................

.......................... 8 Figure 5 – A Typical Superframe Structure (from ref........................... 21 Figure 10 – Ekman Spiral in Northern Hemisphere (from ref.... [16]) .................. 62 Figure 29 .. 43 Figure 23 – Node movements in Monterey Bay ................ 63 Figure 31 – Results of Packet Delivery Ratio with Node Movement in Time ............................................... 56 Figure 26 ............................................................................................... [3]) .......... [6])... 23 Figure 12 – Ebb current at low tide and Flood current at high tide (from ref.................................................. ..........Results of Network Throughput with Varying Data Rate.. 27 Figure 15 – Manhattan Grid model scenario (from ref..................... 5 Figure 2 – ISO-OSI Reference Model and IEEE 802 Model (from ref...... 66 ix ................15..................... 9 Figure 6 – Path Discovery..... 35 Figure 21 – NAM Application Window...... 7 Figure 4 – LR-WPAN Device Architecture (from ref... 19 Figure 9 – Surface Ocean Currents (from ref............................. 6 Figure 3 – IEEE 802................... 29 Figure 17 – Architecture of NS2... 28 Figure 16 – RPGM model scenario (from ref............... 45 Figure 24 – Process of Generating Mobility File .............. 62 Figure 30 – Node Movements after 1 hour ............... 17 Figure 8 – Typical Multi-Cluster Network ....... 26 Figure 14 – Gauss-Markov mobility model scenario (from ref..................... [17]) ............................................... 33 Figure 19 – Flow Diagram for Running Scenario in NS2 .. [20]) ..................................................... [30]) .................................................. [6])..LIST OF FIGURES Figure 1 – Wireless Networking (from ref........................................................ 24 Figure 13 – RWM model scenario (from ref................ 64 Figure 32 – Results of Network Delay & Throughput with Node Movement in Time 65 Figure 33 – Positions of 9 Nodes Configuration at the 9th Hour............. [25])........................................ 61 Figure 28 ................................ 38 Figure 22 – Data points of Monterey Bay........... 34 Figure 20 – NS2 Mobile Node Model (from ref.......................................................................4 Network Topologies (from ref. [25]) ................... [10]) .......... [25]).............................Results of Average Network Delay with Varying Data Rate......................... [3]) .......Upwelling Effect and Downwelling Effect (from ref.......................................... 58 Figure 27 .............. [6]) ................ 32 Figure 18 – NS2 Event Scheduler (from ref........................................... 23 Figure 11 ........................................ 16 Figure 7 – Typical Cluster Tree Network............................. [15])...................................... 16 and 25 Nodes ............................................. 46 Figure 25 – Initial Coverage with 9....................Results of Varying Node Density with (a) PDR (b) Average network delay and (c) Network Throughput ....................... [29])........ [25]) ......... Forward and Reverse Path (from ref................Results of Packet Delivery Ratio with Varying Data Rate ..........................................

THIS PAGE INTENTIONALLY LEFT BLANK x .

............4 Operating Frequencies.................................................. 39 NS2 New Trace Format for Wireless Packet......................... Table 10........................................... 60 xi ....................................................... 40 ARP Trace Format ................................ IEEE 802................. Table 6............................... Table 3........ Table 2............. 55 Simulation Parameters for Node Density Analysis .................. Table 4............. 57 Simulation Parameters for Network Loading Analysis............... 41 AODV Trace Format ....................... 41 CBR Trace Format .....LIST OF TABLES Table 1................... Table 8....................................................... 37 NS2 Trace Format for Wireless Packet................. Table 7.............. 11 Simulation Parameters...................15............ Table 5...................... Table 9................................... 41 Simulation Parameters............................................

THIS PAGE INTENTIONALLY LEFT BLANK xii .

Also. xiii .ACKNOWLEDGMENTS I would like to take this opportunity to express my sincere gratitude to those who have lent their support in my master study. to senior lecturer Guest Arlene for her patience in teaching and advising on the movement patterns of Oceanography. Fern. in giving me advices and guidance for the completion of this thesis. Professor John McEachen and Professor Gurminder Singh. Firstly. who has continuously encourage and been most supportive in my studies. My appreciation to both my advisors. And for her dedication and patience which have been the driving forces of my determination and achievement. to my beloved wife.

THIS PAGE INTENTIONALLY LEFT BLANK xiv .

A. These nodes would be at various depths and will be drifting slowly towards as well as apart from each other. It also has to be able to handle large variations in information load with the possibility of information transfer being multi-hopped without centralized control. These nodes within MANETs have salient properties including limited power. An example military application of such a system in an ocean environment would be for quick deployment for early warning defense. GENERAL INTRODUCTION Mobile Ad-hoc NETworks (MANETs) advocate self-configuration and adaptation of wireless links between communication devices (mobile nodes) that operate autonomously or as an extension to a wired infrastructure. But there has been relatively limited focus on using MANETs in an ocean environment. The nodes are equipped with antennas for reception and transmission within the communication medium through broadcasting. Advancements in sensor technology have made MANETs a viable solution for many commercial as well as military applications. Wireless networks and large-scale sensors provide information and sensing dominance for network centric warfare. A typical scenario would consist of a collection of nodes. which are ocean buoys containing sensors that are partially submerged at various positions within a designated operating area. low processing power and limited bandwidth. relatively short communication distance.I. 1 . Such a system needs to be robust for frequent and unpredictable changes in topology due to the mobility of ocean buoys. The wireless communication links that form the network have to be characterized by a dynamic topology with no fixed infrastructure since the nodes are highly mobile.

OBJECTIVE AND SCOPE The objective of this thesis is to perform the necessary research to conduct analysis on the performance of IEEE 802.29 [1]. control overhead and transmission collision) as well as behaviors that are specific to MANETs (such as association. An oceanic system creates a challenging environment where the ocean current and waves are dynamic and unpredictable which is highly variable as a function of time and space. IEEE 802.15.15. orphaning and transmission methods). In this thesis.4 is a standard that has been designed for low data rate. C. These factors would cause interference and bit errors at the physical level resulting in unreliable and intermittent connectivity and hence hinder the scalability of protocols.4 in an ocean environment using an open-source network simulator tool. This code conforms to IEEE P802. NS2 is a discrete event simulator that is targeted for networking research purposes.4 extension [2] (contributed code) will be utilized. an IEEE 802.4 in an oceanic environment using an open-source tool called network simulator. There are a host of technical difficulties for implementing this technology for oceanic applications. MOTIVATION Conventional protocols waste energy in collisions and idle listening.15. besides the installation of NS2.15.15. version 2 (NS2). The experiments for performance analysis are simulated using the latest version of NS2 2. It provides substantial support for simulation of protocols over wired and wireless networks. low power consumption and low cost which is ideal for MANET applications.B. This study focuses on performing the necessary theoretical research to conduct analysis of the performance of IEEE 802. delivery latency.4/a18 draft based on the physical layer and the MAC 2 . A simulation model will be built and the various performance behaviors will be investigated that are relevant to a generic wireless networks (such as packet delivery ratio.

how does IEEE 802. D. Each of these models will be examined in details for suitability to represent node movement in an ocean. The computed movement will be used to generate the scenario file in NS2. Gauss-Markov. In essence. what are good alternatives to simulate the ocean mobility model? 2. Manhattan Grid and Reference Point Group mobility model. For the performance analysis. A few of the models considered are Random Waypoint. With the selected mobility model. Chapter VI will conclude these studies and recommend further actions and propose future studies.15. These mobility models are broadly classified as independent or group-based. If it is determined that these models are not suitable. THESIS OUTLINE This chapter provides the introduction and motivation to the study of IEEE 802.layer behavior of a wireless network. Chapter III will specifically focus on the methodology in computing node movements from measured data of the Monterey bay. an appropriate mobility model representing the oceanic environment has to be selected.4 protocol. 3 . Chapter II introduces the theoretical background to this research. Chapter IV is dedicated to the simulation environment and setup with Chapter V discussing the results of the simulation.4 perform in the oceanic environment? Simulations will be conducted using NS2 and evaluated against a set of performance metrics. this thesis endeavors to answer the following questions: 1. Also.15. mobility models that are specific to the simulation are discussed.4 as well as key concepts behind the ocean effects on mobile nodes is presented. Are the available mobility models in NS2 suitable to simulate the ocean environment? Currently there are several models that have been used for research investigation. An overview of IEEE 802.15. Finally.

THIS PAGE INTENTIONALLY LEFT BLANK 4 .

low power applications with less stringent requirements on throughput and latency (see Figure 1). While IEEE 802.15. in which most attention has been given to wireless local area networks (WLANs) and technologies involving the IEEE 802.4 as well as key concepts and theory relating to this research. factors that contribute to the movement of nodes are studied. The various mobility models used in simulating the MANET are discussed. Since the mobility models are determined by the environment. The primary objective is to provide reliable data transfer with reasonable battery life for short range operations while maintaining simple and flexible protocol. if applicable.15.15.4 The technology for wireless communications has made tremendous advances. the IEEE 802. A. the performance matrices used in the evaluation of IEEE 802. IEEE 802.11 standard.4 standard is designed for low cost. THEORETICAL BACKGROUND This chapter provides an introduction to IEEE 802. especially the ocean surface. These ocean effects are taken into consideration for the selection of mobility models.15.II.4 for ocean environment are detailed. Figure 1 – Wireless Networking (from ref.11 standard focuses on high-end wireless communication system. [3]) 5 . Finally.

6 .15. a device can be assigned to either a 16 bit short or a 64 bit extended address during association. Allocated 16 bit short or 64 bits extended addresses.4 standard defines the physical layer (PHY) and medium access control (MAC) sub-layer specifications for Low Rate . OVERVIEW OF IEEE 802. which defines the detailed specifications. Full acknowledgement protocol for transfer reliability.15. Star or peer to peer operation. Low power consumption. 40 kb/s and 20 kb/s. a single network could potentially accommodate 65. Figure 2 – ISO-OSI Reference Model and IEEE 802 Model (from ref.4B (D6) Draft Revision [4] in June of 2006.Wireless Personal Area Networks (LR-WPANs). Unlike WLANs having higher operating range and data-rate. [6]) Some of the unique characteristics of a LR-WPAN are: • • • • • • • Over-the-air data rates of 250 kb/s. the development of the upper layers is led by the ZigBee™ Alliance through definition of application profiles utilizing the simplified five layer ISO/OSI reference model shown in Figure 2. The IEEE standards board approved the IEEE P802.536 (216) devices. Currently. WPANs are designed to function in a personal operating space which can be extended up to 10m omni-directional.4 The IEEE 802.15.1. Carrier sense multiple access with collision avoidance (CSMA-CA). Within a LRWPAN. Allocation of guaranteed time sots (GTSs). Hence.

The decision on which topology to adopt is dependant on the operating distance. 10 channels in the 915 MHz band and 1 channel in the 868 MHz band. a full function device (FFD) or a reduced function device (RFD). A FFD contains the complete set of MAC services and is able to operate as a network coordinator or a network device. typically one-hop star and multihop peer-to-peer or cluster tree topology when communication range exceeds 10m.15. a RFD is simply a network device with a reduced set of MAC services and usually used for simple applications. namely star. Three types of topologies are supported. Each RFD can only associate with a single FFD at an instance whereas FFDs can communicate with other FFDs or RFDs. Link quality indication (LQI). Cluster Network Star Topology Network Cluster Cluster Peer to Peer Network Cluster Reduced Function Device PAN Coordinator Full Function Device Figure 3 – IEEE 802. The following sections highlight some important design features [4.4 Network Topologies (from ref. 16 channels in the 2450 MHz band. 2. [6]) 7 .• • • Energy detection (ED). peerpeer and cluster tree as shown in Figure 3. On the contrary. 5 & 6] of this standard. Network Topologies and Device Architecture Devices that participate in a LR-WPAN can be of 2 types.

There are 14 PHY and 35 MAC primitives described in IEEE 802. form around the PAN coordinator and act as data terminal locations. consisting of FFDs or RFDs. The architecture of a LR-WPAN device. Although a PAN coordinator is required somewhere in the network. each device can form multiple links to other devices. [6]) 8 .2 logical link control (LLC) can accesses the MAC sub-layer. Every event will require passing of service primitives from a layer to another through a service access point.15. Upper Layers 802.2 LLC SSCS MAC PHY Physical Medium Figure 4 – LR-WPAN Device Architecture (from ref. hence increasing redundancy at the expense of complexity. In the peer-to-peer topology. Each layer will contain services which have the capability to build functions on the services of lower layers and present them to the next higher layer. Through the service specific convergence sub-layer (SSCS) an IEEE 802. This topology simplifies routing and reduces direct links at the expense of data traffic latency. shown in figure 4. comprises the PHY layer and MAC sub-layer.4. The PHY layer consists of an RF transceiver including a low level control mechanism while the MAC sub-layer provisions for access to the physical channel for all transfer types. communication is established between devices by a single central controller known as the PAN coordinator.With star topology. The cluster tree is similar except that the network hierarchy is more complex. each device in the network can communicate with any devices within its radio range. The PAN coordinator (which is a FFD) acts as a hub that forms direct links to other devices. These devices.

Data transfer can occur either from a device to a coordinator. The superframe consists of an active and an inactive period where beacons in a beacon-enabled network are periodically transmitted for synchronization. some of the functional features used are the superframe structure. In general. [3]) • Data transmission methods. transmitting devices will listen to the channel for a predetermined time to check for activities on the channel. Within the active portion. low power consumption as well as self-configuration and orphaning. If the channel is idle. indirect transmission and GTS transmission. only devices with a guaranteed time slot (GTS) can perform data transmission. the data transfer process can be classified into direct transmission. In CSMA-CA. CAP CFP Beacon GTS 0 1 2 3 4 5 6 7 GTS Inactive Period 8 9 10 11 12 13 14 15 Active Period Figure 5 – A Typical Superframe Structure (from ref.15.3. the device is permitted to transmit and if busy. Direct data transmission will happen for the three data transfer cases and depending on whether the network is beacon9 . different data transmission methods. coordinator to a device or from one peer to another in a peer-to-peer multi-hop network.4 standard. Functional Features In the IEEE 802. devices in the network can transmit with slotted Carrier Sense Multiple Access – Collision Avoidance (CSMA-CA) in the contention access period (CAP). The superframe (shown in Figure 5) is a special network communication architecture introduced for time division multiplexing. In the contention free period. • Superframe structure. the station has to delay its transmission.

Orphaning mechanism provides detection of link or node failures for devices in beacon-enable mode and is tracking beacons. Finally.enabled or beaconless.e. Devices can also be configured to low power (i. Other inherent properties to reduce power consumption are the small CSMA-CA back-off period and short transceiver warm-up time. When a device misses a pre-determined number of beacons consecutively. devices are usually battery operated and hence power consumption is a vital factor. Due to their mobile nature.15.4 to prolong device battery life. • Self-configuration and Orphaning. GTS transmission does not require the use of CSMA-CA protocol. the device will perform a re-alignment procedure to establish link with its coordinator. GTS data transfer occurs both from a device to its coordinator and from coordinator to devices. it is possible. The self-configuration capability is part of the association and disassociation functions in the MAC sublayer. This capability will automatically establish a star network and also perform self configuration of peer-to-peer network. Indirect data transmission applies only to data transfer from a coordinator to its devices where the coordinator keeps a data frame in a transaction list and waits for the device to extract data. Devices will check on beacon frames received from the coordinator to determine if data packets are pending in the transaction list. 10 . but unlikely that indirect data transmission occurs in beaconless mode where unslotted or slotted CSMA-CA is used in the data extraction procedure. • Power Consumption. Most of these mechanisms operate in beacon enabled mode where the receiver of coordinator or its devices are disabled for a specific period during direct transmission. Several power-saving mechanisms are incorporated in IEEE 802. a slotted or unslotted CSMA-CA is used. Also. sleep) state when there is no data transmission or transmitting GTS data transfer at low duty cycle.

4 has been designed to be applied worldwide supporting three different operating frequency bands. The PHY layer acts as the interface between the MAC sub-layer and the physical medium and provides both data services and management services accessed through two service access points. PHY Layer One of the primary reasons for the failure of several proprietary technologies is the inability to adapt.4 GHz band and the licensed 868/915 MHz band. There are 2 types of frequency bands defined in the PHY layer. • Activation and deactivation of radio transceiver. Frequency band 2. The following tasks are the responsibility of the PHY layer. the internal operating state of the transceiver can be de-activated (sleep mode). congestion state and data rate of each channel (in terms energy and cost efficiency). with a different number of supporting channels and at specific data rates (Table 1). With that. there 27 channels and 3 different data-rates that is specific to the frequency band.4. Depending on the requests from the MAC sub-layer.15. IEEE 802. transmitting or receiving. the license-free industrial scientific medical (ISM) 2. The availability of the ISM band eliminates the need for a license and allows development of devices to be used anywhere in the world.15. However. investment risk is greatly reduced which results in lower cost devices. IEEE 802. IEEE 802. The basis for the selection is usually dependent on availability. 11 . Despite its simplicity. In total.4 GHz 915 MHz 868 MHz # of channels 16 10 1 Data rate (Kbps) 250 40 20 Applicability Worldwide USA Europe Restrictions Unlicensed Licensed Licensed Table 1.4 also strives to provide flexibility which allows selection of operating in any one of the channels.4 Operating Frequencies.15.

This is the primary task of the sub-layer. or both measures to compute the link quality or strength where packets are received. network configuration. channel access. The features of MAC sublayer includes beacon.4. carrier sense and carrier sense with energy. The last mode will report a busy medium when both above-mentioned conditions are met. a medium is reported busy when the detected signal has the modulation and spreading characteristics of IEEE 802. The result of this measure is used in the network or application layer. Upon receiving request from MAC Data transmission and reception. • Clear channel assessment (CCA) for CSMA-CA. The following tasks are the responsibility of the MAC layer. a medium is reported busy if any detected energy is above the ED threshold. 12 . 5. This measurement is derived from receiver ED estimates. • • Channel frequency selection.15.• Energy detection (ED) within the current channel. providing MAC data and management services. signal-to-noise ratio. This service performs the estimation of the received power within the channel bandwidth and this result can be used in the network layer for channel selection or for the purpose of clear channel assessment (CCA). As for carrier sense mode. guaranteed time slot (GTS) and link management. • Link quality indication (LQI) for received packets. In energy mode. PHY layer where various modulation and spreading techniques are employed depending on the frequency band. MAC Sub-layer The MAC sub-layer acts as the interface between the SSCS and the PHY layer. CCA is performed by the PHY layer using at least one of three modes of energy. the PHY layer will tune to the selected channel.

unstable channel states and resource constraints such as power and bandwidth. Various such as CSMA-CA. Synchronization is required for data polling. In a MANET. synchronization of attached device and identifying the network. B. the movement of nodes will cause communication between nodes to be disrupted 13 . • Association and disassociation of network. MOBILE AD HOC ROUTING PROTOCOLS Due to the highly dynamic nature of mobile nodes and the absence of a central controller. • Employing CSMA-CA mechanism for channel access. A FFD that is designated as a coordinator has the ability to operate in beaconless or beacon-enabled mode. While in beacon-enabled mode. • Maintain reliable link between two MAC sub-layer entities. the request-to-send (RTS) and clear-to-send (CTS) mechanism are not utilized in the CSMA-CA. MAC sub-layer association and disassociation supports the automatic setup and selfconfiguration of star and peer-to-peer network. Some of the considerations required in the design of MANET routing protocols include the mobility of nodes. are employed by the MAC layer to provision for reliable link. frame mechanisms acknowledgement and retransmission. GTS allows allocation of dedicated resource to a particular device within a certain portion of the superframe. energy saving and detection of orphaning. • Allocation and management of guaranteed time slot (GTS) mechanism. CRC data verification. Beacons are transmitted periodically for describing the superframe structure. Beacon-enabled mode allows the use of superframe that has a structure which is bounded by network beacons and is divided 16 equal sized slots. In consideration of the low data rate in LR-WPAN.• Beacon generation for PAN coordinator and synchronization. traditional routing protocols used for a wired network cannot be applied directly to a MANET.

low power consumption. power availability is often limited since the nodes are connected to batteries. Also. network formation and routing of packets.4 have no notion of node resources and energy. the network and upper layers of IEEE 802. Zigbee employs a basic master-slave configuration where each master can support up to 254 slaves that can be nested to support a hierarchical routing strategy [7]. Similar to IEEE 802. AODV also has the ability to adapt to route changes and can create new routes when error occurs. At the network layer. The routing algorithms defined for use by Zigbee are the Ad Hoc On Demand Distance Vector (AODV) protocol and the Cluster Tree protocol.15. Zigbee provides a unique feature of redundancy in communication hence eliminating single point of failure in mesh networks. network discovery. Zigbee is an industrial standard that is targeted for low data rate.4. the broadcasting of radio channels can be highly unstable and the network layer has to interact with the MAC layer for available channels.4 is being implemented by the ZigBee Alliance. Currently. 2. In addition. Zigbee Routing Protocols The MAC and PHY layers of IEEE 802. 1.15. In addition. Routing is accomplished by discovering the shortest possible route and ensuring that these routes do not contain loops. low cost as well as long life wireless network operations. Detailed Documentation for these two protocols is provided in the Zigbee specification [8]. Individual mobile nodes operate as a special router where routes are obtained only when required with minimal reliance on periodic updates.from frequent path breaks and reconnections.15. Ad Hoc On Demand Distance Vector (AODV) Protocol The AODV is a pure on-demand acquisition algorithm system that allows message passing through neighboring nodes to nodes that are unreachable [9 & 10]. Zigbee supports node activation. Nodes not within the active 14 . Details of Zigbee Routing protocols will be discussed and other ad hoc routing protocols will not be addressed in this thesis.

If that particular node has received a similar RREQ. the sequence number and broadcast id. a reverse path is automatically set up where every node maintains the record of the neighboring node that sends the broadcast. the Path Discovery process is initiated. it increases the hop count and rebroadcasts the RREQ to other neighboring nodes. In essence. and one such technique is local broadcasting of “hello” messages. The broadcast id is incremented for a new RREQ. The source address and broadcast id will uniquely identify the RREQ. There are several techniques employed for a mobile node to be aware of other nodes in its vicinity. Along the path from the source to destination node.paths neither maintain any routing information nor participate in exchanging routing tables. The process begins with the source node initiating route request (RREQ) packets to the neighboring nodes. information about changes in local connectivity. 15 . The primary objectives of the algorithm are [6]: • • • Broadcast discovery packets when necessary Distinguish between local connectivity management and general Disseminate to neighboring mobile nodes that are likely to need the topology maintenance. When an intermediate node receives a RREQ. AODV seeks to minimize the number of control messages sent. a route needs to be discovered or maintained when there is communication between two nodes or that the nodes are in the direct path between the source and destination nodes. Each node keeps track of neighboring nodes by listening for the “hello” messages that each node broadcasts at set intervals and by also maintaining two separate counters. the redundant RREQ will be dropped. Routing tables of the neighboring nodes are organized to have optimized response time for local movements and establishing request of new routes. For the instance where a destination or intermediate node has no routing information. However.

When the RREP packet routes back to the source. A route error message (RERR) allows nodes to adjust routes by removing all routes containing bad nodes from the routing table. [10]) 3. (a) (b) Figure 6 – Path Discovery. This process will establish a uni-directional route and is repeated in the reverse direction for a bi-directional route. The path discovery process. Forward and Reverse Path (from ref. a cluster head is selected which will assign a unique 16 . Due to movement of nodes. the route to the destination is determined by comparing both destination sequence number in the node’s route entry and the RREQ. The network is mainly self-organized and network redundancy is maintained to achieve a high degree of fault resistance and self-repair. Within a cluster of nodes. forward and reverse path are shown in Figure 6. This specification is detailed in RFC 3561 [11]. a forward pointer is established on each node and timeout information is updated. Essentially. Cluster Tree Protocol The Cluster Tree Protocol utilizes link-state packets to form a single cluster network or a potentially large cluster tree network.In summary. there could be errors during routing of messages. The node will respond by either rebroadcasts of the RREQ or unicasts a route reply (RREP) packet back to the node in which request is received. nodes form a cluster during the self-organizing process and these formed clusters will connect to each other.

Neighboring nodes will send a 17 . the DD is a node having high computing ability and large memory space. the node appoints itself as the cluster head and sends out “hello” messages. that node will listen for “hello” messages (i. based on the initiating node or stored parameters.node ID to each individual node member during the cluster formation process. the selection is determined from stored parameters such as transmission information. When a particular node is activated. followed by the cluster head expanding links to other node members forming a cluster. For the other option. After a certain duration when no messages are received.4 MAC layer) from other nodes. computing information or location As the cluster head. the node will periodically broadcast “hello” messages which consist of a partial MAC address and node ID 0.e. Single Cluster Network The process of cluster formation begins with the selection of cluster head. Communication range Cluster Head Figure 7 – Typical Cluster Tree Network a. beacons in the IEEE 802. Basically. There are several ways to select the cluster head. A typical cluster tree network is shown in Figure 7. Below sub-section details the process for single and multi cluster network. the node reverts to its original status.15. If no connection request is received. The connection between clusters is established using the Designated Device (DD) which assigns a unique cluster ID to each cluster. range. power capacity.

When a cluster head is assigned to a new CID. all member nodes within the transmission range of cluster head have a star topology with one hop. Also. If there is a need to change the topology. connection requests will be rejected by assigning a unique node ID. It is possible for a node to receive a “hello” message from another cluster.“connection request” message upon receiving the “hello” message. In addition. The DD also serves to calculate the shortest route to clusters and keep nodes within the network informed. CID0 is added to the neighboring list and updates 18 . DD is usually the cluster head of cluster 0 and begins by sending “hello” message. its member nodes are informed using the “hello” message. For the instance where all node IDs have been used or other limits have been reached. If a node member receives the “hello” message from the DD. Due to the dynamic mobile nature. Multi-Cluster Network A network having multi-clusters (as shown in Figure 8) will need a Designated Device (DD) for assigning a unique cluster ID to individual cluster heads. if no update is received from a member node. This process allows the cluster head to be aware of the entire topology for better optimization. A cluster head in trouble will result in stoppage of the “hello” messages and member nodes will be re-configured. the periodic “link state report” message is used to indicate the presence of a troubled node. b. the cluster head will send a “topology update” message. The receiving node will include the cluster ID (CID) of the transmitting node and will update the cluster head through a link state report. it is eliminated from the cluster. Neighboring cluster heads respond by sending a “connection request” message to join cluster 0 followed by a request for a CID to the DD. This cluster can also expand to a multi-hop structure with each node having multiple connections. The cluster head node will in turn reply with a “connection response” message containing the node ID and the respective node member will acknowledge the receipt of message.

Border routers connect the clusters by performing relaying functions where messages are forwarded to border nodes of an adjacent cluster or a destination node that resides in the cluster. In return. Only the DD can communicate with all nodes in the 19 . Eventually. a “network connection response” message containing a new CID is sent to the parent cluster head. a backup DD is often assigned. A “CID request” message is then sent and upon receiving a “CID response” message. Individual nodes belonging to a cluster have to maintain a record of their parent and child clusters as well as the border node ID associated with the clusters.its cluster. the DD should gather the entire tree structure of the clusters. results of the updated route are sent through a “topology update” message from the DD to the cluster. This node will then be selected as the border node for that particular cluster and the “network connection” message is sent to establish a connection to the DD resulting in the border node being a member node of cluster 0. Cluster 2 Cluster 1 Cluster 0 CH2 CH1 DD Border nodes Figure 8 – Typical Multi-Cluster Network Periodic “network link state report” messages are sent by cluster heads to report link state information to the DD for computing route optimization and to update network redundancy. Members in the cluster will be informed through “hello” messages. Other clusters not in the vicinity of the DD utilize intermediate clusters to obtain the CID. To prevent network downtime caused by the DD.

wind drag and the pressure gradient. the sub-surface layer will not be considered. or essentially permanent. It can be transient. extending over a long horizontal distance [12]. Although the wind strongly affects the surface layer. Hence. the current system is complex with the actual current flow varying both spatially and temporally. However.network and the broadcast message is forwarded by the border node from the parent to the child cluster. In some regions. its influence on the ocean is restricted to about 100 meters (325 feet) in depth [13 & 14]. ocean currents can be generally characterized into two types. Since this thesis is only concerned with surface currents which cause movement of the floating nodes. a. Wind is air moving across the Earth’s surface and is generated by asymmetrical heating of Earth by the sun. affecting a small area. 1. The driving force for ocean currents comes from the atmosphere (mainly from winds). Ocean Surface Current An ocean current can be described as a directed movement of oceanic water at the ocean’s surface. surface and sub-surface. Such pattern is caused by the interaction of Coriolis deflection. OCEAN EFFECTS ON MOBILE NODES When nodes (devices on a buoy) are deployed in an oceanic environment. two or more currents may flow in different directions at different depths. there are various factors that affect their movement. Coriolis Deflection Coriolis deflection is caused by the rotation of the Earth due to decreasing velocity at Earth’s surface with increasing latitude. The deflection 20 . Currents exist at all depths in the ocean. the ocean surface current and tidal waves have the most effect on the mobility of the nodes. Essentially. C. resulting in generation of surface circulation patterns.

results in the surface current moving in a clockwise direction (bending to the right) in the Northern Hemisphere and counter-clockwise in the Southern Hemisphere (bending to the left). [15]) 21 . the water currents will flow down the pressure gradient at an angle instead of directly towards the low pressure. the air molecules that are dragged along the surface collide with the surface water molecules and transfer energy through frictional drag. creating a region of high pressure at the surface. As the wind blows across the ocean surface. Figure 9 – Surface Ocean Currents (from ref. b. These differences in air pressure will give rise to winds. Therefore. Wind Drag Air at the poles is cooled and hence sinks. Differential heating on the Earth’s surface by the sun causes air to rise and creates a region of low pressure at the surface of the equator. Surface winds blow in a regular flow pattern and are influenced by the differential heating of air across Earth’s surface and Coriolis deflection. setting the surface water in motion. This process results in momentum being transmitted from the air to the water molecules.

Mounds are caused by convergence (i. the sea surface is warped into broad mounds and depressions. Ideally. creating current loops.e. 22 . the net transport of water is approximately 90° off of the wind. Pressure Gradients A pressure gradient is a change of pressure across a horizontal distance. the surface current resulting from wind drag is very much affected by surface winds.e. d. This phenomenon of creating current loops is known as circulation gyres and is shown in Figure 9. As such. the pressure gradient will rise. as shown in Figure 10. With depth. the speed of the generated current is only approximately 3% of the wind speed. it is deflected (a function of location and speed) by Coriolis. the speed is reduced and the direction of the current changes. water flows together and sinks) while depressions are caused by divergence (i. However.Due to the process being inefficient. Eventually. pressure gradient is almost always balanced by Coriolis force and hence their net result causes no movement. and a phenomenon called Ekman Transport occurs. Ekman Spiral While the surface water moves approximately 45° to the right of the wind in the northern hemisphere. the pressure gradient will increase. When water is flowing down pressure gradients (high to low pressure) on the ocean’s irregular surface. With the variation in the height on the surface. This forms a sea surface topography affecting surface circulation. This flow pattern is known as the Ekman spiral. c. currents come into contact with continents and are deflected. With a greater differential pressure over a specific distance. water rises to surface and flows outwards).

Similarly. Water moved offshore is replaced by waters from below. [17]) 2. Tidal Current Tides are essentially very long-period waves that cause the sea level to rise and fall in response to the forces exerted by the moon and sun [13 & 18]. movement of water to the right of the wind direction caused by Ekman transport will results in downwelling. Figure 11 .Figure 10 – Ekman Spiral in Northern Hemisphere (from ref. 23 . When water moves to the right of wind caused by Ekman Transport. This movement of water offshore is replaced by cold water moving from below to the surface. upwelling occurs. [16]) Surface currents and the Ekman Transport result in the process of upwelling or downwelling (see Figure 11) which is an important aspect of effects along the coasts.Upwelling Effect and Downwelling Effect (from ref.

water currents are generated. tidal currents are relatively weak. There are two kinds of flow from this tidal current. The speed of tidal currents can reach up to several kilometers per hour near coastal regions. gravity and inertia will cause two major tidal bulges [19]. Effectively. In the open ocean. Ebb flow is where tidal current is receding to the sea or low tide ensuing. One of the tidal bulges is from the lunar gravitational attraction that “draws” the ocean to the side nearer to the moon. The strongest currents (flood or ebb) usually occur before or near the time of the high and low tides. flood flow and ebb flow. Flood flow occurs when the tidal current is coming towards the coast or high tide is ensuing (see Figure 12). Figure 12 – Ebb current at low tide and Flood current at high tide (from ref. The weakest currents occur between flood and ebb currents. The size and position of the bulges are very much affected by the sun where there is a complex interaction between these forces and the lunar forces. [20]) 24 . and counterbalancing that force is inertia. Another is on the opposite side where the inertial force exceeds the gravitational force due to less gravitational attraction from the moon and hence forms the other bulge. From the horizontal movement caused by the rising and falling of tides. and are known as slack tides.Tides are phenomena caused by the gravitational pull of the sun and moon.

1. the main focus is on ad-hoc wireless networks where nodes can move freely within an area of influence. such models are categorized into those that are related to cellular networks or ad-hoc networks. A route must be established between the intermediary nodes for communication between a pair of nodes. Mobility Models in BonnMotion Mobility models are used in NS2 to generate the scenario and such scenario can be generated by BonnMotion software [22]. independent or group-based. it is imperative to use a mobility model that accurately represents the ocean environment. Existing mobility models used in simulations can be divided into two distinct classes. For this thesis. Changes in speed and heading must occur within reasonable time steps.D. Essentially.15. BonnMotion software is a Java program developed within the Communication Systems group at the 25 .4 protocol. 2. the modeling of the node positions is vital as performance is dependant on the transmission range which is fairly short with respect to the size of the field. The mobility model should attempt to represent the movement of actual mobile nodes floating on the sea surface. MOBILITY MODELS In order to simulate IEEE 802. model the movement of each node independently from other nodes.15. Overview of Mobility Models Previous work [21] has shown that the chosen models have a great impact on the results of the simulation and hence the evaluation of the IEEE 802. on the contrary. the nodes exhibit a certain relationship between each other and that relationship will determine the movements within the field.4 protocol for an ad-hoc network. Independent models. In the latter category. Hence.

24] available in BonnMotion are the Random Waypoint model. Figure 13 below shows a scenario generated using RWM model. There are currently five mobility models. and scenarios generated can then be exported for NS2. Upon the expiry of pause time.Institute of Computer Science IV of the University of Bonn. Initially. nodes are placed at certain locations in the simulation area. uniformly distributed between a minimum and maximum speed. The nodes in this model will appear to move randomly within the confinement of the simulation boundary. The models [23. These nodes will remain in the new position until the pause time has reached and the process repeats until the end of simulation. a. An overview of each model is provided below. each node will remain stationary for the pause time duration. Random Waypoint Mobility Model The Random Waypoint Mobility (RWM) model is a simplistic model to represent randomness in movement patterns. Germany. two versions of Gauss-Markov model. Manhattan Grid model and Reference Point Group Mobility model. nodes will move toward a new arbitrary position determined by a randomly selected speed. [25]) 26 . It is capable of creating and also providing analysis of mobility scenarios. The required parameters are the pause time between changes and the direction and/or speed during each change. Figure 13 – RWM model scenario (from ref. During the simulation run.

the next location (and velocity) of a particular node is likely to be correlated to the previous and current position. 27 . the change in velocity will be limited due to physical constraint. This model assumes that node movement has a pre-determined destination. During simulation run. a velocity vector with a larger norm is multiplied with an appropriate scalar quantity to reduce the speed. A typical scenario generated from Gauss-Markov model is shown in Figure 14. Gauss-Markov Mobility Models Gauss-Markov Mobility Model is designed to adapt various degree of randomness in the mobility pattern with the use of one tuning parameter. Hence. A maximum speed can also be specified. mirrored). instead of stating the velocity.e. Within a short period of time. [25]) The implementation of the original Gauss-Markov model follows the publication of B. There are two models implemented. The parameters required are a norm and random vector which are assigned to each mobile node. the original Gauss-Markov model and Gauss-Markov model. Figure 14 – Gauss-Markov mobility model scenario (from ref. When a node is the approaching boundaries and about to travel beyond the boundaries. Haas [24]. Liang and Z.b. This keeps the nodes in the boundary of the simulation area. the direction of movement is forced to flip by 180 degree (i.

There are subtle differences in the implementation of this model. the minimum or the maximum value is selected. [25]) 28 . During simulation. As with the original Gauss-Markov model. parallel movement in the x or y direction). This model specifies that the movement of nodes is only allowed along paths of predefined grid (i. the new speed and movement direction is selected from a normal distribution of previous values. Manhattan Grid Model The Manhattan Grid model is a model where the mobility of nodes is confined in a pre-defined grid area within a topological infrastructure [26].normal distribution). minimum speed (with a defined standard deviation for speed . probability of speed change at position update and probability that node will turn at cross junctions. Camp. nodes can move beyond the simulation boundaries and the next movement vector is updated with an angle that brings the node back into the simulation area. When the speed exceeds this range. Figure 15 shows the scenario from a Manhattan Grid model.e. c. Davies publication [23]. The parameters that are used to describe the model include the mean speed. rather than depending on the velocity at a previous instance and a random variable. The speed can also be constrained within a specified range.The Gauss-Markov model is similar to the description from the T. J Boleng and V. Figure 15 – Manhattan Grid model scenario (from ref.

right or go straight depending on a certain probability. unlike previous models. This model represents the randomness in movement of groups as well as individual nodes within the group. in addition to the group motion (see Figure 16).Such a model is useful in emulating the movement pattern in an urban setup where grids are composed of a number of horizontal and vertical streets. Nodes are formed into groups where each group will have a logical centre. Within a group. individual nodes move depending on a pre-defined reference point which follows the group movement. Figure 16 – RPGM model scenario (from ref. Group movement is determined by the group’s logical centre and the motion of nodes in a group is characterized by the centre direction and speed. intersecting each other. When a mobile node is at an intersection of a horizontal and a vertical street. [25]) 29 . Node movement is somewhat driven by a destination and physical constraints within the environment. Reference Point Group Mobility Model Reference Point Group Mobility (RPGM) model [27]. is a group mobility model and allows independent random motion behavior for each node. The group movements will be based upon the path traveled by a logical center. it can turn left. d.

maximum distance to center of group and group size standard deviation. Such properties are ideal for simulating a wireless personal communication service that is restricted by wireless coverage.4 protocol. nodes could be washed ashore or drift further into the ocean.15. For modeling of ocean surface current. the velocity change is not random but deterministic and is influenced by surface current depending on the time of day. Summary Although the RWM model is simple and widely used. The Manhattan mobility model has the properties of high spatial and temporal dependency with a certain restriction on mobility defined by the grid. Hence. it does not capture the essence of node movement on the ocean surface.This model is parameterized by the number of nodes per group. the models in BonnMotion do not accurately represent the ocean environment and cannot be used to provide meaningful evaluation of IEEE 802. 3. The RPGM model provides a general and flexible framework for describing mobility patterns that are task oriented and time restricted. group change probability (where nodes migrate from one group to another). 30 . the movement of nodes is not constrained in any particular fashion except at the coast line. The ocean current is determined mainly by the wind and not necessarily random in movement pattern. Such a model is suitable for military operation environment where military forces usually move in groups. However in oceanic environment. The RPMG is the most promising among the previous models as the nodes in an ocean environment could possibly form group since the difference in velocity of adjacent nodes is small. However. Both the Gauss-Markov models constrain the movement of nodes to be within a certain operating environment.

In addition. A. the uses of network simulation techniques allow simulating network behavior by mathematical calculation of network interaction. The NS2 software and documentation is currently maintained by University of Southern California' Information Sciences Institute (USC/ISI).4. it has the capability to generate graphical details of network traffic (through the Network Animator. generation of NS2 movement and traffic pattern scripts as well as the performance matrices for evaluation of IEEE 802. NS2 began as a s variant of REAL [28] which is a network simulator originally intended for studying the dynamic behavior of flow and congestion control schemes in packet-switched data networks. Despite its capabilities. It is open-source and operates on the UNIX-based operating systems providing substantial support for simulation of routing. NS2 has been built by various developers and contains several inherent known as well as unknown bugs. NS2. This chapter describes NS2.III. NAM) and supports several routing and queuing algorithms. NS2 SIMULATION ENVIRONMENT In computer network research. Installation of NS2 can be done by downloading the all-in-one version or downloading individual components and then compiling each component in a single directory. NETWORK SIMULATOR The network simulator. Network simulator (NS2) is such an open source simulation tool that operates on the UNIX-based operating systems. wireless and satellite networks. It is also possible to run NS2 on Windows machine using Cygwin application. which provides a Linux-like environment under Windows. is a discrete event simulation tool for network simulation which will be used for evaluating the performance of IEEE 802. the methodology used to compute node movements. 31 .15.15. multicast protocols and IP protocols over wired. or simply by operating NS2 through a VMware player.4.

a scheduled time and a pointer to an 32 . Figure 17 – Architecture of NS2 Basically. the two languages are required to complement both run-time speed and iteration time. A detailed simulation involving efficient manipulation of bytes. there is a corresponding link between the two hierarchies. The importance of these tasks requires a system programming language similar to C++ programming.1. where certain parameters might need to be varied for research. A scripting language like OTCL is ideal for such a task that allows frequent configuration changes. NS2 Architecture NS2 is written in the C++ programming language with the Object Tool Common Language (OTCL) as the front-end interpreter. An event is an object in the C++ hierarchy with a unique identity. packet headers and implementing algorithms with large data set will require run-time speed. iteration time is vital. A class of hierarchy supported in C++ is the compiled hierarchy and the interpreter hierarchy for OTCL. Figure 17 shows the architecture of NS2. There will be objects that are completely implemented in C++ or OTCL while some can be implemented in both languages. On the contrary. as shown in Figure 18. A scheduler maintained event timing that determines the advancement of the simulation. For objects that are implemented in both languages.

The final input is the configuration file that defines the ad hoc network routing protocol which is often the main file where the scenario files are called. the movement pattern file. node creation and configuration. The results from the simulation are generated in two separate files. the event will be placed onto an event queue linked to the scheduler.0 through VMware server. The movement pattern file describes all node movements while the communication pattern file describes the packet workload presented at the network layer during simulation. As the simulation progresses. Basically. Event Queue … Executing event Event Event Event Event Node 1 Node 2 Node 3 … Node N Figure 18 – NS2 Event Scheduler (from ref.tr) and a 33 . These two files essentially constitute the description of the simulation scenario. Simulation Environment The version in use for this thesis is version 2. The installation process is available in Appendix A. the communication pattern file and the configuration file. the scenarios are implemented with scripts written in TCL that comprise commands and parameters for simulator initialization. [29]) 2.29. the first event in the queue is assigned with the appropriate network component and executed. an output trace file (*.object that handles events. with installation of the allin-one package that operates on Redhat 9. The data structure is ordered to be synchronized with the executing events invoked by the event handler. For every event created by the network component. There are three inputs to the simulator.

traff) Network Animator file (. file (TCL script) Traffic Pattern Parameters Movement Generator Traffic Generator Movement pattern file (. Analysis of these packets can determine the performance effects from parameter variation.scn) NS2 Communication pattern file (. details of node behavior.NAM trace file (*. packet drops. routing protocols and are performed using awk command.java) Analyzer NAM Excel Output file Topology animator Performance graph Figure 19 – Flow Diagram for Running Scenario in NS2 34 .nam). The nam file contains information on the topology such as node movement traces and events. Scenario Parameters Router config. packet transmissions and receptions. etc. perl scripts or available analysis programs. It is similar to trace files with the exception of the syntax that is used by the network animator (NAM) for visual representation of the simulated scenario.tr) (Awk/. The trace file will contain information on the various events which occurred. The procedure for running the scenarios is shown in Figure 19. communication layer.nam) Trace file (.

transmission and reception on a channel are included to create a wireless mobile environment. added functionalities like node movement.3. As part of the mobility extension. Figure 20 – NS2 Mobile Node Model (from ref. NS2 Mobile Node Model The mobile nodes model is part of CMU’s mobility extension [30] to NS2 where each mobile node operates independently to compute its position and velocity as a function of time. Mobile nodes are attached to a channel through network interfaces that carry packets between nodes. [30]) 35 . Figure 20 shows the mobile node.

Routing agents are used by the nodes to compute the routes from source to destination. There are total of 25 nodes and one of them being the PAN coordinator. Using CBR allows the network to be tested for congestion that will affect delivery ratio. copies of the packet are distributed by the channel to all interfaces residing on the channel. The PAN coordinator is the node at the center.15. During transmission.4 protocol which is part of the NS2 contributed code.Features including node movement. the simulation for this thesis is based on IEEE 802. Given that nodes may not have direct line-of sight and communication range is limited. the radio propagation model for our simulation is the Two-ray ground model approximation assuming reflection off a flat plane. Active flow is the communication that is established between a node and the coordinator. There are two MAC layer protocols implemented for mobile networks. The simulation parameters for this thesis are described in Table 2. The nodes are placed 15m apart form each other. Applications such as constant bit rate (CBR) packets are bounded to a particular node and a routing agent. There are three models supported. Two-ray ground and shadowing model. All the traffic flow from various nodes to the PAN coordinator. Free-space. periodic position updates and maintaining topology boundary are implemented in the C++ portion whereas the network components (such as classifiers. Node parameters Radio Propagation Model Physical parameters 36 . The packet is then passed to the link layer (LL) and queued until a signal is received from the MAC layer for transmission on the channel. Whether a particular interface receives the packet is determined by each network interface’s information and radio propagation model that simulate the physical nature of wireless communication. LL and MAC) are implemented in OTCL. of nodes Node movement Node position Constant Bit Rate (CBR) application based on simple User Datagram Protocol (UDP). stationary nodes and node movements in ocean environment. Fifteen active flows are used for our simulation. Identifying the correct parameters for the simulation is essential for realistic analysis of the study. This is the payload of a packet that excludes the MAC and PHY layer headers. Two types of scenario will be simulated. 802. However.11 and TDMA. Traffic parameters Traffic type Active flow Packet size Traffic direction No.

4.Antenna Path loss The antenna used is omni-directional having unity transmitter and receiver gain. there is a set of control parameters to be specified by the user as well as output parameters that need to be analyzed. trace object for the network simulator and network animator as well as the General Operations Director (GOD) will be created. obstruction and etc. 37 . Queue type Routing layer parameters Queue length Table 2. Packets entering the queue will be executed first and once the queue limit is reached. the properties of individual mobile nodes in the ad hoc network are defined as shown in table 2. the scenario which defines the environment is included in the movement pattern file and communication pattern file (detailed in the following section). The queue length of 100 packets is used as the default parameter. DropTail is the queue type employed that implements the “First in First out” techniques. The path loss is defines as the attenuation during transmission due to factors like antenna height. Simulation Parameters Setting User Parameters in NS2 For any simulation run. Next. the simulator objects will be set up where the simulator instance. As mentioned earlier. A sample of the script used for the simulation is attached in Appendix D. Each node is then attached to the channel with movement and traffic specified in the movement pattern file and communication pattern file respectively. Finally. which is used to store global information about the state of the environment. GOD is a simulator object. last packet entering the queue will be dropped. The configuration file is essentially a script that consists of a general format that can be used to simulate any kind of routing protocol. It is assumed that there is no attenuation and hence the path loss is 1. network. information to end the simulation is included. The topology is also defined where a load_flatgrid object specifies a 2-D terrain. or nodes. After setting up the initial parameters. a large queue length is not required as the data rate is low. The script begins with the definition of the wireless physical medium parameters and initialization of simulation parameters. With a WPAN.

Upon startup. NAM supports topology layout.5. Through the user interface. NAM provides several functions to control the animated simulation. Simple animation event commands are read from nam files to minimize memory usage. The Network Animator file (*. It is created to allow accommodation of large animation data sets and adaptable to different network visualization situations. packet level animation and various data inspection tools. Figure 21 – NAM Application Window There are two types of trace formats that can be used in NS2. A screenshot of NAM is shown in Figure 21.nam) is utilized by the Network Animator (NAM) which is a Tcl/TK based animation tool for viewing network simulation traces and real world packet traces [31]. The old format for wireless simulation traces begins with either 38 . The trace files obtained from the simulation contains the packet dumps between nodes communication. the two generated files can be used for performance analysis. NAM will read the nam file and create the topology followed by displaying the layout on a window. Post Analysis At the end of the simulation.

next hop information (H). As with the old format. D or f to denote sending. receiving. The old trace format is as shown in Table 3.9f _%d_ %3s %4s %d %s %d [%x %x %x %x] double int double Commence with : s: Send Wireless r: Receive Event D: Drop f: Forward double string string int string int hexadecimal hexadecimal hexadecimal hexadecimal Time Node ID X Coordinate (If Logging Position) Y Coordinate (If Logging Position) Trace Name Reason Event Identifier Packet Type Packet Size Time To Send Data Destination MAC Address Source MAC Address Type (ARP. Typically. dropping and forwarding (i. the new format has similar field types. NS2 Trace Format for Wireless Packet As a part of the effort to merge wireless traces. r. MAC level packet information (M) and packet specific information (P) shown in Table 4.2f) %3s %4s %d %s %d [%x %x %x %x] %.one of the characters s. the field type is followed by general flag (-t) and sets of flag/value pairs with the first alphabet of the flag type representing node property (N). This revised format supports backward compatibility with previous trace formats and is divided into the following fields.2f %6. IP level packet information (I).e. IP) Table 3.9f %d (%6. The type field is used to differentiate among different types of traces. node not originator) a packet respectively. Event Abbreviation Type Value %. a new trace format [32] has been introduced. 39 .

…) Packet Size Flow ID Unique ID TTL Value Packet info at Application level Packet Type (arp.) Packet Type (cbr.) Drop Reason Packet information at MAC level -Hs int -Hd int -Ni int -Nx double -Ny double -Nz double -Ne double -Nl s: Send r: Receive d: Drop f: Forward string -Nw string Wireless Event -Ma hexadecimal Duration -Ms hexadecimal Source Ethernet Address -Md hexadecimal Destination Ethernet Address -Mt -Is -Id -It -Il -If -Ii -Iv -P hexadecimal Ethernet Type IP Trace int. MAC. dsr. The format for the ARP. tcp. NS2 New Trace Format for Wireless Packet Depending on the packet type. tora. there are three packet types. For the simulation performed. imep. 40 . CBR and AODV.Event Abbreviation Flag -t Type double Value Time (* For Global Setting) Next hop information Hop source node ID Hop destination Node ID -1: the packet is a broadcast packet -2 destination node has not been set Node properties Node ID Node X Coordinate Node Y Coordinate Node Z Coordinate Node Energy Level Network trace Level (AGT. tcp. the trace may log additional information. …) -Pn string Table 4. CBR and AODV trace are shown respectively in the tables below. etc.int string int int int int string Source Address And Port Destination Address And Port Packet Type (cbr. etc. RTR.int int. ARP.

Event Flag -Pt -Ph int -Pb int AODV -Pd int Trace -Pds int -Ps -Pl -Pc int double string -Pss int Type hexadecimal Type ARP Trace Format Value Hop Count Broadcast ID Destination Destination Sequence Number Source Source Sequence Number Lifetime Operation (REQUEST. REPLY. Both 41 .Event Flag Type -Po -Pms int ARP Trace -Ps int -Pmd int -Pd int Value Source MAC Address Source Address Destination MAC Address Destination Address string Request or Reply Table 5. information has to be extracted to compute the performance parameters from trace files using AWK or Perl script.4. AODV Trace Format Event Flag Type -Pi int CBR Trace -Pf int -Po int Value Sequence Number Number Of Times Packet Forwarded Optimal Number Of Forwards Table 7. CBR Trace Format For analyzing the performance of IEEE 802. AWK is a programming language designed for processing text-based data. Perl is a dynamic programming language that complements AWK to allow processing of repetitive simulation runs. ERROR. either in files or data streams.15. HELLO) Table 6.

Another alternative is to compute node movements using actual surface current measurements. Java program can also be implemented to analyze the trace files. In NS2. 42 . The other part of the scenario is to define and generate the communication pattern file. movement files are generated from mobility models or by using node movement generator. University of Delaware and Monterey Bay Aquarium Research Institute [33]..h} and Makefile. The results of hourly mapped total vectors will be used for the computation of node movements.languages are available in standard UNIX environment. Four High Frequency (HF) radars at different locations measure the currents and the measurements are objectively mapped to fill gaps in space and time. The ASCII data files contains the hourly data of pre-determined locations in latitude/longitude (lat/long) with the vector speed (cm/s) shown in Figure 22. B. Mapping is required due to environment factors causing unavailability and spatial coverage of the HF radar measurements. there is a need for other means to generate the movement pattern file. Near Real-Time Monterey Bay Surface Currents Near real-time coastal surface current data of the Monterey Bay (California) are made available from a collaboration between the Naval Postgraduate School. 1.cc. The node-movement generator allows configuring of nodes movement at particular time and is available under ~ns/indep-utils/cmu-scen-gen/setdest directory consisting of setdest{. GENERATING OCEAN ENVIRONMENT SCENARIOS As the above mobility models do not correctly represent the oceanic environment. The setdest function can then be used to create the movement scenario for NS2.

The randomness was included to account for turbulent diffusion and was applied to the node. the velocity vectors of the data points nearest to the node were referenced to provide a random velocity from a normal (Gaussian) distribution. 43 . Since the variation is small across each time step. Step 1: The initial position (lat/long) of the node is searched through the data files for nearest data points beginning at 0000hrs. Determining Mobility Using Actual Measurements A sample data set (dated 30 January 2005) of the Monterey bay area was taken to simulate the nodes’ movement. Computation was performed for an entire day at a time interval of ten minutes. waves. the hourly velocities are linearly interpolated for the entire day at a time interval of 10 minutes. and random motion which caused the nodes to disperse.Figure 22 – Data points of Monterey Bay 2. tides. Basically. This turbulent motion included the meandering of the current. The next position of the node was computed and the computation was repeated until the end of the day. The following sub-paragraphs detail the steps (performed using Microsoft Excel) to compute a node movement when placed within the Monterey Bay area.

d is the dis tan ce in radians. Such a dispersing behavior is consistent with the meandering of the current. waves. the movements are very much dominated by tidal currents. The computation repeated until the boundaries of the bay were exceeded or simulation time (one day) was reached. The result of simulating 25 nodes placed 10m apart from adjacent nodes within the Monterey Bay is shown in Figure 23. tides. y ' is the longitude of the current location. nodes start to drift out towards the ocean. nodes can be seen to be moving towards the shore and around 1100hrs. and random motion. This pattern is unique which cannot be correctly modeled by any models. 2π ) − π where x' is the latitude of the current location. This velocity then computed the distance and direction of the next position for a period of 10 minutes. since the nodes are within the bay area. Step 3: The coordinates of the next position were computed using the formula [34] given below. Initially. Nodes are gradually dispersing away from each other until the end of the day. Hence. t c is the true course heading in radians. Also. the data (node position at various times and speed) obtained from the computation will be used for the simulation.Step 2: The velocity of the data points nearest to the node were referenced and a random velocity was generated from a normal (Gaussian) distribution which was applied to the node. 44 . Latitude ( x) = arcsin (sin x' cos d + cos x' sin d cos t c ) (1) (2) Longitude ( y ) = mod( y ' − arcsin (sin t c sin d / cos x ) + π .

The script is written in Tool Command Language (TCL) and essentially functions to format the data into the movement file. or nodes 45 . Generating Movement Pattern File A movement pattern file is required as an input to NS2 for the simulation. the formatted file can be used to calculate information for GOD (General Operations Director) object which can also be present in the movement. The GOD object is initially used to store global information about the state of the environment. The “calcdest" function (found in ~ns/indep-utils/cmuscen-gen/setdest/ directory) is used in which information of the GOD object is computed and loaded into the movement file. An external script (see Appendix B) is implemented to parse the computed movement data and generate the mobility file.(Latitude) Monterey Bay Initial Position (Longitude) Figure 23 – Node movements in Monterey Bay 3. network. The movement file consists of initial position of each node (two dimensional) and the “setdest” commands for each movement change at stipulated time. Subsequently.

The calculation is performed in advance to minimize computation time required during simulation. It was discovered that the nodes had to be arranged in an anti-chronological order for the correct execution of “calcdest” function. The script below is modified from a sample script provided by Matthias Budde in the NS forum. Data points are extracted and arranged in the required format of the 46 . “Tclsh” is a shell like application that reads and evaluates TCL commands from standard input or a file. customized to our computed data. This script essentially parses the numerous data generated by the node movement computation using the “Tclsh” command.tcl) Computed data (calcdest –n <node #> -t <simulation time> -I <input file> -o <output file>) Mobility file Figure 24 – Process of Generating Mobility File Figure 24 depicts the process and results generated from the script.but currently stores an array of the shortest number of hops required to reach from one node to another. (tclsh parse.

the Quality of Service (QoS) is to be evaluated against the oceanic environment. The computed movement data have to be arranged in antichronological order for subsequent computation of GOD object. PERFORMANCE METRICS In this thesis. Generating Communication Pattern File The communication pattern file essentially describes the packet workload presented at the network layer during simulation. delay and packet drop have to be considered. seed for generating random traffic pattern. in particular. maximum traffic flow. resources might not always be available and parameters such as throughput. Three performance metrics will be used to determine the QoS provided by IEEE 802.4. The modification includes change to generate traffic at an interval of 10 minutes which coincide with node movements where nodes will be randomly selected to transmit data to the PAN coordinator (see Appendix C). C. followed by optional parameters. The script can be executed using “ns” command. A detailed explanation of these metrics is as follows: 47 . These parameters specify the traffic type (cbr or tcp). end time and the time gap between consecutive transmissions. Due to the mobility and dynamic nature of the MANET.movement file. 4. A TCL script is modified from a constant bit rate generation script file [35] specifically design for star topology.15.15. number of nodes in the scenario. stationary nodes and mobile nodes floating on the ocean. The QoS is determined by a set of service requirements that the network must fulfill when transporting packet streams from a source to its intended destination.4. The traffic scenario is then piped to a communication pattern file. two scenarios are used for the simulations. traffic rate. the performance of IEEE 802. Essentially. start time.

Average Network Delay = (Time packet arrive @ dest − Time packet sent @ source ) Total number of connection pairs (4) 48 .1. PacketDeliveryRatio ( PDR) = Number of received CBR packets Number of transmitted CBR packets (3) 2. Higher PDR implies that packet loss rate is lower and protocol is more efficient from the perspective of data delivery. network load and effects of movement resulting in frequent topological changes. This delay includes all possible delays that are caused by route discovery latency. All the connection delays are aggregated and the average network delay is the aggregated delay divided by the number of connection pairs throughout the simulation. It is an important metric which indicates congestion level of the network. A point to note is that late packet received could be deemed useless even with high PDR. PDR measures the protocol performance from loss ratio experienced at the network layer that is affected by factors such as packet size. queuing in the interface queue. This delay can be computed as the difference in time from transmitting packets from a source to the arrival of packets at the destination node. Packet Delivery Ratio Packet Delivery Ratio (PDR) is the quotient resulting from the number of successful delivered CBR packets to those generated by CBR sources within the simulation period. retransmission at the MAC layer and propagation through the environment. Average Network Delay Network delay is the time delay experienced by a connection between nodes.

having the total number of bits is computed over the simulation runtime.3. Node throughput is a measure of the total number of data packets successfully received at the node. only the data of the CBR packets are considered. Network Throughput The network throughput determines the amount of data that is transmitted from a source to a destination node per unit time (bits per second). While ignoring the overheads in the network. The network throughput is then derived from the average throughput of all nodes involved in the CBR packet transmission. Total bits received by node Simulation time Node Throughput = (5) Network Throughput = Node Throughput s of CBR transmissi on Total number of nodes (6) 49 .

THIS PAGE INTENTIONALLY LEFT BLANK 50 .

01W) is allowed in this band. the document states the IEEE 802.15.15.4 devices are generally envisioned to operate with a maximum transmit power of approximately 0 dBm (1mW). The simulation is reiterated over several runs until certain conclusions can be drawn to determine the feasibility of employing IEEE 802.4 technology in the ocean environment.4 GHz operating in United States. Transmitted Power (Pt_) The transmitted power is the power that is transmitted from the antenna into space.4 against the performance metrics. the specification of the transceiver plays an important role in determining the communication range of the nodes. node density and network loading. Although IEEE 802. The crossbow RF transceiver has power of -24 dBm to 0 dBm.15. The power parameter is based on the specification of Crossbow MICAz processor and radio platform (MPR2400CA). hence 1mW for Pt_ will be used in the simulation.15. SYSTEM SIMULATION AND RESULTS This chapter identifies additional parameters to be used in the simulation with reference to a Zigbee transceiver as well as the analysis of IEEE 802. Pt _ = 0 dBm = 1 mW (7) 51 . 1.4 regulatory requirements that for the ISM band 2. transmitted power of up to 1 watt is provided. In Annex F [4].IV. A. The performance metrics are used in deriving the performance specific to mobility. SPECIFIC TRANCEIVER PARAMETERS Besides physical parameters defined in the previous chapter. a minimum of +10 dBm (0.

it is possible that two packets can simultaneously arrive (i. The 52 .981 × 10-13 W. Hence. The receiver sensitivity for the crossbow transceiver is -94 dBm typical. The capture threshold determines if a packet is successfully received by comparing the power ratio of both packets. The packet with the highest ratio that is greater than the capture threshold is chosen. Taking the typical receiver sensitivity. only packets received in the carrier sensing range of a receiver are considered as potential sources of packet collisions.981×10 −13 W (9) 4.2. CSThresh _ = RxThresh _ = 3. the receiver threshold is -94 dBm which is equivalent to 3. it is assumed that the carrier sensing threshold value is at least the receiver threshold. The Receiver Threshold (RXThresh_) receiver threshold is the parameter used to specify the communication range of the wireless nodes and the threshold is the minimal power of the packet required for successful reception. The sensing range of a node is usually greater than the transmission range. collision) at the receiving node.981× 10 −13 W (8) 3. Carrier Sensing Threshold (CSThresh_) The carrier sensing threshold describes the sensing range of a node. If a packet reaches a node with a power level above the receiver threshold. the receiver is within the carrier sensing range but decoding of the packet is not guaranteed. RxThresh _ = − 94dBm = 3. Capture Threshold (CPThresh_) During packet transmission. In NS2.e. When the received packets have a power level below the receiver threshold but above the carrier sensing threshold. the receiver will be within the transmission range of the sender.

However. antenna gains and the range between communicating nodes. The model essentially accounts for the decrease in power as the range increases. The difference being that the two-ray ground model considers the received power from both the direct path and a ground reflection path. Ricean. Propagation There are 4 types of models used in NS2 to represent the radio propagation properties of the environment. the two-ray ground model is also a large scale model. the antenna will be at a height of approximately 0. Both the Ricean and Rayleigh are fading models that describe the propagation effect of a RF signal in a defined environment.5 m (11) 6. Antenna Height For the simulation environment. a limitation posed in NS2 is that both the communicating nodes have to be of the same height. namely the free space. In NS2. Rayleigh and shadowing models.capture threshold (CPThreshold) is assumed to be 10 dB in the simulations which is a common value used in most simulations. As with free space model. CPThresh _ = 10 dB (10) 5. The free space model is a large scale model where the received power is dependent on transmitted power. Assuming that the buoy has a diameter of 1 m and is partially submerged. two-ray ground. the antenna of a particular node will be mounted on a floating buoy. Rayleigh fading is most applicable when there is no line of sight between communicating nodes 53 .5m. the antenna is defined as a set of three dimensional coordinates with the z dimensional coordinate being antenna height. X _ =0m Y _ =0m Z _ = 0 .

while Ricean fading is more applicable if there is a line of sight. Finally, the shadowing model assumes the average received signal power decreases logarithmically with distance. A Gaussian random variable is added to the path loss to account for environmental influences at the sender and the receiver. Considering the complex ocean environment, the propagation may vary in different location. For simplicity, the two-ray ground model is selected. According to the two-ray ground propagation model, the sensing range of the device is computed to be 112m.

B

PERFORMANCE ANALYSIS

In practice, node movements in the ocean will result in the network having to re-learn optimum routes. Several experiments are conducted to analyze the behavioral response of the IEEE 802.15.4 network, utilizing a Zigbee transceiver that is operating at the 2.4 GHz frequency band. Essentially, the influence of mobility, node density and network loading on the network will be studied. In particular, the network’s packet delivery ratio, delay and data throughput performance are measured with varying transmission rates. The performances resulting from the metrics are presented with moving scenarios. To increase the confidence level of the results, a set of simulation parameters are performed with various random seeds for the data transmission. However, running the scenarios required long simulation hours for node movements within a day. 1. Simulation Setup and Parameters

Wireless networks based on IEEE 802.15.4 are designed for low data rate and low power consumption devices. Depending on the operating requirements and environment, there has to be compromises between the node transmission range, operational lifespan and device cost. The transmission range can be determined from Friss two-ray ground reflection models which relates the 54

maximum range to the antenna gain, transmit power and receiver sensitivity. With the Crossbow MICAz processor and radio platform, the maximum range is computed to be approximately 112m. Since the nodes are highly mobile, this range will determine if a data packet can successfully arrive at the destination node. The data traffic type is Constant Bit Rate (CBR) with the application agent sending at a rate of 20 data packets per second continuously. The nodes used in the simulation will be placed at predetermined distances from adjacent nodes covering an area of 40m by 40m. The centre node is designated the PAN coordinator with all other nodes randomly transmitting data packets to the PAN coordinator. The speed and heading of each node will vary according to the generated ocean movement with a maximum simulation runs of 12 hours. The simulations are conducted with the typical parameters shown in Table 8. Simulation Parameters Protocol Simulation Time # of Nodes Map Size Speed Mobility Model Traffic Type Packet Size Connection Rate Table 8. AODV 1hr, 3hrs, 6hrs, 9hrs, 12hrs 9, 16, 25 4500m × 4500m Varying from 0.006m/s-0.47m/s Actual Measurement Model Constant Bit Rate (CBR) 20 bytes 0.05 to 5 packets per second Simulation Parameters

During the simulation, certain behaviors are exhibited by the nodes if communication cannot be established with the coordinator. When a node losses synchronization, orphan-scanning is performed to relocate the coordinator. When coordinator relocation is successful, communication will resume. If relocation of the coordinator fails, node will subsequently perform active channel scan to send association request to the PAN coordinator. Upon successful association, the

55

node begins to transmit beacons and start data transmission. Else, non-beacon mode is enabled for that node.

2.

Influence of Node Density

In an ocean environment, the number of nodes providing coverage in an area of operation will determine the performance of sensors (i.e. detection range) used in the nodes and ultimately derive the cost of operation. As such, the performance of the network is measured with varying node densities to ascertain the impact. In this set of simulations, the node density is increased from 9, 16 and 25 nodes within operational coverage of 40m × 40m. Figure 25 shows the initial node placement within the operating area.
9 nodes covering 40m x 40m
0 1 2
0

16 nodes covering 40m x 40m
1 2 3

4

5

6

7

3

4

5

8

9

10

11

PAN coordinator
6 7 8

12

13

14

15

PAN coordinator

25 nodes covering 40m x 40m
0 1 2 3 8 13 4

5

6 11 16

7 12

9 14

10

PAN coordinator
17 22 18 23 19 24

20

21

Figure 25 – Initial Coverage with 9, 16 and 25 Nodes 56

Table 9 summarizes the simulation parameters for this set of simulations. 16. the number of connections is set to 8.006m/s-0. The designated PAN coordinator and nodes positions after the respective simulation runtime are shown in Annex G. namely the 1. 20 4500m × 4500m Varying from 0. An interesting observation is that after an hour of simulation. will be used as a basis of comparison with CBR traffic at a data rate of 0. Figure 26 shows the simulation results which demonstrate the performance metrics using different node densities.1 packets per second Simulation Parameters for Node Density Analysis In general. 25 8.1 packets per second. the packet delivery ratio (PDR) remains close to 100% despite the difference in node densities. 3hrs. 14. The experimentation goal is to determine the network scalability rather than to find the optimal node density.Three sets of scenarios. This is due to the node transmission range and also the dispersion of nodes since the movements remains insignificant. 6hrs 9. AODV 1hr. Simulation Parameters Protocol Simulation Time # of Nodes Max Node Connect Map Size Speed Mobility Model Traffic Type Packet Size Connection Rate Table 9. 3 and 6 hours runtimes. 14 and 20 respectively where all nodes are transmitting packets to the PAN coordinator. 57 .47m/s Actual Measurement Model Constant Bit Rate (CBR) 20 bytes 0. As the simulation time approaches three hours. For each scenario set. there is a slight reduction in PDR but still well within the 90th percentile range. The rest of the simulation parameters remain relatively unchanged. due to the highly dynamic nature of node movement. low density may cause the network to be frequently disconnected resulting in a low throughput.

02 0 1 3 Simulation Time (hours) (b) 6 25 nodes 16 nodes 9 nodes Network Throughput vs Node Density Network Throughput (bps) 60 50 40 30 20 10 0 1 3 Sim ulation Tim e (hours) (c) 6 25 nodes 16 nodes 9 nodes Figure 26 . Packet Delivery Ratio vs Node Density Packet Delivery Ratio 120 100 80 (%) 60 40 20 0 25 nodes 16 nodes 9 nodes 1 3 Sim ulation Tim e (hours) (a) 6 Ave Network Delay vs Node Density 0.Results of Varying Node Density with (a) PDR (b) Average network delay and (c) Network Throughput 58 .1 0.08 0.06 0.04 0.14 Ave Network Delay (s) 0.Thereafter. the PDR falls below 90%.12 0.

15. An ideal node configuration has to be determined considering the operational area as well as the nodes dispersion in the ocean. Also. depending on the operational needs. The data rate is gradually increased from 0.4. Influence of Network Loading In this simulation. The emphasis is on the behavior of the network since IEEE 802. The 25-node configuration experiences the most delay since some of the packets are required to be forwarded by adjacent nodes before reaching the PAN coordinator. the PDR reduces as the simulation time increases due to the spreading of node movement. At the 6 hours. The above findings have indicated the node density does influence the performance of 802. the network throughput of the 16-node configuration can be seen to perform better than the 25-node configuration.005 packets per second to 50 packets per second in the three 59 . The delay measured is the average transmission time of all data packets. 3. Since all the packets are effectively sent to the PAN coordinator. However. Effectively. This observation reinforced the earlier PDR observation since more data is received at the destination. the 25-node configuration means that more packets are sent to the PAN coordinator resulting in collisions. As for the 9-node configuration. the influence of network loading is studied. This could be due to the maximum number of connections in each scenario. the network throughput increases cumulatively as the time increase. In general. a higher loading might be required in certain situations. as the nodes are much dispersed at the three hours simulation time.4 is primarily designed for low bandwidth applications.15.An interesting observation is that the density of 16 nodes performs better as compared to the others. the node density directly influences the achievable network throughput. the effect is multiplied resulting in an increased in average network delay. The throughput effectively determines the amount of data that is transmitted and successfully received during the simulation time. which is unexpected.

more packets will be dropped due to collision and bad link quality of transmitted packets. AODV 1hr 9.50 packets per second Simulation Parameters for Network Loading Analysis Since all nodes have the PAN coordinator as the destination. the parameters used remains are relatively unchanged. As in previous simulation. As the data rate increases. The packet delivery ratio generally has a declining trend for the three node configurations when the connection rate is increased. 16. 25 8.47m/s Actual Measurement Model Constant Bit Rate (CBR) 20 bytes 0. the increase in network loading will increase the probability of collision at the PAN coordinator. The resulting effect is the exponential increase in re-transmission of packets and hence further congesting the network. the 60 .005 . 20 4500m × 4500m Varying from 0. 28 and 29 depict the effects of network loading on the performance metrics by increasing the connection rate from 0. regardless of the operational needs. Thereafter.5 packets per second for the 25. 0. 16 and 9 nodes scenario).05 to 50 packets per second. the packet delivery ratio performance decreases exponentially for higher data rates indicating that the network is congested. For the above reason. Table 10 summarizes the simulation parameters for this set of simulations.node configuration scenarios. It can be observed that the packet delivery ratio remain in the 90th percentile range till a specific data rate (approximately 0.75 packets per second and 1. Figure 27. Simulation Parameters Protocol Simulation Time # of Nodes Max Node Connect Map Size Speed Mobility Model Traffic Type Packet Size Connection Rate Table 10. 14. An ideal operating data rate can determine the efficiency of data delivery.006m/s-0.3 packets per second.

the 25-node configuration configurations. collision will occur. The 9 nodes configuration is not affected since packets are sent directly to the PAN coordinator.Results of Packet Delivery Ratio with Varying Data Rate Theoretically for network delay. The peaks at low data rate experienced by both the 16-node and 25node configuration could be due to the time required for packets to be forwarded from outer modes to the destination. At higher data rates. Packet Delivery Ratio vs Data Rate 100 90 Packet Delivery Ratio (%) 80 70 60 50 40 30 20 10 0 0 10 20 30 Data Rate (pkts/s) 40 50 60 25 nodes configuration 16 nodes configuration 9 nodes configuration Figure 27 . experiences a higher delay as compared to the other 61 . the average network delay from Figure 28 can be seen to be generally low.4 protocol cannot be used for data rates above 0.application has to maintain a low data rate. However. computation of average network delay does not consider dropped packets hence the delay reduces.15.3 packets per second in which performance will be unacceptable. the increase in data rate will increase the time for the data packet to reach the intended destination. Overall. In the worst case scenario. the IEEE 802.6 second. fluctuating between 0 to 0. However.

2 0 Ave Network Delay vs Data Rate 25 nodes configuration 16 nodes configuration 9 nodes configuration 1 3 5 8 0.8 0. 5 0.2 1 0.Results of Network Throughput with Varying Data Rate Figure 29 highlights the throughput analysis of the network. It is observed that the network throughput increases linearly as the data rate is increased till a certain throughput for each configuration.1.6 0. The impact on the throughput is apparent with different node configurations. 2 30 0.Results of Average Network Delay with Varying Data Rate Network Throughput vs Data Rate 450 400 Network Throughput (bps) 350 300 250 200 150 100 50 0 0 10 20 30 Data Rate (pkts/s) 40 50 60 25 nodes configuration 16 nodes configuration 9 nodes configuration Figure 29 . Subsequently. 6 0.4 0. 3 0. 05 Data Rate (pkts/s) Figure 28 . 8 10 0.4 Ave Network Delay (s) 1. the throughput remains almost 62 50 . 1 0. 00 5 0. 01 0.6 1.

01 packets per seconds. PAN coordinator Figure 30 – Node Movements after 1 hour To accommodate the node movements.3 packets per second data rate where the performance is deem acceptable. possibly due to network congestion. The AODV routing protocol is applied to all 63 . a map size of 4500m × 4500m is considered for the simulations. The peak performance can be considered to be in the region of 5 to 8 packets per second. the performance metrics are measured at various time intervals of the simulation and for the three node configurations. especially vessels or divers. The movement of individual nodes will follow the path as computed from actual ocean data with the application agent transmitting at 0. Influence of Mobility For the analysis of mobility effects on the network.stagnant (gradual increase). a low data rate is considered. 4. which is below the 0. in an ocean environment are relatively slow and do not change direction rapidly. Since object movements. The 9-node configuration will have the highest throughput since all configurations has similar data rate but require less time for data to reach the destination.

The node positions at various intervals of the three node configurations are as appended in Annex G. the PDR is expected to drop in the 9 nodes configuration since each node is required to provide a much larger coverage as the ocean current caused the nodes to be spread further apart. The 25-node configuration does not perform as well possibly due to more collisions that occur. The result shows that both the 25-node and 16-node configurations can achieve a PDR of approximately 80% and higher throughout the entire simulation. The packet delivery ratio for this simulation is shown in Figure 31. Intuitively.scenarios with the simulation runs varied at intervals in the region of 1 to 24 hours. An illustration of node mobility in the Network Animator (NAM) is shown in Figure 30 where the 25 nodes are dispersed after an hour of simulation. the 9 nodes configuration has the worst results where the PDR reduces from above 80% till about 20% at the end of the 24 hours simulation. Comparatively. Packet Delivery Ratio vs Movement in Time 120 100 Packet Delivery Ratio (%) 80 60 40 20 0 1 3 6 9 12 18 24 Simulation Time (hours) 25 nodes configuration 16 nodes configuration 9 nodes configuration Figure 31 – Results of Packet Delivery Ratio with Node Movement in Time 64 .

8 0.1 0 1 3 6 9 12 18 24 Simulation Time (hours) Network Throughput vs Movement in Time 30 25 nodes configuratin 25 Network Thoughput (bps) 20 15 10 5 0 1 3 6 9 12 18 24 Simulation Time (hours) 16 nodes configuration 9 nodes configuration Figure 32 – Results of Network Delay & Throughput with Node Movement in Time 65 . the network latency for the three configurations is below 0. An interesting observation is that in the first hour.3 0.6 0. This behavior is attributed to the PAN coordinator being placed in an asymmetric position in the 16-node configuration as well as the distance between adjacent nodes.1 seconds after the three hour simulation. In general. Ave Network Delay vs Movement in Time 0.Figure 32 shows the results for the network delay and throughput.9 0. the delay of network is comparatively higher in the 16-node configuration than the 25-node configuration.5 0.4 0.7 25 nodes configuration 16 nodes configuration 9 nodes configuration Ave Network Delay (s) 0.2 0. The latency for the 9-node configuration is much lower since all nodes transmit directly to the PAN coordinator.

Hence.59m 3 5 0 7 2 8 4 93. Considering the sensing range. it was observed there are two drop reasons that are of interest. the node positions of the 9-node configuration indicate that the PAN coordinator has drifted away from the other nodes in the ninth hour. packet drops will affect the system performance. a probable reasoning can be deduced from the node positions.The network throughput in general. From certain trace files which are smaller in file size. 5. the packets that join the queue first are serviced while the last is dropped (FIFO). 9 nodes positions after 9 hrs 6 PAN coordinator 1 93. an analysis is performed to study the likely cause for packets to drop. increases steadily over the entire simulation time. Drop Packet Analysis As discussed in the above findings. A packet drop caused by LQI indicates that the link quality of packets arrived at the MAC layer is not within the acceptable threshold of the 66 . In the network. There is however a reduction in the throughput for the 9-node configuration scenario at the ninth hour.12m Figure 33 – Positions of 9 Nodes Configuration at the 9th Hour. When that happens. all the packets have to be routed through Node 1 to the PAN coordinator which results in the throughput reduction. Since the trace files are too large to be analyzed. From Figure 33. packet drops are due to IFQ and LQI that occur frequently during data transmissions. IFQ is prompted when transmission rate exceeds the capacity of the queue.

network loading and mobility influences are discussed. the mobility of nodes will differ depending on the location. However. with the right selection of parameters. The next chapter concludes the analysis and the findings as well as recommendations for future possible research areas. C. In reality. simulations are conducted to analyze the performance of IEEE 802. these results cannot be applied in general as the mobility model only reflects the ocean condition at the Monterey Bay.CPThresh value. Hence. The results based on the performance metrics of node density. SUMMARY In this chapter. Both queue length and transmission range is a hardware limitation determine by the buffer size and the transceiver on the device. operating IEEE 802. Such a drop is mainly caused when nodes have drifted apart.4 in an ocean environment. However. to reduce packet drops in the network. In general. 67 . the network performance is very much affected by the node movements in the ocean.4 is possible in ocean environment.15. the queue length or the transmission range can be increased.15.

THIS PAGE INTENTIONALLY LEFT BLANK 68 .

in particular to the performance metrics. the results from the analysis can only be representative of the Monterey Bay area. For the purpose of conducting a near realistic simulation.4 architecture and the layered structure as well as the simulator environment has been conducted. A detailed performance study is performed to determine the performance of IEEE 802. RECOMMENDATIONS AND FUTURE WORK CONCLUSIONS A. The simulation results have indicated that the network performance is very much affected by the node movement in the ocean.V CONCLUSIONS. Network Simulator (NS2).15. in particular the surface current causing movement of floating nodes.4 protocol in an ocean environment.15. such technology can be successfully deployed for low data rate applications. Although mobility models are available in NS2. the network performance can be further optimized. by selecting an appropriate node configuration and network parameters such as data rate and transmission power. the Zigbee transceiver parameters used are based on the specification of Crossbow MICAz processor and radio platform (MPR2400CA) which operates at 2. A detailed study on the IEEE 802. Hence. Also. However. All the simulations are conducted using open-source software. This thesis is focused on determining the performance of IEEE 802.4.4 GHz.15. 69 . there are no suitable models to represent node movements in the ocean environment. All the parameters are then incorporated into the TCL scripts. As the behavior of surface current differs from locations. actual measured ocean data of the Monterey Bay area is used as a basis for computing the movements.

In the actual ocean environment. The ocean is a harsh environment for propagating radio waves due to wave blockage. Propagation Model There is a need to refine the two-ray ground model used in the simulations to represent the ocean environment. Hence.B.15. the waves could cause lateral movements that result in intermittent connection due to the line-of-sight between nodes. Vertical Node Movement in Oceanic Environment The current ocean model used in the simulation assumes a flat topology and only considers the horizontal movement of the nodes. FUTURE RESEARCH AREAS The results from the simulation have provided some insights into the use of IEEE 802. 2. The Advanced Refractive Effects Prediction System (AREPS) model [36] is currently in use by the Navy and can be used to accurate 70 . Due to the time constraint and learning curve for NS2. certain simulation parameters are assumed and several features have not been studied. there are still other open research problems that are not addressed and also the simulation parameters in NS2 can still be further improved to represent the actual environment and deployed devices for more realistic result. scattering and reflection of signals by the ocean surface causing multipath propagation which results in signal fading or signal loss. The following details some key areas (non-exhaustive) for future research that can be used in future thesis research work to either augment the results made in this thesis or conducted in an independent thesis work.4/Zigbee wireless technology in an oceanic environment. A 3D mobility model can be created using the setdest function by defining the z parameter for the nodes. 1.

The replay protection is implemented with the use of sequence number.15.4 guaranteed time slot (GTS) 71 .4 such as eavesdropping. jamming and application vulnerabilities. the impact of the network performance has to be assessed.4’s features is the low-power consumption property. The APEPS model takes into account factors that affect radio wave propagation in the maritime environment. The performance of IEEE 802. including atmospheric refraction and surface reflections. replay.15. Guaranteed Time Slot Management GTS implementation is particularly effective for application that has timing constraints where each device is allocated specific time duration for high priority communication. Security Considerations for Network There are certain security risks in utilizing IEEE 802. power consumption of the node is vital which provides another dimension to measure the performance. This can be accomplished by including an energy model into the simulation and also implementing or modifying existing codes to include low power mode. Node Energy Consumption One of IEEE 802. The confidentiality aspect is addressed through the use a stream cipher encryption while integrity is addressed using a message integrity code (MIC) to protect data from being modified without the appropriate cryptographic key. Hence.4.model the RF propagation on the ocean surface.15. packet injection.15. Although the inclusion of these security mechanisms is necessary. 4. 5. The energy consumption can then be investigated at the mobile nodes. Some of these risks can be eliminated with three security options in IEEE 802. 3.

management scheme is not investigated in this thesis. Performance such as bandwidth utilization and data transfer reliability can be investigated. 72 .

APPENDIX A – INSTALLATION OF NS2 The NS2 is designed to operate on UNIX based operating system but it is also possible to run NS2 on Windows machine using Cygwin or on a VMware server. After extraction.isi. If it complains about X libraries.29/tcl8. so that you'll be able to run itm/tclsh/wish/xgraph.13/library your TCL_LIBRARY environmental variable.tar.29/tk8.13/unix:/root/ns/ns-allinone-2. The following detailed the step for installation.29/tcl8.4. add path to your X libraries into LD_LIBRARY_PATH.html#allinone.bashrc 73 .29. into your LD_LIBRARY_PATH environment variable. Navigate back to the root directory and there will be a . (1) You MUST put /root/ns/ns-allinone-2. into will 3.29/bin:/root/ns/ns-allinone2. A new directory is created (“mk ns”) and the compressed file is extracted into the new directory (“tar -xzf ns-allinone-2.gz”). Download the all-in-one package (ns-allinone-2./install”. Otherwise ns/nam complain during startup.4. . .29.tar. you can set it like: setenv LD_LIBRARY_PATH <paths> If you are using sh.29 and run “. 1.12.4. the below message will be received. /root/ns/nsallinone-2.30/otcl-1.bashrc file. change directory into ns-allinone-2. If you are using csh.30/lib.gz) from http://www.edu/nsnam/ns/ns-build. Please put /root/ns/ns-allinone-2. 2. you can set it like: export LD_LIBRARY_PATH=<paths> (2) You MUST put /root/ns/ns-allinone-2.13/unix into your PATH environment. This is the file to place the necessary path environment and a backup of this file is created to allow restoration to original state if anything fails (“cp . The install script will automatically configure. compile and install the components. The package contains the necessary components as well as an install script. If the installation is successful.

bashrc. to verify that ns2 has been successfully installed.origin”).12:/root/ns/nsallinone-2. NS2 can then be validate at the ns-2. $LD_LIBRARY_PATH and $TCL_LIBRARY) will return the PATH variable that contains a list of previously included pathnames that is colon-delimited.29/bin:/root/ns/ns-allinone2. $PATH. 4. 5.29 directory with “. With the current console window still open.13/unix:$PATH LD_LIBRARY_PATH=/root/ns/ns-allinone-2.29/lib:$LD_LIBRARY_PATH TCL_LIBRARY=/root/ns/ns-allinone-2. enter “which ns” which will return /root/ns/ns-allinaone-2. 74 .4.29/otcl-1.4.29/tcl8./validate” command. go to another console window and determining the contents of environment variables by issuing the echo command.29/bin/ns and “ns” which will return the ns command prompt “%” (enter “exit” on the prompt to exit ns).29/tcl8.e.13 /unix:/root/ns/ns-allinone-2.29/tk8.4. Finally.bashru file can be edited using gedit program and including the following script (directory can be different depending on where ns2 is installed) at the end of the file. The .. Environment variables are variables that Unix keeps track of at the shell level. PATH=/root/ns/ns-allinone-2.13/library:$TCL_LIBRARY The echo command in each case (i.

customized to our computed data.N N.APPENDIX B – MOVEMENT PATTERN SCRIPT The script below is modified from a sample script provided by Matthias Budde in the NS forum./Nodemove2.[0-9]+)[^09]+([-0-9]+\. Data points are extracted and arranged in the required format of the movement file. edited by Lim. Kwang Yong set infilename ".scn" set infile [open $infilename ] set outfile [open $outfilename w] #Procedure to calculate seconds from time proc gettime {hrs mins} { puts -nonewline "Transforming time $hrs:$mins to seconds: " set time [expr ($hrs * 3600) + ($mins * 60)] puts "$time" return $time } #Main puts "" puts "Parsing file \"$infilename\"" puts "" while { [ gets $infile line ] != -1 } { # This regular expression looks for a line formatted like #"N:N N. The computed movement data have to be arranged in anti-chronological order for subsequent computation of GOD object./oceanmovement2. This script essentially parses the numerous data generated by the node movement computation using the Tclsh command. ### SCRIPT TO PARSE DATA INPUT AND GENERATE MOVEMENT EVENT FOR NS-2 ### Matthias Budde 2006.txt" set outfilename ".N" with n being any amount of digits from #0 to 9 and saving them to the variables a to d if {[regexp {([0-9]+):([0-9]+)[^0-9]+([-0-9]+.[0-9]+)} $line z a b c d]} { set newtime [gettime $a $b] set newx $c set newy $d 75 .

[0-9]+)[^0-9]+(.[0-9]+)[^09]+([0-9]+\. if the line looks any other than the two above.1] puts "Setting Node ID to $nodeID" set node "\$node_($nodeID)" set newtime 0 # in the else. the node ID is changed if the line doesn't look like above but has the Word "Node " followed by a number. Also the time is reset to 0 } elseif {[regexp {Node *([0-9]+)} $line z a]} { set nodeID [expr $a .0" 76 .0 \"$node setdest $newx $newy $speed\"" } "Setting $outfile $outfile $outfile initial Position for Node $node" "$node set X_ $newx" "$node set Y_ $newy" "$node set Z_ 0.[0-9]+)} $line z a b c d e ]} { set newtime [gettime $a $b] set newx $c set newy $d if {$newtime > 0} { set speed $e puts $outfile "\$ns_ at $newtime. it's ignored } else { # do nothing } } # This while statement reads the inputfile line per line set infile [open $infilename ] while { [ gets $infile line ] != -1 } { # This regular expression looks for a line formatted like #"N:N N.|[0-9]+\.if {$newtime == 0} { puts puts puts puts } set oldx $newx set oldy $newy # in the elseif.N" with n being any amount of digits from #0 to 9 and saving them to the variables a to d if {[regexp {([0-9]+):([0-9]+)[^0-9]+([0-9]+\.N N.

it's ignored } else { # do nothing } } puts "" puts "DONE. Also the time is reset to 0 } elseif {[regexp {Node *([0-9]+)} $line z a]} { set nodeID [expr $a . the node ID is changed if the line doesn't look like above but has the Word "Node " followed by a number.1] puts "Setting Node ID to $nodeID" set node "\$node_($nodeID)" set newtime 0 # in the else.# in the elseif. " 77 . if the line looks any other than the two above. Output has been written to \"$outfilename\".

THIS PAGE INTENTIONALLY LEFT BLANK 78 .

# Traffic is generated every ten minutes customized to ocean node movement.# . Nodes will be randomly selected to transmit data to the PAN coordinator. #The copyright for the original script lies with the following author.# .# Traffic end time (1 day) . #Program to generate random traffic sources from nodes to coordinator. #Previous modified by Vaddina Prakash Rao #Modified by: #Lim Kwang Yong #Traffic source generator from CMU's mobile code.# .# .0 30.0 0 70 0 0.0 .0 "" 20./cbr/trafficpattern. # =========================================================================== # Default Script Options.# .APPENDIX C – COMMUNICATION PATTERN SCRIPT The traffic connection pattern script is modified from a modification (Vaddina Prakash Rao) of the original constant bit rate generation script file by University of Southern California that is specifically designed for a star topology.# Number Random Number Packet of Nodes number generator seed value of sources size set opt(rate) set opt(interval) set opt(type) set opt(starttime) establish) set opt(endtime) set opt(timegap) Datarate inverse of rate Traffic type Traffic start time (need WPAN to .# .# Default traffic gap time # ====================================================================== set opt(outfilename) ". following default values are used when not provided # =========================================================================== set set set set opt(nn) opt(seed) opt(mc) opt(pktsize) 0 0.traff" set opt(outfile) [open $opt(outfilename) w] 79 . The script is modified to generate traffic at an interval of 10 minutes which coincide with node movements.0 86400. #Copyright (c) 1999 by the University of Southern California #All rights reserved.# .

#================================================ # Procedure telling users the optional parameters #================================================ proc usage {} { global argv0 puts "\nusage: $argv0 \[-type cbr|tcp\] \[-nn nodes\] \[-seed seed\] \[-mc connections\] \[-rate rate\] \[-starttime st\] \[-endtime et\] \[timegap tg\]\n" } #===================================== # Procedure to get optional parameters #===================================== proc getopt {argc argv} { global opt lappend optlist nn seed mc rate type starttime timegap for {set i 0} {$i < $argc} {incr i} { set arg [lindex $argv $i] if {[string range $arg 0 0] != "-"} continue set name [string range $arg 1 end] set opt($name) [lindex $argv [expr $i+1]] } } #============== # CBR Procedure #============== proc create-cbr-connection { src dst stime } { global rng cbr_cnt opt puts $opt(outfile) "#\n# $src connecting to $dst at time $stime\n#" puts $opt(outfile) "set udp_($cbr_cnt) \[new Agent/UDP\]" puts $opt(outfile) "\$ns_ attach-agent \$node_($src) \$udp_($cbr_cnt)" puts $opt(outfile) "set null_($cbr_cnt) \[new Agent/Null\]" puts $opt(outfile) "\$ns_ attach-agent \$node_($dst) \$null_($cbr_cnt)" puts $opt(outfile) "set cbr_($cbr_cnt) \[new Application/Traffic/CBR\]" puts $opt(outfile) "\$cbr_($cbr_cnt) set packetSize_ $opt(pktsize)" puts $opt(outfile) "\$cbr_($cbr_cnt) set interval_ $opt(interval)" puts $opt(outfile) "\$cbr_($cbr_cnt) set random_ 1" puts $opt(outfile) "\$cbr_($cbr_cnt) set maxpkts_ 10000" puts $opt(outfile) "\$cbr_($cbr_cnt) attach-agent \$udp_($cbr_cnt)" puts $opt(outfile) "\$ns_ connect \$udp_($cbr_cnt) \$null_($cbr_cnt)" puts $opt(outfile) "\$ns_ at $stime \"\$cbr_($cbr_cnt) start\"" incr cbr_cnt }

80

#============== # TCP Procedure #============== proc create-tcp-connection { src dst stime } { global rng cbr_cnt opt puts $opt(outfile) "#\n# $src connecting to $dst at time $stime\n#" puts $opt(outfile) "set tcp_($cbr_cnt) \[\$ns_ create-connection \ TCP \$node_($src) TCPSink \$node_($dst) 0\]"; puts $opt(outfile) "\$tcp_($cbr_cnt) set window_ 32" puts $opt(outfile) "\$tcp_($cbr_cnt) set packetSize_ $opt(pktsize)" puts $opt(outfile) "set ftp_($cbr_cnt) \[\$tcp_($cbr_cnt) attachsource FTP\]" puts $opt(outfile) "\$ns_ at $stime \"\$ftp_($cbr_cnt) start\"" incr cbr_cnt } #============= # Main Program #============= getopt $argc $argv if { $opt(type) == "" } { usage exit } elseif { $opt(type) == "cbr" } { if { $opt(nn) == 0 || $opt(seed) == 0.0 || $opt(mc) == 0 || $opt(rate) == 0 } { usage exit } set opt(interval) [expr 1.0 / $opt(rate)] if { $opt(interval) <= 0.0 } { puts "\ninvalid sending rate $opt(rate)\n" exit } } puts "#\n# nodes: $opt(nn), max conn: $opt(mc), send rate: $opt(interval), seed: $opt(seed)\n#" # Loop to transmit traffic within defined interval set looptime [expr $opt(endtime)/600] for {set k 1} {$k < $looptime} {incr k} { set rng [new RNG] $rng seed $opt(seed)

81

set u [new RandomVariable/Uniform] $u set min_ 0 $u set max_ $opt(nn) $u use-rng $rng set set set set cbr_cnt 0 src_cnt 0 flag 0 loopcount $opt(nn)

# Loop till the defined connenction has completed, generated scr number for {set i 0} {$i < $loopcount } {incr i} { while {1} { set x [$u value] set x [expr $x/0.01] if {$x < $opt(nn)} { set src [expr round($x)] break } } if { $src >= $opt(nn) } { set src [expr $opt(nn)-1] } # Add the generated source to the list unless we already had the source before if {[array size sources] == 0} { set sources(0) $src } else { # Comparing each source in list to currently generated source to see if match for {set p 0} {$p < [array size sources]} {incr p 1} { if {$src == $sources($p)} { set flag 1 break } } if {$src == 12} { set flag 1 } # If there is a match, break from the current loop (discard the source) if {$flag == 1} { set flag 0 incr loopcount 1 continue } else { set size [array size sources] set sources($size) $src } }

82

set dst 12 if { $opt(type) == "cbr" } { incr src_cnt 1 create-cbr-connection $src $dst $opt(starttime) } else { create-tcp-connection $src $dst $opt(starttime) } if { $src_cnt == $opt(mc) } { # You have created the required number of sources. So break now !! break } else { # If required number of sources have not been reached yet. set temp $loopcount incr temp -1 if {$i == $temp} { incr loopcount 1 } } # Tx each node at an interval set opt(starttime) [expr $opt(starttime)+$opt(timegap)] } # Tx in the next cycle and reset source array set opt(starttime) [expr $k*600] unset sources } puts $opt(outfile) "#\n#Total sources: $src_cnt\n#" 83 .# Destination to be node-12 (PAN coordinator).

THIS PAGE INTENTIONALLY LEFT BLANK 84 .

# nam trace file set val(move) oceanmove3hr. # ======================================================================== set val(chan) Channel/WirelessChannel .15..# # Prepared by Jianliang Zheng # # (zheng@ee. 10m apart from adjacent nodes # ======================================================================== # Set parameters regarding channel.ccny....# link layer type set val(ant) Antenna/OmniAntenna . energy model ..# antenna model set val(ifqlen) 150 ..# connection traffic #set val(Energy) EnergyModel ..# x dimension topography set val(y) 4500 . 85 .nam ...# interface queue type set val(ll) LL .cuny.# packet in ifq set val(nn) 25 .. . .4 (beacon enabled) # # Copyright (c) 2003 Samsung/CUNY # # .# number of mobilenodes set val(rp) AODV ... MAC protocol.. .# Evaluate energy set set set set val(starttime) val(appTime1) appTime2 stopTime 5 [expr $val(starttime)+20] [expr $val(appTime1)+0..scn ..# radio-propagation model set val(netif) Phy/WirelessPhy/802_15_4 set val(mac) Mac/802_15_4 set val(ifq) Queue/DropTail/PriQueue .# Channel Type set val(prop) Propagation/TwoRayGround . Some of the parameters are hard coded which needs to be varied and monitored to execute different sets of experimentations.APPENDIX D – SAMPLE TCL SCRIPT The sample TCL script provided is the configuration file for simulation.... medium.3] 10800 ..# routing protocol set val(x) 4500 . ############################################# # 802.# movement scenario set val(cp) traffic_3hr_pattern.edu) # # # # Modified By: Lim Kwang Yong # # Naval Post-Graduate School # ############################################# # Ocean movement scenario 25 nodes.# trace file set val(nam) ocean_move_25_3hr.# y dimension topography set val(tr) ocean_move_25_3hr.traff ... routing protocol.tr ..

/$val(nam) w] $ns_ namtrace-all-wireless $namtrace $val(x) $val(y) #$ns_ use-newtrace #======================================================================== # Inform nam that this is a trace file for wpan (special handling needed) #======================================================================== $ns_ puts-nam-traceall {# nam4wpan #} Mac/802_15_4 wpanCmd verbose on Mac/802_15_4 wpanNam namStatus on Mac/802_15_4 wpanNam ColFlashClr black .1 Antenna/OmniAntenna set Gt_ 1.# default = off (should be turned on before other 'wpanNam' commands can work) .# default = gold 86 .#=========================== #read command line arguments #=========================== proc getCmdArgu {argc argv} { global val for {set i 0} {$i < $argc} {incr i} { set arg [lindex $argv $i] if {[string range $arg 0 0] != "-"} continue set name [string range $arg 1 end] set val($name) [lindex $argv [expr $i+1]] } } getCmdArgu $argc $argv #========================================= # Define antenna at node centre of ht 0.1m #========================================= Antenna/OmniAntenna set X_ 0 Antenna/OmniAntenna set Y_ 0 Antenna/OmniAntenna set Z_ 0. use new trace format #========================================================= set tracefd [open ./$val(tr) w] $ns_ trace-all $tracefd # Statement indicating to simulator about NAM. set namtrace [open .0 #============================ # Initialize Global Variables #============================ set ns_ [new Simulator] #========================================================= # Create trace object for ns and nam.0 Antenna/OmniAntenna set Gr_ 1.

Phy/WirelessPhy set RXThresh_ 3.981e-13.981e-13. Phy/WirelessPhy set CPThresh_ 10.001.0648 \ #-txPower 0.4e+9.0744 \ #-idlePower 0. Phy/WirelessPhy set freq_ 2.#========================= # For model 'TwoRayGround' #========================= Phy/WirelessPhy set CSThresh_ 3. Phy/WirelessPhy set pt_ 0.00000552 \ 87 .0. #==================================== # set up and define topography object #==================================== set topo [new Topography] $topo load_flatgrid $val(x) $val(y) #========== #Create God #========== set god_ [create-god $val(nn)] set chan_1_ [new $val(chan)] #=============== # configure node #=============== #carrier sensing threshold #receiver threshold #capture threshold #Operating Freq #System loss factor #Tx power $ns_ node-config -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -phyType $val(netif) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -movementTrace ON\ -channel $chan_1_ #======================================== # Parameter req. only when energy logging #======================================== #-energyModel EnergyModel \ #-initialEnergy 13000 \ #-rxPower 0. Phy/WirelessPhy set L_ 1.

1 5.3 6.3 "$node_(7) sscs startCTDevice 1 1 1" $ns_ at 1.6 3." source $val(move) #=============== # SSCS Interface #=============== $ns_ at 0.# disable random motion } #=========================' # Define movement scenario #========================= puts "Loading movement pattern .7 "$node_(8) sscs startCTDevice 1 1 1" "$node_(18) sscs startCTDevice 1 1 1" "$node_(16) sscs startCTDevice 1 1 1" "$node_(6) sscs startCTDevice 1 1 1" "$node_(2) sscs startCTDevice 1 1 1" "$node_(14) sscs startCTDevice 1 1 1" "$node_(22) sscs startCTDevice 1 1 1" "$node_(10) sscs startCTDevice 1 1 1" "$node_(3) sscs startCTDevice 1 1 1" "$node_(19) sscs startCTDevice 1 1 1" "$node_(21) sscs startCTDevice 1 1 1" "$node_(5) sscs startCTDevice 1 1 1" "$node_(4) sscs startCTDevice 1 1 1" "$node_(24) sscs startCTDevice 1 1 1" "$node_(20) sscs startCTDevice 1 1 1" "$node_(0) sscs startCTDevice 1 1 1" 88 .5 3.#=============================================== # Creates specified node and attached to channel #=============================================== for {set i 0} {$i < $val(nn) } {incr i} { set node_($i) [$ns_ node] $node_($i) random-motion 0 .8 4.7 "$node_(17) sscs startCTDevice 1 1 1" $ns_ at 2..0 "$node_(12) sscs startPANCoord 0" .0 7.3 3.5 4.8 7..# startPANCoord # Cmd used to start a device # default <isFFD=1> <assoPermit=1> <txBeacon=0> <BO=3> <SO=3> $ns_ at 0.6 5.8 6.8 5.3 "$node_(13) sscs startCTDevice 1 1 1" $ns_ at 1.0 "$node_(12) NodeLabel \"PAN Coor\"" # Cmd used to start a new PAN with corresponding node as PAN coordinator # default <txBeacon=1> <beaconOrder=3> <SuperframeOrder=3> $ns_ at 0.0 6.3 "$node_(11) sscs startCTDevice 1 1 1" $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ $ns_ at at at at at at at at at at at at at at at at 3.3 4.3 7.

\n\"" #================================= # Setup traffic flow between nodes #================================= puts "Loading traffic pattern ..5 8..$ns_ $ns_ $ns_ $ns_ at at at at 8.1 "$node_(1) sscs startCTDevice 1 1 1" "$node_(9) sscs startCTDevice 1 1 1" "$node_(23) sscs startCTDevice 1 1 1" "$node_(15) sscs startCTDevice 1 1 1" #$ns_ at $appTime2 "$node_(12) sscs stopBeacon" Mac/802_15_4 wpanNam PlaybackRate 3ms $ns_ at $val(appTime1) "puts \"\nTransmitting data .\n\"" $ns_ at $stopTime "$ns_ halt" 89 ." source $val(cp) # Mac/802_15_4 wpanNam FlowClr [-p <packet_type_name>] [-s <src>] [-d <dst>] [-c <clrName>] Mac/802_15_4 Mac/802_15_4 Mac/802_15_4 Mac/802_15_4 Mac/802_15_4 wpanNam wpanNam wpanNam wpanNam wpanNam FlowClr FlowClr FlowClr FlowClr FlowClr -p -p -p -p -p AODV -c red ARP -c green MAC -c navy tcp -c blue ack -c cyan4 #================================== # defines the node size (3) in nam #================================== for {set i 0} {$i < $val(nn)} {incr i} { $ns_ initial_node_pos $node_($i) 3 } #==================================== # Tell nodes when the simulation ends #==================================== for {set i 0} {$i < $val(nn) } {incr i} { $ns_ at $stopTime "$node_($i) reset"... } $ns_ at $stopTime "stop" $ns_ at $stopTime "puts \"NS EXITING.2 8..8 9..

proc stop {} { global ns_ tracefd val(starttime) val env $ns_ flush-trace close $tracefd set hasDISPLAY 0 foreach index [array names env] { puts "$index: $env($index)" if { ("$index" == "DISPLAY") && ("$env($index)" != "") } { set hasDISPLAY 1 } } if { ("$val(nam)" == "ocean_move_25_3hr.nam") && ("$hasDISPLAY" == "1") } { exec nam ocean_move_25_3hr.nam } } puts "\nStarting Simulation." $ns_ run #============== # End of script #============== 90 ...

2 cbr 20 [0 0 0 0] ------.702240000 1.0 CM7 8 [0 ffffffff 7 0] --.303648026 2.703968033 1.0 CM7 8 [0 ffffffff 7 0] --.702688033 1.828640000 1.302368026 2.0 CM7 8 [0 ffffffff b 0] APS 0 CM7 8 [0 ffffffff b 0] 91 .0 CM7 8 [0 ffffffff b 0] --.0 BCN 11 [0 b c 0] --.0 CM7 8 [0 ffffffff d 0] --.2 cbr 40 [0 0 0 0] ------.0 CM7 8 [0 ffffffff b 0] APS 0 CM7 8 [0 ffffffff b 0] --.[18:0 12:0 32 0] --.280320000 0.304928026 1.095008033 2.267808860 D 27.091968026 2.APPENDIX E – SAMPLE TRACE FILE FORMAT s s s s s s s r s s s r s s r s s r s r s r s s s r D s s s r s r s D … D 27.[18:0 12:0 30 12] 0.0 CM7 8 [0 ffffffff d 0] --.0 CM7 8 [0 ffffffff 11 0] --.0 CM7 8 [0 ffffffff c 0] --.0 ACK 5 [0 11 c 0] --.0 CM7 8 [0 ffffffff 11 0] --.0 CM7 8 [0 ffffffff c 0] --.0 CM7 8 [0 ffffffff 7 0] --.0 ACK 5 [0 11 c 0] --.0 BCN 11 [0 11 c 0] --.0 CM1 17 [0 c 11 0] --.0 CM7 8 [0 ffffffff d 0] --.0 CM1 17 [0 c d 0] --.0 ACK 5 [0 d c 0] --.492416033 2.564000000 1.268180039 [2] 0 1 s 27.140160000 0.0 CM7 8 [0 ffffffff 7 0] --.267808849 D 27.092960000 2.091776026 2.227680000 2.565280000 2.964640000 2.0 CM7 8 [0 ffffffff 7 0] --.564960000 0.565728043 _12_ MAC _12_ MAC _12_ MAC _7_ MAC _7_ MAC _7_ MAC _13_ MAC _12_ MAC _12_ MAC _13_ MAC _17_ MAC _12_ MAC _12_ MAC _13_ MAC _7_ MAC _17_ MAC _13_ MAC _12_ MAC _12_ MAC _13_ MAC _7_ MAC _12_ MAC _12_ MAC _17_ MAC _11_ MAC _12_ MAC _7_ MAC _12_ MAC _7_ MAC _17_ MAC _12_ MAC _12_ MAC _17_ MAC _11_ MAC _7_ MAC --.268180039 [2] 0 1 r 27.[18:0 12:0 32 0] --.491680000 2.301920000 1.492960067 2.302368026 1.301920000 2.827360000 1.0 CM7 8 [0 ffffffff 11 0] --.091040000 2.355680000 2.0 CM1 17 [0 c d 0] --.267808863 D 27.092320052 2.0 ACK 5 [0 d c 0] --.268180039 [2] 0 1 _2_ MAC _5_ MAC _1_ MAC _0_ MAC _18_ AGT _18_ RTR _18_ RTR COO 0 BCN 12 [0 ffffffff 13 0] COO 0 BCN 12 [0 ffffffff 13 0] COO 0 BCN 12 [0 ffffffff 13 0] COO 0 BCN 12 [0 ffffffff 13 0] --.0 CM7 8 [0 ffffffff 7 0] --.0 CM7 8 [0 ffffffff 11 0] --.0 CM7 8 [0 ffffffff d 0] --.2 cbr 20 [0 0 0 0] ------.492608033 2.827808042 1.300960000 0.0 CM7 8 [0 ffffffff c 0] --.000640000 0.093408033 2.302368043 2.0 BCN 11 [0 7 c 0] --.0 CM1 17 [0 c 11 0] --.0 CM7 8 [0 ffffffff d 0] --.0 BCN 11 [0 d c 0] --.267808880 s 27.

THIS PAGE INTENTIONALLY LEFT BLANK 92 .

} 93 . droppedLQIpackets=0. recdDataBytes=0.APPENDIX F – SAMPLE AWK SCRIPTS This script is modified from the many example scripts provided in the NS2 forum to parse the data from in the trace file format. droppedbDATApackets=0. RTG=0.tr> # Parse a ns2 wireless trace file and generate performance metrics BEGIN { droppedRTGpackets=0. fwdMac=0. fwdRtgBytes=0. fwdDataBytes=0. recvs=0. totalDROPPEDbytes=0. MACRTG=0. highest_packet_id=0. fwdData=0. droppedLQIbytes=0. totalDROPPEDpackets=0. fwdRtg=0. droppedIFQpackets=0. sentDataBytes=0. droppedbRTGbytes=0. TotalsentDataBytes=0. dataSent=0. dataRecd=0.awk> <trace_file. recdData=0. # Lim Kwang Yong # Usage: awk -f <awk_script. droppedMACpackets=0. RTGbytes=0. droppedIFQbytes=0. droppedbDATAbytes=0. MACDATA=0. sentData=0. #used to compare with the packet id highest_time=0 sum=0. TotalsentData=0. fwdMacBytes=0. sends=0. droppedMACbytes=0.

if ( time > highest_time) {highest_time = time} #============ # Calculate delay #============ if ( start_time[packet_id] == 0 ) {start_time[packet_id] = time. if ( packet_id > highest_packet_id ) {highest_packet_id = packet_id.}. recdDataBytes=recdDataBytes+$8.}. } if ( ( $1 == "r") && ( $7 == "cbr" ) && ( $4 == "RTR" ) ) { recdData++. } #=============== # Calculate RTG load #=============== if ((( $1 == "s") || ($1=="f") ) && ( $7 == "cbr" ) && ( $4 =="RTR" )) { sentData++. if ( action != "D" ) { if ( action == "r" ) {end_time[packet_id] = time. dataRecd=dataRecd+$8. dataSent=dataSent+$8. } if ( ( $1 == "r") && ( $7 == "cbr" ) && ( $4 == "AGT" ) ) { recvs++. #=========== #Calculate PDF #=========== if (($1 == "s") && ($7 == "cbr") && ($4 =="AGT")) { sends++.}.}. sentDataBytes=sentDataBytes+$8.}. RTGbytes=RTGbytes+$8.{ #============================= # Check for the highest packet ID & time #============================= action = $1. node_id = $3 if ($7 =="cbr"){packet_id = $6. } #============== # RTG protocol pkts #============== if ( (($1=="f") || ($1=="s") ) && ($4 == "RTR") && ($7 =="AODV" ) RTG++. } else {end_time[packet_id] = -1. } ) { 94 . time = $2.

droppedLQIpackets=droppedLQIpackets+1. } 95 . } #=============== # Dropped RTG pkts #=============== if ( ($1 == "D") && ($4 == "RTR" ) && ($8 == "AODV")){ droppedRTGbytes=droppedRTGbytes+$8 . } ‘ #=============== # Dropped MAC pkts #=============== if ( ($1 == "D") && ($4 == "MAC" )){ droppedMACbytes=droppedMACbytes+$8 . } || ($1=="s") ) && ($4 == "MAC") && ($7 =="cbr" ) ) { || ($1=="s") ) && ($4 == "MAC") && ($7 =="AODV" ) ) { #============== # Dropped data pkts #============== if ( ($1 == "D") && ($7 =="cbr") && ( $4 == "RTR" )){ droppedDATAbytes=droppedDATAbytes+$8 . droppedIFQpackets=droppedIFQpackets+1. } #============= # MAC RTG pkts #============= if ( (($1=="f") MACRTG++. droppedMACpackets=droppedMACpackets+1.#============ # MAC data pkts #============ if ( (($1=="f") MACDATA++. droppedDATApackets=droppedDATApackets+1. } #============== # Dropped LQI pkts #============== if (($1 == "D") && ($4 == "IFQ")){ droppedLQIbytes=droppedLQIbytes+$8 . } #============== # Dropped IFQ pkts #============== if (($1 == "D") && ($4 == "IFQ")){ droppedIFQbytes=droppedIFQbytes+$8 . droppedRTGpackets=droppedRTGpackets+1.

} #============== # Forward RTG pkts #============== if ( ( $1 == "f") && ($7 == "AODV") && ($4 == "RTR") ) { fwdRtg++. totalDROPPEDbytes=totalDROPPEDbytes+$8 } #============== # Forward data pkts #============== if ( ($1 == "f") && ($7 == "cbr") && ($4 == "RTR" ) ) { fwdData++. fwdBytes=fwdBytes+$8. } if ($1 == "D") { droppingnodes= $3. fwdRtgBytes=fwdRtgBytes+$8. end = end_time[packet_id]. if (start < end) sum= packet_duration+sum. packet_id++ ) { start = start_time[packet_id]. } #=============== # Forward MAC pkts #=============== if ( ( $1 == "f") && ($4 == "MAC" ) ) { fwdMac++.#============== # Total dropped pkts #============== if ($1 == "D") { totalDROPPEDpackets++. } #============== # Total forward pkts #============== if ( $1 == "f") { fwdpackets++. fwdMacBytes=fwdMacBytes+$8. packet_duration = end . } } END { for ( packet_id = 0.start. } 96 . fwdDataBytes=fwdDataBytes+$8. packet_id <= highest_packet_id.

#========== # Show results #========== printf("\n .......Data parsed from trace file with 25 NODES.............\n\n") >> "performance.txt"; printf(" 1. No. of CBR Packets sent = %d PACKETS \n ", sends) >> "performance.txt"; printf(" 2. No. of CBR Bytes sent = %d BYTES \n", dataSent) >> "performance.txt"; printf(" 3. No. of CBR Packets received = %d PACKETS \n", recvs) >> "performance.txt"; printf(" 4. No. of CBR Bytes received = %d BYTES \n", dataRecd) >> "performance.txt"; printf(" \n .......Routing details.............\n\n") >> "performance.txt"; printf(" 5. No. of routing packets = %d PACKETS \n",RTG) >> "performance.txt"; printf(" 6. No. of routing bytes = %d BYTES \n",RTGbytes) >> "performance.txt"; printf(" \n .......MAC details.............\n\n") >> "performance.txt"; printf(" 7. No. of MAC packets for data sent = %d PACKETS \n", MACDATA) >> "performance.txt"; printf(" 8. No. of MAC packets for Rtg sent = %d PACKETS \n", MACRTG) >> "performance.txt"; printf(" 9. Total No. of MAC Packets sent = %d PACKETS \n", MACRTG+MACDATA) >> "performance.txt"; printf(" \n .......Forwarding details............\n\n") >> "performance.txt"; printf(" 10. No. of DATA Packets Fwd = %d PACKETS \n", fwdData) >> "performance.txt"; printf(" 11. No. of DATA Bytes Fwd = %d BYTES \n", fwddataBytes) >> "performance.txt"; printf(" 12. No. of RTG Packets Fwd = %d PACKETS \n", fwdRtg) >> "performance.txt"; printf(" 13. No. of RTG Bytes Fwd = %d BYTES \n", fwdRtgBytes) >> "performance.txt"; printf(" 14. No. of MAC Packets Fwd = %d PACKETS \n", fwdMac) >> "performance.txt"; printf(" 15. No. of MAC Bytes Fwd = %d BYTES \n", fwdMacBytes) >> "performance.txt"; printf(" 16. Total No. of Fwd packets = %d PACKETS \n", fwdpackets) >> "performance.txt"; printf(" 17. Total No. of Fwd Bytes = %d BYTES \n", fwdBytes) >> "performance.txt"; printf(" \n ........Dropping details............\n\n") >> "performance.txt"; printf(" 18. Dropping nodes are %d nodes \n", droppingnodes) >> "performance.txt"; printf(" 19. No. of dropped data (packets) = %d PACKETS \n",droppedDATApackets) >> "performance.txt"; printf(" 20. No. of dropped data (bytes) = %d BYTES \n",droppedDATAbytes) >> "performance.txt";

97

printf(" 21. No. of dropped MAC (packets) = %d PACKETS \n",droppedMACpackets) >> "performance.txt"; printf(" 22. No. of dropped MAC (bytes) = %d BYTES \n",droppedMACAbytes) >> "performance.txt"; printf(" 23. No. of dropped RTG (packets) = %d PACKETS \n",droppedRTGpackets) >> "performance.txt"; printf(" 24. No. of dropped RTG (bytes) = %d BYTES \n",droppedRTGbytes) >> "performance.txt"; printf(" 25. No. of dropped IFQ (Packets) = %d PACKETS \n",droppedIFQpackets) >> "performance.txt"; printf(" 26. No. of dropped IFQ (bytes) = %d BYTES \n",droppedIFQbytes) >> "performance.txt"; printf(" 27. No. of dropped LQI (Packets) = %d PACKETS \n",droppedLQIpackets) >> "performance.txt"; printf(" 28. No. of dropped LQI (bytes) = %d BYTES \n",droppedIFQbytes) >> "performance.txt"; printf(" 29. Total No. of Dropped (packets) = %d PACKETS \n\n",totalDROPPEDpackets) >> "performance.txt"; printf(" 30. Total No. of Dropped (Bytes)) = %d BYTES \n\n",totalDROPPEDbytes) >> "performance.txt"; printf("\n .............PERFORMANCE METRICES .....................\n\n") >> "performance.txt"; printf(" 1. Packet Delivery Ratio (PDR %) = %f %\n", (recvs/sends)*100) >> "performance.txt"; printf(" 2. Average Network delay = %f \n", sum/highest_packet_id) >> "performance.txt"; printf(" 3. Network Throughput = %f \n", (dataRecd/highest_time)/25) >> "performance.txt"; printf(" 4. Normalised routing load (Packets %) = %f %\n", (RTG/sentData)*100) >> "performance.txt"; printf(" 5. Normalised routing load (Bytes %) = %f %\n", (RTGbytes/sentDataBytes)*100) >> "performance.txt"; printf(" 6. Routing OVERHEAD (Packets %) = %f %\n", (MACRTG/MACDATA)*100) >> "performance.txt"; printf(" 7. Optimal Hop Count = %f \n\n", MACDATA/sends) >> "performance.txt";

98

APPENDIX G – NODES POSITION AT VARIOUS TIME INTERVAL
9 nodes positions after 1 hr
0 2

9 nodes positions after 3 hrs
6

1 3 5 6 4 8 4 7 0 1 2 5 8 3

PAN coordinator

7

PAN coordinator

9 nodes positions after 6 hrs
6

9 nodes positions after 9 hrs
6

PAN coordinator
1
0 2

1 5 4

3

3 5 0 7

2 8

PAN coordinator

8 7

4

9 nodes positions after 12 hrs
6

9 nodes positions after 18 hrs
6

1

PAN coordinator
0 8 7 4 3

PAN coordinator

1

5

2
4

5 0 83 2 7

9 nodes positions after 24 hrs
6

PAN coordinator
4

1 2 78 3 5

0

99

16 node positions after 1 hr 1 4 16 node positions after 3 hrs 1 4 10 5 2 3 11 7 12 5 2 14 11 6 10 3 0 6 0 13 9 9 13 14 15 7 15 8 12 PAN coordinator 8 PAN coordinator 16 node positions after 6 hrs 1 4 2 16 node positions after 9 hrs 1 4 2 5 14 15 11 5 14 15 0 10 12 13 6 11 12 10 13 3 7 8 6 0 9 9 PAN coordinator 3 8 7 PAN coordinator 16 node positions after 12 hrs 1 15 5 4 2 11 14 0 13 3 7 9 10 12 6 8 100 .

25-node Configuration: 16 15 0 21 5 1 20 7 2 6 8 17 13 24 11 18 12 23 3 22 9 19 14 4 10 PAN coordinator Node mov e me nts after 3 hrs 16 15 2 0 21 5 8 22 17 24 18 14 9 11 7 23 19 6 3 20 10 12 4 1 13 PAN coordinator Node move ments after 6 hrs 15 0 2 21 5 24 17 18 14 22 8 6 11 9 7 23 19 12 3 20 10 4 1 16 13 PAN coordinator Node mov e me nts after 9 hrs 19 2 24 8 11 14 17 21 6 4 22 0 10 16 20 7 15 9 5 12 1 18 23 3 13 PAN coordinator Node movements after 12 hrs 101 .

THIS PAGE INTENTIONALLY LEFT BLANK 102 .

IEEE Standards.edu/~suman/courses/838/papers/zigbee.engr.cuny.4-2003 (draft). 8. Lee. "ZigBee/IEEE 802. Low Rate Wireless Personal Area Networks (LR-WPANs) – NS2 Simulation Platform. 42. 218-237. José A.15. accessed on August 25. 2006. Zheng and Myung J. Ed Callaway and Raymond Barrett. Version 1. pp. ZigBee Alliance.ccny. 7.wisc. 140-146. pp.15. Royer. November 2003. 9. “IEEE Standard 802. Zheng and Myung J. http://nsnam.4 “. IEEE Press." IEEE Communications Magazine. Mobile Comp. 2006.4 : Wireless Medium Access Control and Physical Layer Specifications for Low-Rate Wireless Personal Area Networks”. http://ees2cy. 10. Chapter 4. December 2004 Sinem Coleri Ergen.4. IEEE Computer Society. Gutierrez. Kevin Klues and Obi Orjih.isi. 4. E. J.LIST OF REFERENCES 1. Wiley Interscience. J.0. M.” in Proc. Lee. "A comprehensive performance study of IEEE 802.php/Main_Page. Wiki for Network Simulator (NS) and Network Animator (NAM). “ZigBee Specification”.." Sensor Network Operations. Washington University in St. 103 2. ZigBee Document 053474r06.15. February 1999. October 2003. Perkins and E. June 2004.4 Summary".edu/nsnam/index. “Low-Rate Wireless Personal Area Networks: Enabling Wireless Sensors with IEEE 802. and Apps. .4 MAC Layer for Single-sink Wireless Sensor Network Applications”.pdf C. Vol. No. 5.15. “Ad Hoc On-demand Distance Vector Routing. 6. “Configuring the IEEE 802. 90-100.4 make ubiquitous networking a reality? – a discussion on a potential low power. "Will IEEE 802. pp.15. Part 15. 2006. 3.15. low bit rate standard. Louis. Joe Hoffert.edu/zheng/pub/. 6. IEEE Press. http://www. 2nd IEEE Wksp. accessed on August 21.cs. September 2004. Sys.

de/IV/Mitarbeiter/dewaal/BonnMotion/. Ross. 21. accessed on August 11.gov/education/kits/ tides/tides01_intro. informatik.bc.uni-bonn. 2006. 5.html.umass. http://earth.htm).noaa.ac. Ocean Currents. 13. accessed on August 28.waterencyclopedia.geog. RFC 3561. 20.oceanservice. 104 18.cs. Background (Mobility Models and Data for Wireless Networks). 2003.txt. New York: HarperCollins College Publishers. Department of Earth Sciences. 2006. R. accessed on August 27.html. 483-502. BonnMotion. accessed on August 25. accessed on August 24. 3rd edition”. Trends and Applications. “Ad hoc On-Demand Distance Vector (AODV) Routing”. http://www. www. Upwelling and Downwelling Effect. J Boleng. http://signl. vol. .edu/~liberato/wireless_background. 2006. http://web.ietf.ca/ physgeog/fundamentals/8q.html. accessed on August 25.uk/server. Surface and Subsurface Ocean Currents. http://www. Ocean World. http://www. 2006.html. 23. 2002. accessed on August 27. 2006. http://www. T. 2006. Camp. 16. 15.Ekman Spiral.11. Tides and Water Levels. 2.usc. Tides and Water Levels.. accessed on August 25.html. 22. pp. 14.6569. Paul. Wireless Communication & Mobile Computing (WCMC): Special issue on Mobile Ad Hoc Networking: Research. Surface Ocean Current. 19. 2006. Jones and Bartlett Publishers Inc. “Introduction to Oceanography”. http://oceanworld. 1995.edu/ students/currents/currents3.tamu.oceanservice. assessed on September 27. 12. David A.org/rfc/rfc3561. “A Survey of Mobility Models for Ad Hoc Network Research”. Currents . 2006. Pinet.com/Mi-Oc/OceanCurrents. A mobility scenario generation and analysis tool. “Invitation to Oceanography. Davies. 2006. accessed on August 25.ouc.edu/~stott/Catalina/ Oceans..noaa.php?show=conMedia File. 17.html. no.gov/education/kits/tides/tides01_ intro. National Oceanic and Atmospheric Administration. IETF. http://www. 2006. V. University of Southern California.nmm.

28. 2006. Computer Science Department. “A Group Mobility Model for Ad Hoc Wireless Networks. http://www. ETSI SMG-5.edu/skeshav/real/overview. 30. Proceedings of the IEEE INFOCOM 1999.M. http://nsnam.cornell. Laboratory S. August 1999.R. X. accessed on October 22. 26.O.edu/nsnam/index. Haas. http://newark.edu/PUBLICATIONS /PDF/Thesis_Taekyu. Near Real-Time Monterey Bay Surface Currents. accessed on October 22.” Proceeding of the 2nd ACM/IEEE Int. 27. Pei and C.best.A.0. Workshop on Modeling and Simulation of Wireless and Mobile Systems (MSWiM' 1999. G.fr/~gauthier/mobility. 32. NS2 Event Scheduler. The VINT Project.1.vwh. http://williams. A Collaboration between researchers at UC Berkeley.php/NS2_Trace_Formats#New_Wireless_Trace_Formats. B.43. accessed on September 2. The CMU Monarch Project.” Technical Report tr 101 112 v3. Gerla. Chiang. “Predictive distance-based mobility management for PCS networks”. 99). Carnegie Mellon University Snapshot Release 1. Mobility model in ad hoc network. wwwpublic. 34.acims.pdf. pp. accessed on September 11.cs. Hong. LBL. “The CMU Monarch Project’s Wireless and Mobility Extensions to ns”. accessed on November 10.2.htm#LL. 2006. 29. M.0 Overview.edu/~brucel/realtimemaps/index.isi. pp.net /avform. Liang and Z.html.html.C. France. and Xerox PARC.24.html.V. REAL 5. USC/ISI. 31. 2006.A. http://www. 2006 Ed Williams. August 2006. 105 .1.udel. 53-60. accessed on September 8. Aviation Formulary V1. 33. “Selection Procedures for the Choice of Radio Transmission Technologies of the UMTS.cms. April 1998. NS-2 Trace Formats.1377-1384.int-evry. 25. “The ns Manual (formerly ns Notes and Documentation)”.arizona. 2006. 2006.

accessed on December 1.navy.35. Vaddina Prakash Roa. Dresden University of Technology. Advanced Refractive Effects Prediction System (AREPS). 2006.mil/. November 2005. http://sunspot. 106 .spawar. 36. “Master Thesis: The simulative Investigation of Zigbee/IEEE 802.15.4”.

sg) Director. Defense Technical Information Center Ft.INITIAL DISTRIBUTION LIST 1. 107 . California Professor Gurminder Singh Department of Computer Science Naval Postgraduate School Monterey. California Professor Peter Denning Chairman. 4.edu. Temasek Defence Systems Institute (TDSI) National University of Singapore Singapore Tan Lai Poh (email: tdstlp@nus. 7. California Professor Yeo Tat Soon (email: tdshead@nus. McEachen Department of Electrical and Computer Engineering Naval Postgraduate School Monterey.sg) Temasek Defence Systems Institute (TDSI) National University of Singapore Singapore Lim Kwang Yong Singapore Technologies Dynamic Pte Ltd Singapore 3. 6. Belvoir.edu. 5. 8. California Professor John C. Department of Computer Science Naval Postgraduate School Monterey. Virginia Dudley Knox Library Naval Postgraduate School Monterey. 2.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.