The simulative Investigation of Zigbee/IEEE 802.15 · Zigbee/IEEE 802.15.4 Vaddina Prakash Rao for the degree Master of Science ... The goals of the thesis are to build a simulation

DRESDEN UNIVERSITY OF TECHNOLOGY

Department ofElectrical Engineering and Information Technology

Chair of Telecommunications

Master Thesis

The simulative Investigation ofZigbee/IEEE 802.15.4

Vaddina Prakash Rao

for the degreeMaster of Science

(M.Sc.)

Supervisors: Dipl.-Ing. Dimitri MarandinDipl.-Ing. Falk Hoffmann

Professor: Prof. Dr.-Ing. Ralf Lehnert

TECHNISHE UNIVERSITAT DRESDEN

FAKULTAT ELEKTROTECHNIK UND INFORMATIONSTECHNIK

Aufgbenstellung fur die Diplomarbeit/Thesis Statement

fur Herrn. Vaddina Prakash Rao

Thema The simulative Investigation of Zigbee/IEEE 802.15.4

Zielsetzung/GoalThe IEEE 802.15.4 is a new personal wireless area network standard designed for applications like wire-less monitoring and control of lights, security alarms, motion sensors, thermostats and smoke detectors.IEEE 802.15.4 specifies physical and media access control layers that have been optimised to ensurelow-power consumption. The MAC layer defines different network topologies, including a star topology(with one node working as a network coordinator, like an access point in IEEE 802.11), tree topology(where some nodes communicate through other nodes to send data to the network coordinator),andmesh topology (where routing responsibilities are distributed between nodes and master coordinator isnot needed).

In this thesis a star network topology according to the 802.15.4 standard has to be simulated withthe simulator ns-2. The goals of the thesis are to build a simulation model and to investigate differentfunctional modes of IEEE 802.15.4 and their impact on energy consumption and network performance.Different application scenarios have to be evaluated. The simulation results must be generated withinput from ZMD for their transceiver ZMD44101.

Betreuer: Dipl.-Ing. Dimitri Marandin (TU Dresden)

Dipl.-Ing. Falk Hoffmann (ZMD AG)

Ausgehandigt am 15.05.2005

Einzureichen bis 14.11.2005

Prof.Dr.-Ing. M.Liese Prof.Dr.-Ing. Ralf Lehnert

Vorsitzender des Prufungsausschusses Verantwortlicher Hochschullehrer

Declaration

I hearby declare that every part of this documentation, unless otherwise indicated, is my own work.The work is done without the collaboration of anyone. No part of this document has been copied fromany copyrighted material without due credit to the author. This document is copyrighted to the Chairof Telecommunications, TU Dresden and no part of this document shall be used, copied, disclosed orconveyed to any party without the prior written permission of the author or that of the chair.

Dresden, November 10, 2005Vaddina Prakash Rao

ii

Abstract

The IEEE 802.15.4 is a new personal wireless area network standard designed for applications like wire-less monitoring andcontrol of lights, security alarms, motion sensors, thermostats and smoke detectors.IEEE 802.15.4 specifies physical and media access control layers that have been optimised to ensure low-power consumption. The MAC layer defines different network topologies, including a star topology (withone node working as a networkcoordinator, like an access point in IEEE 802.11), tree topology (wheresome nodes communicate through other nodes to send data to the network coordinator),and mesh topol-ogy (where routing responsibilities are distributed between nodesand master coordinator is not needed).

In this report a star network topology according to the 802.15.4 standard is simulated with simulator ns-2. The goals of the thesis are to build a simulation model and to investigate different functional modes ofIEEE 802.15.4 and their impact on energy consumption and network performance. Different applicationscenarios are evaluated. The simulation results are generated with parameter input from ZMDs chip,ZMD44101.

iii

Acknowledgments

I take this oppurtunity to express my gratitude to the people who have lent their support all along mymaster study and thus enabled me to concentrate on my work.

Firstly, i express a very emotional gratitude to my parents and family, who inspite of enduring the odds,have supported me all along and gave me this oppurtunity to study at TU Dresden. Their enduranceand patience have been the driving forces of my determination.

I also acknowledge the oppurtunity bestowed on me by the professor of the Chair of Telecommunications,Prof. Dr.-Ing. Ralf Lehnert, to conduct my master thesis in his renowned chair. Also i am thankfulto Dipl.-Ing. Dimitri Marandin, of the chair of telecommunications who have guided me at difficultmoments, and whose timely directions have often pulled me out of trouble and have put me on theright path. I am also grateful to the other professors and teachers of the Department of Electrotechnik,whose quality teaching have helped me gain a sound theoritical and practical knowledge.

I also thank the help offered by Mr. Falk Hoffman, of ZMD AG, in identifying the right parameters forthe simulations.

And finally, i thank my close friends who have been all along with me, supporting and advising me onmy endeavours. Their company have always enlightened my spirit .

Vaddina Prakash RaoSeptember, 2005

iv

Contents

Declaration ii

Abstract / Zusammenfassung iii

Acknowledgments iv

Abbreviations vii

List of Figures viii

List of Tables 1

1 Introduction 21.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Evolution of zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Overview of IEEE 802.15.4 LR-WPAN 82.1 Operating Frequencies and Datarates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Network Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Network Formation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 IEEE 802.15.4 Service Primitives[1] 183.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 PHY Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.3 MAC Primitives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 The Simulation Environment 244.1 Introduction[10][11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Simulator Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 The Network Animator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Process Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5 Result Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.6 zigbee Software Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.7 Software Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.8 Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

v

Contents vi

5 System Performance 485.1 zigbee Specific Simulation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.2 Performance Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.3 Performance Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545.4 Drop Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.5 Effective Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.6 Datarates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.7 Effective Energy Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Adaptive Backoff Mechanism For CSMA-CA 706.1 CSMA-CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 716.2 The Adaptive Backoff Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 736.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.4 Battery Lifetime Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

7 Conclusions and Future Work 857.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Appendices 87

A Source Code and Results 87A.1 source code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87A.2 results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Bibliography 92

Abbreviations

ABE Adaptive Backoff ExponentARP Address Resolution ProtocolBE Backoff ExponentBI Beacon IntervalBO Beacon OrderCAP Contension Access PeriodCBR Constant Bit RateCCA Clear Channel AssessmentCFP Contension Free PeriodCID Cluster IdentificationCSMA-CA Carrier Sense Multiple Access with Collision AvoidanceED Energy DetectionFFD Full Function DeviceFTP File Transfer ProtocolGTS Guaranteed Time SlotsLQI Link Quality IndicationLR-WPAN Low Rate Wireless Personal Area NetworksMLME Mac Layer Management EntityMPDU Mac Protocol Data UnitMSDU MAC Serice Data UnitNAM Network AnimatorNS Network SimulatorPAN Personal Area NetworkPIB PAN Information BasePLME Physical Layer Management EntityPOS Personal Operating SpacePPDU PHY Protocol Data UnitPSDU PHY Service Data UnitRFD Reduced Function DeviceSD Superframe DurationSO Superframe OrderSPDU SSCS Protocol Data UnitSSCS Service Specific Convergence SublayerTCP Transmission Control ProtocolUDP User Datagram ProtocolWPAN Wireless Personal Area Networks

vii

List of Figures

1.1 Wireless Technologies [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Star Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Mesh Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 IEEE 802.15.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4 The SuperFrame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5 BO = SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.6 BO > SO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.7 Superframe Duration and Beacon Interval . . . . . . . . . . . . . . . . . . . . . . . . . . 152.8 Coordinator to Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.9 Device to Coordinator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Service Primitive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.1 NAM Snapshot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Process Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Node placement by scen gen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 Analysis Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.5 Program Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6 Constant Current Discharge[13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 Throughput analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555.2 Throughput Performance in the Range 0.1-3.0 pkts/sec . . . . . . . . . . . . . . . . . . 555.3 Throughput Analysis Assuming Identical Carrier Sense Range . . . . . . . . . . . . . . . 575.4 Delay Analysis for Simulation-1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5 Delay Analysis in the Range 0.1-3.0Pkts/sec . . . . . . . . . . . . . . . . . . . . . . . . . 585.6 Delivery Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 585.7 Delivery Ratio Performance in the range 0.1 - 3.0 pkts/sec . . . . . . . . . . . . . . . . . 595.8 Packet Delivery Ratio When Using Ideal Carrier Sense Threshold . . . . . . . . . . . . . 595.9 Energy Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.10 Energy With Better Confidence Levels in the range 0.1-3.0pkts/sec . . . . . . . . . . . . 605.11 Drop Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 635.12 LQI Drop Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.13 Queue Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.14 LQI Packet Drops for Simulation-2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655.15 Drops due to Queue Overflow for Simulation-2 . . . . . . . . . . . . . . . . . . . . . . . 65

6.1 Carrier Sense Multiple Access - Collision Avoidance . . . . . . . . . . . . . . . . . . . . 726.2 Group Arrangement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.3 Adaptive Backoff Exponent Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.4 Node Reaction on Reception of a Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . 786.5 Beacon Frame Format with ABE implementation . . . . . . . . . . . . . . . . . . . . . . 79

viii

List of Figures ix

6.6 Throughput With ABE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.7 Delay Analysis With ABE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.8 Delivery Ratio with ABE Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 816.9 Energy Analysis for ABE Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 816.10 Link Quality Drop Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 826.11 IFQ Drops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

List of Tables

2.1 IEEE 802.15.4 Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4.1 Traffic Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 Physical Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3 Routing Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.1 Power Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.2 Simulation-1: Carrier Sensing Range = Receiver Sensitivity . . . . . . . . . . . . . . . . 555.3 Simulation-2: Ideal Carrier Sensing Ranges . . . . . . . . . . . . . . . . . . . . . . . . . 555.4 Ideal Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575.5 Packet Drops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

1

Chapter 1

Introduction

ZIGBEE is a new wireless technology guided by the IEEE 802.15.4 Personal Area Networks standard.It is primarily designed for the wide ranging automation applications and to replace the existing

non-standard technologies. It currently operates in the 868MHz band at a data rate of 20Kbps inEurope, 914MHz band at 40Kbps in the USA, and the 2.4GHz ISM bands Worldwide at a maximumdata-rate of 250Kbps. Some of its primary features are:

. Standards-based wireless technology

. Interoperability and worldwide usability

. Low data-rates

. Ultra low power consumption

. Very small protocol stack

. Support for small to excessively large networks

. Simple design

. Security, and

. Reliability

In this chapter, focus has been on the evolution of zigbee, giving an account of other complementarytechnologies, both proprietary and open source, followed by some intended applications, and a detailedintroduction about the various concepts of zigbee.

1.1 Motivation

The wireless market has been traditionally dominated by high end technologies, but so far WirelessPersonal Area Networking products have not been able to make a significant impact on the market.While some technologies like the bluetooth have been quite a success story, in the areas like computerperipherals, mobile devices, etc, they could’nt be expanded to the automation arena.

This led to the invention of the wireless low datarate personal area networking technology, Zigbee(IEEE 802.15.4), for the home/Industrial automation. It has received a tremendous boosting amongthe industry leaders and critics have been quick enough to indicate that no less than 80 million zigbeeproducts will be shipped by the end of 2006[8]. A group of companies, called the Zigbee Alliance, havebeen working together to enable reliable, cost-effective, low-power, wirelessly networked monitoring and

2

1.2 Evolution of zigbee 3

control products, based on 802.15.4. The alliance has been putting considerable weight on the possi-ble success of this technology. Industry leaders like Ember, FreeScale, HoneyWell, Phillips, Motorola,Samsung, ZMD, and a hundred such companies are backing it. Also the alliance is striving to makethis technology applicable worldwide by involving corporates around the globe. Currently the allianceis worth over a hundred other companies and is continually growing. The size of this alliance cannotensure its popularity and widespread use, however, it does indicate a commitment of the industry tofocus on one technology rather than going haphazardly in designing their automation products basedon self-developed technologies.

1.2 Evolution of zigbee

During the last decade there has been an explosion of devices using sensor technologies for controland monitoring purposes. Wired Sensors are now intended to be replaced with wireless technologies.Corporates have been envisioning of a digital home where every device is connected, and remotelycontrolled and monitored. Even though a perfect digital home is yet a mirage, we are now able toapply several technologies to suite our home and industrial networking needs. However, this concept ofa digitally connected home has received a luke warm response due to lack of viable solutions. Over theyears, several possible contenders have been identified. But none match the robustness and reliabilityrequired for the automation applications. Robustness when it comes to critical application scenarios asapplicable to industrial needs and reliability when it comes to power usage and prompt response.

1.2.1 Contenders

Several wireless technologies are already in existence and the first question that arises when we speakof a new technology is why do we need yet another technology? Well, there are a number of reasonsto support our requirement for a new technology. Firstly is the non-availability of a standard, reliable,worldwide applicable technology. To provide evidence to this statement a small study of the existingstandards and how they fail to fulfill the needs of a viable low-power, low-datarate technology.

Before we go on to describe the competing technologies, lets focus on what we aim at. The currentfocus is on home/building/industrial applications. As is obvious, to provide controlling and monitoringservices, it is not necessary to have higher data rates. Similarly, several of the application scenariosmake it difficult to apply high power consuming devices. So the two primary factors in this study ispower consumption and data-rate.

What makes major technologies unfit for the current challenge is the very thing they are designedfor. Most technologies designed so far, primarily focus either directly or indirectly on the ability tosupport higher datarates, with wider operating space (range), which has a direct impact on the powerrequirements, which inturn influence the cost factor, size, complexity in design and feasibility of appli-cation. None of them have been able to overcome these barriers to suite the needs of home/industrialautomation.

The following subsections look at other peer technologies which are predominantly used as networking,automation and sensor technologies. Their feasibility to apply for home automation needs is studied,giving an account of how they fail to provide a viable solution, and finally a solution leading to zigbeehas been presented.

WI-FI

It would be wrong even to say, WI-FI ever was a contender for home automation. With its higherbandwidth support and power thirsty features, it is highly unlikely it is used for home automation,other than the applications that need Audio/Video transmissions.


Bluetooth

Bluetooth is a short range communication technology, intended to replace cables connecting portableand/or fixed electronic devices. Its key features being robust, low complexity, low power and low costtechnology. It utilizes the unlicensed 2.4GHz ISM Band, a globally available frequency band, withfrequency hopping and avoids interference by hopping to a new frequency 1600 times a second andusing small packet size. It has a range of over 10 meters and can easily extend to 100 meters with apower boost. It can transfer data at a maximum range of 720 Kbps.

With the current specifications a small network (called, piconet) can be formed with as many as sevenslave devices and a master coordinator. Also, several piconets can be linked together to form a biggernetwork. Typical applications include, intelligent devices (PDAs, Cell phones, PCs), data peripherals(mice, keyboards, joysticks, cameras, printers, lan access points), audio peripherals (headsets, speakers,stereo receivers) and embedded applications[2].

Based on its application sphere and its features, we can conclude bluetooth can be a good contenderfor automation. But the effort of Bluetooth to cover more applications and provide quality of service(QoS) has led to its deviation from the design goal of simplicity. The complexity of bluetooth makesit expensive and inappropriate for some applications requiring low-cost and low-power applications.Another major constraint being its lack of flexibility in its topologies as in the scatternets. Researchshows that Bluetooth faces scalability problems[3][4].

Infrared

Using infrared radiation as a medium of short-range high-speed communication has been in existence forover a decade now. Virtually every home appliance comes with an infrared commander. Their popularityin the home appliance market brought down the prices of Infrared emitters and detectors to throw awayrates. Also the spectral band offers unlimited band and is unregulated worldwide[5].

It is this technology that zigbee has set out to replace. A typical household, currently use as many as 5-10remote commanders. As more and more appliances are intended to be remotely controlled, more infrareddevices are used. Devices such as TVs, garage door openers, and light and fan controls predominantlysupport one-way, point-to-point control. They’re not interchangeable and they don’t support more thanone device. Because most remotely controlled devices are proprietary and not standardized amongmanufacturers, even those remotes used for the same function (like turning on and off lights) are notinterchangeable with similar remotes from different manufacturers. So if there is a centralized controllingdevice which can be used to form a network among all the devices present, as in a home area network,it could be possible to solve some of these problems.

Z-Wave[6]

Z-Wave is a proprietary short-range low-datarate wireless technology, owned by Zensys Inc. The providerhas aligned with over a hundred other companies to provide building automation services. Z-Wave isa wireless RF-based communications technology designed for residential and light commercial controland status reading applications such as meter reading, lighting and appliance control, HVAC, accesscontrol, intruder and fire detection, etc.

Z-Wave transforms any stand-alone device into an intelligent networked device that can be controlledand monitored wirelessly. Z-Wave delivers high quality networking by focusing on narrow bandwidthapplications and substituting costly hardware with innovative software solutions.

Zensys claims that Z-Wave is superior to zigbee in several ways, such as operating at 908 MHz in theUnited States and at 868 MHz in Europe, meaning that it wont interfere with WiFi as zigbee sometimes.


In Zensys says zigbee requires 10 times the power that Z-Wave does. This is one possible contendingtechnology that may need to be watched noting its high pitched claims of better performance thanzigbee.

X-10[7]

Of the few attempts to establish a standard for home networking that would control various homeappliances, the X-10 protocol is one of the oldest. It was introduced in 1978 for the Sears Home ControlSystem and the Radio Shack Plug’n Power System. It uses power line wiring to send and receivecommands. The X-10 PRO code format is the de facto standard for power line carrier transmission.

X-10 transmissions are synchronized to the zero-crossing point of the AC power line. A binary 1 isrepresented by a 1ms burst of 120KHz at the zero-cross point and binary 0 by the absence of 120KHz.The network consists of transmitter units, receiver units, and bidirectional units that can receive andtransmit X-10 commands. Receiving units work as remote control power switches to control homeappliances or as remote control dimmers for lamps. The transmitter unit is typically a normally-openswitch that sends a predefined X-10 command if the switch is closed. The X-10 commands enable youto change the status of the appliance unit (turn it on or off) or to control the status of a lamp unit (on,off, dim, bright). Bidirectional units may send their current status (on or off) upon request. A specialcode is used to accommodate the data transfer from analog sensors. Currently, a broad range of devicesthat control home appliances using the X-10 protocol is available from Radio Shack or web retailerssuch as www.smarthome.com and www.x10.com.

Availability and simplicity have made X-10 the best-known home automation standard. It enables plug-and-play operation with any home appliance and doesn’t require special knowledge to configure andoperate a home network.

The downside of its simplicity is slow speed, low reliability, and lack of security. The effective datatransfer rate is 60bps, too slow for any meaningful data communication between nodes. High redundancyin transition is dictated by heavy signal degradation in the power line. For any power appliances, theX-10 transmission looks like noise and is subject to removal by the power line filters. Reliability andsecurity issues rule out the use of the X-10 network for critical household applications like remote controlof an entry door.

The figure 1.1 illustrates the datarate and the operating range of zigbee in comparison to the otherfamous wireless technologies.

Figure 1.1: Wireless Technologies [4]

1.3 Applications 6

1.3 Applications

There has been tremendous excitement on part of the corporates, the market and the consumers alikebecause of the wide spectrum of applications that zigbee has to offer. It is a revolutionary new technologybuilt to compliment or replace existing not so successful technologies. Automation is the buzz wordfor zigbee. It stands to automate our household, corporate buildings and industries. Its control andmonitoring capabilities offer an excellent platform for automation.

A host of application categories/scenarios are presented here:

. Monitoring: Surveillance systems, Fire alarms, Pressure sensors, Meter reading monitors, Healthand Environment monitors.

. Control: Health, Environment, Sensors, Home, Building and Industry Automation

. Efficiency

. Conservation

Theoritically there can be innumerable number of applications. It only depends on how better we tendto harness the flexibility, and services offered by zigbee. As already stated, these are merely applicationsthat are intended/desired and there may be scenarios where this technology cannot be successfullyapplied.

Firstly, these application scenarios can be applied broadly into three application spheres, based on thecomplexity, feasibility and requirements posed by each sphere of application.

. Home

. Building

. Industrial

Each of the application categories, even though look very similar, apply differently to each of theapplication spheres. For example, controlling the lighting system are no way similar to the home andthe Industrial application spheres.

To have a better understanding on how well these technologies can be applied to make our lives evenmore lazy and loathsome, lets go through some of these applications in detail.

Monitoring is a part of our daily activity. In industrial applications there are personnel deployed tomonitor certain critical situations. Its significance is no way inferior in the home application sphere. Athome, the contents of the refrigerator, environmental, health and resource (water, power consumption,gas, fuel, etc)management need constant monitoring. Imagine a situation where the refrigerator shops foritems that are frequently used but are currently low on stock. A simple monitoring device, constantlymonitoring the contents of the refrigerator, by waking up at prescribed intervals, and informing thecontrolling station about the current inventory level, can be installed. The controlling station, will beintelligent enough to decide if its time to shop for a particular item and prepares the order form andeither issues it to its master or directly to the supermarket through the internet.

Similarly, consider an industrial application where a bigger and intelligent controlling node is stationedat a manufacturing plant. Several smaller nodes spread across the plant which constantly keeps postingthe central controlling node about the current status of the individual machine. And now lets assumethermostats, boilers, pressure applying devices, a motion detection camera for intruder detection, etcare operational across the plant. These devices either wake up at regular intervals, or constantly monitor

1.4 Outline 7

the given machine/application. Critical applications like security sensors need to be constantly active,where as thermostats, pressure sensors, etc need not have a constant monitoring solution. And anyabnormalities that these sensors observe are reported back to the controlling station, which then executesthe appropriate service routines. It can call on the security staff, when the security camera detectsunwanted motion. Or it can merely relay the archived video of the past few minutes back to the securitycontrol room. Similarly, a pressure threshold break can be reported back to the concerned personnel.

Similarly, this technology can be conveniently applied to obtain better efficiency and conservation ofscarce and precious resources.

. Configuring and running multiple systems from a single remote control

. Automate data acquisition from remote sensors to reduce user intervention

. Provide detailed data to improve preventive maintenance programs

. Reduce energy expenses through optimized HVAC management

. Allocate utility costs equitably based on actual consumption

There is no dearth of applications for this technology. But key to such implementations are cost, powerconsumption and bandwidth requirements.

1.4 Outline

The LR-WPAN is at its nascent stages of development. Many of its supposed features are yet to beeither fully developed or decisively verified. There have been many reports on the performance analysisof IEEE 802.15.4[9][4], for the frequency band of 2.4Ghz with the data rate of 250Kbps. However, nocomprehensive reports are available on the performance analysis of Zigbee in the 868Mhz and the 915Mhz, frequency bands. Primarily because of they being limited to particular geographic locations. Thisstudy explores to fill this gap with a performance analysis report focused on the 868Mhz frequencyband.

Therefore, the current study firstly tries to build a reliable, definitive and deterministic simulationenvironment, identify the various simulation parameters and provide the results obtained for variousperformance metrics like, throughput, delay analysis, and energy performance for the 868Mhz. Theresults obtained for the 868Mhz band, can be in a way, applied to the frequency band of 915Mhz, dueto their close proximity in the spectral space. However, it can be said, the main focus remains to be868Mhz.

This report also focuses on the network congestion giving out reasons, and highlighting the inefficiencyin terms of backoff exponent management on part of the channel access mechanism CSMA-CA. Thedegradation in performance because of this inefficiency is explained and a proposal has been madeto have an efficient backoff exponent mechanism in place for the devices involved in transmission,called the Adaptive Backoff Exponent Algorithm, and results are presented to support the performanceimprovement achieved by it. The report concludes with a highlight on the achievements made, alongwith few comments on some good topics for further research.

Chapter 2

Overview of IEEE 802.15.4 LR-WPAN

AW ireless personal area network conforming to the IEEE 802.15.4 standard is composed of severaldevices and its functionality and features can be illustrated by several terms. Some of them are

listed here.

Co-ordinator : It is a device which is authorized to provide synchronization services in an establishednetwork. There can be two different kinds of co-ordinators based on their operation scope. Firstis the PAN-Corodinator, which acts as a coordinator for the entire PAN. Where as an ordinaryco-ordinator can only function within the scope of a cluster.

Cluster : A cluster is a small section of a bigger network, which has its own co-ordinator. Groups ofclusters communicate with a central PAN-Coordinator to form the PAN in a mesh topology.

Device/End Node : A device is either a reduced/full function device that can be visualized as a leafof a tree structure. Any device that is not a co-ordinator is an end node (device).

Personal Operating Space(POS) : It is the operating range of a node in all directions, and is a constantirrespective of being in motion or stationary.

There are 14 PHY and 35 MAC Primitives defined by the IEEE 802.15.4 standard[4]. The LR-WPANsupports two types of devices called the Full Function Device and the Reduced Function Device.

Full Function Device It is a device which supports all the 49 primitives supported by the technology[4].It is a fully functional device which is capable of assuming the role of either a PAN Coordinator,a Coordinator, or just as an end node (device). Also an FFD can function as a routing device incertain network topologies where data transfer among FFD is allowed (EX: peer-to-peer commu-nication).

Reduced Function Device It is a device with reduced functionality which can only function as an enddevice or node. It cannot communicate with any other device other than the coordinator. Giventheir extremely low functionality, these devices are normally intended for simple applications likea light switch, etc. They merely send information to the coordinator at regular intervals aboutthe status of the device it is monitoring. It can only support a maximum of 38 primitives[4].

A basic LR-WPAN comprises of a mixture of these devices, an FFD being the most common device usedin a PAN. But any PAN network should have at least one FFD, to act as the PAN-Coordinator. However,depending on the application when a RFD is not feasible, to fulfill the needs of the application, an FFDcan be applied. The devices of a network monitor the applications and reply back to the coordinator.The devices within the pan should be around the operating space of the coordinator. But given thedynamic propagation characteristics of the channel a definite operating space for each device cannot bedefined.

8

2.1 Operating Frequencies and Datarates 9

Frequency Band Num of Channels Datarate (Kbps) Applicability Restrictions2.4Ghz 16 250 WorldWide Unlicensed915Mhz 10 40 USA Licensed868Mhz 1 20 Europe Licensed

Table 2.1: IEEE 802.15.4 Operating Conditions

2.1 Operating Frequencies and Datarates

Any technology cannot achieve wide ranging popularity if it not flexible enough to be used worldwide.This is also one of the primary reasons for the failure of several proprietary technologies. However,IEEE 802.15.4 has been designed to be applied worldwide. This allows manufactures to concentrateon devices that can work in any of the available channels based on channel characteristics, bandwidthrequirements, local regulations, etc. It support three different operating frequency bands, with differentnumber of supporting channels and datarates.

2.2 Network Topologies

A Low rate WPAN supports three different types of topologies.

. Star Topology

. Peer-to-Peer Topology

. Cluster Tree/Mesh Topology

2.2.1 Star Topology

The star topology (Fig: 2.1) is one of the most common forms of network formation. This type of topol-ogy can be used in monitoring applications where several devices monitor their applications and reportto the coordinator. And the coordinator, a highly capable FFD, reacts to the situation at hand. In thistype of network formation the communication between any two devices is forbidden. All devices can onlycommunicate with the coordinator irrespective of their device type. Thus, a device can communicatewith the coordinator and vice versa. No routing of information is possible. Given this reduced func-tionality of the system, routing functionalities like Address Resolution, and Routing finding to certainextent can be disabled.

2.2.2 Peer-to-Peer Topology

The Peer-to-Peer topology (Fig: 2.2) is a mode of communication where routing of data among devicesis possible, as long as they are with in the operating space of each other. Complicated applicationswhere devices need sharing of information are intended targets for the implementation of a peer-to-peer topology. Thus possible communication scenarios are between node-to-node, node-to-coordinator,coordinator-to-node. As is evident if two devices need to transfer data, both have to be full functiondevices. Applications such as industrial control and monitoring, wireless sensor networks, asset andinventory tracking, intelligent agriculture, and security would benefit from such a network topology. Apeer-to-peer network can be ad hoc, self-organizing and self-healing.

2.3 Network Formation 10

Figure 2.1: Star Topology

Figure 2.2: Mesh Topology

2.2.3 Cluster-Tree Topology

The cluster tree topology can in a way be considered as a derivative of the peer-to-peer topology.Several small clusters, each being able to communicate peer-to-peer, can be controlled with a PANcoordinator. And each cluster can have its own coordinator. And the coordinators are answerable tothe PAN Coordinator. Among several existing clusters, the coordinators can compete with each otherto choose a PAN coordinator.

2.3 Network Formation

Network formation is part of the network layer functionalities. An example run of the various stepsinvolved for a network formation is presented:

2.3.1 Star-Topology

. Assume a full function device is switched ON for the first time.

. It starts scanning its operating channels for possible beacon transmissions, from other PANs.

2.4 Architecture 11

. If it finds a beacon, it can try to associate with the PAN or it can choose to form its own PAN.

. assuming it chooses to form a new PAN, It chooses a PAN ID unique within its operating space.

. Now it allows other devices to be associated to it. This ends the Star network formation phase,as initiated by the PAN-Coordinator.

2.3.2 Peer-to-Peer Topology

. Assume a full function device is switched ON for the first time.

. It starts scanning its operating channels for possible beacon transmissions, from other PANs.

. If it finds a beacon, it can try to associate with the PAN or it can choose to form its own PAN.

. Assuming it chooses to form a new PAN, It assumes the role of a PAN Coordinator and assignsa Cluster ID (CID) of 0 to itself.

. Now it allows other devices to be associated to it.

. Other devices which intend to join a PAN, look for the beacon transmissions and upon receivingthe beacon transmissions from the coordinator, would request association to the network.

. The coordinator shall decide if it would like to add the device into the network.

. If it wants to add the device, it will assign a CID value to it. The new device shall add thecoordinator as its neighbor, while the coordinator will add it as its child.

. And this new device can now act as a cluster head and transmit beacons.

. Other devices can now join the network at this node.

2.4 Architecture

The LR-WPAN architecture is defined in terms of a number of blocks in order to simplify the standard.These blocks are called layers. Each layer is responsible for one part of the standard and offers services tothe higher layers. The layout of the blocks is similar to the structure of the OSI layered architecture. Butthe IEEE 802.15.4 standard only defines the PHY and the MAC layers. The upper layers of networkingand application have been left for the application developers. An LR-WPAN device comprises a PHY,which contains the radio frequency (RF) transceiver along with its low-level control mechanism, anda MAC sub layer that provides access to the physical channel for all types of transfer. The figure 2.3depicts the layered architecture of IEEE 802.15.4.

The features of the PHY layer activation and deactivation of the radio transceiver, ED, LQI, channelselection, clear channel assessment (CCA), and transmitting as well as receiving packets across thephysical medium. Similarly, the MAC layer is responsible for beacon management, channel access, GTSmanagement, frame validation, acknowledged frame delivery, association, and disassociation.

2.5 Functional Overview 12

Figure 2.3: IEEE 802.15.4 Architecture

2.5 Functional Overview

2.5.1 The Superframe structure

The superframe structure (Fig: 2.4) is an optional part of a WPAN. It is the time duration between twoconsecutive beacons. The structure of the superframe is determined by the coordinator. The coordinatorcan also switch off the use of a superframe by not transmitting the beacons. The superframe durationis divided into 16 concurrent slots. The beacon is transmitted in the first slot. The remaining part ofthe superframe duration can be described by the terms, CAP, CFP and Inactive. The superframe isused to provide vital statistics like synchronization, identifying the PAN and the superframe structure,to the devices connected in a Wireless PAN. This information is critical for the operation of the PANin a Beacon enabled network.

Figure 2.4: The SuperFrame Structure


Contention Access Period : It is the time duration in symbols during which the devices can competewith each other to access the channel using CSMA-CA and transmit the data.

Contention Free Period/Guaranteed Time Slots : It is the time duration for which certain low-latencyapplication devices are given exclusive rights over the channel and the devices can directly starttransmitting the data. There can as many as 7 slots assigned for GTS transmissions. Thesetransmissions start immediately after the contention access period.

Inactive Period : It is the time period during which the coordinator goes to a power save mode and itwould not interact with the PAN. Therefore, during this time, there will be no beacon transmis-sions. This implies that the devices also go to sleep mode for this duration.

Superframe Duration : The total time duration of the CAP, CFP (GTS) and a Beacon. The Superframeduration doesn’t include the inactive period.

Beacon Interval : It is the time duration between two successive beacons.

Synchronization is key for better throughput in the network. Every device in the network when readyto transmit data should compete for the channel. But to compete for the channel, they should knowwhen the contention access periods start. And this is what the superframe structure or truly, the beacontransmission does. This information is embedded into the beacon, and the device receiving the beaconcan extract this information and get ready to compete for the channel. Similarly is the case when adevice wants to exclusively transmit in the GTS mode. It is the coordinator that would assign a deviceaccess to the GTS.

The structure of the superframe structure is determined by two parameters. The Superframe Order(SO) and the Beacon Order (BO). The superframe order is the variable which is used to determine thelength of the superframe duration. Similarly the Beacon Interval is determined by the variable BO.

1 ≤ SO ≤ 151 ≤ BO ≤ 15

For BO=15 shall indicate that there are no beacon transmissions. Also for SO = BO (Fig: 2.5), thebeacon interval is same as the superframe duration indicating there is no inactive portion. Similarly,when BO is greater than SO (Fig: 2.6), indicates there is an inactive portion present in the superframe.

Figure 2.5: BO = SO

Figure 2.6: BO > SO

The beacon interval and the active and inactive part of the superframe are calculated, in the followingcomputation.


Beacon Interval

BI = aBaseSuperFrameDuration× 2BOsymbols (2.1)

aBaseSuperFrameDuration = aBaseSlotDuration× aNumSuperframeSlots (2.2)

aBaseSlotDuration = 60symbols

aNumSuperFrameSlots = 16aBaseSuperFrameDuration = 60× 16symbols = 960symbols

(2.3)

Lets calculate the beacon interval with BO=8 and SO=7.

BI = 960× 2BOsymbols

BI |BO=8= 960× 28 = 245760symbols

BI |20kbps=24576020000

= 12.288

BI = 12.288secs (2.4)

Similarly the Superframe duration can be calculated using the superframe order as follows

SD = aBaseSuperframeDuration× 2SO (2.5)

SD = 960× 2SOsymbols

SD |SO=5= 960× 27 = 122880symbols

SD |20kbps=12288020000

= 6.144secs

SD = 6.144secs (2.6)

aBaseSuperframeDuration =SD

16=

6.14416

= 0.384secs

aBaseSuperframeDuration = 0.384secs (2.7)

And finally the inactive portion of the superframe can be calculated as,

InactivePortion = BeaconInterval − SuperframeDuration (2.8)InactivePortion = 12.288− 6.144 = 6.144secs (2.9)

The figure 2.7 indicates all the time periods for a superframe with BO=8 and SO=7.


Figure 2.7: Superframe Duration and Beacon Interval

2.5.2 Data Transmission

There can be three different types of data transmission possible. They are

. Transmission from a device to the coordinator

. Transmission from the coordinator to the device

. Transmission between any two devices.

In a star topology only the first two transmission techniques are possible. Transmission between anytwo devices is not supported, where as in a peer to peer network all the three types of transmissions arepossible. The transmissions can be carried out again in either of two ways, depending on if the beacontransmissions are allowed or not. The current study is focused on a beacon enabled network. Hence thefollowing paragraphs will find no reference of a non-beacon enabled transmission techniques.

The following subsections will go through the steps followed by each mode of transmission.

Transmission from a Coordinator to a Device (Fig: 2.8)

. The coordinator has data to be transmitted to the device.

. It indicates this in the pending address fields of its beacon.

. Devices tracking the beacons, decode the pending address fields.

. If a device finds its address listed among the pending address fields, it realizes it has data to bereceived from the coordinator.

. It issues a Data-Request Command to the coordinator.

. The coordinator replies with an acknowledgement.

. If there is data to be sent to the device, it would transmit the data.

. If acknowledgements are not optional, the device would respond with an acknowledgement.


Figure 2.8: Coordinator to Device

Transmission from a device to a coordinator (Fig: 2.9)

. The device first listens to the beacon.

. On finding the beacon, it synchronizes first to the superframe structure. This process lets it knowthe start and end time of the Contention access period.

. The device will now compete with its peers for a share of the channel.

. On its turn, it will transmit the data to the coordinator.

. The coordinator may reply back with an acknowledgement, if it is not optional.

Figure 2.9: Device to Coordinator

Transmission between two devices

There is no predefined manner in which there can be a direct communication between two devices in thenetwork. However, the suitable methods of transmission can be by mutual synchronization techniques,or direct transmission using unslotted CSMA-CA. But either technique has their downsides. The syn-chronization technique, even though look simpler is harder to implement. Similarly, direct transmissionmight degrade the throughput performance of the PAN. This can be an interesting topic for furtherresearch.

2.6 Summary 17

2.6 Summary

The chapter gives a brief overview of the various functional aspects of zigbee that are relevant in thecurrent project. The network topologies that are possible are the star, mesh and cluster-tree. Howeveronly the star topology is considered in this project. The network formation technique for the startopology is discussed. The functional overview of the IEEE 802.15.4 starting with the superframestructure, highlighting the active, inactive, CAP and CFP are presented graphically and the calculationof the superframe duration, the beacon interval, the slot duration, etc has been presented for a BO=8,and SO=7. The two transmission techniques, transmission from the coordinator to the node and fromthe node to the coordinator, for a beacon enabled network is presented. Also a brief study about thetransmission between two devices is presented.

Chapter 3

IEEE 802.15.4 Service Primitives[1]

3.1 Introduction

The services of a layer are the capabilities it offers to the user in the next higher layer or sublayer bybuilding its functions on the services of the next lower layer. This concept is illustrated in 3.1, showingthe service hierarchy and the relationship of the two correspondent N-users and their associated N-layer(or sublayer) peer protocol entities.

The services are specified by describing the information flow between the N-user and the N-layer. Thisinformation flow is modeled by discrete, instantaneous events, which characterize the provision of aservice. Each event consists of passing a service primitive from one layer to the other through a layerSAP associated with an N-user. Service primitives convey the required information by providing aparticular service. These service primitives are an abstraction because they specify only the providedservice rather than the means by which it is provided. This definition is independent of any otherinterface implementation.

Services are specified by describing the service primitives and parameters that characterize it. A servicemay have one or more related primitives that constitute the activity that is related to that particularservice. Each service primitive may have zero or more parameters that convey the information requiredto provide the service.

Figure 3.1: Service Primitive

A primitive can be one of four generic types:

. Request: The request primitive is passed from the N-user to the N-layer to request that a serviceis initiated.

18

3.2 PHY Primitives 19

. Indication: The indication primitive is passed from the N-layer to the N-user to indicate aninternal N-layer event that is significant to the N-user. This event may be logically related to aremote service request, or it may be caused by an N-layer internal event.

. Response: The response primitive is passed from the N-user to the N-layer to complete a proce-dure previously invoked by an indication primitive.

. Confirm: The confirm primitive is passed from the N-layer to the N-user to convey the results ofone or more associated previous service requests.

The IEEE 802.15.4 standard describes 14 PHY and 35 MAC primitives. The IEEE 802.15.4, WPANsupports two types of devices. The FFD and the RFD. The FFD is a full function devices supportingall the defined primitives of the standard. While, the RFD, is a reduced function device, degraded interms of functionality. It supports a subset of these primitives. A total of 38 primitives are supported byRFDs. A few of those primitives are described here which are quite frequently used and are implementedin the zigbee modules.

3.2 PHY Primitives

The primitives indicate the functions organized by each layer. The PHY layer is responsible for thefollowing tasks:

. Activation and deactivation of the radio transceiver

. Energy Detection

. Link Quality Indication Measurement

. Clear Channel Assessment

. Data Transmission and Reception


When ever there is data to be transmitted, the MAC layer Management Entity calls upon the PHYlayer with these primitives to transmit a data frame.

PD-DATA.request : The PD-DATA.request primitive is generated by a local MAC sublayer entityand issued to its PHY entity to request the transmission of an MPDU. Upon receiving the PD-DATA.request primitive, the PHY first constructs a PPDU with the supplied PSDU.

PD-DATA.confirm : The PD-DATA.confirm primitive is generated by the PHY entity and issued toits MAC sublayer entity in response to a PD-DATA.request primitive. The PD-DATA.confirmprimitive will return a status of either SUCCESS, indicating that the request to transmit wassuccessful, or an error code of RX ON or TRX OFF, indicating that the transceiver is working inthe Receiver mode or the transceiver is switched off.

3.2.2 Data Reception

This primitive is used by the PHY layer to notify the MAC layer of the reception of a data packet.

PD-DATA.indication : The PD-DATA.indication primitive is generated by the PHY entity and issuedto its MAC sublayer entity to transfer a received PSDU. This primitive will not be generated ifthe received PSDU Length field is zero or greater than aMaxPHYPacketSize.

3.2 PHY Primitives 20

3.2.3 Clear Channel Assessment

The following primitives implement the Clear Channel Assessment logic. When ever there is data tobe transmitted and the node need to compete with its peers using CSMA-CA, it must go through theCCA phase to ascertain if the channel is free/busy. This function is called upon by the MAC LayerManagement Entity.

PLME-CCA.request : The PLME-CCA.request primitive is generated by the MLME and issued to itsPLME whenever the CSMA-CA algorithm requires an assessment of the channel.

PLME-CCA.confirm : The PLME-CCA.confirm primitive reports the results of a CCA analysis.

3.2.4 Energy Detection

The following primitives are responsible for implementing energy detection of the channel. The MAClayer request for such a service and the PHY layer performs the Energy Detection and replies back withthe result of the operation.

PLME-ED.request : The PLME-ED.request primitive requests that the PLME perform an ED(EnergyDetection) measurement.

PLME-ED.confirm : The PLME-ED.confirm primitive reports back the results of the ED measurementto the MLME.

3.2.5 PAN Information Management

The following primitives are subsequently used by the MAC and the PHY layer entities to access aparticular PIB value, or either to set a value for a PIB property.

PLME-GET.request : The PLME-GET.request primitive requests information about a given PHY PIBattribute.

PLME-GET.confirm : The PLME-GET.confirm primitive reports the results of an information requestfrom the PHY PIB.

PLME-SET.request : The PLME-SET.request primitive attempts to set the indicated PHY PIB at-tribute to the given value.

PLME-SET.confirm : The PLME-SET.confirm primitive reports the results of the attempt to set aPIB attribute.

3.2.6 Activate/Deactivate Radio Transceiver

The following two primitives are responsible for implementing the function of activating and deactivatingthe transceiver.

PLME-SET-TRX-STATE.request : The PLME-SET-TRX-STATE.request primitive requests that thePHY entity change the internal operating state of the transceiver. The transceiver will have threemain states:

. Transceiver disabled (TRX OFF)

. Transmitter enabled (TX ON)

3.3 MAC Primitives 21

. Receiver enabled (RX ON)

PLME-SET-TRX-STATE.confirm : The PLME-SET-TRX-STATE.confirm primitive reports the resultof a request to change the internal operating state of the transceiver.

3.3 MAC Primitives

Similar to the PHY layer functions the MAC layer and its supported primitives are responsible for avariety of operations. Some of them are:

. Beacon Transmissions (for a Coordinator)

. Synchronization to the Beacons

. PAN Association/Disassociation

. CSMA-CA for Channel Access

. GTS transmissions

. Reliable Link Between two peer MAC entities


The following primitives are used for data transmission from the next higher layer. The result is indi-cated with confirm primitive. These responses are prepared with respect to its own requests for datatransmission to the PHY layer.

MCPS-DATA.request : Requests the transmission of a data unit from the local SSCS entity. It preparesthe corresponding MPDU from the incoming SPDU and this is passed on to the PHY layer fortransmission.

MCPS-DATA.confirm : Reports the result of the request for the transmission of an SPDU over to asingle peer SSCS entity.

3.3.2 Data Reception

The following primitives are used for data reception from the next lower layer(PHY). The PHY layerupon receiving a data packet informs the upper layer, with an indication about the received packet.And the MAC layer, after analyzing the indication primitive fields, informs the local SSCS entity of anincoming packet data frame, unless it is intended for itself.

MCPS-DATA.indication : The MCPS-DATA.indication primitive indicates the transfer of a data SPDU(i.e., MSDU) from the MAC sublayer to the local SSCS entity. This indicates the arrival of datafrom the peer SSCS to the local SSCS entity.

3.3 MAC Primitives 22

3.3.3 Association

The primitives that are used to associate a network node or to provide association services, as applicableto a coordinator, are presented here.

MLME-ASSOCIATE.request :The MLME-ASSOCIATE.request primitive allows a device to requestan association with a coordinator. The association request is generated at the next higher layer,(generally the routing layer), however it is not part of this study. The conditions that determinethe invoking of the association phase is not defined.

MLME-ASSOCIATE.indication :Indicates the reception of an association request command.

MLME-ASSOCIATE.response :This primitive is used to initiate a response to an MLME-ASSOCIATE.indication primitive.

MLME-ASSOCIATE.confirm :The MLME-ASSOCIATE.confirm primitive is used to inform the nexthigher layer of the initiating device whether its request to associate was successful or unsuccessful.

3.3.4 Disassociation

Similar to the primitives described for the association phase, the following primitives are used for thedisassociation. Their functionality is exactly inverse to that of their counterparts for the association.

MLME-DISASSOCIATE.request

MLME-DISASSOCIATE.indication

MLME-DISASSOCIATE.response

MLME-DISASSOCIATE.confirm

3.3.5 PAN Information Management

The following primitives are used to request and to reply back with information about a particularMAC PIB Value.

MLME-GET.request :The next higher layer issues this primitive to the MAC layer to request informa-tion about a particular, MAC PIB.

MLME-GET.confirm :This primitive is used by the MAC layer to reply back to the MLME-GET.request primitive received to it by the next higher layer.

MLME-SET.request :Request to set the indicated MAC PIB with the passed value.

MLME-SET.confirm :Returns the result of an attempt to set the indicated PIB value.

3.3.6 Orphaning

MLME-ORPHAN.indication :A primitive to indicate to the next higher layer of the presence of anorphan device in the network.

MLME-ORPHAN.response :It helps the next higher layer to respond to the MLME-ORPHAN.indication message by the MAC layer. It indicates if the node in question is associatedto the network.

3.4 Summary 23

3.3.7 Receiver Maintainence

The following primitives are used to maintain the receiver enable time.

MLME-RX-ENABLE.request : The next higher layer requests the MAC for the Receiver to be enabledfor a finite amount of time.

MLME-RX-ENABLE.confirm : It reports the result of an attempt to enable the receiver.

3.3.8 Channel Scanning

These primitives are used to scan the communication channels to determine the presence or absense ofPANs.

MLME-SCAN.request :The MLME-SCAN.request primitive is used to initiate a channel scan over agiven list of channels. A device can use a channel scan to measure the energy on the channel,search for the coordinator with which it is associated, or search for all coordinators transmittingbeacon frames within the POS of the scanning device.

MLME-SCAN.confirm :It reports back to the next higher channel of the result of the channel scan.

3.4 Summary

Primitives are functions offered by each layer. The four generic types of a primitive are Request, Indi-cation, Response, and Confirm. The PHY layer is responsible for tasks like activating/deactivating thetransceiver, CCA, ED, LQI management, Data transmission and reception. The primitives responsiblefor each of the above described mechanisms are presented and are explained in brief. The PHY primi-tives are followed by the MAC primitives. These primitives are used to better understand the softwareimplementation of the zigbee modules which follow in the next chapter.

Chapter 4

The Simulation Environment

4.1 Introduction[10][11]

NS (Version-2) is an object oriented, discrete event simulator, developed under the VINT project as ajoint effort by UC Berkeley, USC/ISI, LBL, and Xerox PARC. It was written in C++ with OTcl as

a front-end. The simulator supports a class hierarchy in C++ (compiled hierarchy), and a similar classhierarchy within the OTcl interpreter (interpreted hierarchy). The two hierarchies are closely relatedto each other; from the user’s perspective, there is a one-to-one correspondence between a class in theinterpreted hierarchy and one in the compiled hierarchy.

The network simulator uses two languages because simulator has two different kinds of things it needsto do. On one hand, detailed simulations of protocols requires a systems programming language whichcan efficiently manipulate bytes, packet headers, and implement algorithms that run over large datasets. For these tasks run-time speed is important and turn-around time (run simulation, find bug, fixbug, recompile, re-run) is less important.

On the other hand, a large part of network research involves slightly varying parameters or configura-tions, or quickly exploring a number of scenarios. In these cases, iteration time (change the model andre-run) is more important. Since configuration runs once (at the beginning of the simulation), run-timeof this part of the task is less important.

ns meets both of these needs with two languages, C++ and OTcl. C++ is fast to run but slower tochange, making it suitable for detailed protocol implementation. OTcl runs much slower but can bechanged very quickly (and interactively), making it ideal for simulation configuration. ns (via tclcl)provides glue to make objects and variables appear on both langauges.

The tcl interface can be used in cases where small changes in the scenarios are easily implemented.Similarly, the C++ code can be changes when processing of all incoming packets are done, or whenchanges in the behavior of the protocol is anticipated.

In ns, the advance of time depends on the timing of events which are maintained by a scheduler. Anevent is an object in the C++ hierarchy with an unique ID, a scheduled time and a pointer to an objectthat handles the event. The scheduler keeps an ordered data structure, with the events to be executedand fires them one by one, invoking the handler of the event.

24

4.2 Simulator Overview 25

4.2 Simulator Overview

The simulator is initialized using the TCL interface. It is in this file that a new simulation object iscreated and several tcl commands relating to the network formation and its properties are added. Whena new simulation object is created, the initialization procedure performs the following tasks:

. initializes the packet formats

. create a scheduler

. create a null agent

Packets may be handed to NsObjects at scheduled points in time since a node is an event handlerand a tasks performed over a packet is an event. Tasks over a packet should be the only type of eventscheduled on a node. The initialization of the packet formats will set up the field offsets used for theentire simulation.

The scheduler is an event driven time management mechanism, which launches the earliest scheduledevent, executing it to completion and returning back to execute the next event. An event comprises ofthe time at which it need to be launched along with a handler function. One property of the schedulerto be noted here is when two or more events occur at the same time (meaning, they have to be executedat the same time). Under these circumstances it would decide the precedence based on the order inwhich they have been scheduled.

A null agent is created to act as a sink for packets, both successfully transmitted and dropped. Packetsthat are dropped for any reason, or the packets that are not intended to be counted, and the packets thatreach the destination node successfully are destined for this agent. The primary part of the simulator isthe scheduler which would execute the events at their start times. This is the primary function whichforms the root of a tree of other dependent functions. The execution of a branch of this tree of eventsand their functions would produce an effect of simulating the network behavior.

Given below is a source snippet of the “run” function of the scheduler. Its function is to extract thenext event from the heap and dispatch it for execution. Dispatch a single simulator event by setting thesystem virtual clock to the event’s timestamp and calling its handler.

void Scheduler::run(){

instance_ = this;Event *p;while (!halted_ && (p = deque())) { // Extract the next event

dispatch(p, p->time_); // Dispatch the event.}

}

Dispatch is a single simulator event by setting the system virtual clock to the event’s timestamp andcalling its handler. Some important models implemented in ns-2 are described here.

Queue ModelThe following code block defines the queue class which implements the queuing mechanism.

class Queue : public Connector {public:virtual void enque(Packet*) = 0;virtual Packet* deque() = 0;

4.2 Simulator Overview 26

void recv(Packet*, Handler*);void resume();int blocked();void unblock();void block();protected:Queue();int command(int argc, const char*const* argv);int qlim_; /* maximum allowed pkts in queue */int blocked_;int unblock_on_resume_; /* unblock q on idle? */QueueHandler qh_;};

The enque and the deque functions are called to add a packet to the queue or to remove a packet fromthe queue, when its ready for transmission. The resume function is used to revert back to the unblockedstate. The qlim variable is used to specify the maximum queue length. However the class is responsiblefor buffer management and scheduling, and the low level functioning is performed by the class packetqueue.

Energy ModelThe task of the energy model is to maintain the updated energy content of a node. A class defining theenergy model is produced here.

class EnergyModel : public TclObject {public:EnergyModel(double energy) {energy_ = energy;}inline double energy() {return energy_;}inline void setenergy(double e) {energy_ = e;}virtual void DecrTxEnergy(double txtime, double P_tx){ energy_ -= (P_tx * txtime); }virtual void DecrRcvEnergy(double rcvtime, double P_rcv){ energy_ -= (P_rcv * rcvtime); }protected:double energy_;};

The energy model is implemented pretty simply in NS-2. The function, setenergy is used to initializea node with initial energy content. The double variable, energy holds the current energy level. Afterevery packet transmission or reception the energy content is decreased. The time taken to transmit orreceive along with the power consumed for transmission or reception of a bit/byte of data is passesas parameters to the functions, DecrTxEnergy and DecrRcvEnergy respectively. And these functionswould thus decrease the energy content of the node. Given the simplicity of the implementation of theenergy model, the results thus obtained by simulations can be quite accurate, as long as the powerconsumed by transmission/reception of a bit/byte of data is correct.

The simulator needs the tcl scenario file as input. So the intended scenario of the network is presentedas a sequence of tcl commands which are fed to the network simulator, and the simulator produces theresultant network performance analysis in two separate files. They are:

4.3 The Network Animator 27

Trace File (*.tr) : The trace file contains information about the various events that occurred duringthe simulation duration. It contains every detail of node behavior, packet transmissions and re-ceptions, packet type, layer responsible for communication, drops and reasons for drops, energyconsumption, etc, to the utmost possible precision.

NAM Trace file (*.nam) : The network animator trace file contains information about topology, e.g;nodes, links, as well as packet traces. It can be said as a mirror of the trace file, with the exceptionthat it uses a different syntax to work with the visualize.

4.3 The Network Animator

The network simulator (ns) comes along with an interesting tool, called the Network Animator (NAM ).Nam is a Tcl/TK based animation tool for viewing network simulation traces and real world packettrace data. The design theory behind nam was to create an animator that is able to read large animationdata sets and be extensible enough so that it could be used in different network visualization situations.Under this constraint nam was designed to read simple animation event commands from a large tracefile. In order to handle large animation data sets a minimum amount of information is kept in memory.Event commands are kept in the file and are read from the file whenever necessary. A snapshot of NAMin action is presented in figure 4.1.

Figure 4.1: NAM Snapshot

4.4 Process Structure

The following passages describe the simulation structure, to generate the final statistics. Several scriptsand programs have been designed for this project to generate the results. This section of the documen-tation concentrates in explaining these programs, the passed parameters, in detail and the organizationof the programming structure to create the simulation environment which would generate graphableresults. The figure 4.2 explains the inter dependency of the scripts and programs of the simulationenvironment.

4.4 Process Structure 28

Figure 4.2: Process Structure

4.4.1 Autosim

. Parameters: It accepts the following command line options.

– autosim [868/24]868: Indicates that the simulation is carried for the radio frequency of 868Mhz.24: Indicates the simulation frequency, as 2.4Ghz.

. Functionality: The autosim program is a simple application with a purpose of automating thesimulation process. If a report need to produce conclusive results, they should be generated ina random fashion taking the mean of several results. However since doing this manually is notpossible an idea of an application which is capable of doing this automatically has been conceived.This application is capable of generating a new seed value for each simulation, choosing the nextdatarate to be simulated, creating the respective traffic file for the current seed and datarate,taking a backup of the traffic files, choosing the right simulation path and network scenario fileand finally conducting the simulation for the current RNG seed.

The frist step in operating the autosim application, is creating the file, parameters.txt, which holdsall the simulation parameters. Its contents include, the number of simulations to be performed, theparameters for the traffic generation, the number of datarates and correspondingly, the dataratevalues for which simulation is to be performed.

The seed for the random number generator is chosen as the simulation iteration number. Hence ifthe simulation is conducted for hundred number of times, the seed value ranges anything betweenone to hundred, based on the current iteration number.


This application is designed to support either frequency band operations. Specifying the frequencyof operation of the PAN would allow it to use the right simulation source file (*.tcl).

The program is also responsible for choosing the right simulation path and the source file (*.tcl)containing the network scenario and settings, and executing it with ns.

. Working: Upon starting the application with a command like, say, autosim 868, we tell theprogram to simulate for the frequency band of 868Mhz. This would allow it to choose wpan868.tclas the input to the simulator, and then generates the traffic file, makes a copy of it in the directory,dir traffic for later reference, saves the current seed value in the temporary file, current seed.txtand finally executes the simulation.

4.4.2 wpan.tcl

The wireless PAN(*.tcl) file contains parameters and variables which help change the network scenarioand settings and control the simulation process. Settings like, channel type, propagation model, queuelength, node starting time, beacon order, superframe order, start and stop time of the simulation, filecontaining the current seed value, antenna height, and several other parameters specific to WPANsimulations are referred as TCL commands. The file also creates the scenario file using the utility,scen gen. It also contains commands (which can be enabled/disabled) to start the network animator,and scripts analyzing the trace file, after the simulation.

This file is fed to the network simulator, which would generate additional files, for tracing. The analyzingscript file (avg throughput.awk) takes the trace file as input and writes its results into custom files, whichare again used for further processing.

4.4.3 scen gen

. Parameters: It accepts the following command line parameters

– scen gen [number-of-nodes] [X-Pos-of-coord] [Y-Pos-of-coord] [Personal-Operating-Space]number-of-nodes: Number of nodes to be placed around the coordinator.X-Pos-of-coord: X position of the coordinator, with respect to the area of the network di-mensions.Y-Pos-of-coord: Y position of the coordinator, with respect to the area of operation of thenetwork.Personal-Operating-Space: The operating space or the reachabilitiy of the coordinator. Thenodes are required to be placed equidistantly around the coordinator, for the test scenariosin this report, within the operating space of the coordinator, this parameter is utilized toarrange the nodes along an imaginary circle drawn around the coordinator with this valueas radius.Example: scen gen 11 25 25 10

– scen gen [?/help]The help/usage messages.

. Functionality: This utility would automatically generate the coordinates of the nodes to placethem around the coordinator, along an imaginary circle drawn with a radius equal to the PersonalOperating Space.

. Working: Running the utility would create a file, wpan.scn, to be used by the source scenariofile, wpan.tcl. The resultant position file for the nodes would like some think like this:


Figure 4.3: Node placement by scen gen

4.4.4 wpan.scn

It is the node position file, holding the positions of all the nodes around the coordinator. Currently thisfile is being generated with the utility, scen gen. However, it is a simple text file, which can be easilyedited to place the nodes at desired positions. Note that the positions of the nodes should respect theboundaries of the network mentioned in the source file, wpan.tcl

4.4.5 cbrgen star

. Parameters:

ns cbrgen star.tcl [-type cbr—tcp] [-nn nodes] [-seed input-seed] [-mc max connections] [-ratedatarate] [-starttime st][-timegap tg]

type: Traffic type (cbr/tcp)

nn: Number of nodes in the scenario

seed: Seed to the RNG to generate a random traffic pattern

mc: Maximum Number of traffic flows

rate: Traffic rate in kbps

starttime: The time at which the first traffic flow would start

timegap: The time gap with which other traffic flows would start with respect to the first trafficflow.

. Functionality: It is a tcl script file, capable of generating a random traffic scenario between nodes.This particular program is a modified version of the original script file, specifically designed for astar topology. The primary modification has been in the way communication direction is defined.Since a star topology cannot support communication between two nodes (none of them being acoordinator), the script file has been modified to produce only communication between a nodeand a coordinator. Another version of the program, extensively used for several experiments inthis project, is available, to generate communication between a node and the coordinator, withcoordinator always being the destination.

. Working: Running this script file would generate the desired traffic scenario which can be alter-natively be piped to a file, to be used with, wpan.tcl.

4.4.6 avg throughput.awk

. Parameters: The script file need to be parsed with a trace file to generate the analyzed results.

awk -f avg throughput.awk [Trace-File]

4.5 Result Analysis 31

. Functioning: The script file currently supports generating the following performance metrics.

1. Throughput

2. Minimum Delay

3. Maximum Delay

4. Average Delay

5. Data Packets Transmitted

6. Data Packets Successfully Received by their Respective Destinations

7. Data Packet Delivery Ratio

8. Average Initial Energy

9. Average Energy Used

10. Average Percentage Energy Used

11. Node Packet Discrepancy Ratio

12. Packet Drop statistics

. Working: Executing the script would generate these metrics, which can be alternatively pipedto a file for further reference.

4.5 Result Analysis

The process structure defined so far would generate the required files that can be used to produce finalanalyzed results. It has been observed that because of the discrepancy in the device starting time andthe time at which traffic for a particular node is started, there are segmentation faults, which result ina failed simulation for a particular seed value. It is to be realized that each seed value would generatea new scenario, which would influence the association phase of the network. In some cases, all devicesare associated pretty quickly as soon as they are started, and before they could act as traffic source ordestination. However, in cases when the traffic start time is early such type of situations might arise.But these situations can be eliminated by keeping the traffic start time considerably farther than thestart time of the node leaving enough room for the devices to successfully associate to the network.But contemplating future situations this utility has been designed to eliminate unsuccessful simulations,and generate the average results. The figure 4.4 depicting the structure and the inter dependencies onvarious files to generate the final analyzed results is presented.

4.5.1 Analyze

. Parameters: The analyze utility can parsed with the following parameters.

– analyze [?/help]Help Menu

– analyzeDefault analysis, taking ideal simulations as 100 and maximum simulations to be 135.

– analyze [ideal num sims] [max num sims]Analysis, giving an opportunity to specify the ideal and the maximum number of simulations.

4.6 zigbee Software Modules 32

Figure 4.4: Analysis Structure

. Functioning: Analyze is the utility designed to produce the average values of the metrics forall the simulations. These files contain the simulations that were successful. It is customary tosimulate a particular scenario for more than the required number of seed values. This would giveroom for unsuccessful simulations to be deleted from the final analysis. The analyze utility wouldjust do that. From the input files, it eliminates the seed values for which simulation has beenunsuccessful and rewrites the other simulations to the required/ideal number, into the two outputfiles. If in a particular case, the ideal number of simulations are 100, and we have simulated thescenario for 135, we would have at least 35 extra simulations as backup incase any of the first 100simulations have failed due to segmentation faults. The remaining seed values which have beenleft over after filling up the failed simulations are dropped from analysis.

. Working: It takes the files, performance.txt, and drops.txt as input and generates the followingfiles as output.

1. new performance868.txt

2. new drops868.txt

The working of the utility can be summed up in two steps. In the first step, the program wouldeliminate the unwanted simulations and generate the new performance and drop files and laterwould present these new files to a few other script files which are required to be present in thecurrent working directory.

These script files are awk scripts, used to find the average of the entries of the new performanceand drop files, in column wise. As a result the following files are created, which would hold thefinal graphable results.

1. final graphs 868.txt

2. final drops 868.txt

4.6 zigbee Software Modules

The zigbee modules used in this project have been jointly developed by The City College of New Yorkand Samsung Advanced Institute of Technology, USA. These software modules can be downloaded fromthe following location [12]. Since the standard defines only the MAC and the PHY layer, the interface


to higher layers has been provided with intermediate sub-layer just above the MAC, called the SSCS(Service Specific Convergence Sublayer). Since a full description of the upper layers will be redundant,the SSCS would act as source and destination for the data.

The source code has been adopted with minor modifications to suite the requirements of this project.The changes made are highlighted in the following sections. Firstly, given an introduction of the variousprimitives in chapter-3, the following section refers to the software implementation of these primitivesto give a brief idea of how the functions behave with each other to communicate to its peer node as anentity.

When the simulation is started, the first task of the scheduler is to schedule the events that are alreadypredefined by the user in the scenario file. Thus ns TCL commands from the scenario file are scheduledfirst. Events like creating a new simulator object, starting nodes/traffic, node configuring, etc can bepredefined, hence are scheduled first. A few scheduled events are given below.

set ns_ [new Simulator]$ns_ trace-all $tracefd$ns_ puts-nam-traceall {# nam4wpan #} ;# inform nam that

;# this is a trace;# file for wpan (special;# handling needed)

# nodechange$ns_ at 0.0 "$node_(0) NodeLabel PAN Coor"$ns_ at 0.0 "$node_(0) sscs startPANCoord 1 3 3"

;# startPANCoord <txBeacon=1> <BO=3> <SO=3>

The coordinator of a network is switched ON with the following command. It is used to specify a startingtime for the device, along with other initializing parameters such as Beacon order, Superframe order,Beacon Transmissions, etc.

$ns_ at 0.0 "$node_(0) sscs startPANCoord 1 3 3";# startPANCoord <txBeacon=1> <BO=3> <SO=3>

This function is directed to the source file corresponding to the sscs layer and the commands from thetcl script functions are decoded in the function, int SSCS802 15 4::command, which would extract thecommands and the parameters passed and finally the function responsible to start the coordinator voidSSCS802 15 4::startPANCoord is parsed with these parameters and executed. The function determinesthe current ’step’, based on a set of predefined steps, as in here are the steps corresponding to startingthe coordinator and the step responsible to start the other devices. In the first step, it would enable itsfeatures, like setting the BO and SO, authority to transmit beacons, assigning a macShortAddress toitself, and finally scanning the channels to establish a network.

In the first steps of formation of a network, it would save its short address to the PIB attributevalue, macShortAddress, by calling the function, Mac802 15 4::MLME SET request. The functionMac802 15 4::MLME SET confirm would confirm the status of the attempt to write the MAC PIBvalue, replying with either a success or a failure with an appropriate reason. The node would then callon the function, Mac802 15 4::MLME SCAN request to perform a scan of all the supported channelseither actively or passively and associate to a channel to establish a PAN network. Again the channelscan mechanism is carried out in a linear fashion. In the first step, beacon transmissions are disabledby setting the BO to 15, and ending any running CSMA-CA sessions. This is followed by the scanningmechanism based on the scan type chosen which is passed as parameter to the function. The scan typechosen can be any of the following:


. ED Scan

An ED scan allows a device to obtain a measure of the peak energy in each requested channel.The MLME notes the maximum energy measurement and moves on to the next channel in thechannel list.

. Active/passive Scan

An active scan is used by an FFD to locate all coordinators transmitting beacon frames within itsPOS. The active scan is performed on each channel by the MLMEs first sending a beacon requestcommand, and recording the information contained in each received beacon in a PAN descriptorstructure. A passive scan, like an active scan, is used to locate all coordinators transmittingbeacon frames within the POS of the scanning device; the difference is that the passive scan is areceive-only operation and does not transmit the beacon request command. It records informationcontained in each received beacon in a PAN descriptor structure.

. Orphan Scan

An orphan scan is used to locate the coordinator with which the scanning device had previouslyassociated. The orphan scan is performed on each channel by the MLME first sending an orphannotification command. The MLME then enables its receiver for at most aResponseWaitTimesymbols. If the device receives a coordinator realignment command within this time, the MLMEwill disable its receiver. Otherwise, the scan is repeated on the next channel in the channel list.

Once the scantype is resolved, the scanning mechanism is achieved through again as a se-ries of steps. In the first step PIB attribute value for the supported channels is requested us-ing the function, Phy802 15 4::PLME GET request, which is later confirmed using the functionPhy802 15 4::PLME GET confirm. It would assign a macPANId of “0xffff” to itself, indicating it is notyet associated. It would also initialize the variables for scan duration, current channel being scanned,number of scanned channels, etc. The current channel being scanned is saved in the PIB attribute value,phyCurrentChannel to indicate that all further transmission and receptions can be carried out in thischannel, using the function, Phy802 15 4::PLME SET request. The function, would test the validity ofthe channel by passing it to the function, Phy802 15 4::channelSupported. The result of this attempt towrite a PIB attribute value is verified by the function, Mac802 15 4::PLME SET confirm.

The function would then call on, Mac802 15 4::dispatch, which handles the control to the procedure,Mac802 15 4::mlme scan request. This function call would resume the other steps of the scanning mech-anism. The next step being step-1, where the scan mechanism for the active and passive scan is im-plemented. The part of code executed depends on the type of scan mechanism. For an active scan thepart of code issuing a data-request command is implemented, however, for the passive scan type thereis no need for a data-request command. It listens for any beacon transmissions in the current channelof operation, by setting its transceiver to the receiver mode. This is implemented using the function,Phy802 15 4::plme set trx state request by passing on the parameter, p RX ON. When the node is op-erating in the active scan mode, it would wait for its turn to transmit using CSMA-CA and issue adata-request message. One important function that can be mentioned here which is used for a clearchannel assessment is the Mac802 15 4::csmacaBegin. This would mark the completion of step-1 andthe control would now move back to the calling function.

A graphical view of the above program control flow is presented in the following picture. It is to beunderstood that only a branch of several such program flows is presented in the figure 4.5.

4.7 Software Modifications 35

Figure 4.5: Program Flow

4.7 Software Modifications

Several modifications have been done to the original source code to personalize the code to ZMD’sTransceiver. The source code depends on the way, data is interfaced. If data is passed directly from theupper layers (SSCS, for example), the behavior of the code has been in accordance with the protocol.However, it is always not possible to send data directly from the upper layers. Frequent changes inthe traffic parameters make this a non-idealistic way of dealing with the situation. Hence, using the


NS-2 data interface to use external data generators, helps in these situations. But, this revealed severalproblems which are discussed in the following sections. Similarly, problems like Radio frequency selec-tion, number of scanning channels, triggering of unwanted routing mechanism and address resolutionfor star topologies, improper messing up of EDThresh (used for Energy Detection mechanism) andCSThresh (Used for Carrier Sensing) are some of the other problems that are dealt in this section.The section highlights these problems in detail and highlights the changes made to the source code toeliminate or move around these problems.

4.7.1 Energy Detection Threshold

The receiver ED measurement is intended for use by a network layer as part of a channel selectionalgorithm. It is an estimate of the received signal power within the bandwidth of an IEEE 802.15.4channel. During the Clear Channel Assessment procedure for the CSMA-CA algorithm, using mode-1, use the ED measurement to determine the status of the channel. The Energy Threshold value,EDThresh comes into play as a reference. Thus, any ED measurement which is above the EDThreshvalue shall indicate the channel is busy, and value less than the EDThresh shall indicate a free medium.Similarly the CSThresh indicates the carrier sensing ability of a node. It is the least power signal ofthe incoming signal that the receiver can detect. However, in the source code, the EDThresh is nevermentioned and the CCA mechanism in turn uses CSThresh as the threshold to assess a clear channel,which is prone to misunderstandings and confusion. It does not provide a meaningful and understandabledistinction between the CSThresh and EDThresh .

The confusion cannot be understood until we realize the significance of EDThresh and CSThresh .According to the standard, EDThresh is atmost 10dB above the Receiver sensitivity. But, the carriersense threshold, CSThresh , is chosen based on the Personal Operating Space of the devices. And insome cases, the receiver may not be sensitive enough, hence is very likely the RXThresh to be abovethe CSThresh . Following the original code might allow an error free operation as long as the receiversensitivity is same as the carrier sensing capability of the device and also when assumed that theEDThresh is same as RXThresh . Its true that these conditions are difficult to implement. Hence,separating the dependence of EDThresh on CSThresh would give a better control on the architecture.

The following modification is implemented to incorporate EDThresh , separating it from CSThresh . Butan ideal implementation would be to modify the ’mac’ layer files to incorporate the variable individually,which would allow EDThresh to be specified as a TCL command in the scenarios. However, this is amuch easier method of implementation. An important fact to be remembered here is that, the EDThreshis assumed to be 10dB above the RXThresh . Modifiy the variable, ’aboveRxThresh’ to set it to othervalue.

Function: Phy802 15 4::CCAHandlerAdd the following code at the start of the function.

// (aboveRxThresh)dB above RxThresh_int aboveRxThresh = 10;// Convert RxThresh_ to dBmdouble RxindBm = 10 * log10(RXThresh_ * 1000);// EDThresh_ in dBmdouble EDThreshIndBm = RxindBm + aboveRxThresh;// EDThresh_ in Watts.double EDThresh_ = pow(10.0, EDThreshIndBm/10.0) * 0.001;

Also modify,

t_status = (rxTotPower[ppib.phyCurrentChannel] >= CSThresh_)?p_BUSY:p_IDLE;


to,

t_status = (rxTotPower[ppib.phyCurrentChannel] >= EDThresh_)?p_BUSY:p_IDLE;

and,

t_status = ((rxTotPower[ppib.phyCurrentChannel] >=CSThresh_)&&(rxTotNum[ppib.phyCurrentChannel] > 0))?p_BUSY:p_IDLE;

to,

t_status = ((rxTotPower[ppib.phyCurrentChannel] >=EDThresh_)&&(rxTotNum[ppib.phyCurrentChannel] > 0))?p_BUSY:p_IDLE;

4.7.2 TxOptions

The MAC sublayer builds an MPDU to transmit from the supplied arguments. The TxOptions param-eter indicates how the MAC sublayer data service transmits the supplied MSDU.

0x00 −→ DirectTransmission −→ Endnodes0x02 −→ GTStransmission −→ Coordinator/Endnodes0x04 −→ indirecttransmission −→ Coordinator

If the TxOptions parameter is equal to 0x00, indicating a direct transmission, the MAC-Sublayer trans-mits the MPDU simply by competing for its turn to transmit using slotted CSMA-CA in the CAP fora beacon-enabled PAN or unslotted CSMA-CA for a nonbeacon-enabled PAN.

If the TxOptions parameter specifies that a GTS transmission(0x02) is required, the MAC sublayer willdetermine whether it has a valid GTS. If the device is a PAN coordinator, it will determine whetherit has a receive GTS with the device with the given destination address. If a valid GTS could not befound, the MAC sublayer will issue the MCPS-DATA.confirm primitive with a status of INVALID GTS.If a valid GTS was found, the MAC sublayer will defer, if necessary, until the GTS. At this time, theMAC sublayer transmits the MPDU without using CSMA-CA, provided that the entire transmissionand acknowledgment, if requested, can be completed before the end of the GTS.

Similarly a value of 0x04, indicates an Indirect transmission of the MPDU. Generally its a transmissiontype that is only possible by a coordinator. The coordinator intimates the nodes which have data toreceive, in the pending address fields of the beacon. A node upon reception of the node, checks thepending address fields and upon finding its address mentioned, prepares a DataRequest message andtransmits it to the coordinator. The coordinator on receiving the datarequest message, acknowledgeswith an acknowledgement message and if the node has data to be sent, sends the data, using CSMA-CA.

Also, the TxOptions parameter can be used to specify, security, which is not implemented in the code,yet and hence is not considered any further.

The implementation of the TxOptions parameter (referred as txoption in the source code), allows tochoose the transmission type based on the node in consideration. However, as said earlier, it is notpossible to control this parameter when a data generator, like a cbr, tcp or a poisson, is interfaced toNS-2 to generate traffic automatically. The data needs to be passed from the upper layer, which in thiscase is the SSCS. The code is written to assume a default value of 0x00 for data transmission. So thefollowing modification in the function, ”Mac802 15 4::recv” has been done to choose the right txoptionvalue based on the node type. However, support for GTS transmission type is not yet implemented.

Function: Mac802 15 4::recv

Replace,


txop |= Mac802_15_4::txOption;

with,

if (capability.FFD&&(numberDeviceLink(&deviceLink1) > 0))txop |= 0x04;

elsetxop |= 0x00;

4.7.3 Radio Frequency Selection

The source code inherently supports the 2.4Ghz of operation. Since the frequency mode of operationfor our current study is 868Mhz, the following modification, has been implemented to choose the rightfrequency band.

Function: SSCS802 15 4::startPANCoord The following lines need to be commented. Presence of thesecode lines prevent scanning the channels ranging from 0-10, which are the supported by the 868 and914Mhz, frequency band. The code allows scanning of channels from 0-10, only in the absence of afree channel to establish a PAN, in the range of 11-27. However, working in the current scenario, suchsituations are remote, because the focus of this study is only a standalone star network topology.

// for (i=11;i<27;i++)// if ((T_UnscannedChannels & (1 << i)) == 0)// break;// if (i >= 27)

4.7.4 Number of Scanned Channels

A device working in the 868Mhz or the 914Mhz frequency band, the number of channels supportedare 11, together for the 868 and the 914 Mhz bands, a node should scan all of these channels to eitherassociate to a PAN or to establish one. However, since we only simulate a standalone network, withoutany alien devices present in their vicinity, we limit the number of scanning channels to 3. It is to benoted that this change does not fix any bug in the code, but is implemented only to save simulationtime. Also to be noted that, this would give a wrong idea about the association time of the devices. Thischange need to be taken into consideration before working with association/orphan-scanning times.

File: p802 15 4sscs.cc

// Scan the first three channels. 0, 1 and 2.UINT_32 SSCS802_15_4::ScanChannels = 0x0007

4.7.5 Channels Supported

The number of channels supported is indicated by the parameter, def phyChannelsSupported in thefile, p802 15 4const.h.

File: p802 15 4const.h

#define def_phyChannelsSupported 0x07ff


4.7.6 Passive Scan Support

The code does not provide support for passive mode of scanning. The following modifications in theirrespective indicated locations would implement it.

Function 1: SSCS802 15 4::MLME SCAN confirmModify,

//Including Passive scantypeif (ScanType == 0x01)

dispatch(status,"MLME_SCAN_confirm");

to

//Including Passive scantypeif (ScanType == 0x01 || ScanType == 0x02)

dispatch(status,"MLME_SCAN_confirm");

Function 2: Mac802 15 4::scanHandlerModify,

if (taskP.mlme_scan_request_ScanType == 0x01)taskP.taskStep(TP_mlme_scan_request)++;

to,

if ((taskP.mlme_scan_request_ScanType == 0x01) || (taskP.mlme_scan_request_ScanType == 0x02))taskP.taskStep(TP_mlme_scan_request)++;

4.7.7 Routing

Routing is a method of determining routes to nodes to which information is due for transfer. Therouting mechanism is guided with routing tables, which holds the best path to the destination node.These tables might have a direct path to the destination or a path to the nearest node, which canforward the information further, thus bridging the route to the destination node. A node which hasdata to be transmitted to a destination node, first looks up into its routing table, to determine if a pathto the destination is available. If yes, it would go ahead with the transmission to the next nearest nodein the path or may transmit a Route Request message to determine a route to the node.

However, a simple STAR topology with one way communication with the coordinator doesn’t requirepassing through the routing mechanism. Yet, we use the AODV routing in the scenarios. Since therecan be no forwarding of data in an IEEE 802.15.4 STAR topology, the next hop to the destinationwould be the destination itself. Hence there is no need for any determination if an entry of the path ismissing in the routing table. Information can be directly sent without any lookup, being assured it issent in the right path. Given this explanation, the routing table lookup and route finding mechanism isconsidered, unnecessary. Hence the following changes are made to prevent calling the resolve procedurefor route finding, hence always assuming the route is present in the routing table. And finally, fillingthe next hop address for the node same as the destination. It is to be noted that these changes doesnot support other topologies which need route resolution.

Function: AODV::recvReplace,


if ( (u_int32_t)ih->daddr() != IP_BROADCAST)rt_resolve(p); // Check of route is present

elseforward((aodv_rt_entry*) 0, p, NO_DELAY);

with,

if ( (u_int32_t)ih->daddr() != IP_BROADCAST)forward((aodv_rt_entry*) 1, p, NO_DELAY); //Always assume route is present.

elseforward((aodv_rt_entry*) 0, p, NO_DELAY);

Function: AODV::forwardComment the following lines.

// if(ih->ttl_ == 0) { // Drop the packet if its Time To Live is expired.//#ifdef DEBUG// fprintf(stderr, "%s: calling drop()\n", __PRETTY_FUNCTION__);//#endif // DEBUG// drop(p, DROP_RTR_TTL);// return;// }

Replace,

assert(rt->rt_flags == RTF_UP);rt->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT;ch->next_hop_ = rt->rt_nexthop;

with,

// assert(rt->rt_flags == RTF_UP);// rt->rt_expire = CURRENT_TIME + ACTIVE_ROUTE_TIMEOUT;ch->next_hop_ = ih->daddr();

4.7.8 Address Resolution

The address resolution protocol is used to resolve the MAC addresses from the IP address. If the nodehas a mapping of the IP address to the MAC address, it would use it, but if its ARP table does not havean entry of the ARP of a destination node, it issues the ARP request with the IP address of destination.Nodes receiving it, respond with the MAC address of the node, if they have one. And, again as in thecase of routing, given the minimal requirements of a STAR topology, an ARP message seeking the MACaddress of the destination is unnecessary.

The function, arplookup() is called each time there is a packet to be transmitted. When there is noentry for the destination, the function is originally designed to return 0. And the calling function,arpresolve(), is supposed to send the arp request messages. But since we want to disable any requestmessage transmission, we make changes to give an impression that an address mapping is always presentin the arp table.

Reformat the function, ARPTable::arplookup, as in the following:

Function: ARPTable::arplookup

4.8 Simulation Parameters 41

ARPEntry* ARPTable::arplookup(nsaddr_t dst){ARPEntry *a;// If a match is found, use it.for(a = arphead_.lh_first; a; a = a->nextarp()) {if(a->ipaddr_ == dst)return a;}// The following change applies when no arp entry is found. We simply make a// new entry and enable it by setting the up_ flag, assign the mac address of// the destination same as the IP Address, and finally return the object.a = new ARPEntry(&arphead_, dst);a->up_ = 1;a->macaddr_ = dst;return a;}

4.7.9 Acknowledgement Wait Duration

The MAC sublayers immediately enables the receiver after the transmission of the MPDU and waitsfor an acknowledgement from the recipient for at most, macAckWaitDuration. The value is dependenton the frequency of operation.

. 868Mhz: 120 Symbols

. 2.4Ghz: 55 Symbols.

An important point to be mentioned is that, for 2.4Ghz operation, the ideal value for macAckWaitDu-ration is 54. However, for NS-2 simulations, taking a value, of 55 is appropriate because of an inherentproblem with the scheduler. In certain simulations with 54 as the Ack wait duration, for the 2.4Ghzoperation, there are extensive retransmissions. Generally retransmission are carried out when the sourcenode cannot receive an acknowledgement with in the macAckWaitDuration time, if acknowledgementsare enabled. And extensive debugging revealed that the transmission has been successful, and the des-tination node responds with an acknowledgement. However, the wait duration elapses by the time theacknowledgement reaches the source node. Coincidence as it may seem, the time of reception of theacknowledgement and retransmission of the next data frame is the same. But the order of these eventsis determined only by the scheduler. Since the two events occur at the same time, the precedence isdetermined by the earliest scheduled event and hence the retransmission of the data packet event ischosen. Changing the scheduler mechanism would be inappropriate in these situations, hence a longerwait duration for the macAckWaitDuration has been proposed.

4.8 Simulation Parameters

Simulation is a flexible means for assessment of the performance offered by a telecommunication system.However, identifying the correct simulation parameters is key for a successful and nearly realistic analysisof any study. The following discussion focuses on the task of identifying the correct parameters togenerate a realistic network scenario, while explaining their meaning and their reason of choice (if any)in detail. General parameters for basic simulations are described here. However, the parameters thatimpact the network performance are discussed in the next chapter where we introduce the performanceanalysis of the system.


4.8.1 Traffic Parameters

Traffic Type

This thesis report is based on results simulated with a Constant Bit Rate (CBR) application, based onthe internet protocol, UDP (User Datagram Protocol). Its primary features are:

. Single Way Transmission (No Acknowledgements)

. Defined Packet size

. Defined Packet Interval

. Unreliable Data Transmission

An FTP traffic with a TCP connection is also possible. However, given its advanced features like con-gestion control, requiring dynamic adjustment of the transmission rate based on the traffic conditions,it is hard to implement simplistic and power efficient devices, for menial applications.

Also a more abstract reason can be that, since a performance analysis would require to test the limitsof the network, a CBR traffic with a constant transmission rate, would help us determining the brinkof congestion. Performance metrics like delivery ratio would be more meaningful in these situations.Whereas, for a TCP source, flow controlling, would dynamically adjust the transmission rate. Hencedelivery ratio would inadvertently be 100%.

Number of Flows

The number of active nodes involved in a communication with the coordinator varies depending on thesimulation requirement and the metric being investigated. However, in the simulations indicated in thenext chapters the number of flows are 8.

Packet Size

The packet size is assumed be to 70bytes. This is exclusive of the RTR, MAC and PHY layer headers.

Traffic Direction

The traffic flows are all one way, with the communication directed to the coordinator. The study isbeing investigated with particular focus on low datarate wireless sensors communicating with a centralnode updating it with the application information.

4.8.2 Node Parameters

The parameters specific to nodes are highlighted in this section.

Number of Nodes

The simulation is carried out with 15 active nodes. One of them being the coordinator.

Coordinators

Since a simple star network topology is being simulated, only a single coordinator is present.


Node Movement

The nodes remain stationary.

Node Position

The nodes are placed along an imaginary circle around the coordinator, with radius equal to the personaloperating space of the nodes.

The traffic and node parameters are summarized in the following table.

Parameter ValueTraffic Type CBR

Number of Nodes 15Number of Flows 8

Number of Coordinators 1Node Movement NoneNode Position Manual (Along a circle of radius POS)

Traffic Direction Node → CoordinatorPacket Size 70Bytes

Table 4.1: Traffic Parameters

4.8.3 Physical Parameters

Radio Propogation Model

There are three propagation models supported by the network simulator. They are:

. Free-Space Model : The free space model is the simplest of the three models with a direct lineof sight path between the transmitter and the receiver. If the devices are arounf the transmitterwithin its operating space, along a circle around it, then it would receive all the packets. Otherwise,it loses all the packets. The received signal power as a function of distance, d is:

Pr(d) =PtGtGrλ

2

(4π)2d2L(4.1)

Pr : Power received at distance d

Pt : Transmitted Signal Power

Gt : Transmitter Gain

Gr : Receiver Gain

λ : Wavelength

d : Distance from the transmitter

L : Path loss


. Two-Ray Ground Model : This is a slightly improved version of the Free-Space model. In this modelother than the direct line-of-sight link, a ground reflection is also considered. When the distancebetween the transmitter and the receiver is long, the Two-Ray Ground model would provide muchmore accurate results than the Free-Space Model. The received signal power at a distance of d isgiven as follows:

Pr(d) =PtGrGth

2rh

2t

d4L(4.2)

ht: Transmitter Antenna Heighthr: Receiver Antenna Height

. Shadowing Model : The two propagation models described so far, are mostly suitable for shortrange communications where a line-of-sight or a near line-of-sight is possible. However, when thedistance between the transmitter and the receiver is considerable, as in mobile communications,the transmitted signal would undergo, fading effects, due to multipath propagation. The first twomodels do not take this into account. Hence this model is widely used in simulating diverse wirelessnetworks.

These models are used to predict the received signal power of each packet. At the physical layer of eachof these models there is a Receive threshold value. Each packet received at this layer should be abovethis threshold. In the current simulations for the IEEE 802.15.4 technology, using a model as simpleas Free-Space wouldn’t suit our expectations, given that the nodes may not have a direct line-of-sightall the time. Also, applying the Shadow model would be over estimating the scenario, since the nodedistances cannot be more than 100 meters. Hence a safe bet is the Two-Ray Ground model.

Antenna Type

The antenna type used in the simulations to deduce these results has been the Omni directional Antenna.The antenna has be chosen for its ability to transmit with equal power in all directions. This is a primaryrequirement, since the node density is not limited to a fixed location or direction.

Transmitter Gain

It is the ratio of the intensity of the radiated signal to that of the transmitted signal at its input, at thetransmitter. It is taken as 1.0, since the transmitter does not amplify the incoming signal power andwould radiate whatever it receives.

Receiver Gain

It is the ratio of the received signal power to that of the output power of the receiver. Again the receiverdoes not amplify the incoming signal power, hence a value of 1.0.

PathLoss

It is the attenuation or power loss (because of obstructions, link distance, or poor antenna height) of anelectromagnetic wave during its transmission from the transmitter to the receiver. However, we assumean attenuation of zero hence the pathloss is 1.0.


Distance between nodes

The simulations are carried out with a scenario where the nodes are placed at equidistant positionsfrom the coordinator. It is assumed to be 10m.

The Physical parameters are summarized in the following table.

Parameter ValueRadio Propagation Model Two-Ray Ground

Antenna Type OmniAntennaTransmitter gain in dB (Gt ) 1.0Receiver Gain in dB (Gr ) 1.0

PathLoss 1.0Distance b/w nodes 10m

Table 4.2: Physical Parameters

4.8.4 Routing Layer Parameters

Queue Type

The queue type used in the simulations is DropTail. It is a queue management technique, implementingthe ”First In First Out” mechanism. Basically, the packet that enters the queue will be served first.When the Queue reaches its limit, the last packet entering the queue will be dropped.

Queue Length

The standard queue length used in the simulations is 150 packets. Once this limit is reached, all packetsare dropped, henceforth. Increasing the queue length would have little impact on the network perfor-mance, since it only depends on the efficient utilization of the available network resources. Also the lowdatarates applicable for this technology wouldnt require a big queue to dissipate packets at a faster rate.When delay is calculated with the time of transmission of the data at the application layer, a longerqueue, would only make it perceive as more delayed.

These parameters are summarized in the following table.

Parameter ValueQueue Type DropTail

Queue Length 150

Table 4.3: Routing Parameters

4.8.5 Miscelleneous

Simulation Time

The simulation time is a measure of the operating time of the network. An inappropriate selection of thesimulation time may reflect as inaccurate results. However, given the simulation statistics, and the fact


Figure 4.6: Constant Current Discharge[13]

that the usual warm up period of the network (association phase of the network) would generally last afew tens of seconds after the start of the first node, the simulation time has been chosen as 1000seconds.The selection leaves ample settling time for the network, to give accurate results.

Initial Energy

The power efficient working of the IEEE 802.15.4 technology is reminded. The technology is designedto work with very low power consumption. These devices are assumed to be working with a single AAbattery for anywhere between 6 months to 2 years. The following discussing is given to calculate theenergy of a AA battery in joules which is used as the initial/starting energy of a node for our simulations.It is to be noted that the performance of a battery varies based on the operating conditions.

Product Information:Manufacturer : EvereadyCommercial Name : EnergizerVoltage : 1.5VType : AA

Using the graph 4.6 as reference, we see that with a constant current discharge of around 10-18mA,the operating time for the battery is around 170 Hours. With this information, the amount of energyavailable in joules can be calculated as,

Power(in W) = Voltage (in V) × Current (in A)

=⇒ Power = 1.5v × 15mA = 22.5 mW = 0.0225 W

Energy available for an operation of 250Hours of constant current discharge

Energy (in J) = Power (in W) × time (in secs)

Energy (in J) = 0.0225W × (170 × 60 × 60)

4.9 Summary 47

=⇒ Energy = 13770 Joules

In our case where the device is only occasionally active, the energy requirements might be much lowerand hence the battery life will be considerably longer. Estimation into the average life of a battery canonly be made using the simulation results which follow in the next chapters.

For the simulations using NS-2, an initial energy of 13000 Joules is assumed.

4.9 Summary

The chapter starts with a brief introduction to the network simulator and the network animator. Themodels like energy, queue, etc are presented, with a brief explanation on how the model is implementedin ns. The trace files of the NS and the animator trace files are presented. Followed by this is the processstructure of the entire simulation. It highlights all the programs and scripts used in this project, andtheir interlink with each other their inter working to generate the final analyzed results is explained.

Some of the programs that have been used in the project are, wpan.tcl, scen gen, wpan.scn, cbrgen star,and avg throughput.awk. These programs are used to simulate the network scenario file, wpan.tcl to gen-erate the trace file ’wpan.tr’. This trace file is used as input to the analysis part of the programs. The pro-grams and scripts used to analyze the results to generate the final results are analyze, find avg868.awk,dfind avg868.awk. The final graphable results are obtained in the text files, final graphs868.txt, fi-nal drops868.txt. A brief description of the zigbee software modules is explained by running down theprogram flow of the association phase.

The software modifications that are done to the zigbee modules are presented followed by the generalsimulation parameters used in the simulations. Variables corresponding to traffic parameters, nodeparameters, Physical parameters, Routing layer parameters, and miscellaneous parameters are presentedand their choice is explained in detail wherever applicable.

Chapter 5

System Performance

This chapter focuses on identifying the parameters that are specific to this frequency band, with referenceto ZMD’s transceiver, then testing the system with exhaustive simulations to reach a point to judge thefeasibility of this technology in its current operating band for the perceived applications. The reportfurther comments on the performance metrics, while highlighting the technology’s performance areaswith a focus on its grey areas explaining reasons where ever possible.

5.1 zigbee Specific Simulation Parameters

Several parameters that are required for the simulation has already been identified in the previouschapter. This section focuses on the power parameters that are provided by ZMD with reference totheir tranceiver, ZMD44101. The simulations that follow use these parameters along with the parametersintroduced in the previous chapter.

5.1.1 Power Variables

Transmit Power(Pt )

It is the power with which the signal is transmitted. According to the regulator document, ETSI EN 300220 [B10] for the 868Mhz frequency band in Europe, the maximum transmission power level can be atmost 25mW. However, the IEEE 802.15.4 standard based devices are envisioned to operate at a transmitpower of 0dBm (1mW). Currently the ZMD44101 transceiver is undergoing testing with transmit powersof 0dBm (1mW), -7dBm (0.199mW), -14dBm (0.0398mW), and -21dBm (7.94e−3mW). For the currentsimulations a transmit power of the ideal case has been assumed. Hence, Pt is 0dBm(1mW, 0.001W).

Pt = 0dBm = 1 mW

= −7dBm = 0.199 mW

= −14dBm = 0.0398 mW

= −21dBm = 7.94e−3 mW (5.1)

Receive Threshold(RXThresh )

The receive threshold value is the least power level of a packet for its transmission to be detected suc-cessfully. If the received signal power is lower than this threshold, it cannot be detected. The ZMD44101transceiver is built to be very sensitive. It is expected to decode signals with power as low as -97dBm,

48

5.1 zigbee Specific Simulation Parameters 49

while levels of -92dBm being ideal. However, it is also being tested with the threshold values of -87 and-82dBm.

Receiver Sensitivity = -97dBm

10× log10(PRXThresh

1mW) = −97

=⇒ PRXThresh = 1.9952× 10−13W (5.2)

Carrier Sense Threshold(CSThresh )

The Carrier sense threshold gives the sensing range of the nodes. If the received signal strength ismore than this threshold, the transmission can be sensed. But this does not guarantee a successfuldecoding and detection of the packet. In order the packet is successfully detected, its power levelshould be atleast equal to the Receive Threshold Value (RXThresh ).

A definite carrier sensing range is not defined. Hence an approximate sensing range is deduced as inthe following calculation.

The receiver is intended to be very sensitive. The lowest signal power that the device is capable ofdetecting is -97dBm. However, since the nodes should be capable of sensing a longer range, or atleastas much as the RXThresh , the carrier sensing threshold depends on the RXThresh . In thesesituations, it can be at most be equal to RXThresh , even though values that are less than RXThreshindicating a longer sensing range are common. But it cannot be greater than RXThresh , in whichcase the variable RXThresh becomes redundant. Hence the least carrier sensing threshold is theReceiver threshold value.

PCSThresh = PRXThresh (5.3)

=⇒ PCSThresh = 1.9952× 10−13W (5.4)

According to the Two-Ray Ground Propagation model, the received power at a distance of d from thetransmitter is given by,

Pr(d) =PtGrGth

2rh

2t

d4L(5.5)

And substituting the following values to deduce the sensing range of the devices:

Pr = −97dBm = 1.9952× 10−13W

Pt = 0.001W

Gt = 1.0Gr = 1.0L = 1.0

ht = 0.0864m

hr = 0.0864m

(5.6)


1.9952× 10−13 =0.001× 1.0× 1.0× (0.0864)2 × (0.0864)2

d4 × 1.0

=⇒ d = (0.001× 1.0× 1.0× (0.0864)2 × (0.0864)2

1.9952× 10−13 × 1.0)

14

=⇒ d = 22.9888m ≈ 23m (5.7)

Therefore using a carrier sensitivity of -97dBm is equivalent to using a sensing range of around 23maround the node. The following lines of code describe the implementation of the sensing and receivingthreshold in NS-2:

File: mac/wireless-phy.ccFunction: WirelessPhy::sendUp

if(propagation_) {s.stamp((MobileNode*)node(), ant_, 0, lambda_);Pr = propagation_->Pr(&p->txinfo_, &s, this); // Extract the power of the received packetif (Pr < CSThresh_) { // Check if power is less than CSThresh_pkt_recvd = 0; // If less, drop the packetgoto DONE;}if (Pr < RXThresh_) { // If power is over the CSThresh_, check if its less than RXThresh_hdr_cmn *hdr = HDR_CMN(p);hdr->error() = 1; // If yes, take up the error routine}

Capture Threshold(CPThresh )

Collisions are common phenomenon. When two packets are received simultaneously, the receiverchooses the strongest packet among them. And this decision is based on the capture threshold limitwhich defines the power ratio between the desired packet (packet at higher power level) with that ofthe other to choose it for decoding. Hence if the ratio is greater than or equal to the capture thresholdlimit, the packet is chosen else both the packets are dropped.

For a successful detection of the desired signal in a collision scenario, it is widely accepted that thedifference between their power levels be atleast 10dB.

10log10Pa − 10log10Pb ≥ 10

⇒ Pa

Pb≥ 10

⇒ CPThresh ≥ 10 (5.8)


Antenna Height

The tests being conducted at ZMD with their transceiver, ZMD44102, use λ/4 monopole antennas.This would reduce the antenna height as follows:

Speed of Light(c) = Frequency of Operation(f)×Wavelength(λ) (5.9)

3× 108 = (868× 106)× λ (5.10)

=⇒ λ = 0.345622m (5.11)

AntennaHeight =λ

4=

0.3456224

= 0.0864m (5.12)

The antenna height of 0.0864m is the absolute height of the antenna. However for ns simulations, theantenna height is produced as a set of coordinates, projecting it in a three dimensional space. The Zcoordinate would give the antenna height over the ground. Hence for the ns simulations thecoordinates of the antenna are assumed as follows.

X = 0Y = 0

Z = 0.0864m

Transmit Power

The transmit power is the power consumed by the transceiver to transmit a data packet. The size ofthe data packet determines the transmit power. More the packet length, more is the power consumed.But, due to transmission of data packets and beacons of different sizes, a definite transmit power levelfor a definitive packet size cannot be produced. Hence the transmit power given here could be for thetransmission of an average sized packet. The transmit power is supplied to be 31mA @ 2.4V.

Therefore the transmit power is calculated to be, 31mA× 2.4V = 31× 10−3 × 2.4 = 0.0744W .

txPower = 0.0744W

Receive Power

It is the power consumed to receive a data packet. The power consumed can be calculated by acurrent discharge of 27mA @ 2.4V.

rxPower = 27mA× 2.4V = 27× 10−3 × 2.4 = 0.0648W .

5.2 Performance Metrics 52

Idle Power

It is the power consumed to by the node during idle/sleep mode of operation. It is to be remindedthat the IEEE 802.15.4 devices are designed to be in snooze mode most of the time and wake up onlyoccasionally. However in the current simulation scenario, where the devices are not allowed to sleep(since there is no inactive portion), the focus is to observe the performance metrics like throughput,delivery ratio, energy performance, etc. The idle mode power can be calculated as 2.3µA @ 2.4V.

idlePower = 2.3µA× 2.4V = 2.7× 10−6 × 2.4 = 0.00000552W .

The following table highlights all the power parameters.

Parameter ValuePt 0dBm (1mW)

RxThresh -97dBm, -92dBm, -87dBm, -82dBmCSThresh -97dBm (1.9952 × 10−13)CPThresh 10

Antenna Height 1.0mtxPower 0.0744WrxPower 0.0648WidlePower 0.00000552W

Table 5.1: Power Parameters

5.2 Performance Metrics

Several metrics can be defined to grade the performance of a technology against the elements ofwireless networking. Some of these metrics have been carefully chosen to give an idea of behavior andthe reliability of the Zigbee networks. Before we go on to describe these metrics, it is reminded thatthe analysis focuses only on data transmission, and the metrics measure their features with respect todata packets, hence other controlling overhead, are overlooked. An detailed explanation of thesemetrics follows:

5.2.1 Network Throughput

It is a measure of the amount of data transmitted from the source to the destination in a unit periodof time (second). Considering the low datarates and throughputs supported by this technology at868Mhz frequency band, the throughput is measured in total bits received per second. Also to benoted is that this metric only measures the total data throughput, ignoring all other overhead, overthe network. The throughput of a node is measured by first counting the total number of data packetssuccessfully received at the node, and computing the number of bits received, which is finally dividedby the total simulation runtime. The throughput of the network is finally defined as the average of thethroughput of all nodes involved in data transmission.

Therefore, throughput can be stated as:

Throughput of a Node =(Total Data Bits Received)

(Simulation Runtime)(5.13)

5.2 Performance Metrics 53

Similarly the throughput for the network can be defined as:

Network Throughput =(Sum of Throughput of Nodes Involved in Data Trans.)

(Number of Nodes)(5.14)

5.2.2 End-to-End Delay

The end-to-end delay is the time taken for a data packet to reach the destination node. The term,”End-to-End” delay does not have much significance in this scenario. The simulations are performedwith a star network topology, and the routing mechanism is disabled, because the standard doesn’tsupport routing of data among peers. Therefore, the maximum number of hops for any data packetbefore reaching the destination node can be only 1. Hence the term End-to-End Delay can be safelyinterchanged with Delay.

The delay for a packet is the time taken for it to reach the destination. And the average delay iscalculated by taking the average of delays for every data packet transmitted. The parameter comesinto play only when the data transmission has been successful.

Packet Delay = Receive T ime at Destination− Transmit T ime at Source (5.15)

Average Delay =Sum of all Packet Delays

Total Num of Received Pkts(5.16)

5.2.3 Delivery Ratio

It indicates the percentage of the transmitted data packets that are successfully received. It is animportant metric which can be used as an indicator to a congested network. Again the delivery ratiois only considered for data packets. Firstly the total number of transmitted packets is counted,followed by the total number of received packets and the total number of dropped packets. Thedelivery ratio is calculated as the percent of packets received to the packets transmitted. The numberof packets dropped does not take into account retransmissions. As an example, if a data packet withan ID: 4 is transmitted and has been dropped for the first time. The packet is retransmitted, as longas we have a successful transmission or the maximum number of retransmissions has been reached.But the drops due to retransmission is not taken into account and are only counted when the packet isultimately dropped, and even in those cases its counted as a single drop. However, if the packet issuccessfully received by the destination after several retransmissions, the drops are not considered.This would effectively make the number of transmitted packets equal to the sum of the number ofreceived packets and number of dropped packets.

Delivery Ratio =Number of Received Packets

Number of Transmitted Packets× 100 (5.17)

5.2.4 Energy Consumption

The metric is measured as the percent of energy consumed by a node with respect to its initial energy.The initial energy and the final energy left in the node, at the end of the simulation run are measured.The percent energy consumed by a node is calculated as the energy consumed to the initial energy.

5.3 Performance Analysis 54

And finally the percent energy consumed by all the nodes in a scenario is calculated as the average oftheir individual energy consumption of the nodes.

Percent Energy Consumed =InitialEnergy − FinalEnergy

InitialEnergy× 100 (5.18)

Average Energy Consumed =Sum of Percent Energy Consumed by All Nodes

Number of Nodes(5.19)

5.3 Performance Analysis

Several experiments have been conducted to analyze the behavior and response of the zigbee networksworking at the 868Mhz frequency band. The experiments measure the data throughput, delay,delivery ratio, and energy consumption, measured as a function of transmission rate. Similarly thepacket drop analysis is done, also as a function of datarate. Most of the results, wherever possible arepresented with a 95% confidence level.

Wireless networks designed for low power consumption have always faced the challenge of providingan acceptable tradeoff between the sensing range and hardware cost. The friis law used for theTwo-Ray Ground model gives a direct relationship between the maximum range of the link with theantenna gain and the transmit power, and an inverse relation with the receiver sensitivity.

d ∝ (PtGtGr

Pr)(

14) (5.20)

Increasing the transmitter and the antenna gain would involve highly complex antenna technologywhich are able to focus all their energy in the direction of the transmission. Given the restrictions ofmenial applications, restrictions due to size and implementation and a major hurdle of cost, applyingsuch a technology for zigbee applications is not feasible. Increasing the transmit power would be anelegant solution. Transmitting the data frames at a power level so that the intended node can perceiveit, might look an easy solution, but the devices are designed for ultra low power consumption, and ishighly likely to interfere with other devices (especially devices working in the 2.4Ghz range), and itwould increase the cost of RF Components and heat sinks. Thus increasing the transmit power wouldonly make the challenge even harder. This leaves the possibility of increasing the receiver sensitivity tosuch an extent that even the lowest powered signals are detected. It has been proved that increasingthe sensitivity by a factor of 6dB would effectively double the operating range of the node. Alsoincreasing the range by providing highly sensitive receivers can be achieved with minimal hardwarecosts and without exposing the receiver to intolerable levels of interference. Based on the abovediscussion, the simulations are repeated for several receiver sensitivity values to display its impact onthe hidden/exposed node problem.

The analysis would then calculate an effective bandwidth achievable and comment on an estimation ofthe power consumption for an illustrative zigbee device.

These simulations are conducted with the following assumptions:

5.3.1 Throughput

The following graph 5.1 highlights the throughput analysis of a system at 868Mhz frequency band.The analysis first considers the datarate range from 0.1 through 1.0 followed by higher datarates until10.0. The graph 5.2 gives the throughput performance in the range of 0.1-3.0 pkts/sec in more detail.


Exp. No Receiver Sensitivity Sensing Threshold Sensing RangeExperiment-1 -97dBm -97dBm ≈23mExperiment-2 -92dBm -92dBm ≈17mExperiment-3 -87dBm -87dBm ≈13mExperiment-4 -82dBm -82dBm ≈10m

Table 5.2: Simulation-1: Carrier Sensing Range = Receiver Sensitivity

Exp. No Receiver Sensitivity Sensing Threshold Sensing RangeExperiment-1 -97dBm -97dBm ≈23mExperiment-2 -92dBm -97dBm ≈23mExperiment-3 -87dBm -97dBm ≈23mExperiment-4 -82dBm -97dBm ≈23m

Table 5.3: Simulation-2: Ideal Carrier Sensing Ranges

Figure 5.1: Throughput analysis

Figure 5.2: Throughput Performance in the Range 0.1-3.0 pkts/sec

The impact due to receiver sensitivity is studied in simulation 1 and 2. In simulation-1, as can beclearly seen when the receiver is sensitive enough (-97dBm) we have a better performance, comparedto the cases when the receiver sensitivity is -92dBm, -87dBm and -82dBm. In the case of -97dBm ofreceiver sensitivity and a -97dBm of carrier sensing range, the throughput increases linearly throughthe datarates from 0.1 to 1.0, and following the trend until, 2.0, where it achieves a stagnation due tonetwork congestion. These experiments reveal a maximum of 5100bits/second can be achieved at thissensitivity. The peak performance is considered at datarates of 1.0-2.0 pkts/sec. Taking the deliveryratio into consideration, ideally a peak datarate of 1.0 Pkts/sec is achievable for the said frequencyband and receiver characteristics.


However, for simulation-1, in the case of lower receiver sensitivity and corresponding sensing ranges,the performance at higher datarates has been considerably lower, and during congestion theperformance reaches their lowest point. Their peak performance can be viewed at rates of 0.7-0.8packets per second where the nodes were able to receive 2700bits/sec for -92dBm sensitive receiver andnearly 2200bits/sec for the other sensitive ranges. Following which the throughput performance takes anegative trend, before settling at ≈ 1000bits/second for -92dBm and a further low of <500bits/secondfor the other receiver sensitivities. However, as the confidence intervals indicate, the performancecannot be judged as final. More simulations are needed to state a definite value in this case. But, as isvisible, at these levels, the system performance is too weak and cannot be applied to any application.Hence the analysis in these areas is not concentrated upon to produce a final estimated value. Thepoor performance of the later three sensitive ranges can be explained with respect to the sensing rangewhich has been deliberately chosen as same as being RXThresh . A detailed explanation follows.

Simulation-2, with all the four receiver sensitivities using an identical carrier sensing range equal to-97dBm has been conducted. The table 5.3 would give more details about the simulation parameters.

The results show that all the four sensitive ranges depict identical performance, each overlapping theother, as in the following graph 5.3.

But why the difference?In simulation-2, the carrier sensing threshold is assumed an identical value of -97dBm, irrespective ofthe receiver sensitivity. And the simulation results produce identical performance by all the foursensitive ranges. This indicates, that the destination nodes (coordinator) is able to, not only sense thedata transmissions from each of the sources, but also successfully decoded them. Since we haveidentical performance, even to the least sensitive receiver, the signal degradation has been not belowthe level of -82dBm. Infact, simulation results indicate a signal power level of ≈8.5e−12W. Therefore,placing the nodes at a distance of 10m apart from the coordinator and maintaining a transmit powerlevel of 1mW, would degrade the transmitted signal to ≈8.5e−12W, before it completes its 10m trek,for the supposed propagation model.

In simulation-1, since the signal degradation is never below the least applied receiver sensitivity of-82dBm (1.9952e−12W), one would again expect the performance to be identical as in the previouscase. However, it is not the case, and each experiment reveal a different pattern. And the reason forthis behavior is Carrier Sensing Range. Since the carrier sensing range is chosen to be equal to theirrespective receiver sensitivities, the range of detection of each node is diminished for each successiveexperiment. This would degrade the link quality for each successive packet transmissions, because ofcollisions. This would warrant a packet to be dropped when its signal-to-noise ratio performance isbelow the capture threshold (CPThresh ). One other reason frequently preventing the packets to bedropped at the PHY is the packet corruption.

Comparing the performances based on identical and non-identical sensing ranges, it can be concludedthat in the given scenario where the nodes are placed at a distance of 10m away from the coordinator,the power content of the transmitted packets is degraded, but not to a level lower than -97dBm.Hence when the sensing range is chosen identically to -97dBm, the coordinator is able to successfullysense the packets from its respective sources. However, their signal strength has been well above thereceivers detectable range, even with a less sensitive receiver.

These experiments for smaller operating ranges (of close to 10m) indicate that such variations inreceiver sensitivity may not have a drastic impact on the performance of the system. But experimentsconducted with higher operating ranges(≈20m), assuming a receiver sensitivity of atleast -97dBm,reveal acceptable performance. However, a conclusive decision is not possible because of insufficientsimulation data. Also, experiments conducted for operating ranges of above 20m with a minimumreceiver sensitivity of -97dBm, it has been observed that the nodes were not able to associate with thecoordinator, because the coordinator cannot detect their association request messages.


Figure 5.3: Throughput Analysis Assuming Identical Carrier Sense Range

Given these insights into the performance of the system, an ideal operating range can be 10m, with areceiver sensitivity of anywhere between -82dBm to -97dBm, with a carrier sensing range beingatleast, -97dBm or even lower. The table 5.4, highlights the ideal operating conditions.

Operating Range RXThresh CSThresh10 -97dBm, -92dBm, -87dBm, -82dBm -97dBm≤ 20 -97dBm -97dBm

Table 5.4: Ideal Operating Conditions

5.3.2 Delay Analysis

The delay measured is the average of the transmission time of all data packets. Again the graph 5.4picture the delay measurement through the datarates of 0.1 - 1.0 and through 1.0 - 10.0, and thegraph 5.5 for the datarates of 0.1-3.0 pkts/sec in more detail, for the first simulation parameters.Again, because of the explanation given in the previous section, using an identical carrier sensethreshold for all the experiments result in identical performance for all the receiver sensitive ranges.

Figure 5.4: Delay Analysis for Simulation-1

From the graph, 5.4, it can be seen with a receiver sensitivity of -97dBm, as in the threshold, thedelay remains lower than 0.5 seconds during most of the cases until datarates are 1.0 packet/second.As datarates increase, towards congestion, the time taken for the data packet to reach the destinationnode keeps increasing gradually. For transmission rates of 1.5pkts/sec, the delay is about 42 seconds,which in general cases are unrealistic and unacceptable in some applications. And as we move toincrease the transmission rates, the delay to deliver a packet to the destination reaches unrealistically


Figure 5.5: Delay Analysis in the Range 0.1-3.0Pkts/sec

over 100 seconds. Similarly for the other receiver sensitive ranges the performance remains withinrealistic levels until 0.8pkts/sec, over which the performance is substantially degraded. However, asthe 95% confidence levels indicate more experimental results are needed to predict an accurate value.But this area of operation is of no interest because of its low performance range, hence are notpursued any more.

As long as the devices are transmitting at modest rates of within 1pkt/sec, the performance has beencommendable. But increasing the datarates further pushes the network closer to congestiondeteriorating the delay performance. The delay in delivering the packet to the destination is due toincreased number of packet drops. Since there is no routing of data, data is supposed to be directlytransmitted to the coordinator, but increasing number of packet drops, corresponding to increasingtransmission rates, warrants more retransmissions, which inturn congest the network further, whichagain cyclically increases the number of drops.


The graph, 5.6 depicts the delivery ratio of the network under different traffic parameters. When usinga receiver capable of detecting packets as low as -97dBm, the delivery ratio is close to 100% in therange of 0.1-1.0 packets/second. The network when operated in the range of 1.0-2.0pkts/sec, maintaina delivery ratio of over 80%. The performance, thereafter, exponentially decreases for higherdatarates. Thus as can be seen from the graphs, nearly all packets are delivered in applicationsmaintaing low datarates.

Figure 5.6: Delivery Ratio

The graph 5.7 highlights the delivery ratio performance of the system in the range of 0.1-3.0pkts/secin more detail. The region between the datarates of 1.2 - 1.3 indicates the transition of the network


from normal to congestion operation.

Figure 5.7: Delivery Ratio Performance in the range 0.1 - 3.0 pkts/sec

As higher traffic is applied to the network, more and more packets are dropped due to collisions andbad link quality of the transmitted packets. This would increase the number of retransmissionsexponentially, effectively congesting the network even further.

Similarly for the other receiver sensitive ranges (Graph: 5.8), the delivery ratio is maintained above,90%, until a rate of 0.65pkts/sec for the -92dBm RXThresh operation, and above 80% for rates ofabout 0.45Pkts/sec, for the other two sensitivities. The performance for the simulation-2, assumingthe carrier sense range equal to their respective RXThresh , is similar to the pattern depicted by the-97dBm sensitive receiver.

Figure 5.8: Packet Delivery Ratio When Using Ideal Carrier Sense Threshold

Thus an ideal operating rate for an application critical on how efficiently data is delivered, would be≤1.0pkt/sec. A medical equipment noting critical data of a patient at regular intervals, needs efficientdata transfer, rather than how fast the data is transmitted. Thus, in these type of circumstancesapplying datarates at ≤1.0pkt/sec with a receiver sensitivity of either, -82dBm, -87dBm, -92dBm or-97dBm, at a minimum sensing threshold of -97dBm, would aptly suit the application. Howeverapplication dependent may be, the technology cannot be used for datarates above, 2pkts/second, afterwhich the performance is unacceptably lossy.

5.3.4 Energy Analysis

The graph, 5.9, refers to the energy performance of the network as a function of traffic rate. Theexperiments conducted assume an initial energy of 1300 Joules, which is the calculated lifetime energyof a 1.5V, AA battery. In view of the low confidence levels, the simulation for the -97dBm receiversensitivity is again conducted for higher number of simulations to achieve a better confidence levels, as

5.4 Drop Analysis 60

indicated in graph 5.10. The energy performance indicates that as long as the network is free fromcongestion for datarates of ≤2.0pkt/sec, the gradual increase in the throughput would inturn increasethe wake time of the transceiver and hence the power consumption is linearly increasing. For thecongestion operation of datarates higher than 2.0pkts/sec, the power consumption reaches astagnation point of close to 0.4% of the initial energy, as the network throughput remains stagnant.The direct proportionality of the energy consumption and throughput performance of the network isevident from the graph. In graph 5.10 the sudden increase in the power consumption for datarate of1.3Pkts/sec can be observed. This can be attributed to the very high packet drops indicating thesystem has moved to congestion regions. This is a region where there is a sudden drop in delivery ratioand increase in the number of link quality indication drops, as can be observed in the graph 5.7.Similarly the performance analysis for the other sensitive receivers can be explained.

Figure 5.9: Energy Analysis

Figure 5.10: Energy With Better Confidence Levels in the range 0.1-3.0pkts/sec

5.4 Drop Analysis

Drop analysis aims to study the causes of packet drops and their effect on the system performancewhich is already study in the previous section. Packets may be dropped due to several reasons. Apacket accepted at the PHY layer may be dropped at the MAC. Hence a comprehensive study of allthe drops would help in our analysis of the system performance. A brief discussion of some packetdrops follows:

. IFQ : Indicates the queue is full due to excessive transmission rate, the queue can manage. It isto be noted that the Queue management is FIFO. The packet that first joins the queue isattended and packets that arrive after the queue is full are dropped.


IFQ DROP IFQ QFULLLQI LINK QUALITY INDICATIONCBK DROP RTR MAC CALLBACKCOL DROP MAC COLLISIONDUP DROP MAC DUPLICATEERR DROP MAC PACKET ERRORRET DROP MAC RETRY COUNT EXCEEDEDBSY DROP MAC BUSY

LOOP DROP RTR ROUTE LOOPTTL DROP RTR TTL i.e TTL

NRTE DROP RTR NO ROUTEARP DROP IFQ ARP FULLEND DROP END OF SIMULATION

Table 5.5: Packet Drops

. CBK : It indicates that the MAC layer was not able to transmit the packet and hence isinforming the upper layer about the transmission failure. A few possible reasons for thetransmission to fail are:

1. m Channel Access Failure: Failure in accessing the channel, following the CSMA-CAmechanism.

2. m No Ack: No Acknowledgement has been received for the transmission.

3. m Transaction Expired

. COL: Defines a collision scenario where two or more packets are received at the same time atthe PHY layer. The code that implements this process in NS is presented.

// Check if no previous packet is being processedif (rxPkt == 0){// Process the packetrxPkt = p;HDR_LRWPAN(rxPkt)->rxTotPower = rxTotPower[wph->phyCurrentChannel];}else // Collision: rxPkt is not Zero indicating it already holds a packet.{// Collision logic.}

. DUP : Indicates that a duplicate packet has been received. The duplicate is then dropped withthis error message.

. ERR: This error is responsible for packet drops at the PHY and MAC layers. At the PHY, itindicates that the packet has been successfully sensed but couldnt be decoded, because of errors.This is generally caused when the received packet power is not greater than the receiverssensitivity. At the MAC layer, a packet drop with this message indicates an incompletereception(because of forced switching of transceiver) or an inappropriate packet size (>aMaxPHYPacketSize). Upon detection of an error, the error flag is set.

. RET : Maximum number of retries has been exceeded.


. BSY : The MAC layer is busy, and cannot accept data frames from the lower of upper layers.

. LOOP : The transmitted packet returns back to the source indicating it is being routed alongthe network circularly. This error can be discarded since the current analysis consists of simpleSTAR topology.

. TTL: The time to live of a packet has been expired. It is a variable indicating the maximumnumber of hops it can make to reach the destination. This error can be ignored in the currentstudy.

. NRTE : Indicates no route has been discovered to the indicated node, during the routingrequest phase. Again, this message can be safely ignored, for the current report.

. ARP : Address resolution has been unsuccessful for the indicated node, during the ARPRequest phase. This mechanism is disabled in the current study, hence can be safely ignored.

. END : Packet drops at the end of simulation. It is an ignorable error message which generallyarises when the traffic source doesn’t stop transmitting even at the end of simulation. To avoidgetting this error message, simply turn off the traffic source at the end of the simulation with aTCL command in the scenario file.

The following drops are specific to Zigbee technology.

. LQI : The Link quality of all packets that arrive at the MAC layer is calculated. It is measuredas the signal to noise ratio with in the channel. When the SNR is within acceptable limits,preferably ≥ CPThresh , the packet is accepted. Else the packet is dropped with the indicateddrop. There are two significant reasons for these drops. Firstly is the hidden node problem andsecondly because of choosing the same backoff duration despite being within the sensing range ofeach other. The hidden node problem is caused when two or more nodes involved in transmissioncannot detect the presence of other nodes and transmit unaware of transmissions of other nodes.The second case of packet drops arise when two nodes choose the same backoff duration and findthe channel is idle, despite being within the reach of each other.

Code fragment to indicate the implementation of LQI in NS is presented.

if ((wph->rxTotPower-p->txinfo_.RxPr) > 0.0)// Check the SNRif (p->txinfo_.RxPr/(wph->rxTotPower-p->txinfo_.RxPr) < p->txinfo_.CPThresh){// Indicate it in NAM with a color flashif (!wph->colFlag)nam->flashNodeColor(CURRENT_TIME);// Drop the Packetdrop(p,"LQI");return;}

. CHN : Packet drop at the PHY, indicating the packet has been corrupted, because the packetbelongs to a different channel, other than the one indicated by the PIB attribute,phyCurrentChannel.

. NOT : Another packet drop at the PHY layer, indicating the packet is corrupted, despite thetransmission being in the correct channel.


. TRX : When an MPDU is ready for transmission, the MAC layer requests the PHY layer usingthe PD DATA request primitive, to transmit the packet. The PHY layer on receiving the requestprimitive, constructs a PPDU out of the received PSDU (Note: Mac Protocol Data Unit is thePHY Service Data Unit at the PHY layer) and transmits the packet provided the transmitterantenna is enabled (TX ON). Based on the result of this operation an appropriate statusmessage is generated. If the transmitter is not enabled, the packet is dropped with this message.

. APS : Indicates Active/Passive Scan mode is active and the node cannot accept any datapackets other than beacons. During the association phase (either active or inactive) the nodesare required to drop all other packets that are not beacons. When the devices are not associated,these messages would have no significance. Hence these packets are dropped.

. ADR: If the pan is operating in either the MAC short address format or the MAC extendedaddress format, and the received packet doesn’t conform to the specification, the packet isdropped.

. ED : All frames received during the PHY Data service shall be dropped during the EnergyDetection Phase (ScanType == 0x00).

. OPH : A node when orphaned cannot accept any data frames. Hence all frames that are notCo-ordinator realignment command frames (that are needed to reassociate to a PAN) aredropped.

Having described some of error conditions that cause a packet to be dropped, we go ahead describingthe drop statistics in response to various traffic conditions.

Two types of drops have been frequently observed for data transmissions. They are the Link QualityIndication (LQI ) and IFQ. Other drops specifically related to upper layers (routing) such as NRTE,ARP, TTL, TOUT, etc would generally wouldn’t arise, since the routing and address resolutionmechanism is disabled for the current project. The graph 5.11 indicates the sharing of drops in therange of 0.1-1.0 and from 1.0-10.0. It can be observed from the graph that for rates lower than,1.0pkts/sec, a major contributor for drops being LQI. As can be seen in case of -97dBm of RXThreshthere are no drops due to IFQ, in this range. Since the network is not yet congested at these rates, thepackets are not accumulated at the Queue; hence not many drops occur at the Queue. However, onincreasing the traffic rate, the ratio of drops due to IFQ, starts taking lead, indicating the congestionin the network. As we move to very high datarates, most of the drops are attributed to IFQ, however,the drops due to bad link quality make their presence felt.

Figure 5.11: Drop Sharing

The following study gives a comparative analysis of the two drop statistics for the four receiversensitivities taken with their carrier sensing range equal to their RXThresh . The graph 6.10 and 6.11

5.5 Effective Bandwidth 64

depicts the two types of drops. As can be seen in the graph for LQI Drops, in the case of RXThreshof -97dBm, in the datarates of 0.1-1.0, the data packet drops due to Link quality is under control,reaching a maximum of 330. This indicates there are less number of collisions during this range. Whilethe system is tested for higher datarates, due to network congestion, the number of packet dropssteadily increase before reaching a saturation value of around, 8200 drops. This effect can be explainedwith reference to the hidden node problem and also to the inefficient CSMA-CA mechanism. Thenodes that remain out of the sensing range of the other source nodes, transmit without the knowledgethat other nodes are also involved in a similar transmission. However, since the nodes remain withinthe sensing range of each other the LQI drops can be solely attributed to the CSMA-CA mechanismdue to inefficient backoff mechanism, which is described in more detail in the next chapter. This wouldresult in collisions. Thus at higher datarates, the backoff mechanism allows more and more nodestransmit at the same time, resulting in greater number of collisions. Hence greater number of dropsdue to LQI.

Similarly, in the case of IFQ drops, it can be seen that starting with a very low value for extremelylow datarates (0.1 pkt/sec) the number of such drops steadily increase, indicating a directproportionality with the traffic rate. When the datarates are within controllable levels under which allarriving packets can be easily dispersed, the IFQ drops are negligible, and for higher datarates morenumber of packets await transmission at the Queue, and the queue is easily overflowed, prompting therouting layer to drop all successive data packets.

Also increasing the queue size would not improve the performance. Since increasing the queue lengthwould enqueue the incoming packet, but the time at which it is processed is also increased. This wouldeffectively delay the packet transmission. However, there might be a marginal improvement in the IFQdrop performance, for lower datarates. But effectively speaking, the queue drops cannot be controlledunless there is a significant improvement in bandwidth.

Figure 5.12: LQI Drop Statistics

Similarly the drop statistics of the system with respect to simulation-2(Graph:5.14 & Graph:5.15),taking an identical carrier sensing range for all the four experiments, reveal an identical performanceas in the case of a -97dBm senstive receiver.

5.5 Effective Bandwidth

To calculate the effective bandwidth, we need to consider the maximum throughput achievable by thistechnology. The above simulation results (graph: 5.2) indicate a throughput of 5302 bits/sec, isachievable when operating at a rate of 1.3pkts/sec (It drops to lower values for rates higher than 1.3pkts/sec). Therefore this indicate a maximum of 5.3Kbps is achievable under this technology. Firstlyit is reminded that the throughput calculation made is only for data, excluding all retransmissions,

5.5 Effective Bandwidth 65

Figure 5.13: Queue Statistics

Figure 5.14: LQI Packet Drops for Simulation-2

Figure 5.15: Drops due to Queue Overflow for Simulation-2

overhead and controlling messages. Thus, a maximum of 5.3Kbps of data bandwidth is available. Thisis equivalent to the quarter of the total bandwidth, this frequency band would theoretically support.

Acheivable Overall Data Bandwidth = 5.3 Kbps

However, utilizing this bandwidth is not possible because of the very high data loss, at these rates.Therefore, to calculate the effective utilizable bandwidth, at which we can expect a Quality of serviceof atleast 99% delivery of data, the throughput at lower datarates need to be considered. Thus

5.6 Datarates 66

referring to graphs 5.2 and 5.7, to achieve a delivery ratio of atleast 99%, the traffic rate should be ≤1.2pkts/sec. And the achievable throughput at this rate of operation is ≈ 5.251 bits/sec.

Acheivable Data Bandwidth for QoS of 99% delivery ≈ 5.25 Kbps

Achievable Data Bandwidth for QoS of 90% delivery ≈ 5.3 Kbps

Similarly for low latency applications, requiring a minimum QoS of close to zero seconds of delay intransmission, according to the graph, 5.5, the datarates of ≤ 1.2pkt/sec can be applied. Therefore theeffective bandwidth under these conditions is:

Achievable Data Bandwidth for ≈0sec delay = 5.25 Kbps

5.6 Datarates

Note that this analysis is dependent on the simulation scenario. Under the current scenario of 15nodes, where 8 nodes are involved in transmission with the coordinator, the following predictions aremade.

Similar to the achievable bandwidth, depending on the applications and the required QoS, there areseveral datarate ranges that can be achieved. To achieve a throughput or effective data bandwidth of3Kbps - 5Kbps, with no severe restriction on the delay performance, datarates of 0.7-1.2pkts/sec canbe effectively used.

Achievable datarates for 3-5kbps = 1-2pkts/sec.

Achievable datarates for ≈0secs delay and near 100% delivery ratio = 0.1 - 1.2 pkts/sec.

5.7 Effective Energy Usage

The energy usage characteristics can also be predicted based on the required QoS. With reference to5.10.

Achievable Energy Consumption for ≈0 secs delay and near 100% delivery ratio with very goodthroughput = 0.255% of initial energy.

5.7.1 Battery Lifetime Calculation

Having seen the energy performance, lets investigate the possible lifetime of a battery being used foran application with high throughput requirement and a very good delay performance. This wouldrequire using the datarates of 1.2 pkts/sec. The energy performance of the device in this case isaround, 0.255% of the initial energy (1300 J). And the simulations have been restricted to 1000seconds.

Thus for a continuous data transmission of 1000 seconds the energy consumed is:

=0.255× 13000

100= 33.15 Joules

5.7 Effective Energy Usage 67

Time taken to consume all of the initial energy is:

=1000× 13000

33.15= 392156.86 secs

= 6535.95 mins

= 108.93 hrs

= 4.54 days

Thus in a period of 4.5 days the application is going to run out of power, under the assumption ittransmits data continuously at 1.2pkts/sec. However, in real time applications, continuoustransmission of data is not realistic atleast not for days in succession.

5.7.2 Illustrated Application

Having commented on the performance of the system under different operating conditions, this sectiondeals with possible applications that are achievable and their application areas are highlighted.

There may be several applications requiring a satisfactory level of performance of a particular metric.An application may require a very good throughput performance; similarly an application may requirea very good delivery or delay performance or may require to be very energy efficient. Someapplications may require the nodes to transmit at higher datarates. Certain applications may need avery good performance in terms of all the metrics mentioned above. Thus the energy consumptiondepends on the intended application.

Let’s take an example of an intended application in the industrial automation segment. A sensordevice is embedded in a motion detection camera, to form a surveillance system. It requires totransmit a note to the central coordinator on a possible intrusion when the camera detects a motion inits coverage area. Apart from this primary task it may require to monitor a variety of camera relatedissues, among others. On detection of an unusual activity or a camera related problem it may indicateit to the coordinator which would take further action. Let the coordinator, on reception of a note onmotion detection, is programmed to draw the attention of the security guards to the coverage area.

And lets assume the covered area might have false alarm in most cases due to dummy motioncaptured by the camera. Assuming the camera operates only at night, and assuming a possibletransmission of data back to the coordinator for atleast 5 mins a day, we can calculate the number ofdays a ’AA’ battery would last as follows:

According to section-5.7, a continuous data transmission at a rate of around, 1.2 Pkts/sec, which is anideal transmission rate in the current example, would last a AA 1.5V battery for around, 6535.95mins. Since in the current example the application is assumed to transmit only for about 5mins a day,the battery would last for 6535.95

5 = 1301.19 hours = 54.47 days. Thus the battery might last for aperiod of ≈2 months.

Calculated Battery Life ≈ 2 months @ 1.2pkts/sec, 5 mins/day

The 5 mins/day data transmission at 1.2Pkts/sec is equivalent to transmitting 5.258 = 0.656kbps by

each node. This is equivalent to transmitting 196.8 kilo bits of data per day.

However as already stated, the power consumption is dependent on the intended application. If theapplication just mentioned is operated at a rate of say, 0.5pkts/sec, where the power consumption is

5.8 Summary 68

0.11% of initial energy(less than 12 of that at 1.2 pkts/sec), the performance of such a device would

last the battery for approximately 4 months.

Calculated Battery Life ≈ 4 months @ 0.5 pkts/sec, 5 mins/day


each node. This is equivalent to transmitting 82.5kbits of data per day.

The node is intended to be in sleep mode for the rest of the time. However, the above predictions donot take into consideration the energy consumption in sleep mode.

The following conditions apply for the above predictions.

. The network operates completely in the active region. There is no inactive portion of operation.Hence the power consumption calculation made above is when the transceiver is always active,listening to the network. But, in the proposed application, the node can remain in sleep for mostof the time. When such a scenario is implemented a much better power performance can beexpected.

. A maximum of eight nodes are involved in a transmission with the coordinator.

. The coordinator is not allowed to transmit data to the nodes.

5.8 Summary

The chapter begins by defining the simulation parameters that are specific to zigbee and to the868Mhz frequency band of operation. Some of the parameters are supplied by ZMD, with reference totheir chip ZMD44101. The variables and their choice is explained in detail. The confusion broughtabout with the CSThresh and the EDThresh is also explained in detail. The other variablespresented are CPThresh , Antenna height, transmit power, the receive power, and the idle power.Followed by this the performance metrics measured in this project to analyze the performance andtheir detailed definitions are given.

The performance is analyzed for the receiver sensitivities of -97dBm, -92dBm, -87dBm and, -82dBm intwo separate simulations. Each simulation involving a set of four experiments. The first simulation isconducted with the carrier sense threshold taken same as that of the receiver threshold, while in thesecond case the carrier sense threshold is taken independent of the receive threshold and has beenassumed to be -97dBm. The performance of the system is then analyzed through a series of graphsmost of them with a 95% confidence levels.

The simulations highlight the following results.

. Achievable Overall Data Bandwidth = 5.3Kbps

. Achievable Data Bandwidth for QoS of 99% delivery ≈ 5.25 Kbps

. Achievable Data Bandwidth for QoS of 90% delivery ≈ 5.3 Kbps

. Achievable Data Bandwidth for ≈0sec delay = 5.25 Kbps

. Achievable datarates for 3-5kbps = 1-2pkts/sec.

. Achievable datarates for ≈0secs delay and near 100% delivery ratio = 0.1 - 1.2 pkts/sec.

. Achievable Energy Consumption for ≈0 secs delay and near 100% delivery ratio with very goodthroughput = 0.255% of initial energy.

5.8 Summary 69

. Time taken to consume all of the initial energy is: 4.54 days

. Calculated Battery Life ≈ 4 months @ 0.5 pkts/sec, 5 mins/day

Chapter 6

Adaptive Backoff Mechanism ForCSMA-CA

IEEE 802.15.4 compliant devices use CSMA-CA to access the media for their data transmissions. Thedevices use slotted CSMA-CA for a beacon enabled network, where as a non-beacon enabled networkuse unslotted CSMA-CA mechanism. In the slotted mechanism, the devices wait for a backoffduration aligned with the start of the beacon transmission. When the device has data or MACcommands to send, it waits for the boundary of the next backoff slot and completes its backoff waitduration. At the end of its wait, the channel is sensed to see if its idle. If the channel is found busy,the device shall wait for the next slot boundary and wait for the entire backoff duration before tryingagain. If the medium is found to be free, the device can proceed with its transmission.Acknowledgements are transmitted without the use of CSMA-CA.

In the unslotted CSMA-CA mechanism, the device shall wait for a randomly chosen backoff interval,after which it shall sense the channel. If the channel is idle, it transmits its data, or if the channel isfound busy, it chooses another random time interval for backoff. It then repeats the same procedureuntil it can transmit the data or it can issue a notice to the upper layer that access to the channel hasfailed. The current focus is on Zigbee networks where beacons are enabled, hence, the unslottedCSMA-CA mechanism is not considered.

A study of the system performance at collision scenarios reveals an exponential increase in the numberof packet drops, for higher datarate operation. Also the system performance for real time trafficscenarios where nodes transmit at different rates, is also very poor, again attributed to the numerouspoor link quality packets. Poor link quality is a direct consequence of the hidden node problem. Evenif the nodes can detect each others presence, collisions are caused when two or more of them choose anidentical backoff time duration. Thus they transmit data/MAC-command packets without being awarethat an other node has also detected an idle channel. This result in frequent confrontations amongnodes which result in collisions, packet drops and as a consequence retransmissions, which affect thethroughput of the network. The reason can be traced back to the inefficient backoff mechanism. Thestandard CSMA-CA mechanism allows the nodes to choose a minimum backoff exponent of 3, andeach time the node fails to access an idle medium, the node is required to increment its backoffexponent, but never moving over 5. And on successful transmission , for the next packet the node isallowed to reset its BE back to the minimum value of 3. And the devices choose anytime between, 0and (2BE-1) as the backoff wait duration. The insufficient distribution of the BE makes two or moredevices in many cases operate with an identical backoff time. Thus odds of two or more transmittingdevices choosing an identical backoff time, is increased.

A method to turn around this problem to see effective improvement in performance at collision ratesis developed by modifying the backoff mechanism of CSMA-CA. The new mechanism allows thedevices to choose from a wider set of available backoff exponent values. Thus minimizing the odds ofusing the same backoff wait duration. The new mechanism will effectively allow the devices to choose

70

6.1 CSMA-CA 71

any value within 1 and 7 based on their contribution to the network congestion. The more a nodecongests the network the more will be its BE. It has been observed that at lower datarates thismechanism allows the network to perform identical to the original scenario while considerablyimproving its performance at higher networks before succumbing to network congestion.

6.1 CSMA-CA

The CSMA-CA algorithm shall be used before the transmission of data or MAC command framestransmitted within the CAP, unless the frame can be quickly transmitted following theacknowledgment of a data request command. If beacons are being used in the PAN, the MAC sublayershall employ the slotted version of the CSMA-CA algorithm for transmissions in the CAP of thesuperframe. Conversely, if beacons are not being used in the PAN or if a beacon could not be locatedin a beacon-enabled PAN, the MAC sublayer shall transmit using the unslotted version of theCSMA-CA algorithm. In both cases, the algorithm is implemented using units of time called backoffperiods, where one backoff period shall be equal to aUnitBackoffPeriod symbols.

In slotted CSMA-CA, the backoff period boundaries of every device in the PAN shall be aligned withthe superframe slot boundaries of the PAN coordinator, i.e., the start of the first backoff period ofeach device is aligned with the start of the beacon transmission. In slotted CSMA-CA, the MACsublayer shall ensure that the PHY commences all of its transmissions on the boundary of a backoffperiod. Each device shall maintain three variables for each transmission attempt: NB, CW and BE.

NB: It is the number of times the CSMA-CA algorithm was required to backoff while attempting thecurrent transmission; this value shall be initialized to 0 before each new transmission attempt

CW: It is the contention window length, defining the number of backoff periods that need to be clear ofchannel activity before the transmission can commence; this value shall be initialized to 2 before eachtransmission attempt and reset to 2 each time the channel is assessed to be busy

BE: It is the backoff exponent, which is related to how many backoff periods a device shall wait beforeattempting to assess a channel. In slotted systems with macBattLifeExt set to FALSE, BE shall beinitialized to the value of macMinBE. In slotted systems with macBattLifeExt set to TRUE, this valueshall be initialized to the lesser of 2 and the value of macMinBE. The backoff wait duration is chosenas a random number of complete backoff periods in the range of 0 to (2BE-1).

The following steps are executed step by step to access the channel for transmission.

. STEP-1 : The MAC sublayer shall initialize NB, CW and BE, and then locate the boundary ofthe next backoff period.

. STEP-2 : The MAC sublayer shall wait for a random number of complete backoff periods in therange of 0 and (2BE-1).

. STEP-3 : At the completion of the backoff delay, the MAC shall request the PHY to perform aclear channel assessment. For a slotted CSMA-CA mechanism, the assessment shall begin at theboundary of the next backoff.

. STEP-4 : If the channel is assessed to be busy the MAC sublayer shall increment both NB andBE by one, ensuring BE is never greater than aMaxBE. CW is also reset to 2. If the value of NBis less than or equal to macMaxCSMABackoffs, the mechanism shall proceed with STEP-2again. If not, the CSMA mechanism shall terminate with a Channel Access Failure status.

6.1 CSMA-CA 72

. STEP-5 : If the channel is determined to be idle, the mechanism shall ensure that CW is equalto zero. If not it shall go back to STEP-3 to Clear channel assessment. Else if the contentionwindow is 0, the MAC shall start transmission immediately.

The above steps are indicated graphically in the figure 6.1.

Figure 6.1: Carrier Sense Multiple Access - Collision Avoidance

6.2 The Adaptive Backoff Mechanism 73

6.2 The Adaptive Backoff Mechanism

This mechanism is based on the principle of incrementing or decrementing the minimum backoffexponent value based on the nodes contribution to the network congestion. The Backoff Exponent of anode which contributes more to network traffic is incremented, basically making it wait longer beforeaccessing the channel. Similarly the BE of devices which contribute less comparatively to the othernodes are decremented making them wait for shorter durations to access the channel. As a result ofthis change, the devices which have been punished with longer backoff wait durations, contribute lessto the network traffic in the next analyzed cycle. And the other devices which have been contributingless, decreasing their BE makes them prey more on the channel and hence transmit more compared tothe other nodes. This would warrant their BE to be decreased in the next cycle. This mechanism thusanalyzes the performance of the devices in every cycle, producing a more random backoff durations.

The criteria for choosing a node for either decrementing or incrementing the backoff exponent, is itsmeasure of involvement in the network traffic. And this is measured by the coordinator by countingthe number of data packets received at its PHY, by each node involved in communication. Thecoordinator at the end of each cycle, would analyse the number of transmitted packets by each nodeand decide the nodes which need to decrement their BE and the nodes whose BE needs to beincremented. A maximum of 8 devices can be analyzed in any cycle. And this analyzed information isembedded in the beacon payload. This information contains the number of nodes which need todecrement their BE with the address list of those nodes and the number of nodes who have toincrement their BE, along with their short addresses. The nodes upon receiving the beacon check tosee if it is time yet to change their BE by analyzing the beacon payloads and on finding its addresslisted in any of those fields would act by either decrementing /incrementing according to the field.

The adaptive backoff algorithm will not interfere in the way CSMA-CA operates. Its only task is todetermine an appropriate macMinBE (minimum backoff exponent), which is used by CSMA-CA toreset the nodes BE after a successful channel access. Thus after every analyzing cycle, the coordinatordetermines the new macMinBE, for every node involved in a data transmission. And for everysuccessful transmission, the nodes will reset their backoff exponent to the minimum value thusdetermined by the coordinator. But the maximum backoff exponent value is limited by the PIBattribute, aMaxBE, which has been set to 7. Thus this would limit all devices to use a maximumbackoff of 7, therefore preventing them to wait an unreasonably longer duration to access the channel.

6.2.1 The Decision Criteria

The criteria used by the coordinator to determine which nodes shall decrement their minimum BEand the nodes which shall increment their minimum BE, is explained in the following steps. Before wego on to analyze the involved steps, a brief description of the involved parameters is described.

1. Group-1 : It comprises of devices/nodes whose macMinBE (minimum backoff exponent) is tobe decreased by 1. The group can contain a maximum of 4 nodes. These are the nodes whichcontribute less to the network traffic compared to the other nodes.

2. Group-2 : It comprises of devices/nodes whose macMinBE (minimum backoff exponent) is tobe increased by 1. The group can contain a maximum of 4 nodes. These are the nodes whichcontribute more in comparison to the other nodes. When, the transmitted packets by Group-2nodes differ from Group-1 nodes by atleast PKT DIFFERENCE number of packets, thealgorithm is applied.

3. PKT DIFFERENCE : It is the variable which is the deciding factor for the application of thealgorithm. If the difference between first element of Group-2 and the first element of Group-1 ismore than PKT DIFFERENCE number of packets, the algorithm is applied. And the


coordinator would include the group nodes under their positions in its beacon payload for thedevices to read and adjust their macMinBE accordingly.

4. numBeaconIntervals: The number of beacon intervals which comprises one analyzing cycle. Itis the time period after which the need for an adjustment of macMinBE is analyzed. This isdetermined as a number of beacon intervals after which this analysis is to be conducted.Example: If the beacon interval is 0.384secs (for BO=3), and the numBeaconIntervals=3, thenone analyzing cycle would be 1.152secs. Thus the core part of the algorithm is applied afterevery 1.152 seconds.

5. numReceivedPkts[i] : The array used to maintain the count of the number of packetscontributed by each transmitting source node to the network traffic.

6. nodeIndexes[i] : The array holding the node indexes of the sources which are transmitting tothe coordinator. The order of arrangement of the nodes in this array and their contributions asindicated by the array numReceivedPkts[i] is always matched. Arranging the contributions arrayin any order should make a corresponding adjustment to this array.

7. ’BeaconPayloadFields’ ABE Specification Fields: The specification field of the BeaconPayload of 1 octet in size, indicating the number of nodes whose macMinBE needs to bedecremented and the number of nodes whose macMinBE is incremented. The figure 6.5 wouldgive more understanding.

8. addrList[8] : The list of short addresses (2 octets) of devices whose minimum BE is incrementedor decremented. The first four node addresses indicate nodes whose minimum BE is decreasedby 1, while the end 4 node addresses indicate nodes whose minimum BE is increased by 1.

The following steps are conducted at the coordinator.

. STEP-1 : Initialize the following variables as given below. Note that the values are not absoluteand the correct tuning of these values is required to produce very efficient results. These valueshave been used in the simulations that follow, and have been observed to be producing goodresults as indicated.

– PKT DIFFERENCE : 5

– numBeaconIntervals: 3

– aMaxBE : 7

. STEP-2 : Wait for a packet reception, and on receiving a packet, check if the received packet isa data. If not, go back to STEP-1. If yes, follow STEP-3.

. STEP-3 : Increment the packet count for the source node of the packet. Check if the analyzingcycle is complete. If not, go back to STEP-2, else follow the next step (STEP-4).

. STEP-4 : Arrange the nodes in order of the number of packets contributed by each flow, so thatthe least contributor stays in the first place and the major contributor is placed at the last.

. STEP-5 : Check if the number of contributors are more than 8. If yes, go to STEP-6. If thecontributors are less than 8, go to STEP-7.

. STEP-6 : The first four elements of the contributors list form Group-1. And the last 4 elementscome under Group-2.


. STEP-7 : The first half of the nodes form Group-1 and the second half the Group-2. Check ifthe number of contributors are even. If odd arrange the middle element to either Group-1 orGroup-2. If the difference in the packet contribution of this node to the packet contribution ofthe first node is greater than PKT DIFFERENCE, the node is listed under Group-2, else itcomes under, Group-1. The figure 6.2 describes the division of the flows into groups in moredetail.

Figure 6.2: Group Arrangement

. STEP-8 : Check if the difference between the first elements of Group-2 and Group-1 is morethan PKT DIFFERENCE. If yes, include Group-1 elements in the decrement fields of thebeacon payload and Group-2 elements in the increment fields. Similarly include the number ofelements in Group-1 and Group-2 in the specification fields. If the difference in the first elementsis not significant, then set the specification fields to 0. Having done the above steps, reset thearrays, numReceivedPkts[i] and nodeIndexes[i], to prepare them for the next analyzing cycle.

The above steps are indicated graphically in the flow diagram 6.3.


Figure 6.3: Adaptive Backoff Exponent Algorithm


6.2.2 On Beacon Reception by a Node

The steps described so far indicate the actions done by the coordinator. It has taken its decision andhas indicated it in the beacon fields. Now it is up to the node to act according to the coordinatorsindication. The following steps are followed at every node that receives the beacon.

. STEP-1 : Upon beacon reception, the node extracts the ABE Beacon Payload Specificationfields.

. STEP-2 : See if the Beacon Payload Specification field is set to 0. If yes, continue with normaloperation. If no, calculate the number of decrements and number of increments.

. STEP-3 : Check if its address matches to the address list in the first four fields of the addrList.If yes, decrement its macMinBE by 1, and check if its equal to 0. If yes, set it to 1. If its addressis not listed in the first four address list, go to STEP-4.

. STEP-4 : Check if its address matches to the address list in the last four fields of the addrList.If yes, increment its macMinBE by 1. If its address is not listed, continue with the normalbeacon operation.

The above steps are highlighted in the flow diagram, 6.4

6.2.3 Beacon Modification

The algorithm utilizes additional space within the beacon payload to convey the coordinator’s decisionon the macMinBE adjustment. Hence additional space is required to indicate the number ofincrementing/decrementing nodes and their respective node addresses. The algorithm uses 1 octet toindicate the number of increments and decrements and a maximum of 16 octets to indicate the shortaddresses of the devices. Depending on the number of decrementing and incrementing nodes amaximum of 17 octets are used for this mechanism.

The figure 6.5 highlights the beacon fields concentrating on the ABE fields in detail.

Thus, applying a dynamically adjustable backoff mechanism would increase the size of the beacon by17 octets. However, since every beacon is transmitted in the first slot of the superframe, independentof the contention access and the free periods, there is no effect on the bandwidth utilization and thuswould bring in no overhead. However, when speaking of beacon overhead it cannot be entirely ruledout, since this has an impact on networks that operate at low beacon orders with the coordinatorperforming GTS management, as indicated in the following calculation.

The maximum size of a beacon can be calculated with the superframe duration as follows:

=SuperFrameDuration

16

=aBaseSuperframeDuration× 2SO

16

=aBaseSlotDuration× aNumSuperframeSlots× 2SO

16

=60× 16× 2SO

16= 60× 2SO

6.3 Results 78

Figure 6.4: Node Reaction on Reception of a Beacon

Using the figure 6.5 we can see that including the implementation of the Adaptive Backoff Exponent,we need a total of (2 + 1 + 10 + 2 + 17 + 2) = 34 octets. However when the network is operating at lowSuperframe Order (1 or 2), the slot duration is (for SO=2)60× 22 = 60× 4 = 240symbols = 240bits = 30octets. Thus a very low superframe order indicates thatthe above algorithm cannot be applied. And when operating at a SO=3,60× 23 = 60× 8 = 480symbols = 480bits = 60octets. Thus, at superframe orders greater than 2, thealgorithm can be applied successfully. However, there can be still restrictions to support a completeset of guaranteed time slots.

6.3 Results

This section produces the investigated performance metrics with new simulations and highlights theimprovement brought about by using the adaptive backoff exponent algorithm.

6.3 Results 79

Figure 6.5: Beacon Frame Format with ABE implementation

6.3.1 Throughput

With reference to the graph 6.6, it can be seen that the network throughput linearly increases until1.6pkts/sec to reach a peak of 6734 bits/sec, and then gradually settles at an average value of over6100 bits/sec. After 1.6pkts/sec a small drop in the throughput is observed indicating the start ofcongestion area to reach a throughput of 6100 bits/sec, which indicates the maximum performance ofthe system possible under these circumstances.

It can be observed from the figure that both the curves perform similarly as long as the network isfree from congestion, until 1.2pkts/sec, and as higher datarates are applied the ABE implementationallows the devices to choose a wider variety of random wait duration, which prevents the devices totransmit at the same time, less frequently. Thus bringing in less number of packet collisions, andhence less number of packet drops, as a result better throughput.

Figure 6.6: Throughput With ABE

6.3 Results 80

Peak data throughput obtainable applying Adaptive Backoff Exponent = 6.73 Kbps

Data throughput obtainable with less than 1sec packet delay, applying Adaptive Backoff Exponent =6.12 Kbps

With reference to 5.5, the peak throughput obtainable is 5.3kbps.

Improvement in peak throughput performance = 6.73−5.35.3 × 100 = 27%

Similarly, improvement at 99% delivery ratio can be calculated as follows, again with inputs from 5.5.

Improvement in peak throughput performance @ 99% delivery ratio = 6.554−5.255.25 × 100 = 24.8 = 25%

6.3.2 Delay Analysis

The graph 6.7 presents the delay analysis of the network as a function of traffic rate with theimplementation of ABE and without the implementation, with a 95% confidence levels.

Figure 6.7: Delay Analysis With ABE

As the graph indicates applying the ABE algorithm would push the congestion area farther until 1.5pkts/sec. Without the modification the devices reach congestion earlier. As long as the traffic rate isacceptable, the devices are able to disperse the packets, with few collisions recorded. The congestionarea is marked by the sudden increase in the average flight time of the data packets. After the networkreaches congestion, more and more collisions are reported, with many packet drops, which effects theaverage flight time of the packet, because of retransmissions. The steep increase in the delay after 1.3pkts/sec indicate a sudden spurt in collisions. Thus the implementation of ABE mends this area, until1.5pkts/sec after which it gives in to incredibly high traffic rate the bandwidth can support.

6.3 Results 81

Figure 6.8: Delivery Ratio with ABE Implementation


The graph 6.8 highlights the improvement brought about after the implementation of the ABEalgorithm. As is previously seen the new implementation delivers the packet with a precision of over99% until 1.5Pkts/sec. However, the incredibly high traffic rates after 1.5pkts/sec indicates the startof congestion area with high number of packet collisions and hence drops.

For QoS of over 90% packet delivery, with the implementation a maximum of 1.6Pkts/sec can besupported with the improvement, as compared to 1.3Pkts/sec supported without the improvement

However, the improvements brought about by the ABE improvement thereafter are undermined bythe very low delivery ratio and extremely high delay, making it impractical areas of application.

6.3.4 Energy

The graph highlights the energy analysis of the ABE implementation in comparison to the ordinarysystem performance without the improvement.

Figure 6.9: Energy Analysis for ABE Implementation

As can be seen in the figure, during the initial operation of 0.1-1.2 pkts/sec, the two methods showsimilar performance. This period of operation is within the congestion area, and the devices transmit

6.4 Battery Lifetime Calculation 82

at a much acceptable rates, hence the contributions of each nodes in comparison to other nodes is notconsiderable, to prompt the application of ABE algorithm, as frequently as in the cases of high datatransmissions. And as we go on applying higher datarates, the sudden transition to the congestionregion marked by higher number of packet drops, is visible in the graph, in the case of ordinaryoperation, by a sudden spurt in energy consumption. And the reasonable operation of the ABEalgorithm in terms of dropped packets, spends a gradual amount of energy to reach a maximum of0.4% of the initial energy. However, the energy performance remains the same after the datarates of1.7pkts/sec.

6.3.5 Link Quality Drops

The figure 6.10, depicts the number of packet drops due to LQI as a function of the data transmissionrate, operating with the ABE modification and without the modification. As can be seen the veryobjective of the implementation of ABE is realized with decreasing number of packet drops underABE, at congestion rates. However the higher rates at which the performance is considerablydegraded is not of much importance. The behavior at higher rates can be explained with reference toABE. As the datarates are increased beyond congestion levels, the transmitting nodes alter their BEaccording to their contribution to the traffic. Thus it is less likely that two or more transmittingdevices choose the same backoff duration, however, it is often is the case. But in comparison to theoperation without ABE, the performance is far better at congestion levels.

Figure 6.10: Link Quality Drop Analysis

6.3.6 Drops at Queue

The figure 6.11 again indicates the data packet drops due to queue overflow for the ABE and withoutABE implementation. As can be seen again, in the case of ABE implementation the performance ofthe system is far better at congestion rates. As the transmission rates increase the number of packetsaccumulated at the queue increase, and more and more packets are dropped when the system cannotdisperse the packets at the rate which can prevent Queue overflow.

6.4 Battery Lifetime Calculation

The following analysis would investigate the improvement brought about in the lifetime of a batteryby applying the Adaptive Backoff Exponent algorithm. This calculation is made with reference to thesection 5.7.1.

6.4 Battery Lifetime Calculation 83

Figure 6.11: IFQ Drops

The improvement brought about at peak performance area of 1.5Pkts/sec with nearly 100% deliveryratio, is 0.39277−0.3389

0.3389 × 100 = 15.89% ≈ 16%. Thus an application implementing the ABE at its MACwill use atleast 16% less energy.

Thus for a continuous data transmission of 1000 seconds the energy consumed is:

=0.3389× 13000

100= 44.057 Joules

Time taken to consume all of the initial energy is:

=1000× 13000

44.057= 295072.29 secs

= 4917.87 mins

= 81.96 hrs

= 3.4 days

Thus in a period of 3.4 days the application is going to run out of power, under the assumption ittransmits data continuously at 1.5pkts/sec.

A continuous data transmission at a rate of around, 1.5 Pkts/sec, would last a AA 1.5V battery foraround, 4917.87 mins. When assumed to transmit only for about 5mins a day, the battery would lastfor 4917.87

5 = 983.57 hours = 41 days. Thus the battery might last for a period of ≈1.5 months.

Calculated Battery Life ≈ 1.5 months @ 1.5pkts/sec, 5 mins/day


each node. This is equivalent to transmitting 245.62kilo bits of data per day.

Again the conditions as described in section 5.7.2 would apply in the current predictions.

6.5 Summary 84

6.5 Summary

The chapter starts with a brief introduction about the carrier sense multiple access - collisionavoidance mechanism. The inefficiency on part of the CSMA-CA for beacon management is indicatedand a path for the introduction of Adaptive Backoff Exponent management technique is laid. Thebackoff mechanism is used to dynamically manage the macMinBE of the devices depending on theircontribution to the network traffic. This allows the devices more room to manage their backoffduration which helps them use the same backoff less frequently thus avoiding collisions frequently. Ithas been observed that utilizing the above algorithm brings in significant changes in the performanceof the system.

The following results are highlighted with reference to the adaptive backoff exponent:

. Peak data throughput obtainable applying Adaptive Backoff Exponent = 6.73 Kbps

. Data throughput obtainable with less than 1 sec packet delay, applying Adaptive BackoffExponent = 6.12 Kbps

. Improvement in peak throughput performance = 27%

. Improvement in peak throughput performance @ 99% delivery ratio ≈ 25%

Chapter 7

Conclusions and Future Work

7.1 Conclusions

ZIGBEE is a promising new wireless short range communications technology. It may not have yetswept the short range communications market but it is surely making its presence felt. An alliance

of companies called the Zibgbee alliance, have already joined hands to benefit from this newtechnology and share information and develop new applications. With its promises of short rangecommunications with very low datarates and ultra low power consumption, it has created a market foritself.

The current project is focussed on providing a comprehensive report on the performance analysis ofzigbee wireless personal area networks operating at 868Mhz with reference to the ZMD’s proprietarytransceiver. This report concentrates on predicting possible working conditions of the technolgy at868Mhz operation. It highlighted the grey areas of operation which can be avoided. The areas ofoperation which have been producing satisfactory results and their possible application scenarios arepresented along with simulation results.

A detailed study of the zigbee technology with its internal architecture, and the layered structure hasbeen conducted. Followed by it is a similar study of the simulator environment (ns-2). A detailedstudy of the zigbee modules built under ns-2 with reference to its implementation in the standard alsohas been done. Later a well behaved and near realistic simulation scenario is built in TCL. The zigbeemodules have been exclusively tested for the simulator environment and several loopholes have beenidentified. These loopholes are further investigated to replace them with working modules. Some ofthe inconsistencies that have been replaced are Routing mechanism, the Address resolutionmechanism, the active and passive scan, the energy threshold and the carrier sense threshold, etc.

A detailed performance study for the said frequency has been done and the working areas have beenidentified. This has highlighted the inconsistency in the CSMA-CA algorithm which has been fixed bythe Adaptive Backoff Exponent mechanism. A comparative analysis focusing on the gain inperformance when using the new algorithm is presented.

The results indicate that the technology can be successfully used for low datarate applications withdurable battery life. It has been predicted that an application running for 5 mins a day and sleepingthe rest of the time and transmitting at 1.2 pkts/sec can last as long as 2 months. The maximum datathroughput obtainable with this technology has been calculated to be 5.3 kbps. And there is animprovement of ≈ 27% in the overall bandwidth available under this technology when applying theAdaptive backoff exponent mechanism. The reliability of data transmission also has been assessedwith the delivery ratio. And it has been seen that on applying the new backoff exponent algorithm thedevices can achieve a throughput of as much as 6.554 Kbps to achieve a QoS of 99% or better deliveryratio.

85

7.2 Future Work 86

With these predictions applying this technology for applications like home, industrial automationwhere the datarates are not higher and reliability and power consumption are critical, the technologyhas been proved to be worthwhile.

7.2 Future Work

This report has provided a comprehensive report on the performance analysis of the zigbee wirelesstechnology. However, there are several zigbee features that have not yet been implemented and tested.The following are some of the possible recommendations for possible future work.

. The guaranteed time slot management is one such issue which has not yet been implemented.Development of the software modules for the GTS implementation can be part of a very goodfuture work. Concepts like efficient bandwidth utilization with GTS and CAP, reliable datatransfer under these conditions, bandwidth sharing etc can be investigated.

. Similarly the software implementation for the sleep power mode of the devices is missing. Theenergy analysis presented in this picture provides a fairly estimated value. Even though thepredictions are assumed to be correct in most cases an accurate picture of the powerconsumption of the devices can be obtained with an investigation after the successfulimplementation of the sleep-power model.

. This report falls short of making a comparative analysis with respect to the 2.4Ghz. Lacks ofaccurate experimental data have hampered attempts to provide with such an analysis. Most ofthe simulation scenario has been already done. Thus obtaining correct experimental data fromreliable sources and conducting experiments can reveal interesting results for a comparativeanalysis.

. The study also focuses on a star topology formation with one way communication between thenodes and the coordinator with the transmission directed towards the coordinator. Thistopology can aptly simulate application scenarios like sensors reporting to a central node,controlling and monitoring systems. However, complex topologies like mesh can be formed anddata can be routed in real time. Thus an appropriate analysis with this technology using theseapplication scenarios can be simulated.

. Also the Advanced backoff exponent algorithm can be applied at congestion areas for the otherfrequency band of operation(2.4Ghz) to obtain a better performing system.

Appendix A

Source Code and Results

This section is intended to provide help on the navigation and arrangement of the software in the CDprovided with this report.

IMPORTANT NOTE

All scripts, programs, and scenario files provided in the software CD are thelastest versions. So when you need any of these programs for your simulationsuse the respective files compiled in this CD.

Also note that these programs and scripts have undergone innumerable alterationsto suite my simulation requirements. And every time the focus has been to get thedesired result in the least possible time rather than developing a compact andbug-free code. So please be aware of possible bugs, redundant code, or undesiredconsequences or results.

Hint: The best way to search for a key word in linux is to use the grep command.Use this command to search the current directory and all its sub-directories.Example: grep -i -r ‘‘prakash’’ *

The software is arranged into two sections, namely, source code, and results. The source codecomprises of all the latest software modules, programs, scripts, etc. Similarly the folder, resultscontain all the simulations conducted so far to generate the results listed in the chapter 5 and 6.

A.1 source code

All folders and files under the folder, source code are described here.

A.1.1 Directory: 868

It contains the zigbee software modules (wpan), personalized to 868Mhz simulation. It does not havecode implementing the Adaptive Backoff Exponent modification. For more details into the changesmade to the source code, search the files for the keyword, “prakash”.

87

A.1 source code 88

A.1.2 Directory: 868abe

It contains the zigbee software modules (wpan), personalized to 868Mhz simulation, implementing themodification, Adaptive Backoff Exponent, as described in the chapter 6. For more details into thechanges made to the source code, search the files for the keyword, “adaptive”.

A.1.3 Directory: analyze program

It contains the programs that are needed to produce the final results before graphs can be generated.The folder contains the files, analyze.cc, which can be compiled to generate the executable, analyze.This program requires the files, dfind avg868.awk and find avg868.awk in the current workingdirectory for the correct operation of the program. Running the program autosim would write theanalysis of the simulation for each run into the files, performance.txt and drops.txt. Copy these twofiles into this directory and execute the program to generate the final results in the following files. Ifthere are segmentation errors in the simulations which can be easily identified by observing the file,performance.txt, execute the program analyze to generate the average values for a certain number ofsuccessful simulations. This can be specified by the parameters, max simulations and min simulations.More about this in chapter-4.

1. final graphs 868.txt - Contains the average of successful simulations involving performancemetrics.

2. final drops 868.txt - Contains the average of successful simulations involving drop statistics.

3. new performance868.txt - Extract of the successful simulations from performance.txt and rewritethem into this file.

4. new drops868.txt - Extract of the successful simulations from drops.txt and rewrite them intothis file.

A.1.4 Directory: modified aodv for star topology

Contains the modified version of the aodv. It is reminded that since this project concentrates on thestar topology of operation routing mechanism has been disabled. Only the file aodv.cc has beenmodified. For more details into the changes made to the source code, search the files for the keyword,“prakash”.

A.1.5 Directory: modified mac for star topology

Contains the modified version of MAC. It is reminded that since this project concentrates on the startopology of operation ARP has been disabled. For more details into the changes made to the sourcecode, search the files for the keyword, “prakash”.

A.1.6 Directory: Traffic Generator

Contains several traffic generator script files. Copy the desired version of traffic generator over the file,cbrgen star.tcl, when running an automated simulation with autosim, since the file name has beenhardcoded into the executable.

A.1 source code 89

A.1.7 Directory: unmodified wpan

It contains a completely untouched version of wpan as is provided by the author. No modificationshave been implemented in any of the files of the directory.

A.1.8 File: autosim.cc

It is the source file for the excutable autosim. Certain parameters like the path to the scenario file,path to the ns executable, path to the traffic generator, etc are hardcoded. Hence make appropriatechanges before using it for your simulations. Also note that it has been changed over a million timesto suit my simulation requirements. Hence there may be code that might be absolutely irrelevant andoften confusing and misleading. User discretion is adviced.

A.1.9 File: avg throughput.awk

It is the source file of an awk script used to analyze the trace file generated as a result of a simulation.This script takes the trace file, wpan.tr as input and generates the analyzed results in the files,performance.txt and drops.txt.

A.1.10 File: p802 15 4phy PATCHED EDThresh.cc

It is a patched version of the file, p802 15 4phy.cc implementing the energy detection threshold, usage.This implementation distinguishes EDThresh with CSThresh . Note that this implementation isindependent of ABE.

A.1.11 parameters.txt

The file parameters.txt is used by the program autosim to generate the results according to theparameters specified here. It should be present in the working directory of the executable, autosim.

A.1.12 File: scen gen.cc

A program to place the nodes around the coordinator. The program can be compiled to generate theexecutable, scen gen.

A.1.13 File: traffic

An example traffic file, generated by any of the traffic generators listed in the section A.1.6. Note thatautosim needs this file to be present in the working directory.

A.1.14 File: wpan868.tcl

It is the network scenario file. More information can be found in the section 4.4.2.

A.1.15 File: wpan.scn

An example of the scenario file indicating the coordinates of the nodes placed around the coordinator.

A.2 results 90

A.2 results

The folder titled, results contains all the simulation results that have been obtained includng the excelgraphs. A brief explanation of the contents of each folder follows.

A.2.1 Directory: Performance Analysis

The performance analysis of the system working with the original code with the improvement broughtabout ABE is presented in this directory. The analysis of all the four simulations are highlighted inthe files, Performance Analysis for 868Mhz.xls andIdentical CSThresh Performance Analysis for 868Mhz.xls

BO3SO3 WITHOUT ABE RX -82dBm 1Way TrafficContains the simulations conducted with the following simulation parameters, the rest being the sameas indicated in the documentation earlier.

. BO = 3

. SO = 3

. Imrovement = None

. RXThresh = -82dBm

. CSThresh = -82dBm and -97dBm

. Number of Simulations = 22

. Traffic Direction = Node to the Coordinator

BO3SO3 WITHOUT ABE RX -87dBm 1Way Traffic

. BO = 3

. SO = 3

. Imrovement = None

. RXThresh = -87dBm





. BO = 3

. SO = 3

. Imrovement = None

. RXThresh = -92dBm

A.2 results 91





. BO = 3

. SO = 3

. Imrovement = None

. RXThresh = -97dBm

. CSThresh = -97dBm



A.2.2 Directory: ABE

The folder contains the study on the improvement brought about by the new algorithmimplementation (ABE). The file, ABE Performance 30runs.xls, highlights the results obtained by thesimulations.

WITH ABE -97dBm 1Way TrafficContains the simulation results performed with the following parameters. The rest of the parametersremain the same as indicated in the previous chapters.

. BO = 3

. SO = 3

. Imrovement = ABE

. RXThresh = -97dBm

. CSThresh = -97dBm


WITH ABE -97dBm 1Way Traffic

. BO = 3

. SO = 3

. Imrovement = None

. RXThresh = -97dBm

. CSThresh = -97dBm



Bibliography

[1] IEEE computer society, “Wireless MAC and PHY Specifications For LR-WPANS” IEEE,2003.

[2] Patricia McDermott-Wells, “What is Bluetooth” IEEE, pp. 33-35, December 2004/January2005.

[3] Y. Liu, M. Lee, and T.Saadawi, “A Bluetooth Scatternet Route structure for Multi-hop AdHoc Networks” IEEE JSAC, vol. 21, no. 2, pp. 229-239, Feb 2003.

[4] Jianliang Zheng, and Myung J. Lee, “Will IEEE 802.15.4 Make Ubiquitous Networking aReality?: A Discussion on a Potential Low Power Low Bit Rate Standard” IEEECommunications magazine, pp. 140-146, June 2004.

[5] Joseph M. Kahn, and John R. Barry, “Wireless Infrared Communications” IEEE, Vol. 85,N0. 2, pp. 265-298, February 1997.

[6] ZENSYS Inc., “Article: Z-Wave, The Wireless Control Language” www.zen-sys.com.

[7] Mikhail Galeev, “Article: Home networking with Zigbee” www.embedded.com, April 2004.

[8] ABI Research, “The ZigBee Wave: Some Hesitate, Some Plunge In” ABI Research,Spetember 2004.

[9] Gang Lu, Bhaskar Krishnamachari, Cauligi S. Raghavendra, “Performance Evaluation ofthe IEEE 802.15.4 MAC for Low-Rate Low-Power Wireless Networks” IEEE, pp. 701-706,2004.

[10] Kevin Fall, Kannan Varadhan, “The NS Manual” VINT Project, May 17, 2005.

[11] Eitan Altman, Tania Jimenez, “NS Simulator for beginners” Lecture Notes, Univ. de LosAndes, Sophia-Antipolis, December 4, 2003.

[12] http://ees2cy.engr.ccny.cuny.edu/zheng/pub/, “Zigbee Software Modules”, City College ofNewYork.

[13] http://www.energizer.com/, “Energizer Engineering DataSheet”, Energizer Battery Co.

[14] Qingshan Shan, Ying Liu, Gareth Prosser, David Brown, “Wireless Intelligent SensorNetworks for Refridgerated Vehicle”, IEEE 6th CAS Symposium on EmergingTechnologies, May 2004.

[15] Kwyro Lee, “MICROS: An Experimental Coin-sized, Low Cost, Low Power CMOSZigBee-like Radio at 2.4 GHz as an Ubiquitous Network Node”, 24th InternationalConference On Microelectronics (MIEL 2004, VOL 2, Serbia And Montenegro, 16-19 MAY,2004.

92

Bibliography 93

[16] Chris Evans-Pughe, “Bzzzz .. Is the ZigBee wireless standard, promoted by an alliance of25 firms, a big threat to Bluetooth?”, IEEE Review, March 2003.

[17] “What exactly is ... ZigBee?”, IEE Communirations Engineer, August/September 2004.

[18] Jeff Grammer, CEO, Ember Inc, “Zigbee Starts To Buzz”, IEE Review, November 2004.

[19] Sinem Coleri Ergen, “ZigBee/IEEE 802.15.4 Summary”, September 10, 2004.

[20] “ZigBee. Wireless Technology Made Simple”, RF & WIRELESS, May, 2005.

[21] Nick Baker, “ZigBee and Bluetooth, Strengths and Weaknesses for IndustrialApplications”, IEE Computing and Control Engineering, April/May , 2004.

[22] David Steed, Jr., MaxStream, “The Power of Sensitivity Improving range with receiversensitivity”.

[23] Pete Cross, “Zeroing in on ZigBee”, Circuit Cellar, Issue 176, March 2005.

The simulative Investigation of Zigbee/IEEE 802.15 · Zigbee/IEEE 802.15.4 Vaddina Prakash Rao for the degree Master of Science ... The goals of the thesis are to build a simulation

Documents