Investigating the Agent-based Ad Hoc Routing Algorithms - nexGIN RC

Investigating the Agent-based Ad Hoc Routing Algorithms: A Probabilistic Performance Evaluation Framework Based on Reliability Theory

By MUHAMMAD SALEEM (05-UET/PhD-CASE-CP-20)

Supervised By Dr. Muddassar Farooq DEPARTMENT OF ELECTRICAL & COMPUTER ENGINEERING CENTER FOR ADVANCED STUDIES IN ENGINEERING

UNIVERSITY OF ENGINEERING & TECHNOLOGY TAXILA PAKISTAN 2010

Investigating the Agent-based Ad Hoc Routing Algorithms: A Probabilistic Performance Evaluation Framework Based on Reliability Theory By Muhammad Saleem (05-UET/PhD-CASE-CP-20) Supervised By Dr. Muddassar Farooq A dissertation submitted in partial fulfillment of the requirements for the degree of

Doctor of Philosophy In COMPUTER ENGINEERING

DEPARTMENT OF ELECTRICAL & COMPUTER ENGINEERING CENTER FOR ADVANCED STUDIES IN ENGINEERING

UNIVERSITY OF ENGINEERING & TECHNOLOGY TAXILA PAKISTAN 2010

Dedication I dedicate this thesis to my loving parents and family. My father was an ordinary worker in Pakistan Railway and had hardly got any regular education. However, his love for education was indispensable. He taught me everything that a student needed before seeking admission in a school. His ambitions for all of us - brothers and sisters - were related to education and education only. He is no more in this world to see that his son has reached another landmark in his academic career. I pray that may Almighty Allah bless him with a home in the paradise (Ameen). To fill up his place, my mother is with me with all the prayers of this world and the hereafter. She witnessed me all the way from M.S. to Ph.D. completion. She just now want me to get rid of all this as soon as possible. Last but not least, my wife and the kids, were always there to let me know that the world has several other attractions that must be cherished other than the Ph.D. research. I appreciate the devotion and support of my wife during all the ups and downs of this Ph.D. journey. My son, Muhammad Wasil, wishes that I should spare my laptop for him now so that he can play his games freely. He does not know that I have to return it to CASE once the job is done.

Acknowledgements

First of all, I express my gratitude and thanks to Dr. Muddassar Farooq – my academic advisor – for identification and refinement of my research ideas. I remember the day he joined CASE as a faculty member. When I wished to work with him, he simply expressed his willingness for the supervision without knowing too much about my academic career. This was rather unusual response that is not expected from a professor of his caliber. As a result, unfortunately, he had to work harder to improve my research capabilities and paper writing skills. However, his confidence in my intellectual capabilities always encouraged me. His dedication to the profession is immaculate and inspirational for all his PhD students. I wish and pray for even a brighter future for his career. Then I would like to pay my heartiest thanks to Dr. Ali Khayam – Assistant Professor SEECS (NUST), Islamabad - for his guidance in resolving several issues related to my dissertation. Our first meeting during my Ph.D. proposal defense – he is a member of research monitoring committee – was not a pleasant one. But as every night is followed by a morning, our first meeting has opened several new research dimensions and Dr. Ali Khayam was always available for help and advice. I also pay thanks to other members of research monitoring committee for evaluating the quality of my work. I also owe sincere thanks to Higher Education Commission (HEC) of Pakistan for providing financial support during my M.S. and Ph.D. studies. I am grateful to Dr. Milli Pant – Assistant Professor Indian Institute of Technology (IIT) Roorkee, India – for her continuous encouragement and thesis review. I also thank to Ms Laala Rukh - Lecturer Bahria College Islamabad - for proof reading of the thesis. Finally, I thank the CASE administrative staff and faculty members for extending their help in all academic matters.

Abstract

Design and development of power-aware, scalable and performance efficient routing protocols for Wireless Sensor Networks (WSNs) is an active area of research. In this dissertation, we show that insect colonies based intelligence – commonly referred to as Swarm Intelligence (SI) – provides an ideal metaphor for developing routing protocols for WSNs because they consist of minimalists, autonomous individuals that through local interactions self-organize to produce system-level behaviors that show life long adaptability to changes and perturbations in an external environment. In this context, we propose a new routing protocol for WSNs – BeeSensor – inspired by the foraging principles of honey bees. We follow a three phase novel protocol engineering cycle. In the first phase, we study the foraging principles of a bee colony and utilize the inspirational concepts to develop a distributed, simple and energy-efficient routing protocol for WSNs. We then evaluate and compare the performance of this protocol with existing classical and SI-based WSN protocols. The simulation results demonstrate that BeeSensor consistently outperforms the existing well-known protocols in terms of packet delivery ratio and energy efficiency. However, its performance degrades slightly as the network size is increased. To gain more insights into the parameters governing the behavior of BeeSensor in large-scale networks, in the second phase, we develop a generic mathematical evaluation framework to model two key performance metric of an ad hoc routing protocol: routing overhead and route optimality. We then develop specific routing overhead and route optimality models of the BeeSensor protocol. The metric models unfold several interesting insights about the performance of BeeSensor in large-scale networks. For instance, with an increase in the average hop length, route discovery probability of BeeSensor decays exponentially. We also model the reliability of packet delivery of the BeeSensor protocol. The model shows that the reliability of packet delivery is a concave function of the total number of paths. Therefore,

maintenance of a set of paths beyond a certain threshold limit does not result in a proportional increase in the packet delivery ratio. Based on the insights inferred through the formal modeling, we revise the design of BeeSensor protocol in the third phase. To conclude this dissertation, we perform simulation studies – using prowler simulator – to analyze and compare the performance of the final BeeSensor design with existing protocols. In the first set of experiments, we compare its performance with SI-based energy-efficient WSN protocols. The simulation results demonstrate that BeeSensor outperforms its competitors in all assumed scenarios and metrics. We then implement the BeeSensor protocol in NS-2 simulator to further investigate its performance in mobile networks and large-scale static sensor networks. The results clearly show that BeeSensor not only performs well in large-scale networks, but is equally good in MANETs as well. Therefore, BeeSensor is a viable protocol for hybrid ad hoc networks.

Contents xviii 1 Introduction

1

1.1

Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.2

Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.3

Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.4

Major Contributions of the Dissertation . . . . . . . . . . . . . . . . . . . . . . .

7

1.4.1

A new bee-inspired routing algorithm for WSNs . . . . . . . . . . . . . .

7

1.4.2

A formal evaluation framework for ad hoc routing algorithms . . . . . . .

7

1.4.3

Reliability theoretic analysis of ad hoc routing algorithms . . . . . . . . .

8

1.4.4

Aggregation of in-network traffic in address-centric protocols . . . . . . .

8

1.4.5

Empirical evaluation framework . . . . . . . . . . . . . . . . . . . . . . . .

9

Organization of the Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.5.1

Chapter 2: Survey of routing protocols for wireless sensor networks . . . .

9

1.5.2

Chapter 3: BeeSensor: A simple, scalable and energy efficient routing

1.5

protocol for wireless sensor networks . . . . . . . . . . . . . . . . . . . . . 10 1.5.3

Chapter 4: Formal evaluation framework for ad hoc routing algorithms . 10

1.5.4

Chapter 5: Reliability theoretic analysis of ad hoc routing protocols . . . 12

1.5.5

Chapter 6: Design review and empirical evaluation of BeeSensor . . . . . 12

1.5.6

Chapter 7: Conclusions and future works . . . . . . . . . . . . . . . . . . 13

2 Survey of Routing Protocols for Wireless Sensor Networks 2.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.1.1

2.2

14

Organization of chapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Routing in WSNs: Challenging Issues . . . . . . . . . . . . . . . . . . . . . . . . 15 2.2.1

Minimal computational and memory requirements . . . . . . . . . . . . . 15

vi

CONTENTS

2.3

2.2.2

Autonomicity and self-organization . . . . . . . . . . . . . . . . . . . . . . 16

2.2.3

Energy efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.4

Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.5

Architecture matching the characteristics of traffic patterns . . . . . . . . 17

2.2.6

Support for in-network data aggregation . . . . . . . . . . . . . . . . . . . 17

Taxonomy of Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3.1

Single path and multipath routing . . . . . . . . . . . . . . . . . . . . . . 18

2.3.2

Reactive, proactive, and hybrid routing . . . . . . . . . . . . . . . . . . . 18

2.3.3

Source and next hop routing . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.4

Flat and hierarchical routing . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.3.5

Data-centric and address-centric routing . . . . . . . . . . . . . . . . . . . 19

2.3.6

Distributed and centralized routing . . . . . . . . . . . . . . . . . . . . . . 20

2.3.7

Best-effort and QoS-aware routing . . . . . . . . . . . . . . . . . . . . . . 20

2.3.8

Event-driven and query-based routing . . . . . . . . . . . . . . . . . . . . 20

2.3.9

Energy-aware routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.3.10 Loop-free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.11 Fault-tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.3.12 Load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4

ACO-based Routing Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4.1

Ant colonies and general principles of ACO for routing . . . . . . . . . . . 22

2.4.2

A general framework for SI-based routing . . . . . . . . . . . . . . . . . . 25

2.4.3

2.4.2.1

Mobile agent generation and management . . . . . . . . . . . . . 26

2.4.2.2

Routing information database (RID) . . . . . . . . . . . . . . . . 28

2.4.2.3

Agent communications . . . . . . . . . . . . . . . . . . . . . . . 28

2.4.2.4

Packet forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Review of ACO-based routing protocols . . . . . . . . . . . . . . . . . . . 29 2.4.3.1

Algorithms adapting AntNet to WSNs

. . . . . . . . . . . . . . 29

2.4.3.2

Data centric routing in WSNs . . . . . . . . . . . . . . . . . . . 31

2.4.3.3

Energy Efficient Ant Based Routing (EEABR) . . . . . . . . . . 33

2.4.3.4

Jumping Ant Routing Algorithm (JARA) . . . . . . . . . . . . . 34

2.4.3.5

Ant-based service-aware routing algorithm (ASAR) . . . . . . . 36

2.4.3.6

Probabilistic, Zonal and Swarm-inspired system for Wildfire Detection (PZSWiD) . . . . . . . . . . . . . . . . . . . . . . . . . . 37

vii

CONTENTS

2.4.3.7

AntChain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.4.3.8

Ant-aggregation algorithms . . . . . . . . . . . . . . . . . . . . . 40

2.4.3.9

ACO-based quality-of-service routing (ACO-QoSR) . . . . . . . 41

2.4.3.10 Self-organizing data gathering for multi-sink sensor networks (SDG) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4.3.11 Many-to-One Improved Ant Routing (MO-IAR) . . . . . . . . . 44 2.4.3.12 E-D ANTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 2.4.3.13 Other ACO-based protocols . . . . . . . . . . . . . . . . . . . . . 47 2.5

Classical Routing Protocols for Wireless Sensor Networks . . . . . . . . . . . . . 48 2.5.1

Directed Diffusion (DD) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

2.5.2

Constrained Random Walks on Random Graphs (CRWRG) . . . . . . . . 50

2.5.3

Active Query Forwarding in Sensor Networks (ACQUIRE) . . . . . . . . 52

2.5.4

Low Energy Adaptive Clustering Hierarchy(LEACH) . . . . . . . . . . . . 53

2.5.5

ReInForm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

2.5.6

SPEED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.5.7

Information Directed Routing . . . . . . . . . . . . . . . . . . . . . . . . . 56

2.5.8

Two-Tier Data Dissemination Model (TTDD) . . . . . . . . . . . . . . . . 57

2.5.9

Gradient Broadcast (GRAB) . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.5.10 BeamStar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 2.5.11 Other classical WSN protocols . . . . . . . . . . . . . . . . . . . . . . . . 63 2.6

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3 BeeSensor: A Simple, Scalable and Energy Efficient Routing Protocol for Wireless Sensor Networks 65 3.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.1.1

3.2

3.3

Organization of the chapter . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Bees in Nature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 3.2.1

Management of the colony agents . . . . . . . . . . . . . . . . . . . . . . . 69

3.2.2

An agent to group communication - the dance language . . . . . . . . . . 69

3.2.3

De-centralized control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.2.4

Energy-efficient foraging process . . . . . . . . . . . . . . . . . . . . . . . 70

3.2.5

Grouping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

3.2.6

Stochastic Selection of Foraging Sites

. . . . . . . . . . . . . . . . . . . . 71

From a Bee Colony to SensorNets . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

viii

CONTENTS

3.3.1 3.4

BeeSensor: Architecture and Working . . . . . . . . . . . . . . . . . . . . . . . . 73 3.4.1

3.4.2

3.5

3.6

Bee agent model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 3.4.1.1

Packers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3.4.1.2

Scouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.4.1.3

Foragers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.4.1.4

Swarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Scouting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 3.4.2.1

Forward scouting . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

3.4.2.2

Backward scouting . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.4.3

Foraging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

3.4.4

Swarming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.4.5

Routing loops and path maintenance . . . . . . . . . . . . . . . . . . . . . 82 3.4.5.1

Routing loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

3.4.5.2

Path maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A Review of SI-Inspired Routing Protocols Used in Comparison . . . . . . . . . . 83 3.5.1

Flooded Piggybacked Ant Routing (FP-Ant) . . . . . . . . . . . . . . . . 84

3.5.2

Energy Efficient Ant Based Routing (EEABR) . . . . . . . . . . . . . . . 84

3.5.3

Ad-hoc On-demand Distance Vector (AODV) Routing Protocol . . . . . . 85

Empirical Evaluation Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 3.6.1

3.7

BeeSensor: The mapping of concepts . . . . . . . . . . . . . . . . . . . . . 72

Description of evaluation metrics . . . . . . . . . . . . . . . . . . . . . . . 88 3.6.1.1

Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.6.1.2

Packet delivery ratio . . . . . . . . . . . . . . . . . . . . . . . . . 88

3.6.1.3

Energy consumption . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.6.1.4

Energy efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.6.1.5

Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.6.1.6

Algorithmic complexity . . . . . . . . . . . . . . . . . . . . . . . 89

3.6.1.7

Control overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

3.6.1.8

Control complexity . . . . . . . . . . . . . . . . . . . . . . . . . 89

Discussion on Simulation Results . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.7.1

Packet delivery ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

3.7.2

Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

3.7.3

Total Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . 92

ix

CONTENTS

3.8

3.7.4

Energy Efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

3.7.5

Algorithmic Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

3.7.6

Control Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

3.7.7

Control Complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.7.8

Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4 Formal Evaluation Framework for Ad Hoc Routing Algorithms 4.1

4.2

4.3

4.4

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.1.1

Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

4.1.2


Introduction to Graph Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.2.1

Neighbors or adjacent vertices . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.2.2

Degree of a Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

4.2.3

Connectivity of a graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

System Description and Modeling Assumptions . . . . . . . . . . . . . . . . . . . 107 4.3.1

Modeling Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.3.2

Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 4.4.1

Routing Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.4.2

Optimal and suboptimal routes . . . . . . . . . . . . . . . . . . . . . . . . 109

4.4.3

Broadcast forwarding probability . . . . . . . . . . . . . . . . . . . . . . . 111 4.4.3.1

4.5

101

Expected Forward Degree . . . . . . . . . . . . . . . . . . . . . . 111

The Routing Overhead Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 4.5.1

4.5.2

4.5.3

The generic routing overhead model in terms of expected forward degree . 113 4.5.1.1

Expected forward degree . . . . . . . . . . . . . . . . . . . . . . 115

4.5.1.2

Collision and contention modeling . . . . . . . . . . . . . . . . . 122

4.5.1.3

Channel error modeling . . . . . . . . . . . . . . . . . . . . . . . 124

4.5.1.4

Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Optimized flooding of RREQs . . . . . . . . . . . . . . . . . . . . . . . . . 125 4.5.2.1

Ring search

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

4.5.2.2

Stochastic flooding / gossiping . . . . . . . . . . . . . . . . . . . 126

4.5.2.3

A hybrid approach . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Comparison of analytical and simulation results . . . . . . . . . . . . . . . 127

x

CONTENTS

4.6

4.6.2

4.6.3

4.8

Protocol specific routing overheads . . . . . . . . . . . . . . . . . 127

4.5.3.2

Comparison of routing overhead model with simulation results . 128

Route Optimality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 4.6.1

4.7

4.5.3.1

The generic route optimality models . . . . . . . . . . . . . . . . . . . . . 131 4.6.1.1

Probability of optimal path discovery . . . . . . . . . . . . . . . 132

4.6.1.2

Probability of suboptimal path discovery . . . . . . . . . . . . . 133

4.6.1.3

Expected probability of path establishment . . . . . . . . . . . . 135

Protocol specific route optimality models . . . . . . . . . . . . . . . . . . 137 4.6.2.1

DSR and AODV . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

4.6.2.2

DSDV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Comparison of route optimality model with simulation results . . . . . . . 139

Derivatives of Routing Overhead and Route Optimality . . . . . . . . . . . . . . 141 4.7.1

Energy consumption model . . . . . . . . . . . . . . . . . . . . . . . . . . 141

4.7.2

Route discovery latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Routing Overhead and Route Optimality Models of BeeSensor . . . . . . . . . . 142 4.8.1

4.8.2

Routing overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 4.8.1.1

Analytical results . . . . . . . . . . . . . . . . . . . . . . . . . . 145

4.8.1.2

Evaluation of BeeSensor in mobile scenarios . . . . . . . . . . . 148

Route optimality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 4.8.2.1

4.8.3 4.9

Analytical results . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

5 Reliability Theoretic Analysis of Ad Hoc Routing Protocols 5.1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 5.1.1

5.2

5.3

156


Background on Reliability Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 157 5.2.1

Structure functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

5.2.2

System and component reliabilities . . . . . . . . . . . . . . . . . . . . . . 158

5.2.3

Series and parallel systems . . . . . . . . . . . . . . . . . . . . . . . . . . 158

5.2.4

𝑘-out-of-𝑛 system with equal reliabilities . . . . . . . . . . . . . . . . . . . 159

5.2.5

Path sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

System Description and Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 160 5.3.1

System description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

xi

CONTENTS

5.3.2 5.4

5.5

5.6

Packet Delivery Reliability of BeeSensor . . . . . . . . . . . . . . . . . . . . . . . 161 5.4.1

The reliability model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

5.4.2

Concavity of the reliability function . . . . . . . . . . . . . . . . . . . . . 164

The Safe Flooding Distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 5.5.1

Reliability model of information flooding . . . . . . . . . . . . . . . . . . . 165

5.5.2

The model of safe flooding distance . . . . . . . . . . . . . . . . . . . . . . 167

Reliability Analysis of Ad Hoc Routing Algorithms: An Application Perspective 168 5.6.1

Improving packet delivery reliability using partially-disjoint paths

5.6.2

Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

5.6.3

Discovering partially-disjoint paths in ad hoc routing protocols . . . . . . 172

5.6.4

5.7

Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.6.3.1

Modifications to route request (RREQ) . . . . . . . . . . . . . . 173

5.6.3.2

Modifications to route reply (RREP) . . . . . . . . . . . . . . . 174

Empirical validation of the reliability models . . . . . . . . . . . . . . . . 174 5.6.4.1

Definitions of the evaluation metrics . . . . . . . . . . . . . . . . 176

5.6.4.2

Discussion on results . . . . . . . . . . . . . . . . . . . . . . . . 176

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

6 Design Review and Performance Analysis of BeeSensor 6.1

6.3


Modifications to BeeSensor Design . . . . . . . . . . . . . . . . . . . . . . . . . . 183 6.2.1

Aggregation and Suppression of Multiple Scouting . . . . . . . . . . . . . 183

6.2.2

A hierarchical network architecture

6.2.3

Fewer node-disjoint paths . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

. . . . . . . . . . . . . . . . . . . . . 185

Empirical Evaluation of BeeSensor . . . . . . . . . . . . . . . . . . . . . . . . . . 187 6.3.1

Comparison of BeeSensor with SC-Ant and FF-Ant . . . . . . . . . . . . 188 6.3.1.1

6.3.2

6.3.3


Performance analysis of BeeSensor on large-scale sensor networks . . . . . 193 6.3.2.1

Description of the evaluation metrics . . . . . . . . . . . . . . . 195

6.3.2.2


Performance analysis of BeeSensor in mobile ad hoc networks . . . . . . . 205 6.3.3.1

6.4

182

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 6.1.1

6.2

. . . . 169


Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

xii

CONTENTS

7 Conclusions and Future Works

210

7.1

Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

7.2

Future Work: Suggestions and Directions . . . . . . . . . . . . . . . . . . . . . . 212 7.2.1

Formal evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212

7.2.2

Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

7.2.3

Real testbeds evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

7.2.4

Secure routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

7.2.5

Bee Colony Optimization (BCO) Metaheuristic . . . . . . . . . . . . . . . 215

A

216 A.1 A Geometrical Model of Expected Forward Degree . . . . . . . . . . . . . . . . . 216 A.2 Bounds on the Reliability Function of BeeSensor . . . . . . . . . . . . . . . . . . 219

References

236

xiii

List of Figures 1.1

Internal architecture of a sensor node . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.2

A multihop wireless sensor network . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1

Diagram of the common routing framework for SI routing protocols. . . . . . . . 26

2.2

JARA: nodes 𝐴, 𝐵, 𝐶, 𝐷 and 𝐸 are interior nodes, 𝐸, 𝐹 , 𝐺 and 𝐻 are boundary nodes, 𝑆 is the central node. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.3

Expansion and compression stages in CRWRG: Stage above the main diagonal is the expansion stage while the one below it is the compression stage . . . . . . 51

2.4

Grid structure formed by source node 𝐴 . . . . . . . . . . . . . . . . . . . . . . . 58

2.5

Location discovery in BeamStar (a) transmission with SN=RN=1, (b) transmission with SN=1, RN=2, (c) transmission with SN=1, RN=3, and (d) transmission with SN=2, RN=1 (taken from [1]). . . . . . . . . . . . . . . . . . . . . . . . 62

3.1

Forward scouting in BeeSensor with 𝐻𝑙 = 2 . . . . . . . . . . . . . . . . . . . . . 75

3.2

Backward scouting in BeeSensor . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

3.3

Backward scouts follow a high reward path and thus travel against the gradients

3.4

Performance Evaluation Framework . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.5

Algorithmic description of evaluation framework . . . . . . . . . . . . . . . . . . 87

3.6

Packet delivery ratios for the two scenarios . . . . . . . . . . . . . . . . . . . . . 90

3.7

Latencies for the two scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

3.8

Total energy consumption for the two scenarios . . . . . . . . . . . . . . . . . . . 93

3.9

Energy efficiency for the two scenarios . . . . . . . . . . . . . . . . . . . . . . . . 94

83

3.10 Cyclic complexities for the two scenarios . . . . . . . . . . . . . . . . . . . . . . . 96 3.11 Control overhead for the two scenarios . . . . . . . . . . . . . . . . . . . . . . . . 97 4.1

Connectivity of a graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

xiv

LIST OF FIGURES

4.2

Propagation of route discovery messages in an ad hoc network . . . . . . . . . . . 112

4.3

Illustration of forward degree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

4.4

An ad hoc network with source node 𝑆 at the center. Each ring has a radius of 𝑟0 − 𝜆 except the innermost ring with a radius 𝑟0 . . . . . . . . . . . . . . . . . . 117

4.5

Start of route discovery: Red color shows that source node 𝑆 transmits a RREQ which is received by nodes in the green ring of radius 𝑟0 . . . . . . . . . . . . . . . 117

4.6

Neighbors of 𝑆 – nodes in red ring – broadcast which is received by nodes in the green ring i.e. Ring 𝐼. Arrows at the periphery of the ring shows that the nodes within the ring are currently transmitting. . . . . . . . . . . . . . . . . . . . . . . 118

4.7

Nodes in red ring – i.e. Ring 𝐼 – broadcast which is heard in Ring 𝐼𝐼 – shaded green. The inactive area is shown in gray color. . . . . . . . . . . . . . . . . . . . 118

4.8

Nodes in ring 𝐼𝐼 broadcast which is heard in ring 𝐼𝐼𝐼. Inner rings are inactive and hence are grayed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

4.9

Nodes in ring 𝐼𝐼𝐼 broadcast which is heard in ring 𝐼𝑉 . . . . . . . . . . . . . . . . 120

4.10 Expected forward degree at different hops from the source node . . . . . . . . . . 122 4.11 Route discovery in an ad hoc network: Source node broadcasts a RREQ which is flooded in the entire network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 4.12 Packet routing probability through optimal / suboptimal paths reported in [2]. . 140 4.13 Optimal / suboptimal path discovery probabilities: analytical results. . . . . . . 140 4.14 Routing overhead of BeeSensor for different values of broadcast forwarding probabilities (𝑝𝑠 = 𝑝𝑏 × 𝑝𝑐 × 𝑝𝑒 ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 4.15 Routing overheads of BeeSensor, BeeSensor-R and AODV for different network topologies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 4.16 Example illustration of mobile scenarios. . . . . . . . . . . . . . . . . . . . . . . . 147 4.17 Optimal and suboptimal path discovery probabilities with 𝑡 = 2 . . . . . . . . . . 150 4.18 Optimal and suboptimal path discovery probabilities with 𝑡 = 3 . . . . . . . . . . 150 4.19 Expected probability of route discovery of BeeSensor and AODV. . . . . . . . . . 151 4.20 Expected probability of route discovery of BeeSensor at various values of 𝑝𝑠 = 𝑝𝑏 × 𝑝𝑐 × 𝑝𝑒 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 5.1

A series and a parallel system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

5.2

A pair connected through 𝑚 node-disjoint paths. . . . . . 162

5.3

Packet delivery reliability of BeeSensor. . . . . . . . . . . . . . . . . . . . . . . . 163

xv

LIST OF FIGURES

5.4

Flooding as a series system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

5.5

Safe flooding distance at various reliabilities levels. . . . . . . . . . . . . . . . . . 168

5.6

Example of a node-disjoint and a partially-disjoint path. . . . . . . . . . . . . . . 170

5.7

A pair of nodes, separated by flooding distance 𝑡, linked through a set of nodedisjoint / partially-disjoint paths. . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

5.8

Reliability comparison of node-disjoint and partially-disjoint paths. . . . . . . . . 172

5.9

An illustration of flooding-based route discovery in ad hoc networks to discover node-disjoint paths. Solid lines show the links which shall be discovered while red-and-dashed lines represents undiscovered links. A RREQ received at 𝐷 with the source routing header (as in DSR) is also shown to further elaborate the process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

5.10 Packet delivery ratios of DSR-PD and DSR-FD against speed, no. of flows, network size and packet sending rate. . . . . . . . . . . . . . . . . . . . . . . . . . 177 5.11 Packet latencies of DSR-PD and DSR-FD against speed, no. of flows, network size and packet sending rate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 5.12 Average used energy of DSR-PD and DSR-FD against speed, no. of flows, network size and packet sending rate. . . . . . . . . . . . . . . . . . . . . . . . . . . 180 6.1

An hierarchical sensor network equipped with long-haul nodes . . . . . . . . . . . 186

6.2

Packet delivery ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

6.3

Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

6.4

Energy efficiency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

6.5

Control overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

6.6

Network lifetime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

6.7

Minimum remaining energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

6.8

Flat network with a global sink node . . . . . . . . . . . . . . . . . . . . . . . . . 194

6.9

Hierarchical network with four long-haul nodes (LHN), an access point (AP) and a global sink

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

6.10 Packet delivery ratio Vs. network size . . . . . . . . . . . . . . . . . . . . . . . . 197 6.11 Packet delivery ratio Vs. number of source nodes . . . . . . . . . . . . . . . . . . 198 6.12 Packet delivery ratio of BeeSensor with a flat and hierarchical network against different number of source nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 6.13 Latency Vs. network size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

xvi

LIST OF FIGURES

6.14 Latency Vs. number of source nodes . . . . . . . . . . . . . . . . . . . . . . . . . 200 6.15 Latency of BeeSensor with a flat and hierarchical network against different number of source nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 6.16 Normalized routing overhead Vs. network size . . . . . . . . . . . . . . . . . . . . 201 6.17 Normalized routing overhead Vs. number of source nodes . . . . . . . . . . . . . 202 6.18 Normalized routing overheads of BeeSensor with a flat and hierarchical network against different number of source nodes . . . . . . . . . . . . . . . . . . . . . . . 202 6.19 Average used energy Vs. network size . . . . . . . . . . . . . . . . . . . . . . . . 203 6.20 Average used energy Vs. number of source nodes . . . . . . . . . . . . . . . . . . 204 6.21 Average used energy of BeeSensor with a flat and hierarchical network against different number of source nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 6.22 Packet delivery ratio Vs. number of flows . . . . . . . . . . . . . . . . . . . . . . 206 6.23 Latency Vs. number of flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 6.24 Normalized routing overheads Vs. number of flows . . . . . . . . . . . . . . . . . 208 6.25 Average used energy Vs. number of flows . . . . . . . . . . . . . . . . . . . . . . 209 A.1 Propagation of route discovery messages in an ad hoc network . . . . . . . . . . . 217 A.2 Overlapping transmission circles of Node S and T . . . . . . . . . . . . . . . . . . 217 A.3 A sparse network with nodes having equal expected forward degree . . . . . . . . 219

xvii

List of Tables 2.1

Features of ACO-based routing protocols for WSNs. . . . . . . . . . . . . . . . . 49

2.2

Features of classical routing protocols for WSNs. . . . . . . . . . . . . . . . . . . 61

3.1

Control complexity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

3.2

Lifetime of the network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

4.1

Description of Modeling Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

4.2

Routing overhead: Simulation results reported by Broch et al. [2] Vs. the analytical results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129

4.3

Routing overhead of BeeSensor-R under mobility . . . . . . . . . . . . . . . . . . 148

5.1

Total transmissions required to route a packet at a desired reliability level . . . . 173

5.2

Simulation parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

xviii

Chapter 1

Introduction Wireless Sensor Networks (WSNs) are emerging as a technology that can revolutionize the world we currently live in. Initially, they were intended to be used for military purposes only. However, with advances in Micro-Electro-Mechanical Systems (MEMS) technology, WSNs have passed the barrier in a very short span of time. MEMS refers to the fabrication of micromechanical components e.g. sensors, actuators etc. and the silicon-based microelectronic components on a single silicon substrate. Microelectronic components are the brain of a modern system and MEMS is equipping this brain with the monitoring and actuating capabilities to control its operation. Sensor nodes are one of the several products of the MEMS technology which can sense an environmental parameter, process and communicate it remotely to a base station. Consequently, the application spectrum of WSNs has expanded which dragged the focus of research community, academia and the industry (the three main pillars of todays market). Automatic detection and prevention of natural disasters, home automation, habitat monitoring, remote patient monitoring, security and tactical surveillance, target tracking and intrusion detection are just a few from an endless list of WSN applications. Wireless sensor networks (WSNs) [3] consist of large number of autonomous sensor nodes which have on-board sensors, wireless transceivers, a small processor and a battery (see Fig. 1.1). Consequently, when sprayed in a targeted area, they are capable of forming a communication network on the fly. The nodes are usually statically deployed over large areas. They can also be housed in mobile vehicles and can interact with the environment as well. In these special cases, the network is more appropriately referred to as a robotic network and/or a sensor-actor network. The purpose of a sensor node is to sense a given physical variable – for instance temperature – and communicate it to a base station where it is utilized for decision

1

Figure 1.1: Internal architecture of a sensor node making. A typical WSN architecture is shown in Fig. 1.2 in which sensor nodes transfer the sensed information in multiple hops fashion to a base station. Sensor node(s) may be forced to sense and communicate through a query injected into the network from a certain node e.g. base station. Otherwise, sensor nodes may activate automatically on an event detection e.g. the environment temperature has exceeded a given threshold limit. Ideally, a WSN should be scalable and energy-efficient, smart and configurable, reliable and long-lived, highly responsive and incur small installation and maintenance cost. However, the goals are optimistic taking into view the available limited resources. WSNs are distinguished from other types of ad hoc networks primarily due to the limited capabilities of a sensor node. For instance, a typical processor available on a sensor node may have a clock rate of 8 – 400 MHz [4]. On-board memory of a sensor node may lie in the range of 32 – 512𝐾 Kbytes, which may be further extended to few MBytes by external means. Battery of a sensor node is one of the most critical components. In most cases, it is non-rechargeable or is infeasible to recharge them when nodes are deployed in huge number e.g. few thousands. Consequently, energy-efficient operation of every single component of a sensor node, shown in Fig. 1.1, is the prime requirement in a WSN. With such limited hardware resources, accomplishing the ideal characteristics of a WSN is an extremely challenging task if not impossible. Routing protocol is the nervous system of any computer network. In a network, where

2

Sensor node

Base station

Gateway sensor node Wireless link

Figure 1.2: A multihop wireless sensor network hundred or thousands of nodes are working simultaneously, the job of a routing protocol is to identify / discover one or more paths connecting a pair of nodes under a given set of constraints. The discovered paths are then used for information exchange. The routing constraints may vary. For instance, an application might require delivering information with a minimum delay. Furthermore, the type of network also plays an important role in the decision of routing constraints. Take for example a fixed network where the nodes are resource-sufficient and are wired to each other. Therefore, the prime requirement for a routing protocol is to optimize the network performance. On the other hand, ad hoc networks form a distinct category of networks. Nodes are wirelessly connected to each other and may be in constant random motion (e.g. Mobile Ad Hoc Networks(MANETs) ). Now, in such a network, wireless medium and mobility poses another set of constraints. A MANET routing protocol’s prime function is to maintain the connectivity between a pair of nodes in the face of a frequently changing network topology. WSNs are a specialized class of ad hoc networks and routing in such networks has even different set of requirements. Data communications can be directed from a sensor node to a monitoring node for inference (the most common communication pattern), from a sensor/monitoring node to another sensor/monitoring node to realize some form of local cooperation, or from a monitoring node to one or more sensor nodes to disseminate control information. From the

3

1.1 Motivation

point of view of information processing, the aggregation of the sensed data and the consequent statistical inference can be realized in a number of different ways that results in a number of different network architectures. In the most studied cases [5], individual sensor nodes send their readings towards: (i) a global monitoring node – sink or a base station– that performs full data aggregation and inference, (ii) intermediate sink nodes that can individually or cooperatively process the data before sending the results to the global sink or locally trigger the appropriate actions, (iii) a global sink, but with partial data aggregation being executed as the data moves hop by hop from the sensor nodes towards the sink. Cases (ii-iii) are referred to as in-network aggregation, and are meant to save energy and bandwidth. Routing in WSNs has been a challenging task primarily because of limited hardware resources available at a sensor node. Consequently, routing protocols are designed with low processing complexity and minimum communication overhead. Since the sensor nodes mostly operate in pervasive environments with no user intervention; therefore, routing must be done through distributed and decentralized controllers at each node, which through local and partial information should be able to self-organize and take adaptive routing decisions in response to changing external environments. Moreover, the protocols must be scalable, performance efficient with an ability to keep the network alive for a longer period of time [6].

1.1

Motivation

Swarm intelligence (SI) [7, 8, 9] is a relatively novel field that was originally defined as “Any attempt to design algorithms or distributed problem-solving devices inspired by the collective behavior of social insects and other animal societies” [7]. However, nowadays it refers more generally to the study of the collective behavior of systems composed of many components that coordinate using decentralized controls and self-organization. From an engineering point of view, SI emphasizes the bottom-up design of autonomous distributed systems that can show adaptive, robust, and scalable behaviors. The SI encompasses other popular frameworks such as Ant Colony Optimization (ACO) [10, 11] and Particle Swarm Optimization [9]. Most of the work in the field of SI design has been and still is mainly inspired by the reverse engineering and adaptation of collective behaviors observed in natural systems such as insect societies e.g. ants or bees colonies. The analogy with the characteristics and the requirements of routing in WSNs and a bee colony is striking. A honey bee colony collectively solves the routing problems to discover and

4

1.2 Problem Statement

setup optimized paths to foraging sites and subsequently route back and forth the individuals from colony’s hive to the sources of food. Paths result from the synergistic interaction among a large number of relatively simple individuals that concurrently sample paths and inform the other individuals about their characteristics using indirect and direct communication schemes e.g , tremble and waggle dance. The observed colony’s behavior is adaptive to environmental variations, robust to losses of individuals, and fully distributed and scalable. The bee colony can be seen as a distributed adaptive system of smart control packets that make use of little computing and energy resources to explore the network, and that efficiently cooperate by exchanging routing information with their colleagues about the discovered paths and their quality. These characteristics have already been applied successfully for the development of two stateof-the-art routing protocols: (1) BeeHive [12] which is specially designed for packet switched networks, and (2) BeeAdHoc [13] for mobile ad hoc networks. BeeHive delivers better performance with a simple agent model in fixed networks as compared to existing algorithms. On the other hand, BeeAdHoc delivers similar or better performance and is more energy-efficient than other ad hoc routing algorithms. The success of BeeHive and BeeAdHoc and resemblance of a bee colony food collection with a WSN are the two prime motivations of this work.

1.2

Problem Statement

Agents in a bee colony – although have limited individual capabilities – through local coordination: (1) produce an highly organized and efficient system level behavior, (2) show adaptivity to a constantly changing environment, (3) exhibit resilience to loss of individuals, and (4) scale well to larger populations. Therefore, we believe that it can serve as an ideal metaphor for developing a routing protocol for WSNs which have identical characteristics. In this context, the objective is: 1. to engineer an event-driven, simple, scalable, reliable, decentralized and energy-efficient multipath routing protocol for WSNs through nature-inspired simple bee agents. 2. to evaluate the performance of the resulting WSN routing protocol through sound mathematical and empirical evaluation techniques. The new routing protocol should meet the following set of requirements that are fundamentally important in WSNs.

5

1.3 Research Methodology

✓ The bee agent model should be simple and easily realizable. Simplicity of a bee agent indirectly requires that its size should be minimal. ✓ Processing of bee agents on intermediate nodes must be time and memory efficient. ✓ Routing protocol must be scalable to large network topologies and able to handle high traffic loads. ✓ Routing protocol must conserve energy in every possible manner without compromising the network performance in terms of packet delivery. ✓ It must incorporate mechanism to aggregate in-network traffic as close to the source as possible. ✓ It must have decentralized control so that it can self-organize and able to adapt to topological changes in the network.

1.3

Research Methodology

In this section, we outline the research methodology that is followed for the design of a new bee-inspired routing protocol for WSNs. 1. We first investigate the constraints and requirements of WSNs. This helps in understanding the environment in which the newly proposed routing protocol is expected to operate. We call it the requirement engineering phase. 2. In the second stage of dissertation, we study the foraging principles of a honey bee colony in-order to take inspiration from the relevant concepts for our new WSN routing protocol.

3. We then map the principles of a bee colony to a real world problem – routing in WSNs. Steps 2 and 3 are a part of the natural engineering phase [12]. 4. Having done the above steps, we enter the protocol engineering phase. We transform the natural concepts into the algorithmic details of our new routing protocol for WSNs. 5. We analyze the performance of the proposed routing algorithm through empirical and formal techniques to gain insights into the parameters governing its behavior in an ad hoc network.

6

1.4 Major Contributions of the Dissertation

6. We revise the initial design proposed in step 4 by incorporating the changes inferred through mathematical analysis (step 5). 7. In the evaluation phase, we extensively evaluate the performance of the final design of our routing protocol through simulation studies to show that it meets the design objectives.

1.4

Major Contributions of the Dissertation

Protocol engineering is a type of multi-objective optimization problem and is, therefore, complex. We have followed a rather novel approach in the design and development of a new routing protocol for WSNs. Novelty of our approach stems from the fact that we utilize mathematical modeling not only as a part of the BeeSensor’s evaluation process, but also use it in the protocol engineering phase. Few sparse attempts for performance modeling of ad hoc networks have been reported in the literature. However, to the best of our knowledge, none of them utilize the feedback of the models to improve the protocol design. In this context, we have worked in several dimensions and made significant contributions in each area. In this section, we highlight all the major contributions of our five years research on this project.

1.4.1

A new bee-inspired routing algorithm for WSNs

We show, in this dissertation, that agent-based system that take inspirations from the natural system can show adaptive, robust, and scalable behaviors. In this context, we demonstrate through extensive simulations that the proposed routing protocol for WSN – BeeSensor – is simple, scalable, performance and energy-efficient as compared to existing SI-based and classical routing protocols for WSNs. To elaborate the adaptive nature of BeeSensor, we also evaluate its performance in mobile ad hoc networks. The simulation studies clearly demonstrate that its performance is comparable to that of the existing state-of-the-art routing protocols for MANETs. Consequently, BeeSensor can be considered for hybrid ad hoc networks as well.

1.4.2

A formal evaluation framework for ad hoc routing algorithms

Ad hoc routing algorithms are generally evaluated through simulation studies. However, a recent survey of these works – conducted by Kurkowski et al. (2005) [14] – shows that simulation analysis has several deficiencies. Therefore, we believe that simulation studies must be complemented by sound mathematical analysis. With this motivation, in this dissertation, we have

7

1.4 Major Contributions of the Dissertation

developed a probabilistic framework for formal evaluation of ad hoc routing algorithms. The key features of this framework are given below. ✓ The framework models the two baseline performance metrics of ad hoc routing algorithms; route optimality and routing overhead. Therefore several other relevant metrics for ad hoc networks can be derived from these two metrics. We illustrate this process by deriving models for few other metrics that are frequently used in the evaluation of ad hoc networks. ✓ The framework is parameterized in such a way that it can be adapted to several ad hoc routing protocols. As a proof of concept, we develop protocol specific route optimality and routing overheads for the most prominent ad hoc routing protocols. ✓ The framework is developed with the intention of keeping it generic and open for future research. Consequently, it can easily be adapted or extended to simulate different traffic patterns as well as network topologies. To this end, we elaborate the adaptation of the developed framework to mobile scenarios. ✓ The framework provides several insights into the parameters governing the behavior of any ad hoc routing algorithm in general and BeeSensor in particular. Consequently, it is an extremely useful tool that can be utilized in the protocol engineering cycle.

1.4.3

Reliability theoretic analysis of ad hoc routing algorithms

The theory of reliability is an elegant tool that models the reliability of a system in terms of its components reliabilities. In this context, we utilize the basics concepts of reliability theory to model the packet delivery reliability of single as well as multipath ad hoc routing protocols. We also analyze alternate mechanisms to improve the packet delivery ratio of ad hoc routing algorithm without incurring additional energy overhead. To the best of our knowledge, reliability of ad hoc routing algorithms has never been analyzed in this way which represents the novelty of our work.

1.4.4

Aggregation of in-network traffic in address-centric protocols

One of the distinguishing features of WSNs is that sensor nodes generate huge amount of redundant information. Address-centric protocols are generally believed to be non-supportive in this respect. We have successfully addressed this issue in BeeSensor which is an address-centric protocol. We incorporate special mechanism in BeeSensor that not only enables in-network

8

1.5 Organization of the Thesis

data aggregation near the source of events but also drastically reduces the amount of routing overhead. We demonstrate through simulation studies that this feature of BeeSensor protocol makes it highly energy-efficient.

1.4.5

Empirical evaluation framework

Another important contribution of this work is an extensive empirical evaluation framework. The framework captures a wide range of metrics that are pertinent to WSNs in particular and ad hoc networks in general. Consequently, we – as a protocol designer – are able to analyze the performance of BeeSensor over a large operational landscape. We are confident that the framework will serve as an inspiration for WSN research community.

1.5

Organization of the Thesis

The rest of this thesis is organized into six chapters. In the following subsections, we present a brief summary of each of these chapters.

1.5.1

Chapter 2: Survey of routing protocols for wireless sensor networks

The purpose of this survey is to understand the design principles of existing WSN routing protocols and study their strengths and weaknesses – the so-called requirement engineering phase. To this end, we first describe a set of challenging issues in the design of a routing protocol for WSN. We then introduce a comprehensive taxonomy that helps us in identifying the key features of existing SI-based and the classical routing protocols surveyed in the chapter. After discussing the basics of Ant Colony Optimization (ACO), we propose a generic framework that represents a unified view of the different components of SI-based routing algorithms. It not only facilitates the mutual comparison of different SI-implementations but can also guide the design of future SI routing protocols. We then present a comprehensive survey of SI routing algorithms for WSNs. Subsequently, we investigate some prominent WSN protocols proposed by the networking community. This helps in understanding the design philosophies adapted by the two research communities. This chapter is based on the following publication: ✓ Muhammad Saleem, Gianni Di Caro and Muddassar Farooq. Swarm Intelligence Based Routing Protocols for Wireless Sensor Networks: Survey and Future Directions. Information Sciences (2010), doi:10.1016/j.ins.2010.07.005, IF=3.291.

9


1.5.2

Chapter 3: BeeSensor: A simple, scalable and energy efficient routing protocol for wireless sensor networks

This chapter forms the core of this thesis in which we first describe the natural engineering process – using the principles of a natural system to solve a real world problem i.e. routing in WSNs. To this end, we start with the description of the foraging principles of a honey bee colony and identify a set of most relevant features that can be exploited in the design of BeeSensor protocol. Subsequently, we describe the concept mapping used in the design of BeeSensor. This is important for the readers as it enables them to trace the features of BeeSensor to the working of a bee colony. This is followed by a detailed design of the BeeSensor protocol. We start with the description of our agent model by highlighting the movement pattern and functions of each bee agent. We also describe the communication paradigm used by bee agents in-order to refine their view of the network topology that ultimately leads to the discovery of high quality paths. We then introduce our empirical evaluation framework and its realization in the Prowler simulator. We collect a range of relevant metrics and carefully engineer the experiments to reflect the traffic patterns of a real world WSN. We compare the performance of BeeSensor with two SI-based WSN routing protocols namely EEABR [15], FP-Ant [16] and a classical routing protocol Ad hoc On-demand Distance Vector (AODV) [17]. The simulation results demonstrate that BeeSensor has significantly higher packet delivery ratio – comparable to the best performing FP-Ant protocol. BeeSensor’s performance in terms of energy-efficiency and the routing overhead is the best among all the three protocols. This chapter is based on the following two publications. ✓ Muhamad Saleem and Muddassar Farooq. BeeSensor: A Bee-Inspired Power Aware Routing Protocol for Wireless Sensor Networks. Lecture Notes in Computer Science, LNCS 4448, pages 81–90, Springer Verlag, Valencia, Spain, April 2007. ✓ Muhammad Saleem and Muddassar Farooq. A Framework for the Empirical Evaluation of Nature-inspired Routing Protocols for Wireless Sensor Networks. In the proceedings of IEEE’s Congress on Evolutionary Computing (CEC) 2007, Singapore, September 2007.

1.5.3

Chapter 4: Formal evaluation framework for ad hoc routing algorithms

This chapter describes our mathematical evaluation framework for formal analysis of ad hoc routing algorithms. We start with the basics of graph theory which is followed by the mod-

10


eling assumptions and the system description. We then define the terms that are used in the mathematical modeling process. In the next section, we describe the routing overhead model in which: (1) we formalize the generic routing overhead model, (2) we model the unknown parameters in the generic routing overhead model i.e. expected forward degree, probability of zero collisions and the probability of zero channel error, (3) we elaborate the way in which prominent flooding optimization techniques can be modeled using the proposed generic routing overhead, and (4) finally, we develop the routing overhead models of AODV, DSR and DSDV and compare the analytical results of protocol specific models with the results of simulation studies. The comparison shows that analytical results closely follow the simulation results. In the next section, we develop the generic route optimality models. In this context, we first model the probability of discovering optimal and suboptimal paths. Subsequently, we use these models to derive expression for the marginal probability of route establishment. To elaborate the transformation of generic route optimality models to specific protocols, we develop the models for AODV, DSR and DSDV. We then compare the results of the route optimality models with the simulation results to show that they exhibit identical trends. After the completion of routing overhead and route optimality models, we demonstrate the importance of these two metrics by deriving two additional metrics from them; energy consumption and route discovery latency. In the final section of this chapter, we model the routing overhead and route optimality of BeeSensor protocol. We then present a comprehensive analysis of BeeSensor protocol using these models and infer several interesting insights about the performance of BeeSensor in largescale networks. We utilize these insights for reviewing the design of BeeSensor in Chapter 5. This chapter is based on the following publications. ✓ Muhammad Saleem, Syed Ali Khayam, and Muddassar Farooq, On Performance Modeling of Ad Hoc Routing Protocols, EURASIP Journal on Wireless Communications and Networking, volume 2010, Article ID 373759, 13 pages, 2010, doi:10.1155/2010/373759, IF = 0.732. ✓ Muhammad Saleem, Syed Ali Khayam, and Mudassar Farooq. A Formal Performance Modeling Framework for Bioinspired Ad Hoc Routing Protocols. In the proceedings of ACM Genetic and Evolutionary Computing Conference (GECCO), USA, July, 2008. ✓ Muhammad Saleem, Syed Ali Khayam, and Mudassar Farooq. Formal Modeling of BeeAdhoc: A Bio-Inspired Mobile Ad Hoc Network Routing Protocol. In the proceedings of

11


International Conference on Ant Colony Optimization and Swarm Intelligence (ANTS), LNCS 5217, pages 315 - 322, Belgium, September 2008.

1.5.4

Chapter 5: Reliability theoretic analysis of ad hoc routing protocols

We continue the formal analysis of BeeSensor in this chapter in which we make use of the theory of reliability. We start with the basics of reliability theory and subsequently, we describe the modeling assumptions. We then model the packet delivery reliability of BeeSensor protocol. We prove that the reliability function is concave with respect to the total number of paths and therefore, maintaining a large set of redundant paths merely costs discovery and maintenance overhead. We also modeled the reliability of the flooding process and derive an upper bound on the number of hops at which a packet may be flooded under the given reliability constraints. In the last section, we extend the reliability analysis to evaluate the performance of ad hoc routing algorithms in loss-and-delay sensitive applications. In this case, we investigate the use of multiple simultaneous node-disjoint and partially-disjoint paths. The reliability analysis shows that partially-disjoint paths are more reliable and energy-efficient as compared to nodedisjoint paths. We also complement our theoretical findings through simulation studies. This chapter is based on the following paper. ✓ Muhammad Saleem, Israr Ullah, Syed Ali Khayam, and Mudassar Farooq. On the reliability of ad hoc routing protocols for loss-and-delay sensitive applications, Ad Hoc Networks (2010), doi:10.1016/j.adhoc.2010.07.012, IF = 1.293.

1.5.5

Chapter 6: Design review and empirical evaluation of BeeSensor

Based on the insights inferred through the formal analysis – Chapter 4 and Chapter 5 – we revise the BeeSensor design in this chapter. We then perform an extensive empirical evaluation of the final BeeSensor design. We divide the evaluation process into two distinct portions. In the first phase, we compare the performance of BeeSensor with two SI-based energy-efficient WSN routing protocols namely FF-Ant and SC-Ant [16] using the Prowler simulator. The simulation results demonstrate that BeeSensor outperforms its competitors in all assumed scenarios and metrics. In the next phase of empirical evaluation, we implement the BeeSensor protocol in the de-facto NS-2 simulator. The use of new simulator is compulsory because Prowler does

12


not support mobile networks / a network with nodes of different hardware capabilities. We require these two facilities in a simulator in-order to analyze all the features of BeeSensor. We then compare the performance of BeeSensor with AODV, DSR and DSDV – using NS-2 – both in static as well as mobile scenarios. The NS-2 simulation results clearly demonstrate that BeeSensor is scalable, energy and performance efficient. Our results also show that BeeSensor is a promising protocol in MANETs as well making it viable for hybrid ad hoc networks.

1.5.6

Chapter 7: Conclusions and future works

This chapter outlines the key findings of this dissertation. We conclude that insect colonies provide an ideal metaphor for developing a WSN routing protocol. The resulting protocol – like its natural counterpart – is adaptive, scalable and robust to loss of individual units. We also identify areas that may be targeted in future. The first and the foremost is an extension of our formal evaluation framework. We believe that the framework – in its existing form – has tremendous potential to evolve into a de-facto formal evaluation framework which can be used in future research. We also conclude that the theory of reliability can be further investigated for evaluation of ad hoc and sensor networks. Last but not the least, Bee Colony Optimization (BCO) metaheuristic is also emerging as a new field in swarm intelligence that can be a focus of future research.

13

Chapter 2

Survey of Routing Protocols for Wireless Sensor Networks 2.1

Introduction

Routing in Wireless Sensor Networks (WSNs) has been the focus of research in the networking community due to their immense potential for various real world civil and military applications [18]: target field imaging, intrusion detection, weather monitoring, security and tactical surveillance and disaster management [6, 18]. Therefore, a number of routing protocols based on different design doctrines have been proposed for WSNs. In this chapter, a comprehensive review of these routing algorithms is presented. The purpose of this survey is: ✓ to make a wide audience aware about the latest SI-inspired WSN routing protocols (and the state-of-the-art classical routing protocols) and their usually good performance. ✓ to highlight the strengths and weaknesses of the proposed algorithms given the constraints and the objectives of WSNs. ✓ to understand the design doctrines adopted by different research communities to address different routing constraints which will ultimately lead to cross fertilization of ideas to develop new state-of-the-art routing solutions for WSNs.

2.1.1

Organization of chapter

The rest of the chapter is organized as follows. In Section 2.2, the major challenges / objectives that a routing protocol for WSN must meet are described. In Section 2.3, a novel taxonomy for

14

2.2 Routing in WSNs: Challenging Issues

WSN routing protocols which is subsequently used to classify different algorithms reviewed in this chapter is introduced. Section 2.4 forms the bulk of this chapter in which: (1) the foraging principles of ant colonies and the ACO metaheuristics are discussed, (2) a general framework for SI-based routing protocols is presented, and (3) a comprehensive review of ACO-based WSN routing protocols is provided. The most prominent WSN routing protocols proposed by the networking community are surveyed in Section 2.5. The key conclusions of the survey are given in Section 2.6.

2.2

Routing in WSNs: Challenging Issues

There are several features of WSNs which distinguish them from more traditional wireless ad hoc networks. First, WSNs have specific traffic patterns in the form of multicast (one-to-many) and converge-cast (many-to-one) trees [18] (e.g., a query sent to sensor nodes located in a specific area or a wild fire detected by multiple sensor nodes that send back the relevant information to a monitor node). Second, WSNs are made up of small/tiny nodes equipped with little memory, limited non-rechargeable battery, low-end processors, and small bandwidth wireless links. Third, a vast majority of intended applications of WSNs require the deployment of the sensor nodes in large numbers, ranging from thousands to millions, and hence the scalability of used protocols is also a major concern [3]. Fourth, sensor nodes generate huge amounts of redundant data and transmitting every bit of this data to a sink node will waste enormous amount of energy, bandwidth, and processing power. Therefore, redundant information need to be detected, filtered out, and/or aggregated in order to reduce the in-network traffic. In the following subsection, we identify a list of must-to-have features for a routing protocol that is going to be used in a real-world implementation of WSNs.

2.2.1

Minimal computational and memory requirements

Sensor nodes are typically equipped with a low-end CPU and limited memory. For instance, Crossbow’s XM2110 mote is equipped with ATMega 1281 processor running at 16 MHz [19]. Therefore, it is customary for the routing algorithm to have a low processing overhead to make it feasible for execution on such a low-end processor.

15

2.2 Routing in WSNs: Challenging Issues

2.2.2

Autonomicity and self-organization

A WSN is expected to remain operational for an extended period of time. During this time, new nodes might be added to the network, while other nodes might incur in failures or exhaust their batteries, becoming unoperational. A routing protocol must be resilient to such dynamic and generally unpredictable variations and must sustain the availability of the essential network services [18]. Therefore, the network protocols, and the routing protocols in particular, must be empowered with self-organizing and self-management properties, in order to let the network functioning as an autonomic system [20].

2.2.3

Energy efficiency

Sensor nodes are equipped with small non-rechargeable batteries (less than 0.5 Ah and 1.2 V) [3]. Therefore, the efficient battery utilization of a sensor node is critical to support the extended operational lifetime of the individual nodes and of the whole network. A WSN routing protocol is expected to: (i) minimize the total number of transmissions involved in the processes of route discovery and data delivery, and (ii) distribute the forwarding of the data packets across multiple paths, so that all the nodes can deplete their batteries at a comparable rate. This will result in the net increase of the network lifetime. It is worth mentioning here that, along with the transmissions / reception of data packets, passive listening of the network traffic is also a major consumer of energy resources. Therefore, scheduling the sleep times for nodes may also lead to significant energy saving.

2.2.4

Scalability

WSNs have a wide range of applications in which thousands of nodes are expected to be deployed [3]. A typical example of such applications is battle field surveillance, in which the criticality and the geographical extension of the scenarios require the deployment of large numbers of densely distributed sensors that have short communication ranges and high failure rates. Therefore, the routing protocol should be able to effectively cope with the challenges deriving from intensive radio interference, very long paths, and unpredictable failures, and should be able to display scalable performance in face of these challenges.

16

2.3 Taxonomy of Routing Protocols

2.2.5

Architecture matching the characteristics of traffic patterns

One of the features that make WSNs clearly different from other types of networks such as MANETs, as well as wired networks for local/wide area connectivity, is the structure of their traffic patterns. The most common traffic patterns include: event-driven, query driven, continuous monitoring, and some hybrid combination of these [21]. An event-driven traffic is triggered when a sensor node detects an event of interest (e.g., the environment temperature goes above a certain threshold). In a similar way, a user may generate a query to a set of nodes which will respond with the required data. In continuous monitoring data are sent back to the monitoring nodes at regular intervals. Traffic patterns affect the choice of a routing protocol. For instance, a proactive approach, which is based on the periodic gathering of routing information for all possible destination nodes, is suitable for continuous traffic models but might determine an excessive energy expenditure for applications that only require sporadic data transmissions. In these cases a reactive/on-demand approach might be more appropriate.

2.2.6

Support for in-network data aggregation

Sensor networks can generate large amounts of locally redundant data. For instance, when a node detects that the temperature in its surroundings has exceeded a certain threshold value, it is likely that its neighboring nodes will also detect the same event. If all these sensor nodes notify the event to the monitor node, this can jointly use the received information to assess the event with high statistical confidence. The downside of this way of proceeding lies in the excessive use of network resources. However, not every single piece of information need to be communicated to the global sink. Information from a group of neighboring nodes can be partially aggregated and processed, as close as possible to its origin. In this way, it is possible to reduce the number of transmissions significantly, saving on the limited available hardware resources and reducing the negative effects due to interference. A good routing protocol for WSNs must be able to effectively support the setup and use of data paths for in-network data aggregation.

2.3

Taxonomy of Routing Protocols

Akkaya and Younis [21] group routing protocols for WSNs into four categories: (1) datacentric, (2) hierarchical, (3) location-based, and (4) QoS-aware. Data-centric protocols do not

17


require globally unique IDs of sensor nodes and perform multihop routing by using attributebased naming mechanisms. Hierarchical protocols divide the network into small clusters with a representative node acting as a cluster head. The location-aware algorithms exploit the knowledge of the geographical position of a node to perform energy efficient routing. The QoSaware protocols can explicitly deal with multi-constrained requests for data transmissions. More recently, Boukerche et al. [22] have proposed a taxonomy that enlarges Akkaya and Younis’s by considering six architectural categories: attribute-based, flat, geographical, hierarchical, multipath, and QoS-based. The new category flat refers to the case in which a large number of nodes collaborate together to sense the environment. The nodes are all similar and cannot be assigned global IDs. The category multipath, includes the algorithms that compute multiple paths from sources to destinations in order to cope effectively with failing nodes. In this section, we propose a more comprehensive and fine-grained classification compared to those of Akkaya and Younis and Boukerche et al.. The proposed taxonomy covers a relatively large set of features that are of interest for generic routing protocols and, more specifically, for WSNs protocols. The categories comprised in the taxonomy are individually discussed in the different subsections that follow.

2.3.1

Single path and multipath routing

Routing protocols may maintain single or multiple routes to a given destination. Single path protocols can discover one or multiple routes and then always select the best path for data transportation, discarding the other paths [17]. On the other hand, multipath routing refers to the protocols that discover, maintain, and use multiple paths to transport the data packets [23]. Multipath routing protocols are helpful in extending the network lifetime because they help in depleting the battery of different nodes at a comparable rate. In the case of so-called alternate path protocols the information about multiple paths is maintained in the routing table but is used only as a backup in the case the primary path fails.

2.3.2

Reactive, proactive, and hybrid routing

In reactive/on-demand protocols paths are searched and setup only when required [24], while in proactive protocols routing information for all known destinations is being maintained upto-date all the time, irrespective of whether a destination is being selected or not for data transmission [25]. Some protocols use a combination of both techniques and hence are called hybrid protocols (e.g., see [23, 26] for more extensive discussions and examples). A proactive

18


approach is usually quite energy expensive and therefore should be used only if the application justifies its use.

2.3.3

Source and next hop routing

In next hop routing, data packets only contain the information about their final destination. At each node the routing protocol decides the next hop using information stored in the local routing table (e.g, [17]). In the case of source routing, all the information about the path to be followed is encapsulated in the datagram at the source, such that at the intermediate nodes the routing protocol only need to read the information from the datagram and forwards it accordingly (e.g., [24]). Some protocols make use of both techniques. For instance, the ant packets normally used in ACO approaches, retrace a discovered path making use of source routing, while data packets are always routed according to a next hop scheme. In general terms, the use of source routing can be very effective to reduce per packet processing requirements and to avoid loops [23]. On the other hand, it can limit the scalability of a protocol and can incur into problems in highly dynamic networks, especially when used to route data packets rather than control packets.

2.3.4

Flat and hierarchical routing

Flat routing protocols view the entire network as a set of nodes located on the same hierarchical level [27]. Their job is to find route between any arbitrary pair of nodes. Hierarchical protocols, on the other hand, divide the network into regions called zones / clusters [28]. The nodes within a cluster only need to deliver their data to the cluster head (CH). In turn, the cluster head can be part of a further level, according to some hierarchical arrangement of the nodes rooted at the final sink nodes.

2.3.5

Data-centric and address-centric routing

Data-centric protocols do not require globally unique node IDs [27] while address centric protocols do [15]. Data-centric routing is commonly used when assigning a unique ID to each node in a very large network is either not feasible or appropriate given the purpose of the network. Data-centric routing, which is also indicated as content-based routing, is the common way of operating in sensor networks, global grid infrastructures, and publish/subscribe and event-notification schemes for peer-to-peer/overlay networks [29]. In data-centric routing, data

19


is named using some high level descriptors and queries are generated for the named data. The nodes which have the requested data only respond to these queries.

2.3.6

Distributed and centralized routing

In centralized routing models, discovery and maintenance of routing information is controlled by a single node known as sink / base station [30]. In the distributed approach, each node gathers / builds routing information on its own [27]. The distributed routing model is more robust to network variations and is therefore more appropriate for dynamic and ad hoc networks. The centralized model presents a single point of failure and unable to follow timely the changes due to network dynamics. On the other hand, the powerful processing capabilities of the controller node can be exploited to effectively execute a variety of processing tasks.

2.3.7

Best-effort and QoS-aware routing

Protocols that do not provide any guarantees in terms of quality of the service delivered to the application are categorized as best-effort [16]. Protocols that can provide to the application routing services with quality guarantees (e.g., in terms of end-to-end delay, delay jitter, available bandwidth, packet losses, etc.) are indicated as QoS-aware [31].

2.3.8

Event-driven and query-based routing

This classification is based on the nature of the applications the routing protocol is serving for. In event-driven protocols, routing of data starts after the detection of an event from a sensor node [32]. For instance, an event might be triggered when the value of a monitored variable (e.g., the temperature) exceeds a certain threshold value, or after the expiration of a timer used for the periodical report of sensed data. In case of query-based protocols, data is sent from the sensor nodes to the monitor node in response to a specific query [33]. Some protocols may support both types of applications [34].

2.3.9

Energy-aware routing

Routing protocols that prioritize routes on the basis of an energy metric (e.g., the residual energy of the nodes on the route) are classified as energy-aware [31]. Since nodes in sensor networks have limited non-rechargeable batteries it is customary to make an efficient utilization of the available energy if the network has to stay operational for a long time span (this might not

20

2.4 ACO-based Routing Protocols

be the case for uses that involve the acquisition of very precise environmental information over short time periods).

2.3.10

Loop-free

If the paths that are going to be used by data packets are guaranteed to have no cycles, the protocol is said to be loop-free [24]. In order to provide this guarantee the protocol must make use of some explicit mechanism to check and avoid the possible occurrence of loops. Also control packets can incur in loops during path discovery. Looping of data packets can have a strong negative impact on network performance since it reduces data throughput and/or increases packet delay, wasting at the same time bandwidth and energy resources. Looping of control packets might be less critical but it should still be avoided for the same reasons. Looping is an issue for all next hop protocols.

2.3.11

Fault-tolerance

Wireless sensor networks are dynamic in nature. Nodes can fail due to hostile environment or battery outage. Moreover, control packets can get lost due to interference or memory/processing problems. A routing protocol which is robust to topological changes and to packet losses is termed as fault-tolerant [27]. Multipath routing is often used as a way to provide fault-tolerance.

2.3.12

Load balancing

Load balancing refers to the mechanism in which data packets are spread in a balanced way across multiple paths from sources to the destination. This traffic distribution can optimize network throughput and can allow all nodes to deplete their batteries at a similar rate. The use of multipath routing is a natural way to implement load balancing. However, the spreading across multiple paths must be done by minimizing path interference, since a high rate of radio collisions would vanish the desired positive effects.

2.4

ACO-based Routing Protocols

Ant Colony Optimization (ACO) is a population-based metaheuristic – initially proposed by Dorigo (1992) [35] – which is used to solve complex optimization problem. In a nut shell, in ACO, a set of artificial ants look for an approximate solution to the given problem e.g. shortest path in a weighted graph. The problem solving is stochastic in nature and governed by a

21


set of parameters – called pheromone model – updated by the artificial agents. Most of the routing protocols developed according to the design principles of swarm intelligence (SI) have been more specifically inspired either by ant colony – i.e. based on ACO metaheuristic – or bee colony behaviors, with the ant colony inspired ones being the largest majority. In particular, the behaviors of these insect societies that have served as source of inspiration to design novel routing protocols are the foraging behaviors. During foraging, the colony’s individuals collectively explore the external dynamic environment to discover sources of food and, once have found them, they setup optimized paths between the nest and the food sources in order to transport the food back to the nest. Therefore, these collective processes involve distributed exploration, discovery, setting, and use of optimized routing paths in dynamic environments. These are precisely the same ingredients of routing in modern networks. The ant-inspired routing algorithms do actually belong to the more general optimization framework of the ACO metaheuristic [10, 11], based on the engineering of the basic mechanisms at work in ant colony foraging. Algorithms developed according to the ACO metaheuristic have been applied to a number of different problems ranging from combinatorial optimization to distributed robotics (e.g., see [10, 36, 37] for reviews of applications). Ant colonies have served as an important source of inspiration for the design of novel algorithms and system since about two decades. On the other hand, honey bee colonies posses even more interesting and relevant features that can be exploited for design of networking protocols. For instance, bees perform energy-efficient foraging and are extremely adaptive to fullfil the colony requirements. Therefore, more recently they attracted the attention of engineers and computer scientists and their applications now expand from networking to optimization domain [12]. In the following subsections, we briefly explain the main components of the ACO metaheuristic for routing which have been exploited in developing state-of-the-art routing protocols for various types of networks – and for WSNs in particular.

2.4.1

Ant colonies and general principles of ACO for routing

It has been observed that ants in a colony can converge on moving over the shortest among different paths connecting their nest to a food source [38, 39]. The main catalyst of this colony-level shortest path behavior is the use of a volatile chemical substance called pheromone: ants moving between the nest and a food source deposit pheromone, and preferentially move towards areas of higher pheromone intensity. Shorter paths can be completed quicker and more

22


frequently by the ants, and will therefore be marked with higher pheromone intensity. These paths will then attract more ants, which will in turn increase the pheromone level, until there is convergence of the majority of the ants onto the shortest path. The indirect communication and coordination based on the pheromone signals released in the environment is termed stigmergy [7]. The basic idea behind ACO algorithms for routing [36, 40] mimics this ant behavior and is based on the acquisition of routing information through a collective learning process based on path sampling using ant agents. These lightweight agents are generated concurrently and independently by the nodes, with the task to try out a path to an assigned destination. An ant agent going from source 𝑠 to destination 𝑑 collects information about the quality of the path (e.g. end-to-end delay and number of hops), and, retracing its way back from 𝑑 to 𝑠, uses this information to update the routing tables at intermediate nodes. The routing tables, called pheromone tables, contain for each destination a vector of real-valued entries, one for each known neighbor node. These entries, the pheromone variables, are a measure of the goodness of going over that neighbor on the way to the destination. They are continually updated according to the quality of the paths sampled by the ants. The repeated and concurrent generation of ants results in the availability at each node of a bundle of paths, each with an estimated measure of quality. In turn, the ants use the pheromone tables to find their way to their destination: at each node they stochastically choose a next hop, giving higher probability to those next hops which are associated with the higher values of the combination of pheromone values and of a local heuristic function. Pheromone values are the results of the long-term collective learning from the ants, while the heuristic values reflect the current network situation. For instance, in AntNet [41], the heuristic function assigns higher values to the next hops that at the decision time have shorter link queues, and the combination between pheromone and heuristic values is an additive one. That is, the probability to select at node 𝑘 neighbor 𝑛 as next hop for ants with destination 𝑑 is calculated, for each 𝑛 ∈ 𝒩(𝑘) = {neighbors of 𝑘}, as: 𝑝𝑑𝑘𝑛 =

𝑑 + 𝜔𝜂𝑘𝑛 𝜏𝑘𝑛 , C

with

𝑞𝑛 𝜂𝑘𝑛 = 1 − ∑∣𝒩(𝑘)∣ 𝑖=1

𝑞𝑖

,

1

𝝉 , 𝜼, 𝜔 ∈ [0, 1].

(2.1)

𝐶 is a normalization factor to let 𝑝𝑛𝑑 be in [0, 1], while 𝑞𝑖 is the current length (in bits) of the link queue to neighbor 𝑖. The value of 𝜔 balances the relative weight of pheromone versus 1

In order to make the notation lighter, the superscript 𝑑 is dropped when indicating selection probabilities and pheromone values, also considering that often in a WSNs there is only one destination, represented by the 𝑑 (similarly for 𝑝 ), where the value sink. However, it has to be understood that, 𝜏𝑖𝑗 in general always mean 𝜏𝑖𝑗 𝑖𝑗 of 𝑑 should be clear from the text. In fact, the same link 𝑘 → 𝑛 will have different desirability for different destinations 𝑑. This is not the case, however, for the heuristic values 𝜂𝑖𝑗 , which are usually related to the characteristics of the local connection between 𝑖 and 𝑗, that do not depend on 𝑑.

23


heuristic values. Another popular way to combine pheromone and heuristic values is according to the following general expression: 𝑑 𝛼 ] [𝜂𝑘𝑛 ]𝛽 [𝜏𝑘𝑛 , 𝑑 𝛼 𝛽 𝑖∈𝒩(𝑘) [𝜏𝑘𝑖 ] [𝜂𝑘𝑖 ]

𝑝𝑑𝑘𝑛 = ∑

𝛼, 𝛽 ∈ ℝ+ .

(2.2)

Routing of data packets follow the same stochastic rule of ant routing. However, mechanisms are adopted to avoid low quality paths, since exploration is the task of ants not of user data. This way data traffic flows are adaptively spread over multiple paths with a strong preference for the best paths, automatically resulting in load balancing. If enough ants are sent to the different destinations, nodes can keep up-to-date information about the best paths, and automatically adapt their data load spreading to this. The ant generation rates, together with the mechanisms and the parameter values regulating the way pheromone tables are updated, define the network-level dynamics of the adaptive learning of the routing decision policy. A variety of different approaches have been proposed in the different implementations. For instance, in wired networks ants are usually generated according to a periodic scheme, while in MANETs and WSNs various reactive, proactive, and hybrid schemes have been proposed (e.g., see [42]). Also concerning the updating of the pheromone levels various updating rules have been proposed. For instance, in the case of the mentioned AntNet, if the destination of the forward agent was 𝑑 and it traveled from its origin 𝑠 to 𝑑 through the link 𝑛 → 𝑓 , when the associated backward agent arrives at 𝑛 after traversing the link 𝑓 → 𝑛, the pheromone table is updated as follows. First, a reinforcement value 𝑟 ∈ [0, 1] for the 𝑛 → 𝑓 choice to go to 𝑑 is calculated. Then, in the pheromone table, the entries 𝑑 , ∀𝑖 ∈ 𝒩(𝑛), are changed as: 𝜏𝑛𝑖 { 𝑑 𝑑 𝜏𝑛𝑖 + 𝑟(1 − 𝜏𝑛𝑖 ) 𝑑 𝜏𝑛𝑖 = 𝑑 𝑑 𝜏𝑛𝑖 − 𝑟𝜏𝑛𝑖

if 𝑖 = 𝑓

[Positive reinforcement]

∀𝑖 ∈ 𝒩(𝑛), 𝑖 ∕= 𝑓

[Decrease by normalization].

(2.3)

𝑑 In this way, for the same value of 𝑟, a small selection probability 𝜏𝑛𝑓 is increased propor-

tionally more than a large one, favoring the quick exploitation of new good paths. All other neighbor nodes implicitly receive a negative reinforcement by normalization. The value of the reinforcement is calculated by evaluating the estimated ant traveling time 𝑡𝑛→𝑑 versus the statistical data related to the observed traveling times to 𝑑, maintained in the node’s routing information database (see Section 2.4.2.2). The way this estimation is carried out determines 𝑑 the increase in 𝜏𝑛𝑓 and, therefore, affects the rate of adaptive learning of the system.

24


Another rule common to many implementations is the following, where 𝑟 can in general belong to ℝ+ and 𝜌 ∈ [0, 1] is the so-called evaporation coefficient: { 𝑑 𝜏𝑛𝑖

=

𝑑 (1 − 𝜌)𝜏𝑛𝑖 + 𝜌𝑟 𝑑 (1 − 𝜌)𝜏𝑛𝑖

if 𝑖 = 𝑓

[Positive reinforcement + Evaporation]

∀𝑖 ∈ 𝒩(𝑛), 𝑖 ∕= 𝑓

[Decrease by evaporation].

(2.4)

Pheromone evaporation favors exploration and the progressive penalization of not often reinforced paths.

2.4.2

A general framework for SI-based routing

SI-based routing protocols share similar principles and structures 1 . In this section, a unified view of SI-based algorithms – a common modular framework – is provided in which the different instances can be put in. It serves two purposes. First, it provides a common reference framework to describe and compare the different implementations of SI-based routing algorithms (and in particular those for WSNs reviewed in Section 2.4.3). Second, it is also aimed to define a general architecture that can guide the design of future SI algorithms for network routing. In addition, the general engineering guidelines to design the components and the functioning of an SI router and define the behavior of the control agents used to setup routing paths are also provided. The proposed framework consists of five top level modules and some additional submodules. The ensemble of these modules and submodules implements the architecture and the operations at the node router. The top level modules are: (i) Mobile agents generation and management, (ii) Routing information database (RID), (iii) Agent structures, (iv) Agent communications, and (v) Packet forwarding. Figure 2.1 summarizes the characteristics of the different modules and their relationships. The explanation of the characteristics and functionalities of the modules is provided in the following subsections and is based on the normal practice followed in ACO-based routing protocols. 1 SI here refers to two main categories of algorithms; the protocols inspired from the ant colonies and the honey bee colonies. However, since we did not introduce bee-inspired routing algorithms, which in fact is the main topic of this dissertation, we only refer to ACO-based algorithms in the rest of our discussion in this subsection. However, the concepts are equally applicable to bee-inspired routing. In the subsequent chapter, we utilize this framework to develop a new bee-inspired routing protocol for WSNs.

25


Proactive unit

Reactive unit

Proactive

Agent communications

Generation unit

Broadcast Unicast (source routing)

Probabilistic

Forwarding engine Backward agents control unit

Forwarding engine

Parameters update

Generation

Forward agents control unit

Other agents module

Other tables

Routing tables

Mobile agents generation and management

Agent structure

Fixed length

Forwarding engine

Parameters update

Network statistics Source routes Tables update

Stochastic Deterministic Broadcast module

Random Unicast module

Source routed

Reactive

Generation unit

Hybrid

Broadcast

Stochastic

Optimal

Unicast

Deteministic

QoS-based Single path

Forwarding engine

RID

Multipath Path selection unit Packet forwarding

Figure 2.1: Diagram of the common routing framework for SI routing protocols. 2.4.2.1

Mobile agent generation and management

SI-based routing protocols commonly use two types of agents to collect routing information. ACO-based protocols call them forward and backward ants. Forward ants are launched by source nodes to find a path to an intended destination – we call them forward agents in the present framework. Once a forward agent reaches its destination, it travels back to the source node as a backward agent. Some protocols use other types of agents to participate in the routing process (e.g., guide ants [43]. Forward agents control The main duty of a forward agent is to discover a path leading from the source to a given destination node. Additionally, they collect routing information on their way to the destination (e.g. experienced delay, minimum remaining energy). The forward agents control module contains three components: (i) agent generation unit, (ii) forwarding engine and (iii) parameter update module. The Agent generation unit can launch the forward agents in a proactive (e.g.,

26


periodically), reactive/on-demand (e.g., following a link failure or a new route is required) or hybrid fashion (see [36] for more detailed discussion on reactive vs. proactive generation strategies). Once a forward agent is generated, the forwarding engine controls its transmission from node to node. Forwarding engine either unicasts it to one of its neighbors or broadcasts it to all or to a selected subset of the neighbors. In most ACO-based routing schemes, next hop selection is controlled by a stochastic decision policy based on selection probabilities which in turn are derived from pheromone and heuristic values. Pheromone values are collectively learned and adapted over time by the mobile (backward) agents. At the beginning of the learning process, all the next hops have equal pheromone values such that next hop selection is mainly driven by the heuristic values. Backward agent control The backward agent control module consists of a generation block, and a forwarding engine. The generation block reactively decides whether to generate or not a backward agent in response to a forward agent received at the destination (e.g., it might be not appropriate to setup a low-quality path). Backward agents can be also generated proactively, as is done in [44]. If a backward agent is being generated, it inherits all the information gathered by the forward agent and retraces its path back to the source node. Retracing in ACO-based schemes is executed using a source-routing approach. Retracing the forward path, in ACO schemes, at intermediate nodes, the backward agent makes use of the routing information it carries on and of the information from the local Routing Information Database (RID) (Section 2.4.2.2) to evaluate the quality of the forward and/or backward path. In turn, the agent communicate its evaluation and information to the Agent communication module to update the RID. As a consequence, the overall selection probability of an existing path can be reinforced positively or negatively. Other agent control Some implementations make use of additional agents during the path finding/updating process. For instance, the authors of [45] make ants to move randomly to disseminate the gathered routing information to their neighbors. In Figure 2.1, these additional behaviors are presented with a separate module which is much identical to a forward agents control block.

27


2.4.2.2

Routing information database (RID)

This is a set of locally maintained data structures that includes the routing tables for agents and data, as well as possible additional data structures holding statistics of interest about node and network status used for path evaluation and for taking decisions. For instance, data concerning the expected queuing time, which is used by the heuristic function in ACO approaches, is maintained in the RID. Routing tables, called pheromone tables in ACO, have entries of the form 𝜏𝑖𝑗𝑑 , representing the estimated goodness of selecting neighbor node 𝑗 to reach destination 𝑑. The set of 𝜏 values for the same destination can be normalized, becoming selection probabilities. Modification and update of the entries in the RID is realized through the Agent communications module. The routing information database can also serve to hold sequence numbers and other information related to passing-by agents. This can be used to avoid agents carrying on the full list of visited nodes (e.g., this is the case of ACO’s backward ants), that can result heavily resource-consuming or even infeasible in very large networks [15]. Maintaining sequence numbers at the nodes also serves to avoid the multiple forwarding of an agent originated from a route setup and that has been duplicated through repeated broadcast (this is a typical problem in MANETs and WSNs protocols based on some form of flooding to find a path [23]). 2.4.2.3

Agent communications

The mobile agents share network data as well as sampled and collected paths quality information e.g. using a stigmergic approach, as in ACO-based protocols. The Agent communications module provides the logical and functional interface to mediate agent communications inside the router. It has direct access to the data in the RID and implements the ’formulae’ to update routing tables and statistics. Therefore, it is central to control the degree of adaptivity of the system. In Section 2.4.1, some common rules (Eqs. 2.3 and 2.4) that have been adopted, or used as reference, in the majority of the ACO routing implementations are discussed. 2.4.2.4

Packet forwarding

This module deals with the local forwarding of data packets. It makes use of the information built by the agents and available in the RID. The module consists of a path selection unit and a forwarding unit. Data packets can be routed either through multiple paths or through the best path. In multipath approaches, the selection of a path among the set of available next hops is done at the source node (as in case of source routing) or at intermediate nodes (next

28


hop routing) in a stochastic or deterministic fashion. The stochastic approach is the most common one. As already discussed in Section 2.4.1, this determines the distribution of traffic across multiple paths, resulting, in WSNs, in an extended network lifetime, and, if the paths do not interfere and are comparably good, in increased throughput. Data packets are normally unicast to the destination node. However, in some cases, they can also be flooded towards the destination, as in [16]. This concludes the description of ACO-based routing framework. Rest of this section describes a critical review of ACO-based routing protocols for WSNs in the context of the proposed framework.

2.4.3

Review of ACO-based routing protocols

In this section, we review the selected ACO-based routing protocols for WSNs and their properties with respect to the taxonomy of Section 2.3. First of all, we discuss the most prominent and pioneer protocols in the area – starting from least-recent to most-recent protocols. Towards the end of this section, we describe other less popular protocols which are also sorted according to their year of publication. Furthermore, a summary of the properties for all the algorithms is shown in Table 2.1, reported at the end of the section after reviewing the protocols. 2.4.3.1

Algorithms adapting AntNet to WSNs

Zhang et al. (2004) [16] have investigated the use of the reference algorithm AntNet [36, 41] in WSNs and have proposed four different variants of it: a basic routing algorithm directly derived from AntNet, Flooded Piggybacked Ant Routing (FP-Ant), Flooded Forward Ant Routing (FF) and Sensor-driven Cost-aware Ant Routing (SC). The basic AntNet-like algorithm proposed by the authors make use of unicast forward ants generated by source (sensor nodes). The launching interval 𝐼 is set adaptively. The cost of a sampled path is calculated in terms of the number of hops. A node along the path receiving a backward ant first uses the sampled cost 𝐶 to update RID’s statistics about the observed costs from itself to the destination (a sink node) in terms of average costs 𝜇 and variance 𝜎 2 using the same AntNet’s equations: 𝜇 = 𝜇 + 𝜂(𝐶 − 𝜇),

𝜎 2 = 𝜎 2 + 𝜙((𝐶 − 𝜇)2 − 𝜎 2 ),

(2.5)

where 𝜙 is a constant depending on 𝑀 , the size (in terms of number of samples) of an observation window W where the costs of the last sampled paths are stored in. The pheromone values for

29


the destination are then updated as in Eq. (2.3), with the reinforcement value 𝑟 ∈ [0, 1] being calculated as in the original AntNet: ( ( ) ) 𝐶𝑖𝑛𝑓 𝐶𝑠𝑢𝑝 − 𝐶𝑖𝑛𝑓 𝑟 = 𝑘1 + 𝑘2 , 𝐶 (𝐶𝑠𝑢𝑝 − 𝐶𝑖𝑛𝑓 ) + (𝐶 − 𝐶𝑖𝑛𝑓 )

(2.6)

𝜎 ), 𝑘1 + 𝑘2 = 1, and 𝑧 > 0. Clearly, the higher the cost where 𝐶𝑖𝑛𝑓 = min(𝑊 ), 𝐶𝑠𝑢𝑝 = 𝜇 + 𝑧( 𝑀

compared to what it has been observed so far in 𝑊 , the smaller will be pheromone reinforcement for the sampled path. After receiving a backward ant at the source node, the launching interval for forward ants is set as 𝐼 = 𝑒𝑟−0.5 𝐼. In this way, the launching interval is reduced if paths with better costs are discovered, or it is increased otherwise. Data packets are stochastically distributed across multiple paths. The three proposed variants of this basic algorithm to make it more viable for WSNs are described in the following subsections. Sensor-driven Cost-aware Ant Routing (SC) In the basic scheme, at the beginning the routing performance are quite poor, since forward ants move according to random walk, such that it takes time before pheromone tables can indicate good paths. This is due to the fact that, in absence of a priori information, the pheromone variables are initialized according to a random uniform distribution. The authors try to overcome this problem assuming that each node can derive an initial estimate 𝑄𝑛 of the cost to the destination, in terms of hops, for each one of its neighbors 𝑛 as next hop. Given 𝑄𝑛 , at a node 𝑘 the initial selection probability used by the forward ants is set to ∑ 𝑝𝑑𝑘𝑛 = exp(𝐶 − 𝑄𝑛 )/ 𝑖∈𝒩(𝑘) exp(𝐶 − 𝑄𝑖 ). 𝑄𝑛 estimates can be obtained through geometric composition if the nodes know their own coordinates and those of the destination. Alternatively, the sink can start a flooding process and the hop distance from each sensor node to the sink can be iteratively built while the flooding messages spread throughout the network. Flooded Forward Ant Routing (FF) In the second variant the source nodes flood the forward ants towards the sink node. FF, like SC, assumes that forward ants are equipped with direction/location sensors. Forward ants in FF are flooded stochastically to reduce protocol overhead. Two methods are used to restrict the flooding process. First, an intermediate node 𝑖 rebroadcasts a replica of a forward ant only if 𝑖 estimates that it is closer to the destination than the node it has received the ant from. Second, node 𝑖 waits for a random amount of time before forwarding the ant to the next hop. If

30


it hears the same replica of a forward ant from one of its neighbors in the meantime, the node simply drops it. Flooded Piggybacked Ant Routing (FP) The key idea behind FP is to piggyback data packets into ant packets, with the aim of generating a higher rate of routing updates and fully exploit the multipath nature of ant forwarding. Each data packet is encapsulated in a separate ant agent (named data ant), which is then stochastically flooded towards the sink node and generates a path updating backward ant at the sink. Backward ants are source routed (this is true also for SC and FF). The flooding of both forward and data ants is controlled as in the FF case. The pheromone tables updated by the backward ants are used to restrict the flooding process. The authors of [16] tested their algorithms considering an evader-pursuer simulated scenario in a small 7x7 network and using success rate, latency, and energy consumption as performance metrics. There was not a clear winner among the four algorithms. The basic algorithm had extremely poor success rates. FP has the highest success rates but it is not energy efficient. FF has in general the shortest delays, while SC is the most energy efficient algorithm. Clearly further tests are needed, especially for larger networks, where the growing node lists in forward ants and the source routed backward ants can be impractical, and interference can be an issue, causing serious ant losses. 2.4.3.2

Data centric routing in WSNs

Singh et al. (2005) [46] first introduce an offline centralized ACO algorithm for the solution of the Steiner tree problem (and provide a computational study of its performance), and then present an online distributed version of the algorithm for data centric routing in WSNs. The network is modeled as a weighted graph in which the weight (cost) of an edge is the Euclidean distance between the two nodes. The task is then to form a minimal cost Steiner tree routed at the sink node. This can be used to route data/events from the sensor nodes to the sink. They specifically consider the case of a single sink, but by replication the algorithm can be straightforwardly adapted to the multi-sink case. Each sensor node iteratively sends a forward ant to find a path from itself to the sink in a multicast tree. Therefore, if there are 𝑚 sensors, 𝑚 forward ants are generated at every round. The next forward ant is generated only after the associated backward ant is back at the sensor node. This makes the algorithm synchronous. On the average, only 𝑚 forward

31


ants or 𝑚 backward ants are present in the network. As usual in ACO algorithms, a forward ant maintains the list of visited nodes to ensure not to visit them again. If two forward ants meet at an intermediate node, they are merged into one single ant. This is because the paths followed by the joining ants become connected into one single subtree. In this way, the paths sampled by the set of forward ants arriving at the sink will constitute a Steiner tree. At node 𝑖, the next hop 𝑗 ∈ 𝒩(𝑖), is selected by the forward ant adopting the stochastic selection rule of Eq. (2.2). The pheromone variables 𝜏𝑖𝑗 encode the learned shortest paths in the Steiner tree. The heuristic variables 𝜂𝑖𝑗 , termed potentials, assigns low potential (higher desirability) to the nodes 𝑗 that are at the same time close to the sink and close to nodes that have been already visited by a forward ant in the current round of the algorithm. The rationale behind this is that moving a forward ant towards the path of another forward ant allowing the merging of two paths, with the result of creating a single subtree to reach multiple sensor nodes. A forward ant carries a variable 𝑝𝐶𝑜𝑠𝑡 that indicates the partial cost contributed by the ant’s path to the Steiner tree. 𝑝𝐶𝑜𝑠𝑡 is set to zero at the source and is incremented with the value of 𝑑𝑖𝑠𝑡(𝑖, 𝑗) when going from 𝑖 to 𝑗. A counter 𝑡𝑎𝑔𝑗 is maintained at each node and is incremented each time a forward ant visits the node in the current round. If arriving in 𝑗 the forward ant finds that 𝑡𝑎𝑔𝑗 ∕= 0, 𝑝𝐶𝑜𝑠𝑡 is not incremented, since in this case node 𝑗 has been already included in an ant path. When a forward ant arrives at the sink, the sum of the values of ants’ 𝑝𝐶𝑜𝑠𝑡 is added up to calculate the overall 𝑐𝑜𝑠𝑡 of the Steiner tree found by the forward ants in the current round. After all 𝑚 forward ants have arrived at destination, 𝑚 backward ants are generated carrying a copy of the 𝑐𝑜𝑠𝑡 variable. This is used to update pheromone variables along the paths found by the forward ants according to the formula of Eq. (2.4), where the reinforcement value is set proportionally to (𝑐𝑜𝑠𝑡)−1 . All the entries of the pheromone tables are subject to evaporation. Backward ants also carry two additional cost variables, 𝑖𝑝𝐶𝑜𝑠𝑡, which is incremented by 𝑑𝑖𝑠𝑡(𝑖, 𝑗) when moving from 𝑗 to 𝑖, and 𝑟𝐶𝑜𝑠𝑡, which is incremented as 𝑖𝑝𝐶𝑜𝑠𝑡 but is reset to zero each time the backward detects a branching in the Steiner tree. This is detected through the 𝑡𝑎𝑔 variables: if 𝑡𝑎𝑔𝑖 < 𝑡𝑎𝑔𝑗 there is a branching. On leaving a node, a backward ant decrements node’s 𝑡𝑎𝑔 variable, such that at the end of the round they are reset to zero. The updating rule for the potential functions is reported in Eq. (2.7). Since ants preferentially move toward low potential (and high pheromone) nodes, according to (2.7) they move toward the nodes that are closer to the sink and closer to branching points: 𝜂𝑖𝑗 = 𝛾 ⋅ 𝑟𝐶𝑜𝑠𝑡 + 𝜆 ⋅ 𝑖𝑝𝐶𝑜𝑠𝑡,

32

𝛾, 𝜆 ∈ [0, 1].

(2.7)


The authors evaluate the performance of their algorithm through simulation considering randomly generated networks of 50, 100, and 200 nodes. The algorithm shows convergence to near optimal solutions in about 1000 iteration rounds. The proposed algorithm has been also compared to the state-of-the-art data centric algorithm of Krishnamachari et al. (2002) [47]. In all the considered scenarios, the ACO algorithm was able to find a Steiner tree with a cost significantly better than that found by the competitor algorithm. However, more extensive tests are necessary to assess its performance. The algorithm is an elegant solution for forming a multicast tree in sensor networks. However, it relies on some questionable assumptions. For instance, the number of source and destination nodes are assumed to be known a priori. Second, the sink node generates backward ants only when it receives all the forward ants, and vice-versa for the sensor nodes. This mechanism can be hard to realize in practice due to the inherently unreliable nature of WSNs, such that an ant can easily get lost on its way. Another questionable aspect concerns the claim that it is a data-centric algorithm. This is not entirely true since forward ants are assumed to build a source routing header of the path they follow, which in turn requires unique node IDs. This contradicts the design philosophy of data centric routing [27]. 2.4.3.3

Energy Efficient Ant Based Routing (EEABR)

Energy Efficient Ant-Based Routing algorithm, proposed by Camilo et al. (2006) [15], is designed to extend network lifetime by reducing the communication overhead in path discovering. This is achieved by using fixed size ant agents and introducing energy and number of hops metrics in the pheromone update mechanism, allowing in this way to establish energy efficient paths. Forward ants in EEABR are generated on proactive basis at fixed intervals and are unicast to next hop nodes selected according to a stochastic rule. Pheromone reinforcement Δ𝜏 is computed as: (

Δ𝜏 = 𝐸0 −

1 𝑘 − 𝐻𝑑𝑘 𝐸𝑚𝑖𝑛 𝑘 𝐸𝑎𝑣𝑔 − 𝐻𝑑𝑘

),

(2.8)

𝑘 𝑘 is the average energy of the nodes visited by forward ant 𝑘, 𝐸𝑚𝑖𝑛 is the minimum where 𝐸𝑎𝑣𝑔

node energy, 𝐸0 is the initial energy level of the nodes, and 𝐻𝑑𝑘 is the number of hops in the path. Making Δ𝜏 a function of both path length and energy levels of the nodes would result in the discovery of short as well as energy-efficient routes. At a node 𝑖, and for a sink 𝑑, EEABR

33


uses the following pheromone update rule: 𝜏𝑖𝑗 = (1 − 𝜌)𝜏𝑖𝑗 +

Δ𝜏 𝜙𝐵𝑑𝑘

(2.9)

where 𝜙 is a scaling coefficient, 𝜌 represents the pheromone evaporation factor and 𝐵𝑑𝑘 is the number of nodes visited by the backward ant till the current node. The motivation of Eq. (2.9) is to decrease the impact of Δ𝜏 as the backward ant moves away from the sink node, favoring in this way exploratory behavior at the distant nodes. This is a useful feature when the sink node is mobile. Neighbor selection probabilities are computed using Eq. (2.2) in which 𝜂𝑖𝑗 = 𝐸0 − 𝑒𝑗 and 𝑒𝑗 is the current energy level of next hop node 𝑗. Simulation results show that EEABR performs comparatively better than other variants of it in terms of minimum remaining energy of a node, standard deviation in the battery levels, and energy efficiency. Fixed sized forward ants are implemented by letting the ants keeping memory of only the two last visited nodes, and maintaining the full lists in the RID of the visited nodes together with the ant identifiers in order to be easily retrieved (see also Section 2.4.2.2). This reduces agent bandwidth utilization. On the other hand, the proactive nature of EEABR makes it too demanding in terms of energy. 2.4.3.4

Jumping Ant Routing Algorithm (JARA)

JARA, Chen et al. (2007) [48], combines the core characteristics of the proactive Ant-based Routing Algorithm for MANETs (ARAMA) [43] and of the hybrid Zone Routing Protocol (ZRP) [49] for MANETs. JARA divides the network into zones. Inside each zone the nodes make use of a proactive strategy to discover routes to destinations located within the zone radius. On the other hand, a reactive ACO-based mechanism is used to discover routes to nodes located beyond the zone boundaries. JARA assumes that each node has its own zone and their routes to other nodes located within the zone are known through a proactive strategy and therefore it only focuses on interzone route discovery and management based on an ACO strategy. The nodes in each zone of radius 𝜌 hops are categorized as interior nodes and boundary nodes (see Fig. 2.2). A node that can be reached in less than 𝜌 hops from the central node is an interior node. Boundary nodes are at a distance of precisely 𝜌 hops from the central node. When a node needs to send data to a destination located outside the zone radius, it creates multiple forward ants and each one of them is randomly sent to one of the boundary nodes. Since routes inside the zone are assumed

34


E

Boundary node D

A

Interior node

S

C

H F Z B

G

Figure 2.2: JARA: nodes 𝐴, 𝐵, 𝐶, 𝐷 and 𝐸 are interior nodes, 𝐸, 𝐹 , 𝐺 and 𝐻 are boundary nodes, 𝑆 is the central node. to be known, the forward ants are seen as moving in jumps of 𝜌 hops each through interior nodes. Next hop selection is made in a probabilistic way according to the following selection probabilities, which are of the form of (2.2) (but the precise form of 𝑓 is left unspecified in [43]): ⎧ 𝑓 (𝜏𝑖𝑗 , 𝜂𝑖𝑗 )  ⎨∑ 𝑘∈𝒩(𝑖) 𝑓 (𝜏𝑖𝑘 , 𝜂𝑖𝑘 ) 𝑝𝑖𝑗 =  ⎩ 0

if 𝑘 = 𝑗

(2.10)

otherwise,

where 𝜂𝑖𝑗 denotes the local heuristic value of the link (𝑖, 𝑗) and 𝜏𝑖𝑗 is the pheromone value on the same link. Backward ants use source routing to travel back to the source node and update pheromone table using Eq. (2.4). Data packets are routed to their destination nodes using so-called guide ants that act as data carriers. The main purpose of a guide ant is to route data packets along the best found paths. The guide ant is also used when a path to a node, interior or boundary node, is broken. For instance, assume that node 𝑆 in Fig. 2.2 looses connection to node 𝐴. As 𝑆 is aware of its local topology, it will select an alternate node (node 𝐸) as a relaying node to reach node 𝐻, and it will launch a guide ant to reinforce pheromone on the new path. In this way, JARA can repair broken links without initiating another route discovery mechanism. The simulation results reported in [48] show that JARA discovers routes more quickly than ARAMA at a much less overhead. It is hard to judge this protocol since the description given in [48] is rather vague and unclear, and important concepts like proactive route management are missing. Moreover, as mentioned before, WSNs have unique traffic patterns that make them quite different from generic MANETS, and probably inter-zone routing may not be viable in WSNs scenarios.

35


2.4.3.5

Ant-based service-aware routing algorithm (ASAR)

ASAR is a QoS-aware routing protocol proposed by Sun et al. (2008) [50] for multimedia sensor networks. The authors have targeted two different operating network modes having different QoS requirements: (a) the event-driven mode includes only one type of service, R-service, which is event-driven, and puts strict requirements in terms of both delay and reliability for event detection and notification (e.g., surveillance of elder people), (b) the query-driven mode includes two types of services, data query (D-service) and stream query (S-service), with the former being strictly intolerant to errors but more tolerant to delays (e.g., a user querying about parking information), while the QoS requirements of the latter are the opposite (e.g., users query for real-time audio/video data). A path with low traffic and high signal-to-noise ratio suits R-type applications, while a congested path with high signal-to-noise ratio may fulfill the QoS requirement of D-type applications. The requirement of S-type applications can be satisfied by selecting a path having low traffic and low signal-to-noise ratio. ASAR assumes a clustered network and its sole purpose is to build paths from the cluster heads to the sink node that services the three types of applications. The authors do not specify how the process of cluster formation is realized, how sensors send data to their cluster head, and how data aggregation is implemented. A path 𝑙 with a total of 𝑛 links in ASAR is evaluated on the basis of four quality metrics: (1) cumulative queuing delay 𝑑𝑙 , (2) minimum of all link bandwidths 𝑏𝑙 , (3) packet loss rate 𝑝𝑙 , and (4) cumulative energy consumption 𝑐𝑙 . The objective is to find a QoS-aware path between a cluster head and the sink node for each one of the considered three types of services. Each cluster head iteratively launches a group of 3𝑚 forward ants which are probabilistically unicast to the sink node. When all the ants arrive at destination, the pheromone reinforcement for the used paths Δ𝜏 are calculated as: Δ𝜏 ℎ =

𝑚 ∑ 𝑘=1

1

𝛾ℎ𝑏 (𝑏𝑙 ) + 𝛾ℎ𝑝 (1 − 𝑝ℎ ) ∣ℎ∣ +

𝛾ℎ𝑑 (𝑑𝑚𝑎𝑥 − 𝑑𝑙 ) + 𝛾ℎ𝑐 (𝑐𝑚𝑎𝑥 − 𝑐𝑙 ) , ∣𝑙ℎ ∣

(2.11)

where ℎ ∈ {𝑅, 𝐷, 𝑆} refers to service type, 𝑑𝑚𝑎𝑥 and 𝑐𝑚𝑎𝑥 are the bounds on delay and energy consumption, and 𝛾 𝑏 , 𝛾 𝑝 , 𝛾 𝑑 , 𝛾 𝑐 are weighting factors respectively for bandwidth, packet losses, queuing delay, and energy consumption. Equation (2.11) is intended to meet the different requirements of the 3 different services and calculates pheromone increments accordingly. For each visited link (𝑖, 𝑗), pheromone updates are calculated at the sink using the following

36


equation, and then the appropriate backward ants are generated: 𝜏𝑖𝑗ℎ = 𝜌𝜏𝑖𝑗ℎ + Δ𝜏 ℎ

(2.12)

ℎ ]. This accelerates convergence In ASAR pheromone values are quantized between [0, 𝜏𝑚𝑎𝑥

and reduces the number of needed pheromone updates (small values of Δ𝜏 might not produce effects on the quantized 𝜏𝑖𝑗 ), with the consequent reduction of downstream control traffic (sink to source), that is, of generated backward ants. Selection probabilities are updated using Eq. (2.2). While pheromone values are computed using global information gathered by ants, the ℎ is entirely based on local information: heuristic function 𝜂𝑖𝑗 ℎ 𝜂𝑖𝑗 = 𝛾ℎ𝑏 (𝑏ℎ𝑖𝑗 ) + 𝛾ℎ𝑝 (1 − 𝑝ℎ𝑖𝑗 ) + 𝛾ℎ𝑑 (𝑑𝑚𝑎𝑥 − 𝑑ℎ𝑖𝑗 ) + 𝛾ℎ𝑐 (𝑐𝑚𝑎𝑥 − 𝑐ℎ𝑖𝑗 ).

(2.13)

The NS-2 simulator is used to compare the performance of ASAR with Directed Diffusion [27] and Dijkstra’s algorithm. Results are reported for a 20-node network considering latency, energy consumption, bandwidth, and packet loss rate metrics. ASAR appears to provide only marginally better performance than its competitors. ASAR’s energy consumption is the highest among the three protocols even though it does not include the overhead for the cluster formation and data aggregation. Moreover, the algorithm relies on computationally-demanding calculations that could badly affect energy consumption in real WSNs. 2.4.3.6

Probabilistic, Zonal and Swarm-inspired system for Wildfire Detection (PZSWiD)

Ramachandran et al. (2008) [34] have proposed PZSWiD which is a cluster-based ACO-inspired system for wildfire detection. In PZSWiD, nodes perform two functions: (i) respond to different queries that are generated by a sink node, and (ii) transport detected events (e.g the outbreak of a fire) to the sink node. It can work with both event and query based applications (a feature absent in most other protocols). The algorithm routes queries of a sink node to the zone where it can be answered with a high probability. In comparison, the sensor nodes can also generate periodic reports or emergency reports depending on the criticality of sensed data and then transport them to the sink node in a proactive manner. An example of a regular report is to periodically communicate the current ambient temperature. On the other hand, an emergency report might be triggered when the local temperature exceeds a certain threshold value indicating the outbreak of a fire. The protocol is complex and description of its different components is vague. The algorithm assigns a probability 𝑝𝑖𝑡 of satisfying a sink query 𝑖, comprising of 𝑛 records, to each node 𝑡

37


in the network. These probabilities are assigned on the basis of two factors: (1) how closely locally sensed data matches with the queried data? (2) the amount of pheromone. The values of 𝑝𝑖𝑡 are dynamically updated by the moving ants; as a result, sink queries are routed to the nodes which have high probability of occurrence of data. 𝑝𝑖𝑡 at node 𝑡 is defined as: ∑𝑛 𝐶𝑅𝑖 =𝑅𝑑 𝑝𝑖𝑡 = 𝑖=1 𝑃𝑡 , 𝐶𝑛

(2.14)

where 𝐶 represents the number of matches found, 𝑅𝑖 represents an individual record of the query, 𝑅𝑑 represents the data sensed by node 𝑡, and 𝑃𝑡 is the total pheromone strength at 𝑡. Ants in PZSWiD are simply the data packets – reports or responses to the sink queries – that are used to update the pheromone on their way to the sink node. Pheromone is updated using the following rule.

{ 𝑇𝑒 𝐹𝑒 [(1−𝜌)𝜏𝑖𝑘 +𝜌𝑄] 𝜏𝑖𝑘 =

𝐹𝑡 ×𝑇 𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 𝑇𝑒 𝐹𝑒 [(1−𝜌)𝜏𝑖𝑘 ] 𝐹𝑡 ⋅𝑇 𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡

if 𝑘 = 𝑗 otherwise,

(2.15)

where 𝐹𝑒 is the number of factors currently affecting ants movement, 𝐹𝑡 is the total number of factors that can affect the ants movement, 𝜌 and 𝑄 are ACO parameters and 𝑇 𝑜𝑡𝑎𝑙𝐶𝑜𝑠𝑡 is the total overhead including memory, communication and processing. Paths with high pheromone values not only have high probability of answering a query but also route it on a low cost path. Consequently, the good paths are reinforced while suboptimal paths are removed due to the evaporation of pheromone. As discussed earlier, PZSWiD can also generate regular or emergency reports without any explicit notification from the sink. Mathematically, the threshold value 𝑇𝑒 is computed using the probability of occurrence and the pheromone strength: ⎧ ⎨ 𝑃𝑡 if threshold is calculated by ant 𝑡 𝑝𝑖𝑡 𝑇𝑒 = 𝑃 ⎩ 𝑡 𝐶𝑒 if threshold is calculated by node 𝑡, 𝑝𝑖𝑡

(2.16)

where 𝐶𝑒 represents the number of nodes that sense the temperature above a given threshold (i.e the nodes that match a query). Intuitively speaking, it represents the speed at which fire is spreading. The authors implemented the algorithm in NS-2 and reported average dissipated energy (Joules/node/event) and the average delay with different zone radii. The simulation results show that PZSWiD consumes least amount of energy for a zone radius of 3. It is surprising that the authors did not compare its performance with any existing protocol.

38


2.4.3.7

AntChain

AntChain, proposed by Ding and P. (2004) [30], is a centralized algorithm which partitions the responsibilities of sensor nodes and of the sink node according to their hardware resources and relative distances in order to optimize energy consumption and transmission delays. AntChain targets the applications in which location and identity of the sensor nodes is known in advance (e.g., in some health care applications). The sink node exploits location information to calculate a near optimal chain organization for the nodes, which is then used for efficient data transmission. AntChain assumes that each sensor node can directly reach every other node in the network and can directly communicate with the sink. A node can be in one of four states: sleeping, idle, receiving, or transmitting. In the setup phase, the sink node broadcasts a setup signal to sensor nodes, which in response send their location and ID. With all the information about location and IDs of the operational sensor nodes in the hand, the sink node applies the Max-Min Ant System (MMAS) algorithm [51] to solve a TSP-like optimization problem to identify a near-optimal chain arrangement for the communications in WSN. Chain information is then broadcast to the sensor nodes. The node assigned to the farthest end of the chain starts data collection and sends it to its upstream neighbor. Each intermediate node performs data aggregation and forwards the results to the next node in the chain. The process continues until data reaches the tail node of the chain, that communicates the final result to the sink node. The nodes that are not part of the chain can go to sleep mode until the next setup message. Repeating the setup process serves to continually refresh the chain arrangement in order to overcome problems resulting from possible node failures or battery depletion. If a node does not receive data from its downstream neighbor, it assumes that the node is not operational, and therefore it directly transmits its data to the base station. AntChain’s performance has been evaluated in simulation using the NS-2 simulator. The LEACH [52] and PEGASIS [53] algorithms were used for comparisons. They are classical routing algorithms for sensor networks that also share some similarities with AntChain. Simulation results show that AntChain is more energy efficient and can provide a longer network lifetime. An important feature of this protocol is that it distinguishes between nodes with different resources. This not only reduces the processing overhead of the sensor nodes but also results in near-optimal chain by running MMAS at the sink node. Allowing nodes to go to sleep mode saves significant amount of energy. The main flaw of the algorithms lies in the fact of being centralized, therefore missing the robustness of fully distributed algorithms. Moreover, the

39


assumption that each node can directly communicate with the sink node is usually hard to implement in practice. 2.4.3.8

Ant-aggregation algorithms

Misra and Mandal (2006) [54] applied the ACO metaheuristic to propose a data aggregation mechanism, Ant-aggregation, for WSNs. This work is based on the argument that a multihop communication model coupled with in-network aggregation can significantly enhance the network lifetime because of reduced energy requirements. Therefore, the authors address the problem of optimal aggregation in a multicast tree, which is an NP-hard problem [55]. Antaggregation is based on ACO to build minimum cost aggregation trees. Forward ants either look for the shortest path to the destination or for a close by aggregation point. At node 𝑖 a forward ant is unicast to the next hop 𝑗 with probability: ( ) 𝛽 𝜏𝑖𝑗𝛼 /𝜂𝑖𝑗 𝑝𝑖𝑗 = ∑ 𝛽 𝛼 𝑘∈𝒩(𝑖) 𝜏𝑖𝑘 /𝜂𝑖𝑘

(2.17)

where pheromone encodes the preference for shortest paths and the heuristic values 𝜂 represent a node potential. A node with a low potential value means that the node is near a sink or an aggregation point. 𝛼 and 𝛽 are in [0, 1] and, as usual, weight the relative importance of pheromone versus potential. Node potentials 𝜂𝑖𝑗 are in practice distance estimates of a nearby aggregation point or of a shortest path to destination. An aggregation point is a node where two or more ants join their paths. A forward ant terminates its journey either at the sink or when it arrives at an aggregation point (notice that this algorithm joins ant sub-trees similarly to the DCR algorithm, in Subsection 2.4.3.2). Backward ants update both pheromone and potentials. These latter are updated as follows: 𝜂𝑖𝑗 = 𝛾 𝐶𝑖𝑗 where 𝐶𝑖𝑗

𝑎𝑔𝑔 𝑝𝑜𝑖𝑛𝑡

and 𝐶𝑖𝑗

𝑑𝑒𝑠𝑡

𝑎𝑔𝑔 𝑝𝑜𝑖𝑛𝑡

+ 𝜂 𝐶𝑖𝑗

𝑑𝑒𝑠𝑡

+ 𝑘 𝐶𝑖𝑗

𝑐𝑜𝑟𝑟 ,

(2.18)

are the estimated distances to reach respectively a close by

aggregation point or destination node passing by 𝑗, while 𝐶𝑖𝑗

𝑐𝑜𝑟𝑟

∈ [0, 1] is a coefficient mea-

suring the data correlation between 𝑖 and 𝑗 (e.g., if 𝑖 always uses 𝑗 to forward its data, the two nodes are statistically highly correlated). A low value of 𝐶𝑖𝑗

𝑐𝑜𝑟𝑟

indicates that data of

nodes 𝑖 and 𝑗 are highly correlated. The pheromone updating rule is the same as in Eq. (2.4), with the pheromone reinforcement defined as 𝑄/𝐻, where 𝑄 is a positive constant, and 𝐻 is the distance to the destination as measured by the forward ant. The algorithm iterates with different permutations of source nodes to converge to near-optimal aggregation points. Once

40


the algorithm converges, sources will be directing their detected events either to an aggregation point or to a sink node, whichever is closer to the source. In a limited number of simulation experiments, with networks of 20 up to 40 nodes, the authors have compared their algorithm to both a greedy and an opportunistic aggregation algorithm, showing a significant gain in energy reduction. Liao et al. (2008) [56] have extended the work of Misra and Mandal. These authors argue that the probability of locating an aggregation point in the Ant-aggregation algorithm is low. To mitigate this potential problem, the authors have introduced the concept of path extension, which enables multiple routes to intersect with each other in order to increase this probability. In this scheme, a sink node first floods a packet in the network, so that sensor nodes can estimate their hop distance to the sink node. Then a node 𝑠 launches an ant packet that carries the data packet to one of its neighbors (say 𝑗) which is selected probabilistically using Eq. (2.2), with 𝛼 = 1 and 𝜂𝑖𝑗 equal the inverse of the number of hops to reach the sink node passing by 𝑗. This ant is further broadcast by subsequent nodes until its TTL expires. The intermediate nodes generate a backward ant which is routed to the source along the reverse path. When a node 𝑖 receives this ant, it updates its pheromone table by using the following equation: 𝜏𝑖𝑗 = (1 − 𝜌)𝜏𝑖𝑗 + 𝜌Δ𝜏𝑖𝑗 ,

(2.19)

where Δ𝜏𝑖𝑗 = [1 + (ℎ𝑖 − ℎ𝑗 )]Δ𝜔𝑗 and Δ𝜔𝑗 is the number of hops between the source and the sink through node 𝑗, ℎ𝑖 and ℎ𝑗 are the number of hops separating the sink node from 𝑖 and 𝑗 respectively. The purpose of the backward ant is to enforce the route leading to a node lying closer to the sink node. An additional advantage of this approach is that different paths might have overlapping nodes. As a result, packets are routed towards the overlapping nodes or aggregation points where they can be combined with other data packets to reduce the in-network traffic. The simulation results reported by the authors show that the modified approach consumes significantly lower energy than directed diffusion which performs opportunistic aggregation. 2.4.3.9

ACO-based quality-of-service routing (ACO-QoSR)

ACO-QoSR is a reactive protocol proposed by Cai et al. (2006) [31] in which the authors try to cope with both strict delay requirements and the limited energy and computational resources available at the sensor nodes. The addressed problem consists in finding paths from sensor to sink nodes such that the total end-to-end delay is less than a bound 𝐷, while the energy residual ratio, 𝐸𝑅𝑅 = 𝐸𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙 /𝐸𝑖𝑛𝑖𝑡𝑖𝑎𝑙 , is above a certain threshold value. In ACO-QoSR,

41


when a source/sensor node has data to send, it checks its routing table for an appropriate path. If such a path does not exist in the routing table, a new route probe phase is initiated. 𝑚 forward ants are used for each path probe. These are unicast to next hop nodes using selection probabilities calculated as in Eq. (2.2). The heuristic values favor the nodes with higher level of residual energy, in order to balance energy usage: 𝜂𝑖𝑗 = ∑

𝐸𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙 (𝑗) . 𝑘∈𝑁𝑖 (𝑘) 𝐸𝑟𝑒𝑠𝑖𝑑𝑢𝑎𝑙 (𝑘)

(2.20)

In the ACO-QoSR algorithm, the local heuristic information is defined as the ratio between the residual energy of node j and the summary residual energy of all the neighbor nodes of node i. Forward ants carry a sequence number 𝑘 = 1, . . . , 𝑚, in their header in order to sort the paths at destination. Pheromone reinforcement for ant 𝑘, Δ𝜏 𝑘 , is computed as: { if path delay ≤ 𝐷 𝑓 (𝐸𝑅𝑅𝑘∗ , Δ𝜏 𝑘−1 ) 𝑘 Δ𝜏 = 0 otherwise,

(2.21)

where 𝐸𝑅𝑅∗𝑘 = 𝐸𝑅𝑅𝑘 /Hops𝑘 is path’s normalized energy residual ratio. Equation (2.21) ensures that paths with large delays will not get pheromone increment. Equation (2.4) is used to update the pheromone variables at the nodes on the sampled paths. ACO-QoSR also embeds the pheromone smoothing and bounding mechanism of Max-Min Ant System [51]: 𝜏𝑖𝑗 = 𝜏𝑖𝑗 + 𝛾(𝜏𝑚𝑎𝑥 − 𝜏𝑖𝑗 ), where 𝜏𝑚𝑎𝑥 is a constant and 𝛾 ∈ [0, 1]. ACO-QoSR’s performance has been compared in simulation to AODV [17] and DSDV [25], two classical routing algorithms for MANETs, using four metrics: end-to-end delay, packet delivery ratio, routing overhead and the energy residual ratio. ACO-QoSR is shown to meet the timing constraints and has higher packet delivery ratio than AODV. QoS routing in WSNs has not received the deserved attention of SI community and ACOQoSR is a reasonably good attempt in this context. On the weaker side of it, the use of unicast ants for providing a delay-constrained routing solution is questionable. Keeping the routing information in the header of forward ants is also a serious shortcoming because it will not only result in more energy consumption, but delay guarantees will also degrade especially in large networks. Finally, the authors paid little attention to do a comprehensive analysis of their protocol.

42


2.4.3.10

Self-organizing data gathering for multi-sink sensor networks (SDG)

Kiri et al. (2007) [44] describe a cluster-based data gathering scheme to achieve reliability and scalability in WSNs. The authors argue that a WSN architecture with a single sink is not robust to energy depletion. In fact, once the nodes around the sink run out of energy, the sink remains isolated and the WSN become useless. They propose a multi-sink WSN in which the nodes can use an alternate sink in case of failure. In the protocol, in order to minimize routing overhead, ant agents are only generated by sink nodes in the form of backward ants. These are broadcast by sink nodes on proactive basis. They carry a pheromone value Δ𝜏 to be used for updating the pheromone at the sensor nodes. At the beginning Δ𝜏 is set by the generating sink 𝑠 to a value 𝜏𝑚𝑎𝑥 . A node 𝑖 receiving the backward ant from neighbor 𝑗, stores the value of Δ𝜏 , as well, the id 𝑠 of the generating sink and that of the neighbor 𝑗. This data is used to update the routing table, with Δ𝜏 used to update the benefit of using neighbor 𝑗 to send data to 𝑠. Δ𝜏 is then decreased as follows, and further broadcast:

( ( )) 𝐸𝑟 Δ𝜏 = 𝛼 1 − 𝑒𝑥𝑝 −𝛽 Δ𝜏, 𝐸𝑚

(2.22)

where 𝛼 ∈ (0, 1), 𝛽 ∈ ℝ+ , and 𝐸𝑟 and 𝐸𝑚 are respectively 𝑖’s residual energy and initial energy levels. The intuition behind (2.22) is to deposit higher pheromone at nodes that are near the sink and have high energy levels. This process is however based on flooding, which has a high overhead. Therefore, backward ants are generated at a very low rate, and are integrated by a local mechanism based on Hello Ants which are generated by sensor nodes at a higher rate than backward ants but do not get further broadcast after reception. A Hello Ant sent by sensor node 𝑗 carries the id of the sink node 𝑠 to which it belongs to, the average 𝜏𝑗𝑠 of all its 𝑠 pheromone values 𝜏𝑗𝑘 , 𝑘 ∈ 𝒩(𝑗), and the pheromone of the cluster handled by 𝑠. A node 𝑖, on

receiving an Hello Ant from 𝑗, updates its pheromone entries if (and only if) 𝑖 and 𝑗 belong to the same sink 𝑠: 𝜏𝑖𝑗 = 𝛾𝜏𝑖𝑗 + (1 − 𝛾)𝜏𝑗 ,

𝛾 ∈ [0, 1].

(2.23)

Sensor nodes communicate data and event information to their sink node through the usual ACO stochastic forwarding mechanism. The probability that a node 𝑖 will select 𝑗 as a next hop node is given by: 𝑝𝑖𝑗 = ∑

(𝜏𝑖𝑗 )2 . 2 𝑘∈𝒩(𝑖) (𝜏𝑖𝑘 )

(2.24)

Node clustering in this algorithm is inspired from eggs and larvae grouping behavior of ant colonies. Ants repeatedly pick up and drop eggs according to their degree of similarity.

43


Based on this, the authors define an additional pheromone variable, termed cluster pheromone, which reflects the advantage of being associated with the cluster headed by sink node 𝑠. The information exchanged through the Hello Ants is used to iteratively update cluster pheromone at the nodes, which is calculated as an average of the pheromone values 𝜏𝑖𝑗𝑠 of all the nodes in the same 𝑠 cluster. Nodes at the borders of their cluster can dynamically change cluster membership according to a probabilistic mechanism that favors clusters with higher cluster pheromone. If a sensor node detects that its sink node is not operational or is out of reach, it exploits cluster pheromone to allocate itself to another cluster. The algorithm has been evaluated in simulation using NS-2. The main considered metric is reliability, expressed in terms of event-notification rate, that is, the ratio between the number of sensor generated packets associated to the detection of an event and the effective number of the packets delivered at the sinks. Even in presence of very lossy communication channel, the algorithm is able to achieve event-notification rate of about 90%. The authors also show that the algorithm successfully handles both random node failures and sink node failures. The disadvantage of this algorithm is that it consumes significant amount of energy because of its proactive nature and hello packets exchange. The authors did not make any comparison with other existing protocols. 2.4.3.11

Many-to-One Improved Ant Routing (MO-IAR)

MO-IAR, introduced by GhasemAghaei et al. (2008) [57], is an extension of their previous work [58]. The algorithm works in two phases. In the first phase, the protocol tries to establish shortest paths using ant agents. The second phase starts with actual data routing. During this phase a proactive congestion control mechanism is adopted to minimize packet losses. The protocol assumes that each sensor knows its location and the location of the destination (e.g., using GPS devices), as well as its neighbors and their distances (e.g., through the exchange of Hello messages). During the first phase, each node 𝑖 launches a sequence of 𝑛 forward ants. Each ant is unicast to a neighbor node 𝑗 ∈ 𝒩(𝑖) selected according to the following rule: 𝑝𝑖𝑗 = 𝐴𝑗𝑑

𝜏𝑖𝑗 + 𝛽𝑑𝑖𝑗 , 1 + 𝛽(∣𝒩(𝑖)∣ − 1)

(2.25)

where 𝐴𝑗𝑑 = (𝜆𝐷𝑗𝑑 )−1 is a distance weighting factor, with 𝐷𝑗𝑑 being the estimated Euclidean distance between node 𝑗 and the destination, 𝜆, 𝛽 ∈ [0, 1], and 𝑑𝑖𝑗 is the heuristic value repre-

44


senting the cost (delay) of routing a packet from 𝑖 to 𝑗. At node 𝑖, a backward ant coming from neighbor 𝑗 updates the pheromone tables using the following rules: ⎧ 𝜏𝑖𝑘 + Δ𝜏   if 𝑘 = 𝑗, ⎨ 1 + Δ𝜏 𝜏𝑖𝑘 =   ⎩ 𝜏𝑖𝑘 otherwise, 1 + Δ𝜏

(2.26)

𝑗 𝑗 where Δ𝜏 = exp(−𝛾𝐷𝑖𝑑 ), 𝛾 ∈ [0, 1], and 𝐷𝑖𝑑 is the Euclidean distance between current node

𝑖 and the destination 𝑑 through next hop 𝑗. The probability is higher for nodes geometrically close to the destination. In phase two, data packets are stochastically forwarded using data ants (ants carrying data), that rely on the built routing tables. If the paths toward the destination of two or more source nodes cross (or join) at some node 𝑘 (i.e., they are not fully disjoint), it is very likely that the data ants associated to the different sources will experience collision at node 𝑘. The algorithm makes use of a relatively simple mechanism to arbitrate the access to the wireless channel in 𝑘: the lowest ID nodes are allowed to proceed with their transmissions first, while nodes with higher ID execute a binary exponential back-off algorithm waiting for their turn. The authors show through simulations that congestion awareness of MO-IAR helps in reducing the number of collisions at the MAC layer. The performance of MO-IAR is compared with the SC, FF and FP algorithms proposed in [16] (see Section 2.4.3.1). Reported simulation results on rather small randomly generated networks (49 nodes) show that MO-IAR has smaller average latency and experiences less number of collisions than its competitors. More extensive experiments are however necessary to assess the performance of the algorithm. Moreover, the congestion awareness mechanism assumes that neighboring source nodes know about the best paths that they have discovered. However, it is not clear how this information is exchanged among neighbors. The use of source routing and the inclusion of other state information in the header of forward ants can also be problematic as discussed earlier. 2.4.3.12

E-D ANTS

Wen et al. (2008) [59] have proposed the Energy-Delay ant-based (E-D ANTS) routing algorithm. E-D ANTS aims to find a route with minimum energy-delay product in order to maximize network lifetime and to provide real-time data delivery service. E-D ANTS is a reactive protocol based on the iterative generation and unicast transmission of multiple forward ants to discover minimum energy and delay paths. The algorithm is very similar to AntNet. Each forward ants stores in its memory the values about the energy level

45


and the hop delay experienced at each node. At node 𝑖, next hop 𝑗 ∈ 𝒩(𝑖) is selected according to the following rule, analogous to the one used in AntNet (Eq. 2.1): 𝑝𝑖𝑗 =

𝜔𝜏𝑖𝑗 + (1 − 𝜔)𝜂𝑖𝑗 , 𝜔 + (1 − 𝜔)(∣𝑁𝑖 ∣ − 1)

(2.27)

where 𝜔 ∈ [0, 1] weighs the relative importance of pheromone vs. heuristic values, where 𝜂𝑖𝑗 is given by: 𝜂𝑖𝑗 = ∑

𝑒𝑗

𝑘∈𝒩(𝑖) 𝑒𝑘

,

(2.28)

where 𝑒𝑗 is the residual energy level of node 𝑗. The next hop is therefore probabilistically selected as the one with the best tradeoff between expected latency and energy product (encoded by pheromone variables) and larger residual energy. Pheromone is updated using the following equation. 𝜏𝑖𝑗 = 𝜌𝜏𝑖𝑗 + Δ𝜏𝑖𝑗 .

(2.29)

Δ𝜏𝑖𝑗 is calculated considering the relative goodness of the path sampled by the ant versus some statistic of the goodness of the paths that have been sampled in the near past. More specifically, for each destination 𝑑, a function 𝑔 is defined at each node 𝑖 as the following exponential average: 𝑖 𝛽 𝑔(𝑘) = (1 − 𝛾)𝑔(𝑘 − 1) + 𝛾𝑒𝛼 𝑖𝑗 (𝑡𝑗𝑑 ) ,

(2.30)

where 𝑘 is a discrete index which is incremented after the arrival of a backward ant, 𝑒𝑖𝑗 is the energy cost of using the link (𝑖, 𝑗), 𝑡𝑖𝑗𝑑 is the latency experienced by the ant from 𝑖 to 𝑑 going through 𝑗, 𝛾 ∈ [0, 1] is a learning rate, and 𝛼 and 𝛽 are positive weighting constants. If the most recent ants have followed low cost paths in terms of low energy× latency weighted product, then 𝑔 will decrease, or it will otherwise increase. 𝑔 defines an adaptive comparison baseline to evaluate ant paths over time (this way of proceeding is very similar to AntNet’s behavior). If 𝑧𝑛𝑒𝑤 is the energy× latency cost of the path sampled by the 𝑘-th backward ant arriving at node 𝑖 from destination 𝑑, then Δ𝜏𝑖𝑗 is calculated as: ) ( 𝑧𝑛𝑒𝑤 − 𝑔(𝑘) , Δ𝜏𝑖𝑗 = 𝜏0 1 − 𝑧¯ − 𝑔(𝑘)

(2.31)

where 𝑧¯ is the average goodness of the last 𝑛 sampled paths, where 𝑛 affects algorithm responsiveness. The authors used the OPNET simulator for the empirical evaluation of E-D ANTS algorithm and have compared its performance to that of AntNet and AntChain (see Subsection 2.4.3.7). The results reported in [59] show that E-D ANTS converges faster than the other two algorithms

46


to near-optimal paths, at the expenses of a lower routing overhead. The interesting feature of E-D ANTS is that it routes packets through shorter and energy-abundant paths, and also avoid congested paths. Being flat in nature, E-D ANTS can however hardly scale to large topologies without the inclusion of specific hierarchical mechanisms. 2.4.3.13

Other ACO-based protocols

Bashyal et al. (2007) [60] have proposed the Collaborative Routing Algorithm for Wireless Sensor Networks (CRAWL). Assuming that the nodes have random non-uniform distribution of residual energy levels, CRAWL forms clusters by assigning the role of cluster heads to the nodes with larger residual energy. Consequently, CRAWL is quite scalable to large network topologies and can easily adapt to random distributions of residual energy levels. The authors also suggest that network lifetime should be a measure of how long the network performed satisfactorily. Based √ 𝐴𝑟𝑒𝑎𝐶𝑜𝑣𝑒𝑟𝑒𝑑×𝑆𝑢𝑟𝑣𝑖𝑣𝑖𝑛𝑔𝑁 𝑜𝑑𝑒𝑠 . on this argument, they define an effectiveness metric 𝐸𝑓 𝑓 = 𝑇 𝑜𝑡𝑎𝑙𝐴𝑟𝑒𝑎×𝑇 𝑜𝑡𝑎𝑙𝑁 𝑜𝑑𝑒𝑠 𝐸𝑓 𝑓 gives a quantitative measure of the effectiveness of a network after a certain percentage of nodes are not operational anymore. The reported simulation results show that CRAWL is able to achieve 20% better network lifetime than a non-collaborative routing algorithm. Selvakennedy et al. (2007) [61] have proposed T-ANT which is a distributed, cluster-based data gathering protocol for WSNs. The major objective of T-ANT is to form evenly distributed clusters on a consistent basis at minimal energy cost to optimize network lifetime. The authors exploit the separation and alignment principles found in biological swarms thereby making use of a very limited number of ants to form clusters, and hence incur in less energy overhead. The simulation results reported in [61] show that T-ANT attains even distribution of cluster heads and better network lifetime compared with its competitor protocols. The Pheromone based Energy Aware Directed Diffusion PEADD algorithm, Zhu (2007) [62], is a variant of the classical directed diffusion protocol [27]. PEADD is based on ACO. The major objective of the algorithm is to extend the network lifetime by involving high energy nodes in the data gathering process. PEADD’s ants reinforce the pheromone on a path proportionally to the remaining energy levels of the nodes. Paths with larger residual energy are positively reinforced while the others are negatively reinforced. The simulation results reported in [62] show that for increasing node death ratios the network lifetime achieved by PEADD is significantly higher compared to that achieved by directed diffusion. Paone et al. (2007) [63] have proposed an SI-based routing algorithm which is designed to be fault tolerant, self-organized, and adaptive to the changing environment. The authors define

47

2.5 Classical Routing Protocols for Wireless Sensor Networks

the forwarding attitude (𝐹 𝐴) of a node 𝑖 as a function 𝐹 𝐴𝑖 (𝑏𝑐) ∈ ]0, 1[ of its battery charge, which is then used to reinforce pheromone values. The algorithm has a proactive nature. The sink node broadcasts its 𝐹 𝐴 to its neighbors, which in turn calculate their own 𝐹 𝐴 using 𝐹 𝐴 = 𝐹 𝐴𝑒 ⋅ 𝐹 𝐴𝑖 , where 𝐹 𝐴𝑒 =

∑𝑛

𝑖=1

𝑛

𝜏𝑖

, with 𝑛 being the number of neighbors, and 𝜏 𝑖 is

the perceived pheromone level. Also the sensor nodes periodically exchange their 𝐹 𝐴 values, and, as a result, they form a pheromone gradient towards the sink. The simulation results reported in [63] show that packet delivery ratio of the proposed algorithm remains constant varying the characteristics and the size of the network, showing in this way good scalability of the algorithm. Chen et al. (2006) [64] have introduced an improved ant-based routing algorithm that seems to converge quicker than other ant-based routing algorithms. The authors make use of search ants, which are generated by the sink node and guide the subsequent forward ants so that they can quickly reach the sink node. The authors rely on the Euclidean distance as the measure of a link cost and for assigning pheromone values. The technique used for guiding forward ants is similar to the one used in [15] and [16]. There are few other variants of ant-based algorithms for WSNs reported in literature. The interested reader can consult, for instance, the following additional references: [65, 66, 67, 68, 69, 70, 71].

2.5

Classical Routing Protocols for Wireless Sensor Networks

Like other packet switched networks, bulk of the research work in the area has also been done by the networking community. Several state-of-the-art routing protocols based on different design objectives have been proposed e.g. SPIN, directed diffusion, LEACH, ACQUIRE etc. The list is endless and therefore, we restrict ourselves to the most prominent routing protocols. Table 2.2 provides a summary of the main features of protocols discussed in the following subsections with reference to the taxonomy presented in Section 2.3.

2.5.1

Directed Diffusion (DD)

Directed diffusion is a data-centric routing paradigm proposed by Intanagonwiwat et al. (2003) [27] which is based on the concept of query / response mechanism. The sink node floods the queries, called interests, for the data using the attribute-value pair – and the nodes within the specified

48


Table 2.1: Features of ACO-based routing protocols for WSNs. Routing protocols

Characteristics SC

FF

FP

EEABR

ACO-QoSR

ASAR

T-ANT

SDG

Single path (S) ∣ Multipath (M)

M

M

M

M

M

M

S

M

Reactive(R) ∣ Proactive(P) ∣ Hybrid(H)

H

H

H

P

R

P

P

P

Best effort (B) ∣ QoS (Q)

B

B

B

B

Q

Q

B

B

Loop free

No

No

No

No

No

No

Yes

No

Load balancing

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Fault tolerant

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Energy aware

No

No

No

Yes

Yes

Yes

Yes

Yes

N,SR

N,SR

N,SR

N

N,SR

N,SR

N

N

F

F

F

F

F

H

H

H

AC

AC

AC

AC

AC

AC

AC

AC

Distributed (D) ∣ Centralized (C)

D

D

D

D

D

D

D

D

Query-based (QR) ∣ Event-driven (E)

E

E

E

E

E

E

E

E

Nexthop(N) ∣ Source routing(SR) Flat (F) ∣ Hierarchical (HR) Data centric (DC) ∣ Address centric (AC)

Routing protocols

Characteristics MO-IAR

AntChain

JARA

Ant-Agg.

PZSWiD

E-D ANTS

DCR


M

S

S

M

S

M

S

Reactive(R),Proactive(P) ∣ Hybrid(H)

P

R

H

P

R

R

P


B

B

B

B

B

Q

B

Loop free

No

Yes

No

No

No

No

No

Load balancing

Yes

Yes

No

Yes

Yes

Yes

No

Fault tolerant

Yes

No

No

No

Yes

Yes

No

Energy aware

No

No

No

No

Yes

Yes

No

N,SR

N

N,SR

N, SR

N

N, SR

N, SR

F

HR

HR

F

HR

F

F

Nexthop(N) ∣ Source routing(SR) Flat (F) ∣ Hierarchical (HR) Data centric (DC) ∣ Address centric (AC)

AC

AC

AC

AC

DC

AC

DC

Distributed (D) ∣ Centralized (C)

D

C

D

D

D

D

D

Query-based (QR) ∣ Event-driven (E)

E

QR

E

E

E,QR

E

E

region respond with the required data. A key characteristic of this algorithm is its in-network aggregation of the data packets which significantly reduces the transmission overhead. In addition to this, being data-centric in nature, it does not require globally unique IDs for the sensor nodes. It is also interesting to note that the authors of directed diffusion utilize AntNet as a source of inspiration. The route establishment process starts when a sink node forms an interest and broadcasts it to all its neighbors. Interest is a type of query message containing the description of sensing

49


task in which the sink / user is interested. When a node receives an interest, it checks its local interest cache to see if it has a matching entry. If no match is found, it creates an entry with a single gradient (a reverse link) towards the neighbor from which the interest is received. If interest entry exists in the cache with no gradient, a gradient towards the neighbor is created. If both – interest entry and the gradient – exist, the node might update the time-stamp and duration fields of the entry. The node may rebroadcast the interest to all or some subset of its neighbors and the process continues. A node within the specified region processes the interest in a similar way. Additionally, it tasks its sensors to start collecting the data at the highest event rate. It then sends the sensed data to all its neighbors for which it has a gradient entry. Intermediate nodes – on reception of the data message – update their local data cache and forward it to all their neighbors provided that a matching interest entry exists in the local interest cache and the message does not exist in the data cache. Initially, the sink requests data at a lower rate and the corresponding interests are categorized as exploratory interests. When the sink starts getting the data, it sends interests to the neighbor with a lower sampling interval – a process known positive reinforcement – which subsequently reinforces its upstream neighbors using a local rule and the process continues until a path starts delivering the data messages at the higher rate. The remaining low rate paths continue to deliver events at exploratory rates until they timeout or negatively reinforced explicitly to stop the events delivery. Negative reinforcements is also used to remove routing loops or repair broken routes. Directed diffusion is shown to have the best average dissipated energy and average delay while maintaining a reasonably high packet delivery ratio – even in the case of high node failures – than Omniscient Multicast and pure flooding. The prime reason for good performance is its ability to suppress duplicate data packets and remove the paths with high packet loss. However, the performance is achieved at the cost of high memory and processing overhead. In addition, directed diffusion is not suitable for continuous traffic applications and may suffer in dense networks due to high contention at the MAC layer because it keeps too many paths intact in parallel.

2.5.2

Constrained Random Walks on Random Graphs (CRWRG)

Servetto and Barrenechea (2002) [72] have proposed three protocols depending upon the family of graphs under consideration; regular and static graphs, irregular and static graphs and

50


th

Figure 2.3: Expansion and compression stages in CRWRG: Stage above the main diagonal is the expansion stage while the one below it is the compression stage dynamic graphs . Each node maintains a probability distribution table – pretty much like ACO-based protocols – and forwards the sensed events to a next hop utilizing the probability values. A key characteristic of these protocols is the routing of events across all possible paths without any explicit route discovery / repair process. This not only reduces the initial delay but also saves significant amount of hardware resources e.g. memory, battery etc. incurred during the route discovery process. Assuming that the nodes are lying on a regular grid of 𝑁 × 𝑁 , see Fig. 2.3, the authors define 𝑙

𝑡ℎ

diagonal as a set of nodes for which 𝑖 + 𝑗 = 𝑙 where [𝑖, 𝑗] are the coordinates of nodes on

the diagonal. The diagonal size is represented by ∣ 𝐷(𝑙) ∣ while 𝑑𝑒 [𝑖, 𝑗] is the distance from [𝑖, 𝑗] to the nearest node on the grid boundary. Each node is connected to four other nodes – two of which lie in the direction of source node while the other two are in the direction of the destination node. Consequently, for node [𝑖, 𝑗], there are two neighbors located on the shortest path leading to the destination and hence a random walk is simply the selection of one of these two links. Probability that a node – lying in the expansion stage (Fig. 2.3) – will forward an event to a node lying closer to the boundary of the grid, 𝑝, is defined as: 𝑝=

∣ 𝐷(𝑖 + 𝑗) ∣ −𝑑𝑒 [𝑖, 𝑗] ∣ 𝐷(𝑖 + 𝑗) ∣ +1

Similar equation for the node in the compression stage is 𝑝=

𝑑𝑒 [𝑖, 𝑗] ∣ 𝐷(𝑖 + 𝑗) ∣ −1

51


The authors also derive equations for the value of 𝑝 for regular / irregular and static graphs. According to the results reported in [72] , the algorithms perform better in terms of load distribution than tossing a coin strategy. However, the author’s assumptions do not reflect a real world network. For instance, the authors assume that the nodes are placed on a regular grid while sensor nodes normally have random placements. Even if deployed in a regular pattern, the topology will get random with time as nodes start failing.

2.5.3

Active Query Forwarding in Sensor Networks (ACQUIRE)

ACtive QUery forwarding In sensoR nEtworks (ACQUIRE) – proposed by Sadagopan et al. (2005) [33] – is a data-centric query resolution protocol designed to resolve diverse types of queries in an energy efficient manner. Resolution principle is to inject an active query at a certain point in the network and resolve it locally with the help of nodes lying within 𝑑 hops. If the query is not resolved completely, unresolved portion is forwarded to a neighbor and the process continues. When the query is finally resolved, it is routed back to the original source node along the reverse links. Nodes keep record of partially resolved queries which are then combined on return. An important contribution of this work is that the authors complement the empirical evaluation of ACQUIRE by mathematical modeling of two performance metrics: (1) the average energy consumed during the resolution of query, and (2) the latency involved in the process. Final expression derived for the average energy 𝐸𝑎𝑣𝑔 consumed by ACQUIRE is given below: ( ) 𝑐𝑁 (ln 𝑀 + 𝛾)(4𝑑3 + 12𝑑2 − 4𝑑 + 3) 𝑁 (ln 𝑀 + 𝛾)2𝑑 𝐸𝑎𝑣𝑔 = + , (2.32) 3(2𝑑2 + 2𝑑 + 1) 2𝑑2 + 2𝑑 + 1 where 𝑀 represents the number of sub-queries, 𝑁 denotes the number of tracked variables, 𝑐 is amortization factor (a measure of updates frequency), 𝛾 is the Euler’s constant and 𝑑 is a look ahead parameter. Similarly, average latency of ACQUIRE to resolve a query with M components is given by

( 𝑇𝑎𝑣𝑔 = 2𝑑

𝑁 ln 𝑀 + 𝛾) 𝑓 (𝑑)

) (𝑐 + 1),

(2.33)

where 𝑓 (𝑑) represents the number of neighbors of a node. Analytical results reported in [33] show that 𝑑 increases with decrease in the amortization factor. For 0.08 ≤ 𝑐 ≤ 0.9, the best energy efficiency is attained by keeping 𝑑 = 1. When 𝑑 equals the network diameter, ACQUIRE behaves like a pure flooding protocol. The authors also conclude that for higher values of 𝑐, it is more energy efficient to resolve the query locally.

52


Directed diffusion and ACQUIRE are both query resolution algorithms but the former is not designed to resolve complex queries which is the later. In the case of large network topologies, ACQUIRE may take too much time to resolve the query. It should also be noted that ACQUIRE uses a random selection of next hop neighbor which can also increase the latency of the resolution process.

2.5.4

Low Energy Adaptive Clustering Hierarchy(LEACH)

Low Energy Adaptive Clustering Hierarchy (LEACH) is one of the earliest WSN protocols proposed by Heinzelman et al. (2002) [52] based on the concept of clustering. LEACH arranges the sensor nodes into clusters with a node acting as the cluster head (CH). CH, after collecting and processing the data received from the members nodes, transmits it directly to the base station. The role of cluster head is rotated in order to consume the nodes battery uniformly. Furthermore, the decision of becoming a CH is a function of nodes residual battery capacity thus favoring the nodes with high residual energy to become CH. Consequently, the network lifetime is further enhanced. Operation of LEACH is split into four distinct phases; advertisement, setup, schedule creation and the data transmission. Based on the required percentage of cluster heads (known as priori) and the number of times a node has already been a CH, a node may decide to announce itself as a CH using a broadcast message during the advertisement phase. As nodes may receive multiple advertisements, decision of selecting a CH is based on the received signal strength i.e. a CH with high signal strength is preferred. Once a CH is selected, nodes join the cluster by sending a message during the setup phase. CHs then generate a TDMA schedule for the cluster members and broadcast it during the schedule creation phase which then leads to the start of data transmission phase. The nodes transmit their data to their respective CH during the specified time slots or sleep otherwise. After processing the received data, the cluster heads transmit it to the base station. Election of cluster heads is repeated at regular intervals. The author used MATLAB simulations to compare LEACH with three other protocols; direct transmission, Minimum Transmission Energy (MTE) protocol and static clustering protocol. The simulation results show that LEACH consumes least amount of energy and achieves better network lifetime by distributing the energy consumption evenly across the network. In addition, clustered architecture is more robust against node failures. On the downside of it, LEACH may suffer if the base station is fixed (as the protocol assumes) and the sensor nodes are scattered over a large geographical area making it impossible for certain nodes to transmit

53


directly to the base station. It is also a matter of concern that the simulation results reported by the authors do not take into accounts the energy associated with the clustering setup which might be a significant factor.

2.5.5

ReInForm

Deb et al. (2003) [73] have proposed Reliable Information Forwarding using Multiple paths (ReInForM) which is an information-aware protocol targeted to deliver the events to a sink node with a specific reliability guarantees. The basic idea is to transmit a copy of data packet through multiple paths. More specifically – depending upon the data criticality – the source node assigns a certain reliability level to each data packet which in turn is a measure of the number of paths over which the packet must be sent to deliver the packet within the given reliability constraints. Not to mention that for high reliability levels, a packet must be routed through more number of paths and vice versa. ReInForm is proactive in nature. The sink node broadcasts a routing update message at regular intervals. On reception of the message, each node repeats this broadcast at least once. In parallel, nodes also maintain multiple next hop neighbors using the information contained in the routing update message. For instance, node 𝑖 located at ℎ𝑖 hops from the sink maintains three next hops located at ℎ𝑖 , ℎ𝑖+1 and ℎ𝑖−1 hops from the sink respectively. When source 𝑆 generates a packet with reliability (𝑟𝑠 ), it calculates the number of paths 𝑃 over which the packet must be forwarded using the following equation. 𝑃 =

log(1 − 𝑟𝑠 ) − (1 − 𝑒𝑠 ), log(1 − (1 − 𝑒𝑠 )ℎ𝑠 )

(2.34)

where 𝑒𝑠 is the local channel error estimate computed at source node 𝑆. Optimal routes i.e. shortest paths are preferable for high reliability. However, if the available optimal paths are less than the required number of paths, suboptimal paths are used instead. Source nodes place the value of 𝑒𝑠 in the packet which is subsequently used by the intermediate nodes in the routing process. Intermediate nodes compute the packet reliability estimate using the following expression. 𝑟𝑖 = 1 − (1 − (1 − 𝑒𝑠 )ℎ𝑠 −1 )𝑃

(2.35)

At this point, node 𝑖 will behave like a source node and uses its local channel error estimate 𝑒𝑖 , hop distance ℎ𝑖 and 𝑟𝑖 to compute the number of paths over which packet is forwarded using (2.34).

54


ReInForm is shown to have low overhead compared to pure flooding while it achieves the desired reliability level. ReInForm is one of the very few protocols that addresses the reliability issue in sensor networks. Load balancing is another important feature of this protocol. However, the mechanism used by ReInForm to achieve high reliability must be compared with the more conventional hop-to-hop reliability method through extensive simulations before making any claim.

2.5.6

SPEED

He et al. (2003) [74] have proposed SPEED which provides soft real time guarantees in WSN with support for three different types of routing: unicast, area-multicast and area-anycast. All three are specifically designed to handle the typical traffic patterns found in WSN. SPEED meets the soft real time requirements by maintaining a certain delivery speed across the network. SPEED does not utilize any routing tables. It makes use of the geographical location information to perform its routing function. Each node in the network periodically generates a beacon to announce its location to the neighbors. Using the beacon information, each node 𝑖 maintains a set of neighbors 𝑁𝑖 and a set of forwarding candidates 𝐹𝑖 which contains the nodes lying closer to the sink. Nodes in 𝐹𝑖 are classified into two groups; (1) nodes with relay speed 𝑆 higher than the desired value, and (2) rest of the nodes. Relay speed 𝑆 at node 𝑖 is calculated using 𝑆𝑖𝑗 =

𝐿 − 𝐿𝑗 𝐷𝑖𝑗

,

(2.36)

where 𝐿 is the Euclidean distance of a node to the sink, 𝐷 is link delay between node 𝑖 and next hop 𝑗. Packets are forwarded to a node belonging group (1) in 𝐹𝑖 . Packet is usually dropped if none of the nodes lie in group (1). SPEED uses the concept of back-pressure routing to avoid congested next hops. In this strategy, a node may: (1) route a packet along an alternate route after noticing frequent packet drops through the current route, or (2) explicitly slow down the incoming traffic by announcing higher delays through an on-demand back-pressure beacon. Another component of SPEED is last mile processing. When the packet reaches the targeted area, it is either delivered to a specific node (unicast), the entire area (area multicast) or any node in the region (area anycast) which is identified by the packet type. The simulation results show that the average delay of SPEED is around 30 – 40% less even in the congested network as compared to AODV, DSR, GF etc. However, it suffers in low traffic

55


scenarios where it generates more control overhead. SPEED is QoS-aware protocol with soft real-time guarantees. However, its energy consumption characteristics are not much appealing due to its proactive nature. In addition, provision of geographical location information is still not a viable option in WSNs which is a pre-requisite for SPEED.

2.5.7

Information Directed Routing

The objective of Information directed routing (IDR) – proposed by Liu et al. (2005) [75] – is to maximize the information gain at minimum of communication cost. IDR considers two different types of routing scenarios in WSN: (1) the query is issued from an entry point – known as query proxy node – and routed towards the area of high information contents within an 𝑀 hop neighborhood, and (2) query proxy node is then asked to report the information at a certain point in the network, the so-called exit node. IDR models the network as a graph 𝐺 with a set of vertices 𝑉 and a set of edges 𝐸 between the nodes. A cost 𝐶𝑖𝑗 is associated with an edge between two nodes 𝑣𝑖 and 𝑣𝑗 . The routing problem is then defined as the discovery of a path 𝑣1 , 𝑣2 , ...., 𝑣𝑇 that maximizes the information contents about the intended target incurring minimum / moderate communication cost. Mathematically, it is expressed as 𝐸=

∑

𝐶𝑖𝑗 − 𝛾 × 𝐼(𝑣1 , 𝑣2 , . . . , 𝑣𝑇 ),

(2.37)

𝑖

where 𝐼 represents the negative information. When the query is issued at the query proxy node, it ideally should be routed to an area of maximum information about the target. However, the proxy node may not have this information. Therefore, based on its local information i.e. node positions, link qualities and 1-hop communication cost, it forwards the query to a next hop node with better information content. The node also incorporates its own estimate about the target to refine the search process. Selection of a next hop node is carried out within an 𝑀 -hop neighborhood. Relaying process continues until the query reaches the intended high information region, after which the information is routed back to the proxy node. The next phase starts when the proxy node is asked to report the information to an exit node. Now the goal is to route information towards the specified node while maximizing the information gain on the way. IDR uses a heuristic search algorithm. The first step in this search is to estimate the cost-to-go which comprises of the communication cost and the information gain (Eq. 2.37). The most difficult task is to estimate the information contribution of a path

56


leading to the exit node. There might be multiple paths leading to the exit node from the current node. IDR uses the numerical integral to compute the information available on different paths and uses this information to plan the next move. Simulation results show that IDR’s performance in terms of routing around the holes is 4−11 times better than CADR and also possesses 2 − 4 times less error in tracking a signal source. IDR is targeted specially to route query around holes in sensor networks. However, it would be interesting to compare its energy cost to gather the neighborhood information with CADR. Use of GPS for position information is also questionable. Furthermore, IDR is computationally expensive for low-end processor available at a sensor node.

2.5.8

Two-Tier Data Dissemination Model (TTDD)

Ye et al. (2002) [76] have proposed TTDD which primarily addresses the sink mobility problem in a rather unconventional way. The sensor nodes in TTDD proactively build a grid structure using the geographical positions of the neighboring nodes in which forwarding information is stored at the nodes located near the grid crossing points – the so called dissemination nodes. The sink then floods a query within its local cell. When it reaches a dissemination node with a corresponding matching event, it routes the query towards the source of event by using its upstream dissemination node. TTDD has three components; grid construction, query & data forwarding and grid maintenance. A source divides the whole sensor field into cells of size 𝛼 × 𝛼. Assuming itself at the center / crossing point of a cell, a node disseminates the detected event to its neighboring disseminating points (see Fig. 2.4 showing the crossing points of source 𝐴 labeled as A-1, A-2 and A-3). If the location coordinates of a source node are (𝑥, 𝑦), its dissemination points are then located at located at (𝑥𝑖 , 𝑦𝑗 ) computed as {𝑥𝑖 = 𝑥 + 𝑖.𝛼, 𝑦𝑗 = 𝑦 + 𝑗.𝛼; 𝑖, 𝑗 = ±0, ±1, ±2, . . .}.

(2.38)

The event is routed to the dissemination points using greedy geographical forwarding. When it reaches a node that is located at a distance less than a threshold value

𝛼 2

from the dissem-

ination point, it becomes the dissemination node. A dissemination node stores the data announcement message, dissemination point and upstream dissemination node’s position. It then forwards the event to its own dissemination points and the process continues. An example grid formed by source 𝐴 is shown in Fig. 2.4. In the second phase – query and data forwarding phase – a sink floods the query within its

57


Į Į Dissemination point for node A

A-2 A-3 Sink A

A-1

Figure 2.4: Grid structure formed by source node 𝐴 local cell (recall that the cell size is 𝛼 × 𝛼). Once this query reaches a dissemination node, it forwards this query to its upstream dissemination node. The process continues until it reaches the source of events. The source then responds with the data to the dissemination node and it continues to flow along reverse links until it reaches the sink (Fig. 2.4). Intermediate disseminating nodes may receive multiple queries from different sink nodes in which case they forward a copy of event towards each sink. There is an associated lifetime with a grid structure. If the disseminating nodes do not receive data updates at regular intervals, the grid is collapsed and the state information is flushed by the disseminating point nodes. The authors of TTDD has evaluated its performance analytically to show that it has much less communication overhead than Sink Oriented Data Dissemination approach (adapted by several protocols e.g. directed diffusion) while maintaining lesser states at intermediate nodes. The authors also performed empirical evaluation of TTDD and show that it has significantly high success rate (80% - 100%) in static as well as mobile sink scenarios. Energy consumption of TTDD increases with multiple sinks although at a slow pace. TTDD – in static scenarios – performs equally well when compared to direction diffusion. TTDD presents an elegant way of handling mobile sinks. However the grid maintenance and construction on reactive basis makes it suitable only for applications where query response

58


has some delay constraints or the sources generate large amounts of data. Finally, position information provision is also not viable in WSNs.

2.5.9

Gradient Broadcast (GRAB)

GRAB – proposed by Ye et al. (2005) [77] – provides robust data delivery by forwarding a copy of packet along multiple paths. The idea is to build a cost field at each node based on the minimum energy overhead required to reach the sink node. When an elected source starts the data forwarding process, the nodes use this cost field to decide: (1) if they are eligible to forward the packet in the first place, and (2) the power – if declared eligible – at which the packet should be broadcast in order to keep the required level of robustness in the face of link / node failures. GRAB has three main components; construction of cost field, source election and the creditbased data forwarding. To compute the cost field, each node initializes its local cost variable to ∞. A sink node then broadcasts an 𝐴𝐷𝑉 message setting its cost field to zero. A node, on reception of 𝐴𝐷𝑉 packet, calculates its cost by adding the energy cost required to reach the sender of 𝐴𝐷𝑉 to the cost contained within 𝐴𝐷𝑉 . If it is less than the existing cost at that node, old entry is replaced by the new one and the node may then rebroadcast the 𝐴𝐷𝑉 message. Otherwise, it is dropped. To minimize broadcast overhead, nodes in GRAB use a waiting algorithm to ensure that each node in the network broadcast 𝐴𝐷𝑉 only once. An event might be detected by several neighboring nodes. Every node can not be allowed to broadcast this event to avoid excessive depletion of the nodes battery. Therefore, through an election process, a node located nearest to the source of events is elected as the Center of Stimulus (COS). For this purpose, each event source broadcasts a message indicating its signal strength. If the node then hears a weaker signal, it rebroadcasts the message. Otherwise, it stops broadcasting. Consequently, the node with maximum signal strength is elected as CoS. Once CoS is elected, it computes: (1) the amount of credit 𝛼 – indicating the maximum allowable cost budget – for each packet, (2) 𝐶𝑆 which is the cost of source to reach sink node, and (3) 𝑃𝑐 representing the amount of credit consumed so far power. CoS then broadcasts this message to its neighbors. The receiving nodes forward the packet only if their cost field is less than the sender ensuring that packet flows towards the sink node. To ensure reliable and robust delivery of packets, GRAB has to address three problems using the parameters mentioned above. The first problem is to keep the width of forwarding mesh to a sufficient limit to ensure required reliability. The second issue is to maintain the path mesh width in case

59


of node failures. Last issue that need to be addressed is to prevent packets from going away from the sink node. For this purpose, initial credit (𝛼) set by CoS is consumed in such a way that nodes near CoS are able to consume bulk of its share while rest of them consume smaller. Consequently, nodes near CoS broadcast packet at higher power level which effectively expands the routing mesh. As packets move closer to sink – recall that only nodes with cost less than the sender are allowed to repeat broadcast – the mesh first remains constant and then collapses as required. Performance models of GRAB indicate that multiple paths are more robust to node and link failures. Empirical results are also reported by the authors to show that larger values of 𝛼 achieve higher packet delivery ratio without increasing the energy overhead. Furthermore, GRAB outperforms directed diffusion under abrupt failure of a set of nodes. On the other hand, GRAB relies on the assumption that sensor nodes are capable of transmitting at different power levels which may not be valid for every type of mote. However, it should also be noted that GRAB is a centralized algorithm where cost fields construction / maintenance are dependent upon the sink node.

2.5.10

BeamStar

More recently, Mao and Hou (2007) [1] have proposed BeamStar which is a centralized data dissemination protocol. The design of BeamStar is based on two important observations in a WSN: (1) optimum utilization of available resources at a sensor node is extremely critical, and (2) the significant difference between the hardware resources available at a base station and a sensor node has never been exploited to its full potential. In this context, BeamStar proposes the use of directional antenna which enables the sensor nodes to receive their location information as well as forwarding rules from the base station. Sensor nodes then use this information to broadcast detected events restrictively towards the base station. In this way, BeamStar is able to shift the bulk of routing task to the base station making it possible to design and develop tiny and inexpensive sensor nodes. BeamStar makes the following assumptions: (1) the network is connected and each node directly accessible from the base station, (2) the base station has an infinite energy source and possesses a directional antenna capable of transmitting at different power levels, and (3) sensor nodes are synchronized with the base station. Base station sends the location information to sensor nodes in the form of a 2-tuple . This control message

60


Table 2.2: Features of classical routing protocols for WSNs. Routing protocols

Characteristics DD

CRWRG

ACQUIRE

LEACH

ReInForm

SPEED

BeamStar


M

M

M

S

M

M

M

Reactive(R) ∣ Proactive(P) ∣ Hybrid(H)

R

R

R

P

P

P

P


B

B

B

B

Q

Q

B

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Load balancing

No

Yes

No

Yes

Yes

Yes

Yes

Fault tolerant

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Energy aware

No

No

No

Yes

No

No

No

Nexthop(N) ∣ Source routing(SR)

N

N

N

N

N

N

N

Flat (F) ∣ Hierarchical (HR)

F

F

F

HR

F

F

F

DC

AC

DC

AC

AC

AC

AC

D

D

D

D

C

D

C

QR

E

QR

E

E,QR

E

E

Loop free

Data centric (DC) ∣ Address centric (AC) Distributed (D) ∣ Centralized (C) Query-based (QR) ∣ Event-driven (E)

Routing protocols

Characteristics IDR

TTDD

GRAB

BeamStar

SPIN


S

S

M

M

M

Reactive(R),Proactive(P) ∣ Hybrid(H)

R

R

P

P

R


B

B

Q

B

B

Loop free

Yes

Yes

Yes

Yes

Yes

Load balancing

No

Yes

No

No

Yes

Fault tolerant

Yes

Yes

Yes

Yes

Yes

Energy aware

No

No

No

No

Yes

Nexthop(N) ∣ Source routing(SR)

N

N

N

N

N

Flat (F) ∣ Hierarchical (HR)

F

F

F

F

F

AC

AC

AC

AC

DC

D

D

C

C

D

QR

QR

E

E

E

Data centric (DC) ∣ Address centric (AC) Distributed (D) ∣ Centralized (C) Query-based (QR) ∣ Event-driven (E)

also contains base station ID as well as current scan number. If a sensor nodes receives multiple control messages, it selects 𝑆𝑁 and 𝑅𝑁 as follows. 𝑆𝑁𝑖 = max{𝑆𝑁𝑖 ∥𝑖𝜖{𝑟𝑐𝑣𝑑 − 𝑐𝑡𝑟𝑙 − 𝑚𝑠𝑔𝑠 − 𝑤𝑖𝑡ℎ − 𝑆𝑒𝑞𝑁 𝑢𝑚}}

𝑅𝑁𝑖 = min{𝑅𝑁𝑖 ∥𝑖𝜖{𝑟𝑐𝑣𝑑 − 𝑐𝑡𝑟𝑙 − 𝑚𝑠𝑔𝑠 − 𝑤𝑖𝑡ℎ − 𝑆𝑒𝑞𝑁 𝑢𝑚}} An example of this location discovery mechanism is shown in Fig. 2.5. Nodes in the shaded

61


Figure 2.5: Location discovery in BeamStar (a) transmission with SN=RN=1, (b) transmission with SN=1, RN=2, (c) transmission with SN=1, RN=3, and (d) transmission with SN=2, RN=1 (taken from [1]). area of Fig. 2.5(a) may receive multiple control messages i.e. the ones targeted for other rings. However, they always choose the same ID selected using the above mentioned rule. Data dissemination is initiated by the source of highest signal strength i.e. the one located closest to the target. The report generated by the source node contains the BaseID, sourceID, LastRelayID and Timestamp. Each node that receives this report may repeat it using the forwarding rules set by the base station. For instance, the general rule is that the nodes with the same 𝑆𝑁 and lower 𝑅𝑁 will repeat this broadcast. To avoid the well-known broadcast storm problem, node maintains a signature list and rebroadcasts only if the report signature does not exist in it. Finally note that BeamStar supports multiple base station configurations and the 3-tuple (BaseID, SourceID, Timestamp) uniquely identifies a base station. The authors of BeamStar compared its performance with directed diffusion. The simulation results show that BeamStar achieves higher packet delivery ratio at minimum control overhead. BeamStar adapts a novel approach to shift the routing functionality from resource constrained devices to a resource-sufficient base station. However, being centralized in nature, base station may bring the whole network down. Secondly, directional antennas have their own problems and work best in the line-of-sight cases only.

62

2.6 Conclusions

2.5.11

Other classical WSN protocols

Sensor Protocol for Information via Negotiation (SPIN) is proposed by Heinzelman et al. (1999) [32]. SPIN is a data-centric protocol that negotiates high level meta-data descriptors to do energy efficient routing. The nodes advertise availability of data to their neighbors. The interested nodes can request data from the advertising nodes. The problem with SPIN is that it may fail to deliver data to a sink or an interested node, if its neighbors are not interested in it. Lindsey and Raghavendra (2002) [53] have proposed Power-Efficient Gathering in Sensor Information Systems (PEGASIS) which is a variant of LEACH protocol in which the nodes form a chain along which the data is communicated to a designated node. This node ultimately transmits it to the base-station. Although it avoids the overhead of cluster formation, it is based on the same assumption as LEACH: every node can directly reach the base station. Haas and Small (2006) [78] have proposed Shared Wireless Info-station Model (SWIM) which targets low latency in data delivery but at an additional memory requirement. It works in three phases: (1) nodes sense the events, (2) then they exchange them with their neighbors, and (3) finally, they deliver the stored events to the base station once they come in its vicinity. Interested readers are referred to Abbasi and Younis (2007) [28], Akkaya and Younis (2005) [21], Al-Karaki and Kamal (2004) [6], Boukerche et al. (2008) [22], Jin et al. (2009) [79] and references therein for additional information about the classical WSN routing algorithms.

2.6

Conclusions

Wireless sensor networks contain large sets of resource constrained nodes. Therefore, design of effective, robust, and scalable routing protocols for WSNs is an extremely challenging task. In comparison, the domain of swarm intelligence offers algorithmic design principles, inspired by complex adaptive biological systems, which well match the constraints and the challenges of WSNs. In this chapter, we presented a comprehensive review of SI-based and the most prominent classical WSN routing protocols. In addition, we also identified the strengths and weaknesses of these algorithms. We believe that the critical review described in this chapter will be instrumental for cross fertilization of ideas in the domain of WSN routing. In parallel, we have also fulfilled the requirement engineering of a new WSN routing protocol which is the main focus of this dissertation.

63

2.6 Conclusions

In the following chapter, we describe the foraging principles of a honey bee colony along with its key characteristics that are utilized to develop another series of SI-based – the so called bee-inspired – routing protocols for fixed as well as mobile ad hoc networks.

64

Chapter 3

BeeSensor: A Simple, Scalable and Energy Efficient Routing Protocol for Wireless Sensor Networks 3.1

Introduction

After the immense success of ACO metaheuristic, Bee Colony Optimization (BCO) metaheuristic has been proposed very recently as a new potential research direction in the area of swarm intelligence with application to several engineering and management problems [80]. Colonies of honey bees resemble ant colonies in several ways e.g. distributed food collection, individuals with limited capabilities, indirect communication between the insects etc. However, due to difference in the nature of insects – with the foraging ants moving on the terrain and the bees flying – their foraging processes differ significantly from each other. For instance, bees also communicate with each other directly through dances to exchange the quality and location of potential foraging sites as demonstrated by Seeley (1995) [81]. Wireless sensor networks (WSNs) have surprising number of properties in common to the insect colonies especially a honey bee colony. For instance, individual nodes in a WSN are resource-constrained autonomous entities that form a communication network by collaborating with the neighboring nodes. In comparison, a honey bee colony also consists of minimalist bee agents that through local interaction perform a system level behavior that is scalable,

65

3.1 Introduction

robust and tolerant to a dynamically changing environment without any centralized control. Second, individual nodes are less important as compared to overall sensor network. A similar characteristic is observed in a bee colony where bees always work to optimize the colony profit. Third, honey bee colony is extremely adaptive in terms of its resource management e.g. when a foraging site quality falls below a certain threshold level, the foraging force is diverted towards a better quality food source. This is also a desirable characteristic as sensor networks are dynamic in nature and a routing protocol has to adapt to such environmental changes. Motivated by the similarities of the systems, in this chapter, the foraging principles of a honey bee colony are utilized to design a simple, scalable and energy efficient routing algorithm for WSNs, BeeSensor. More specifically, we followed the following design guidelines to achieve the final objective. 1. Bee agent model must be simple and independent of the size of the network. This requirement primarily targets the scalability aspect of a routing protocol. The intended applications of wireless sensor networks, for instance battle field surveillance, may contain several thousands of small tiny nodes [18]. If an agent is allowed to have a source routing header of the complete path, its size will grow indefinitely making it impractical for large scale networks. 2. Routing overhead must be minimized in every possible way without affecting the capability of nodes to reach the most distant sink node(s). This is a critical requirement keeping in view of the fact that wireless sensor nodes carry limited and non-rechargeable batteries [18]. Pure flooding based protocols generate large routing overhead that can quickly drain the energy resources of individual nodes ultimately resulting in a lower network lifetime. Stochastic rebroadcasting is one of the options usually used for minimizing the control overhead [82]. However, its performance in large scale networks must be evaluated before making the final design choice. 3. Bee agents – having limited knowledge about the overall network topology – must cooperate and share the routing information with their fellow agents to make more intelligent routing decisions. This is one of the typical characteristics of Bee-inspired protocols [12, 13]. Allowing the agents to communicate with each other at intermediate nodes will enable them to select the high quality routes. 4. Distribution of network traffic across multiple routes is another critical requirement due to two main reasons. First, it naturally results in lower number of route discoveries

66

3.2 Bees in Nature

in a dynamic network because are connected through multiple routes. Secondly, the network lifetime is extended as the batteries of individual nodes are drained at an approximately equal rate. 5. Nodes in an ad hoc network perform an additional task of routing the packets on behalf of the other nodes. Therefore,we have to ensure that the nodes lying on a route should not be over stretched in terms of their resource usage (memory, energy, processing etc.) because it might affect the overall network performance. Extensive simulations are used to evaluate the performance of BeeSensor. The results clearly demonstrate that BeeSensor outperforms the existing ACO-based routing algorithms EEABR [15], FF-Ant [16] and a classical ad hoc routing algorithm AODV [17] in terms of energy efficiency, cyclic complexity, routing overhead and network lifetime. In addition to this, BeeSensor closely follows the best protocol in terms of packet delivery ratio i.e. FP-Ant.

3.1.1

Organization of the chapter

The rest of the chapter is organized as follows. Foraging principles of a honey bee colony are described in Section 3.2. Section 3.3 describes the concept mapping – translating the natural concepts to routing in sensor networks – utilized in the design of BeeSensor protocol. Section 3.4 forms the core of this chapter in which architecture and working of BeeSensor is discussed in detail. The empirical evaluation framework used for the performance analysis of BeeSensor is described in Section 3.6. A brief description of the competitor protocols used in the evaluation process is given in Section 3.5. A thorough analysis of the simulation results is presented in Section 3.7. Conclusions are listed in Section 3.8.

3.2

Bees in Nature

According to Seeley (1995) [81], ”Everyone knows that individual bees glean nectar from flowers and transform it into delicious honey, but it is not so widely known that a colony of bees possesses a complex, highly ordered social organization for the gathering of its food”. Annual requirement of food reserves of a honey bee colony are immense keeping in view of their limited individual capacity. A rough estimate shows that bees need around 120𝐾𝑔 of nectar, 20𝐾𝑔 of pollen, 25𝐿 of water and 100𝑔 of resin each year [81]. The process of food gathering gets even more difficult due to inconsistent supply of food throughout the year i.e. food reserves in

67

3.2 Bees in Nature

nature are available to a bee colony only during few weeks of the year. Therefore, to exploit the food resources in the periods of availability, a honey bee colony needs to deploy a large foraging force to high quality flower patches. Adapting to the varying environmental conditions and the changing demands of a bee colony, bee agents have to work as a unit – mutually cooperating with each other – to gather the required amount of food. An amazing characteristic of a honey bee colony is to carry out the surveillance and foraging activity in an area of around 100𝐾𝑚2 around the hive. The process of surveillance for new potential food reserves is known as scouting. Unemployed bees travel from flower to flower and look for new food sources. Once a flower patch is discovered, its location and quality need to be communicated to forager bees at hive before the patch is found by other competitors. When multiple food sources are discovered, a colony is able to exploit the high quality source by rapidly diverting its foragers accordingly. Interestingly, the complex coordination among the hive agents is obtained through simple independent decisions taken by the bees using local information without any central controlling authority. The food collection is performed by the colony through recruitment of bee agents. The recruitment is done by the forager bees after returning from the food source. Foragers communicate the quality and location (distance , direction) of the site to the bees inside the hive through dances. Dancing is performed on a dance-floor located at the entrance of a hive. Each bee colony is gifted by the nature with few hyper-bee agents – agents that do not like to be associated with a specific source for too long – known as scouts. Consequently, they start looking for alternate food sources. The scout bees become foragers after discovering a proper food source and start recruiting the unemployed bees as foragers. A forager which wants to advertise her food source in order to recruit more bees for its foraging site performs the waggle dance at the dance-floor. After waiting for an unusually longer period of time for a food-storer bee, a forager may decide to perform a tremble dance. The tremble dance is an indication to the dancing foragers that the rate of nectar collection is greater than the rate at which it is being processed. Therefore, they are required to stop their foraging activity and start food processing to keep the balance. Owing to the low profitability of a food source, foragers may decide to abandon it and get recruited for some other source. In the subsections that follow, we summarize the key characteristics of a honey bee colony through which it gathers food from external sources and transports it to the hive for transformation of the ingredients into delicious honey. The features of a bee colony that may be

68

3.2 Bees in Nature

exploited and mapped to solve the routing problem in telecommunication networks [12, 83] are specifically highlighted.

3.2.1

Management of the colony agents

The bees by nature are uniform individuals. However, their role / responsibility may change in accordance with the colony requirements. For instance, forager(s) may give up its foraging activity in response to a tremble dance. Similarly, scouts do not remain loyal to a single food source. As a result, after performing foraging for some random amount of time, they leave the source and start looking for new and better quality sources. This is an extremely important characteristic of the bee agents which enhances the colony’s adaptive behavior to constantly changing environments.

3.2.2

An agent to group communication - the dance language

Colony behavior has strong dependence upon the exchange of information among bee agents. Individual bee agents have their own view of colony requirements and they behave accordingly. However, to fulfill the true colony needs, bee agents communicate with each other to transform their individual perceptions into a better integrated output. In this way, the ever changing colony requirements are met through the adaptation of existing colony resources. Bee agents communicate with each other through the dance language. A scout bee, after discovering a fresh patch of flowers and returning home as a forager, communicates the quality and location of the food source to foragers at hive by performing a waggle dance. The direction and the time of waggle run indicates the direction and distance to the newly discovered flower patch [81]. Intensity of this dance is an indication of the perceived food source quality. Higher the intensity of the waggle dance, better is the quality. Common foragers may also perform a waggle dance to recruit the unemployed foragers. It is interesting to note that only the food sources with a certain threshold quality are advertised by the bee agents. Another important type of dance is the tremble dance. If a returning forager has to wait longer to get unloaded, it performs the tremble dance. As discussed earlier, tremble dance indicates that the current food collection rate is higher than the processing rate. Therefore, in response, foragers may abandon their current activity and join the food-storer bees (bees which stay at hive to unload the foragers and store the collected food at appropriate place in the hive).

69

3.2 Bees in Nature

3.2.3

De-centralized control

As discussed above, bee foraging is a pretty complex process due to dynamic environment and heavy demands of food reserves that a colony needs each year. A typical bee colony consists of thousands of worker bees involved in different activities. Surprisingly, they perform complex foraging task without being administered by a single authority. Each individual bee agent perceives the colony requirement by itself and acts accordingly. However, they exchange views / perceptions which results in a highly organized and efficient foraging activity.

3.2.4

Energy-efficient foraging process

Foragers advertise the food source if its quality is above a certain threshold. An imperative question at this point might be: what are the criteria for measuring the quality of a food source? Foraging theory suggests two models. The first model suggests that animals maximize their energy intake while foraging [84]. The second model suggests that the animals / insects maximize their net energy efficiency, an appropriate model for honey bees [85]. If a forager consumes 𝐶 units of energy per trip and collects 𝐺 units of energy, energetic efficiency then equals

𝐺−𝐶 𝐶 .

Experiments reported by Seeley [81] indicate that bees maximize their energetic

efficiency during the foraging process. There is also evidence that bee agents lifetime for foraging gains are bounded by the lifetime energy expenditures. Therefore, in order to deliver maximum energy to the hive, a bee maximizes her energy gains per unit of expended energy. She achieves this objective in two ways. It appropriately selects the foraging sites (through monitoring the waggle dance) that have high potential for efficient foraging. Once a site is selected, foragers do not carry the maximum load to the hive (as it will cost them more energy). Due to same reasons, the sites that are located near the hive are preferred over the ones located at some distance [81].

3.2.5

Grouping

Nectar foragers of a flower patch recognizes each other through the odor of nectar they carry and form a group. On the dance floor, foragers of a particular group respond to the dances of their group mates and do not care about the other groups offer [83]. However, a forager belonging to a group may decide to leave its group and join the other.

70

3.3 From a Bee Colony to SensorNets

3.2.6

Stochastic Selection of Foraging Sites

Natural systems exhibit stochastic properties and the bee agents are no exception to this rule. Dance floor is a center of all communication activities. Foragers perform dances on this floor to advertise the location and quality of food sources (nectar, pollen or water). There might be multiple foragers dancing simultaneously. An unemployed forager may monitor all the available foraging sites being advertised before making the final selection. However, it usually is not the case and bees play a dice. As a result, unemployed bees select one of the dances at random and try to understand the information being advertised in the selected dance. An apparently bad looking decision of the bees to play a dice in fact helps in maximizing the colony profit rather than maximizing the individual profit. Had the bees broadly monitored the dances and made an intelligent decision, it would have resulted in ”all-or-none” response [81].

3.3

From a Bee Colony to SensorNets

In this section, we describe the working principles of a bee colony that are utilized in the design of BeeSensor protocol. Subsequently, we elaborate the concept mapping process. Although some of the text in this section is overlapping with Section 3.2, we believe that the repetition is useful in two ways. First, it will facilitate the reader to trace back the features of BeeSensor protocol to the principles of a bee colony. Second, it will make the section self-contained. ✓ Recruitment and agent communication. In a honey bee colony, scouts discover flower sites and then recruit foragers for the sites through a waggle dance on the dance floor inside the hive. The waggle dance encodes the distance (from hive) and direction – relative to sun – of the flower site. The scouts/foragers only advertise a flower site if the net energetic gain of foraging at this flower site is above a threshold value. The colony also regulates the nectar processing and nectar intake rate through interesting “cues” – for instance, longer delays in nectar unloading may result in a tremble dance. ✓ Energy efficient foraging. Researchers have shown that colony wants to enhance its net energetic gain during the foraging process. As a result, most of foragers prefer foraging in the near vicinity of hive – so-called short distance bees in BeeHive. However, only few of them travel to long distant flower sites. As a result, most of nectar intake is collected at minimum energy expense.

71

3.3 From a Bee Colony to SensorNets

✓ Multiple flower site foraging. A colony always tries to distribute its workforce on two to three flower sites instead of just exploiting the best site. As a consequence, foragers bees do not extensively monitor the waggle dances of fellow foragers to go to the best quality sites only. Rather, they stochastically select a foraging site after examining only two to three dances. In this way, colony maintains a balance between exploitation and exploration.

3.3.1

BeeSensor: The mapping of concepts

In this section, the concept mapping that will facilitate the reader to trace back the features of BeeSensor algorithm to the principles of a bee colony is summarized . 1. Each sensor node has a software module – called hive – that houses different types of bee agents: packers, scouts, foragers and swarms. Packers reside inside a hive and process incoming data packets from upper layers. Packers in the hive of a source node launch scouts to find paths to a new sink node. Scouts also evaluate the quality of paths between the source node and the sink node. Once the scouts return to the source node, they recruit foragers for their paths. Foragers undertake two tasks: (1) transport data packets, and (2) evaluate the quality of the visited paths. The quality of a given path is a function of the path length and the remaining battery levels of the sensor nodes. A scout/forager simulates ”recruiting through waggle dance” by cloning itself a certain number of times depending on the quality of a path. 2. The number of cloned foragers would be large in two scenarios: (1) the path is shorter and the nodes on it have a good amount of spare battery capacity, which means that this is a good route that can be well exploited, and (2) a large number of packers are waiting for the forager, so that the route needs to be exploited even though it might be having nodes with little battery capacity. On the other hand, if no data packets are waiting to be transported, then a forager with a very good route might even abstain from cloning itself because its fellow foragers are doing a good job in transporting data packets. 3. The majority of scouts in BeeSensor explore the network in the neighborhood (𝐻𝑙 hops) of their source nodes and only few of them are allowed to do exploration beyond 𝐻𝑙 hops. As a consequence of it, three benefits are achieved:(1) substantial reduction in the routing overhead, (2) energy efficient route discovery and sampling, and (3) relatively small routing and forwarding tables.

72

3.4 BeeSensor: Architecture and Working

4. A packer stochastically selects a forager – in case foragers of different paths are available – at the source node depending on the quality (goodness) of the paths. Consequently, data packets are distributed on multiple paths. This not only helps in maximizing the performance by avoiding congestion on high quality paths but also enhances the lifetime of the network. We now describe the design of BeeSensor protocol - inspired from the honey bee colony - for WSNs.

3.4

BeeSensor: Architecture and Working

BeeSensor is an event driven multi-path routing protocol for WSNs. BeeSensor discovers paths only when they are needed. The source node maintains all the discovered paths between a pair and routes different events stochastically on these multiple paths. The paths get a priority on the basis of a reward value which in turn is a function of the path length (hops) and the least energy level of a node on the path. To begin with, the bee agent model utilized in BeeSensor is described next.

3.4.1

Bee agent model

Conceptually speaking, BeeSensor works with four types of agents: packers, scouts, foragers and the swarms. Packers are classified as static agents because they perform their tasks within a sensor node. Different mobile agents though have the same structure – consisting of header and payload fields – but they undertake different types of tasks. A brief description of each type of agent is as follows. 3.4.1.1

Packers

Packers behave like the food-storer bees in a hive. Their major responsibility is to receive packets coming from the upper layer and locate an appropriate forager (route) for them. Once a forager is found, packet is encapsulated in its payload and the packer starts waiting for the next packet. Failure in locating a forager is an indication to the packer that no route exists for the sink.

73


3.4.1.2

Scouts

Like their natural counterparts, scouts explore the network in search of a potential sink node. Scouts are classified into two categories: forward scouts and backward scouts. A scout is uniquely identified by its agent ID and the source node ID. Forward scouts propagate in the network using the broadcasting principle. During the exploration of the network, they do not construct a source routing header. As a result, their size becomes independent of the path length that helps BeeSensor to scale to large networks. Once forward scout reaches a sink node, it delivers the event to the upper layer and starts its return journey as a backward scout. Its task is to build a path leading from the sink to the source node (or vice versa) and report the quality of the discovered path once it reaches the source node. 3.4.1.3

Foragers

Like BeeAdHoc [12], foragers are the main workers in BeeSensor as well. Their major role is to carry events to the sink nodes through a predetermined path that is selected stochastically at the source node. Foragers that follow the same path are grouped together in BeeSensor. Foragers traverse using point-to-point mode by utilizing the forwarding information stored at intermediate nodes. They index the table using their path identifier (PID). Foragers also evaluate the quality of their path and report it back to fellow foragers at the source node. 3.4.1.4

Swarms

Foragers are implicitly piggy-backed in the lower link acknowledgement packets to the source node to save energy. However, sometimes they need to be explicitly transported back to their source nodes. A swarm agent exactly serves this purpose. Foragers wait for a certain amount of time at the sink node and then take the initiative to build a swarm of waiting foragers. A swarm can transport multiple foragers in its payload back to the source node. A swarm like foragers is also routed on the reverse links. The four distinct phases of our BeeSensor protocol namely scouting, foraging, swarming and routing loops and path maintenance are discussed in the following subsections.

3.4.2

Scouting

The scouting is divided into two steps: forward scouting and backward scouting. Forward scouting is initiated when a path to a sink node is not available. Forward scouts explore the

74


network and look for a potential sink node. Once a sink node is found, the backward scouts establish multiple paths between the pair.

Forward Scouting

Sink

All 2-hop neighbors rebroadcast forward scouts

Source

Node 4 stochastically decides not to rebroadcast 4

Figure 3.1: Forward scouting in BeeSensor with 𝐻𝑙 = 2

3.4.2.1

Forward scouting

When an event1 is detected at a sensor node, it is handed over to a packer. The packer looks for an appropriate forager that might carry this event to a sink node. If the packer fails to find a forager, it launches a forward scout and encapsulates the event in its payload. Apart from the agent’s type field, the forward scout also carries four additional information fields in the header: scout ID, source node ID, minimum remaining energy (initialized to ∞) and the number of hops (initialized to zero). The forward scout is then broadcast to the neighbors of the source node. A forward scout does not know a priori the address of the sink node. A sink node interested in the event, carried in the payload of a scout, will convert the forward scout to a backward scout. When an intermediate node 𝑖 receives a forward scout from node 𝑗 for the first time, it increments the hop field. The next step is to decide whether node 𝑖 is going to broadcast the 1 We

use the term ”event” and ”data packet” interchangeably in the rest of our discussion.

75


Algorithm 1 : Forward Scout Processing Require: A Replica of Forward Scout (FS) 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34:

if (SinkNode) then //Extract event and pass to application layer EventToApplication(FS); UpdateForwardingTable(FS.From, Node.ID, PathID); //Construct a backward scout and forward to FS.From BS ← ConstructBackwardScout(FS); Forward(BS, FS.From); else if ( NotSeenBefore(FS) ) then 𝐻𝑖𝑠 ← FS.Hops ← FS.Hops + 1; if (FS.Hops ≤ 𝐻𝑙 ) then //Set Broadcast Flag 𝐵𝐹 𝑙𝑎𝑔 ← 1; else 𝐵𝐹 𝑙𝑎𝑔 ← StachasticForwarding(); end if 𝐸𝑖𝑠 ← FS.MinEnergy ← Min(FS.MinEnergy, Node.Energy); 𝐸𝑖𝑠 𝑅𝑖𝑠 ← 𝐻 ; 𝑖𝑠 UpdateScoutCache(FS.From, FS.sourceID, FS.ScoutID, BFlag, 𝑅𝑖𝑠 ); if (BFlag) then Broadcast(FS); else DeleteForwardScout(FS); end if else if ( Forwarded(FS) ) then 𝐻𝑖𝑠 ← FS.Hops +1; 𝐸𝑖𝑠 ← Min(FS.MinEnergy, Node.Energy); 𝐸𝑖𝑠 𝑅𝑖𝑠 ← 𝐻 ; 𝑖𝑠 if ( 𝑅𝑖𝑠 > RewardInCache()) then UpdateScoutCache(FS.From, FS.sourceID, FS.ScoutID, BFlag, 𝑅𝑖𝑠); end if end if DeleteForwardScout(FS); end if

76


forward scout to the next hop or not. If node 𝑖 is at 𝐻𝑙 or less number of hops away from the source, it decides to rebroadcast the forward scout unconditionally. Otherwise, it rebroadcasts it with probability 𝑝𝑏 (See Fig. 3.1) [82]. 𝐻𝑙 and 𝑝𝑏 define a tradeoff between route discovery probability and energy efficiency (details to follow in Chapter 4). It is proposed that 𝐻𝑙 should be a function of the current estimate of the hops between pair. In the next step, node 𝑖 compares the minimum remaining energy field to its own energy level and the value in the forward scout is updated to the minimum of the two. Finally, it creates a scout cache entry that consists of five information elements (see Fig. 3.2): (1) source node ID, (2) scout ID, (3) previous hop (i.e. node 𝑗 in the given example), (4) rebroadcasting flag (=1 if node 𝑖 has decided to rebroadcast else it equals to zero), and (5) reward of the route calculated using 𝑅𝑖𝑠 =

𝐸𝑖𝑠 , 𝐻𝑖𝑠

(3.1)

where 𝐸𝑖𝑠 is the minimum remaining energy level of a node on the path from 𝑖 to 𝑠 and 𝐻𝑖𝑠 is the number of hops from node 𝑖 to source 𝑠. The intuition behind (3.1) is to prefer the least hop path in the first place as paths with high value of 𝑅𝑖𝑠 are preferred. If two paths are of similar hop length, the one with better remaining energy level is preferred. After updating the scout cache, node 𝑖 rebroadcasts the forward scout to the next hop if the rebroadcasting flag in the scout cache is set. Otherwise, the scout is killed and its memory is de-allocated. Each intermediate node keeps repeating this process until the forward scout arrives at the sink node. The processing of a forward scout is also illustrated in Algorithm 1. Communication Among Forward Scouts. One of the key components of Bee-Inspired algorithms is the information exchange among different replicas of the same agent that arrive at an intermediate node through different paths. The first replica of a forward scout in BeeSensor is processed as discussed before. However, when a node receives another replica of the same ID, it does the following: 1. It checks whether the first replica of the current scout ID is already forwarded or not (please recall that a flag is maintained in the scout cache for this purpose). 2. If the first replica was dropped, the duplicate replica is killed without any further processing. This is important because it is useless to store the routing information carried by this replica at node 𝑖 as no backward scout will visit this node to utilize it. 3. If node 𝑖 has earlier broadcast the replica, it updates the hop and energy field of new replica and computes the reward. If the new reward is higher than the existing entry

77


Backward Scouting

ScoutID From Source Ris 1 1 1 10

A scout cache entry at node 2

PID=2

Multiple paths established by backward scouts

13 1

2

3

F 1

54

44 PID=1

A forwarding table entry at node 2 PID NextHop PrevHop 1 3 1

Source Dest. PID NextHop DN 1 54 1 2 15 A routing table entry at Source 1

Figure 3.2: Backward scouting in BeeSensor

in the scout cache, previous hop and the reward fields are updated. In this way, the paths with higher rewards take precedence over the low ones. The new replica is then killed. As a result, this communication paradigm enables the algorithm to discover better routes without any additional overhead. It is also pointed out here that the scout cache entries are maintained for a specific time period. If a corresponding backward scout is not received within this time, the entry is removed. 3.4.2.2

Backward scouting

Nodes in BeeSensor maintain three types of tables: routing table, probability distribution table and forwarding table. Routing tables and probability distribution tables are maintained by source nodes only while forwarding tables are maintained by the sink and the intermediate nodes on a given path. When a sink node receives a forward scout, it extracts the event from the payload area and passes it to the application. Then it creates a new forwarding table entry which contains three fields: a unique path ID, next hop ID and previous hop ID (see Fig. 3.2). Next hop is set to the sink ID, previous hop entry in the forwarding table is set to the node ID from which the forward scout is received.

78


The size of payload is truncated to zero and the minimum remaining energy field in the forward scout header is set to ∞. Then the sink node inserts a unique path ID to the header of the forward scout. Finally, it changes the agent ID to convert it to a backward scout. The backward scout is then forwarded to the node from which the forward scout was received. When a node 𝑖 receives a backward scout from node 𝑗, it looks for a matching scout cache entry. If the information is found, it creates a forwarding table entry (Fig. 3.2) with the next hop set to 𝑗, path ID is set to the value contained in the header of the backward scout while previous hop is set to the previous hop ID present in the scout cache. The scout cache entry is then flushed. No future backward scout of the current generation is entertained and therefore the node will be a part of single route only. In other words, BeeSensor will discover node-disjoint paths only. Finally, it compares its own energy level with the level contained in the header of a backward scout and updates the field to the minimum of the two values. It then forwards the backward scout to the previous hop. Each intermediate node processes the backward scout in a similar way until it reaches the source node. Algorithm 2 : Backward Scout Processing Require: A Replica of Backward Scout (BS) 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20:

if (SourceNode) then 𝐷𝑁𝑛 ← 𝐶𝑎𝑙𝑐𝑢𝑙𝑎𝑡𝑒𝐷𝑎𝑛𝑐𝑒𝑁 𝑢𝑚𝑏𝑒𝑟(𝐵𝑆.𝑀 𝑖𝑛𝐸𝑛𝑒𝑟𝑔𝑦); //Update the routing and probability tables UpdateRoutingTable(BS.SinkID, BS.PathID, BS.From, 𝐷𝑁𝑛 ); UpdateProbabilityTable(𝐷𝑁𝑛 ); DeleteBackwardScout(BS); //Announce path to the neighbors BroadcastBeacon(); else //Check if a matching FS was forwarded earlier if (MatchInScoutCache(BS) then //Update the forwarding table UpdateForwardingTable(BS.From, ScoutCache.PrevHop, BS.PathID); Forward(BS, ScoutCache.PrevHop); DeleteScoutCacheEntry(BS); BS.MinEnergy ← Min(BS.MinEnergy, Node.Energy); else DeleteBackwardScout(BS); end if end if

79


When backward scout reaches the source, it calculates a dance number using the following formula:

⌈ 𝐷𝑁𝑛 =

⌉ 𝑟 ∣(𝛽 − (𝐸𝑚𝑎𝑥 − 𝐸𝑝𝑖𝑑 ))∣ × 𝛼(𝑒) , 𝛾

(3.2)

𝑟 is the minimum remaining energy of the path (identified by unique ID i.e. 𝑝𝑖𝑑) where 𝐸𝑝𝑖𝑑

reported by the backward scout, 𝐸𝑚𝑎𝑥 is the initial (maximum) energy level, 𝛼(𝑒) is a function of the number of events waiting in cache and 𝛽, 𝛾 are user defined constants. The dance number represents the number of foragers recruited for this route (remember a forager carries an event). For higher number of events waiting in the cache, 𝛼(𝑒) has a higher value and more foragers are recruited (see Section 3.3 for the inspiration behind 𝛼(𝑒)). Similarly, a path for which 𝑟 𝑟 is higher, 𝐷𝑁𝑛 would be lower due to low value of 𝐸𝑝𝑖𝑑 . 𝐷𝑁𝑛 is associated with 𝐸𝑚𝑎𝑥 − 𝐸𝑝𝑖𝑑

neighbor 𝑛 from which the backward scout is received. Routing table is then initialized with entries having five fields: source node ID, destination ID, path ID, next hop, 𝐷𝑁𝑛 . In addition to the routing table, BeeSensor also maintains a probability distribution table which is used during the transportation of foragers. The probability distribution table is of size 𝑙 × 𝑑 where 𝑙 represents the number of valid next hop neighbors and 𝑑 is the number of sink nodes. The probability of selecting neighbor 𝑛 as a next hop to reach sink 𝑑, 𝜌𝑛𝑑 , is given by the following equation:

𝐷𝑁𝑛 , 𝜌𝑛𝑑 = ∑𝑙 𝑗=1 𝐷𝑁𝑗

(3.3)

where 𝐷𝑁𝑛 is the dance number associated with the neighbor 𝑛 and 𝑙 is the total number of valid next hop neighbors. A higher dance number represents a good quality path and hence have high selection probability. The processing of a backward scout is summarized in Algorithm 2.

3.4.3

Foraging

Once a route is discovered, the foragers transport events to the sink node. The source node maintains a small event cache in which the events, generated during the route discovery process, are stored. A packer then selects a forager stochastically and encapsulates the event in it. Stochastic selection is based on probability distribution table. For this purpose, a window of 𝑀 events is maintained and a path for each event is selected using the 𝜌𝑛𝑑 values. For instance, if path 1, 2 and 3 has 𝜌𝑛𝑑 = 𝑝1 , 𝑝2 and 𝑝3 respectively (where 𝑝1 + 𝑝2 + 𝑝3 = 1), the number of packets sent along each path are 𝑀 × 𝑝1 , 𝑀 × 𝑝2 and 𝑀 × 𝑝3 respectively. The forager is

80


finally forwarded to the next hop using the path ID of the forager. For instance, in Fig. 3.2, a forager with path ID 1 is forwarded to node 2 by source node 1. A forager follows a predetermined path, therefore, intermediate nodes do not make routing decisions. This is in contrast to ACO/ant-based routing protocols in which intermediate nodes maintain routing tables and then stochastically select the next hop [15, 16]. In BeeSensor, the intermediate nodes simply forward the forager to the next hop based on the path ID. For instance, when node 2 (see Fig. 3.2) receives a forager with path ID 1, it sends it to the node 3. This reduces the forager processing overhead at intermediate nodes. Algorithm 3 : Foraging Require: An event for transportation to sink node 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:

for all Events received from Application do FR=SearchForager(); if (FR == NULL) then if (ForwardScoutingInProgress() ) then //Forward scouting in progress, wait in cache StoreEventInCache(E); else //Route required, initiate forward scouting LaunchForwardScout(E); end if else //Forager found, forward to next hop Forward(FR, NextHop); end if end for

Algorithm 4 : Forager Processing at Intermediate nodes Require: A forager 1: 2: 3: 4: 5: 6: 7:

if SinkNode() then PassToApplication(FR.E); AddToForagersList(FR); else Next ← GetNextHop(FR.PathID); Forward(FR, Next); end if Finally, the probability distribution table is not updated after selecting each forager; rather,

81


new values are reflected in the table after sending a specific number (i.e. 𝑀 ) of foragers to save processing energy. The probability distribution table is also updated once a swarm/forager returns to the source node and updates its dance number. Forwarding of a forager – at the source node and intermediate nodes – are summarized in Algorithm 3 and 4 respectively.

3.4.4

Swarming

The foragers should have a return path to get back to the source node from the sink node. Otherwise, the source node runs out of foragers and subsequently loses path to the destination. It is already mentioned that the foragers are either implicitly piggy-backed in the lower layer acknowledgement packets or swarms are used to explicitly transport them back to the source node. A swarm encapsulates all foragers belonging to its own group – same path ID foragers – in its payload. The swarm is then routed towards the source node using the reverse link entries (previous hop) in the forwarding tables. In addition to this, a swarm does not advertise a path if its minimum remaining energy level is below certain threshold, say 𝐸𝑡ℎ , provided that better quality paths are available. Consequently, the poor quality paths are gradually removed from the routing tables.

3.4.5

Routing loops and path maintenance

3.4.5.1

Routing loops

The reward function in BeeSensor is designed to provide loop freedom in the discovered routes. (Remember that the majority of ant-inspired algorithms suffer from loops due to their stochastic forwarding policy [12, 86]) Recall that backward scouts follow the maximum reward paths. Consequently, backward scouts keep moving in the direction of the source node reducing the probability of selecting a node which is at a larger distance than the current node (see (3.1)). This is illustrated in Fig. 3.3. Moreover, the forwarding table entry at a node indicates that the backward scout has already visited this node. Therefore, if a backward scout visits a node for the second time, it is dropped by the node and the corresponding entry is flushed. In this way, it is ensured that the discovered paths are loop free. 3.4.5.2

Path maintenance

Another important feature of BeeSensor, like BeeAdHoc protocol , is that it does not use explicit HELLO or route error (RERR) messages to check the validity of the routes. Swarming is simple but an elegant way of doing path maintenance. A path at a source node remains

82

3.5 A Review of SI-Inspired Routing Protocols Used in Comparison

Figure 3.3: Backward scouts follow a high reward path and thus travel against the gradients

valid if it has foragers for it. The moment the dance number of a path in the routing table becomes zero, the path becomes invalid and therefore corresponding entry in the routing table is removed after 𝐹 𝑂𝑅𝐴𝐺𝐸𝑅𝑊 𝐴𝐼𝑇 – the waiting time for the foragers that might be on their return journey towards the source node. However, if no forager arrives within the wait time, it is a clear indication that either the path is broken or the sink node is no more interested in the events. It is important to note here that forward scouting is only initiated if: (1) all the paths to a sink node are broken, and (2) events are still being generated / waiting in cache. Finally, it should also be noted that a TTL value is associated with foragers. If the forager is not used within this time, the forager dies. Forwarding table entries at intermediate nodes have also an associated lifetime. This concludes the description of BeeSensor protocol.

3.5

A Review of SI-Inspired Routing Protocols Used in Comparison

As described earlier, BeeSesnor is compared to three other protocols; EEABR, FP-Ant and AODV. A detailed review of the first two protocols is given in Chapter 2. Therefore, a quick

83

3.5 A Review of SI-Inspired Routing Protocols Used in Comparison

recap of these protocols is provided in the following subsections to facilitate the readers in understanding the interpretation of results discussed in Section 3.7.

3.5.1

Flooded Piggybacked Ant Routing (FP-Ant)

FP-Ant is a flooding based variant of AntNet [41] proposed in [16]. In FP-Ant, each data packet is encapsulated in a separate forward ant, which is then stochastically flooded towards the sink node. It utilizes the notion of restrictive flooding, in which an intermediate node 𝑖 rebroadcasts a replica of a forward ant only if it is closer to the destination than the transmitting node. Moreover, node 𝑖 waits for a random amount of time before forwarding the ant to the next hop in order to optimize the flooding process. If it hears the same replica of a forward ant from one of its neighbors then it is dropped. Forward ants also build the source routing header of the path followed by them. Once forward ant reaches the sink node then it is converted to a backward ant, which subsequently visits this path in a reverse order. It reinforces the probabilities of the links of the path visited. This algorithm, as expected, will have a high packet delivery ratio and high energy consumption. FP-Ant is included in the evaluation study because it can act as a benchmark for packet delivery ratio. Moreover, due to the flooding mechanism, FP-Ant will also deplete the energy resources of different nodes at the same rate.

3.5.2

Energy Efficient Ant Based Routing (EEABR)

Energy Efficient Ant-Based Routing algorithm proposed in [15] is based on Ant Colony Optimization (ACO) metaheuristic [10]. Each node in the network launches a forward ant at regular intervals to a specific destination. Forward ants do not construct source routing header of the complete path. Rather, the forward ant carries the addresses of the last two visited nodes only. Other information is stored in the tables at the intermediate nodes. When the forward ant reaches the destination node, it is converted to a backward ant which updates the probability of the path followed by the forward ant to reach the destination node. The reinforcement factor, Δ𝑇𝑘 , is calculated as: Δ𝑇𝑘 =

𝐶−

(

1 𝐸𝑚𝑖𝑛𝑘 −𝐹 𝑑𝑘 𝐸𝑎𝑣𝑔𝑘 −𝐹 𝑑𝑘

)

(3.4)

where 𝐸𝑎𝑣𝑔𝑘 is the average energy of the nodes visited by a forward ant, 𝐸𝑚𝑖𝑛𝑘 is the minimum energy and 𝐹 𝑑𝑘 is the number of hops. When a node 𝑟 receives a backward ant coming from a neighboring node 𝑚, it updates its routing table using the following equation. 𝑇𝑘 (𝑟, 𝑚) = (1 − 𝜎)𝑇𝑘 (𝑟, 𝑚) +

84

Δ𝑇𝑘 𝜙𝐵𝑑𝑘

(3.5)

3.6 Empirical Evaluation Framework

where 𝜙 is a coefficient and 𝐵𝑑𝑘 is the number of nodes visited by the backward ant till node 𝑟. EEABR is a typical proactive routing protocol targeted for energy efficiency and low standard deviation in remaining energy levels to extend network’s lifetime.

3.5.3

Ad-hoc On-demand Distance Vector (AODV) Routing Protocol

AODV [17] discovers routes on-demand only. When a node needs to transport a data packet to an unknown destination, it generates a Route Request (RREQ) packet and broadcasts it to all its neighbors. Intermediate nodes, on receiving a RREQ, search their local routing tables for a valid route to the requested destination. If the search is successful at a node, it generates a reply (RREP), which is unicast to the source node using the reverse links. If no route is found, RREQ is forwarded further after setting up a reverse link. On reception of a RREQ, destination generates a RREP which is unicast to the source node. The current implementation of AODV in RMASE (the simulator used in our empirical study) does not use explicit HELLO packets to detect link failures, rather it implicitly uses link layer packets to do the job. It employs cross layer techniques to avoid paths which have high packet loss ratio. Consequently, AODV becomes highly energy efficient and acts as a baseline protocol in terms of latency as well as total energy consumption. In the following section, we describe the empirical evaluation framework which is used for comprehensive simulation analysis of BeeSensor and other protocols.

3.6

Empirical Evaluation Framework

In this section, the empirical evaluation framework used for an unbiased performance analysis of BeeSensor and other competitor protocols is described. A conceptual view of the framework is shown in Fig. 3.4. Topology generator block, using a set of parameters (e.g. grid size, random offsets, node density etc.), generates a desired network topology. Next important block is the traffic pattern generator or the application generator block. Application generator sets the number of sources and the sink nodes, traffic generation rate of the sources, dynamic or static behavior of the sources and other related parameters. Once, these two blocks are done, the evaluation process selects a protocol from the repository and starts the simulation process. At the completion of an experiment, the metrics are generated by the evaluation block which are written to a file for further processing.

85


Figure 3.4: Performance Evaluation Framework

The empirical evaluation framework is further elaborated with the help of a flow chart shown in Fig. 3.5. After the selection of an algorithm, the application parameters are selected. Then the topology generator block takes over. The selected algorithm is put to simulation test with multiple iterations / runs of the same experiment. After the specified number of iterations are completed, the metric values are recorded in a file. A new topology is then generated and the simulation process repeats for the same algorithm. In the next phase, the application is changed and the same protocol is evaluated under different network topologies. Once this process completes, a new candidate algorithm is selected and passed through the same set of application - topology combinations. In this way, each protocol undergoes rigorous testing procedure over a large operational landscape. Prowler [87], a simulator designed specifically for wireless sensor networks, is utilized for comparative evaluation of BeeSensor with three candidate algorithms: EEABR, FP-Ant and AODV. Prowler is selected because it offers a realistic radio and Medium Access Control (MAC) models for the Berkeley mote platform with a support for an event-based structure similar to TinyOS/NesC that facilitates the implementation of algorithms on real sensor nodes. Routing Modeling Application Simulation Environment (RMASE) [88] is a framework implemented as an application in Prowler. RMASE supports a layered architecture in which the

86


Start Select the next algorithm

Algorithms repository

Application generator

No

Write the results to a file

Topology generator

All topologies done?

Start simulations

Yes No

all applications done? Yes

No

Collect and process the metrics

All algorithms done?

Runs complete?

Yes End

No

Yes

Figure 3.5: Algorithmic description of evaluation framework

routing algorithms can be easily incorporated for comparative evaluation. Moreover, RMASE has a library of built in ant algorithms – FP-Ant, FF-Ant and SC-Ant – and enhanced AODV which removes custom implementation related bias in evaluation. To the best of our knowledge, other simulators do not come with so many SI algorithms. The built-in performance model of RMASE measures few basic evaluation metrics only: latency, success rate / throughput and energy consumption. The performance model is extended to record several other relevant parameters like cyclic complexity, routing overhead (both in terms of packets and bits), average remaining energy and its standard deviation, minimum remaining energy etc., which provide valuable insights into the behavior of a routing protocol for WSNs. All the four protocols are evaluated with two different types of applications. First application is a typical converge-cast scenario in which multiple sources communicate with a single sink node. For this purpose, a circular region is defined allowing a specific percentage of nodes within the region to act as the source nodes. The events are generated at a constant rate of 1 event per second. An event is a fixed sized packet of 512-bits. While keeping the radius at a fixed value, the center of the circular region is selected in a random fashion to factor out any bias that may result due to fixed geographical locations of the source and the sink nodes.

87


The second scenario is a well-known target tracking application of sensor networks. In this application, events are generated by a number of neighboring nodes during a given run of an experiment. A sensor node in the vicinity of a moving target generates some arbitrary sequence of events. As the target moves out of the range of that node, it stops generating the events and another node takes over. Consequently, the scenario becomes challenging for reactive protocols due to the need of repeated route discovery. Both applications, the converge-cast and the target tracking, are run on six different network topologies containing 49, 64, 81, 100, 121 and 144 sensor nodes. The network of 49 nodes is generated by placing the nodes randomly in a square of 140m x 140m. The transmission radius of each node is set to 35 m. Other topologies are generated by scaling the square so that the average node density remains the same. The initial energy level of the nodes in the first static scenario was set to 20 Joules while it was 50 Joules in the case of the target tracking application. The difference in energy levels was intentionally kept higher to study the energy consumption pattern of different protocols at different initial energy levels. The results reported in this chapter have been published in [89]. In each one of these experiments, it is assumed that the links between the nodes are symmetric and nodes are deployed randomly in the sensing field. Each experiment is performed for a duration of 300 seconds and the reported values are an average of five independent runs. The choice of five runs is based on the observation that the results obtained from five runs were approximately identical to the ones obtained from ten runs.

3.6.1

Description of evaluation metrics

3.6.1.1

Latency

It is defined as the difference in time when an event is generated at a source and when it got delivered at the sink node. The lost events are not included in the latency calculations. An average value of the latency is reported. 3.6.1.2

Packet delivery ratio

It is the ratio of total number of events received at a sink node to the total number of events generated by all the source nodes in the network. The loss ratio is then defined as: 𝐿𝑜𝑠𝑠𝑟𝑎𝑡𝑖𝑜 = 1 − (𝑝𝑎𝑐𝑘𝑒𝑡 𝑑𝑒𝑙𝑖𝑣𝑒𝑟𝑦 𝑟𝑎𝑡𝑖𝑜)

88

(3.6)


3.6.1.3

Energy consumption

Energy consumption model includes three major types of energy consuming processes in wireless devices; transmission of packets, reception of packets, and the energy consumed in the idle state. The total energy consumed by all the sensor nodes in a given network during each experiment is reported. 3.6.1.4

Energy efficiency

Energy efficiency is defined in terms of Joules / Kbits. More specifically, it is computed by dividing the total energy consumed in the network by the number of Kbits delivered successfully at the sink node. Kbits here refers to 1000 bits of data. 3.6.1.5

Lifetime

Although both average remaining energy of the nodes and its standard deviation are recorded, these two parameters are not reported independently. Rather, the lifetime of the network which is defined as the difference of average remaining energy levels of sensor nodes and the standard deviation of energy levels is reproted. The basic motivation behind this definition is that an algorithm should try to maximize average remaining energy levels of nodes with a small standard deviation. It is reported in %. 3.6.1.6

Algorithmic complexity

It is defined as the total number of CPU cycles consumed, for processing control packets and forwarding of data packets, by a protocol during an experiment per 1000 bits of data delivered at the sink (Cycles/Kbits). 3.6.1.7

Control overhead

It is defined as the number of control bits in the network per 1000 bits of delivered data at the sink (Control bits/Kbits). 3.6.1.8

Control complexity

It is defined as the total number of CPU cycles consumed in processing of control traffic per 1000 bits of delivered data (CPU cycles/Kbits).

89

3.7 Discussion on Simulation Results

3.7 3.7.1

Discussion on Simulation Results Packet delivery ratio

The packet delivery ratios of the protocols in both applications are shown in Fig. 3.6(a) and 3.6(b). FP-Ant has the highest packet delivery ratio followed by BeeSensor in both scenarios. High packet delivery ratio of FP-Ant shows that information dissemination through flooding is more robust in dynamic networks. In the case of the converge-cast scenario, the packet delivery ratio of BeeSensor is significantly higher compared with AODV and EEABR in large networks. The other important observation is that EEABR does not provide a consistent performance. The inconsistent behavior of EEABR is due to its proactive route discovery mechanism. As the number of control packets increase in the network, congestion occurs and collisions increase. As a result, forward ants start losing their way to the sink node and probability values do not stabilize which leads to the loss of data packets. This argument is supported by the fact that the performance of EEABR deteriorates further in larger topologies where control traffic is even higher (recall that every node in EEABR launches forward ants at regular intervals). Target tracking, as expected, is a difficult scenario for BeeSensor and AODV due to their

(a) Packet delivery ratio: Converge-cast

(b) Packet delivery ratio: Target tracking

Figure 3.6: Packet delivery ratios for the two scenarios reactive nature. Every time a source node changes, a new route discovery is initiated. However, the results demonstrate that the performance of BeeSensor is significantly higher as compared to AODV. There are three important reasons for this superior performance as mentioned below.

90


✓ BeeSensor limits the control traffic through stochastic forwarding of scouts and suppressing the multiple scoutings process. As a result, nodes handle this small traffic gracefully and protocol converges pretty quickly. ✓ Use of a small event cache also marginally improves the packet delivery ratio. It should be pointed out here that BeeSensor does not maintain a large event cache. Rather, only the last 5 events are cached in the current implementation. Effect of cache in converge-cast scenario is even further reduced because the number of events waiting in cache would be smaller. ✓ A simple forager forwarding logic at intermediate nodes also improves the packet delivery ratio by avoiding the buildup of queues at intermediate nodes. FP-Ant is almost unaffected by this dynamic scenario as it simply floods the forward ants carrying the events in a restricted way. As different nodes take over as a new source of events, FP-Ant simply floods the events from the new source. The performance of EEABR relatively suffers more in this dynamic application primarily because its convergence rate is too high. Switching of source nodes on run time even further complicates the convergence process.

3.7.2

Latency

The latencies of the protocols are shown in Fig. 3.7(a) and 3.7(b). In the static scenario, all protocols have approximately the same average latency. In small networks, the average number of hops between the source and the sink node is smaller and therefore latencies are also relatively smaller. However, as expected, they increase in larger topologies. However, in case of target tracking, BeeSensor has the largest latency. Recall that BeeSensor maintains a small event cache which stores the events detected during the scouting process. As number of route discoveries in target application are initiated too often, it results in more events waiting in the cache. Consequently, the number of events reaching the sink node with higher end-to-end delay increase which ultimately contributes to higher average packet latency. AODV maintains no event cache in the current implementation. This option was kept intentionally to study the trade-offs of having and not having an event cache at a sensor node. The target tracking results show that an event cache will increase the average packet latency but enhance the packet delivery ratio. One can also verify this argument by analyzing the latency values of converge-cast scenario. In this scenario, BeeSensor has almost identical latency values as compared to rest of the protocols. In some cases, it is even less than AODV. Furthermore,

91


BeeSensor is a multi-path routing protocol and tries to route packets through high energy nodes instead of always routing through shorter paths. This also contributes to higher latency of BeeSensor.

(a) Latency: Converge-cast

(b) Latency: Target tracking

Figure 3.7: Latencies for the two scenarios

3.7.3

Total Energy Consumption

Wireless sensor nodes are equipped with a small non-rechargeable battery. In addition to this, due to immensely high number of nodes, it is practically infeasible to replace the battery of the nodes. Therefore, optimal utilization of available energy resource is critical to the overall operation of a sensor node and the network. Fig. 3.8(a) and 3.8(b) shows the total energy consumption of the protocols for both types of application scenarios (note that y-axes in the figures are on a logarithmic scale). It is clear from Fig. 3.8(a) and 3.8(b) that BeeSensor consumes least amount of total energy. Remember that nodes in BeeSensor located beyond 2 hops perform stochastic broadcasting of scouts. As a result, number of transmissions in the network reduce and hence the energy consumption. Remember AODV is used as a benchmark algorithm for energy consumption because it is specially optimized for this purpose. Results show that in the static converge-cast scenario, energy consumed by AODV is either lower or equal than that of BeeSensor. This primarily is due to two reasons. First, the number of route discoveries in converge-cast scenario are minimal as the sources do not change on run time. Second, average hop length between a source and the sink node is approximately 3.5 hops. Consequently, stochastic broadcasting impact is not much distinguishable.

92


FP-Ant as expected has the highest energy consumption and it remains approximately the same in both scenarios. It is important to note that FP-Ant is not a pure flooding protocol but it performs restrictive flooding of forward ants which carry the data ants as described in Section 3.5. One can easily extrapolate the energy consumption of a pure flooding algorithm. Target

(a) Total energy consumption (J): Converge-cast

(b) Total energy consumption (J): Target tracking

Figure 3.8: Total energy consumption for the two scenarios tracking results show similar trends. An important point to note is that the difference between the energy values of AODV and BeeSensor is higher than the one observed in the converge-cast scenario. This confirms the argument mentioned above that number of route discoveries do affect the energy consumption of both protocols. Higher is the number of route discoveries, higher will be the difference between the two. An additional point to is that BeeSensor has a higher packet delivery ratio and successful delivery of these packets also consumes appreciable energy. As the network becomes larger, this part of energy also increases due to increased number of hops between the source and the sink nodes. Therefore, the difference in the energy consumption of BeeSensor and AODV becomes smaller. The behavior of EEABR is consistent in terms of energy consumption. When the number of nodes are smaller, they generate less number of forward ants and hence the energy consumption is low. As network goes bigger, more nodes participate in the proactive route discovery mechanism leading to the higher energy consumption. EEABR has almost similar energy consumption in both types of scenarios primarily because the launching interval of forward ants is fixed. Therefore, EEABR generates almost identical control traffic irrespective of the traffic pattern or the application requirement. This can be devastating in case of applications which

93


generate very less or periodic events. Therefore, the choice of proactive approach and fixed launching interval must be carefully analyzed and justifiable in resource constrained sensor networks.

3.7.4

Energy Efficiency

The primary purpose of a routing protocol is to deliver a data packet from one node, called a source node, in the network to another node, called a destination node. Rest of the design considerations are of secondary importance and differ in various categories of the network. In case of wireless sensor networks, the secondary objective of a routing protocol is to route this data packet at minimal of energy cost. The energy efficiency metric is used to analyze the performance of the protocols under evaluation in meeting these two objectives. Energy efficiency values of these protocols are shown in Fig. 3.9(a) and 3.9(b)). AODV and BeeSensor are the two best protocols in terms of energy efficiency. Best energy efficiency of BeeSensor is due to its low total energy consumption and high packet delivery ratio. Remember that if the loss ratio is high (or the packet delivery ratio is low), as in case of AODV, it shows that protocol is unable to establish a route quickly (i.e. in the first attempt). Consequently, it launches another series of RREQs which ultimately contribute to higher energy consumption.

(a) Energy efficiency (J/Kbits): Converge-cast

(b) Energy efficiency (J/Kbits): Target tracking

Figure 3.9: Energy efficiency for the two scenarios Recall that FP-Ant launches a forward ant with each event generated at a source node. Therefore, number of ants generated in the network increases as more and more events are detected at the node causing substantially higher energy consumption as shown in Fig. 3.8.

94


However, this high energy consumption of FP-Ant is dampened by its high packet delivery ratio. The energy efficiency figures show that EEABR is pretty close to FP-Ant although EEABR consumes significantly low energy. This trend is clearly due to the poor packet delivery ratio of EEABR. This gives us an important information. If the use of flooding type approach is justified, either through delivering higher number of packets or in terms of any other metric (e.g. fault tolerance, reliability), it can be used under the assumed conditions. Also note that in the static converge-cast scenario, the energy efficiency bars of BeeSensor and AODV are pretty close to each other. On the other hand, in the target tracking application, BeeSensor is significantly better compared with AODV. The reason is the ability of BeeSensor to converge quickly in case of a dynamic scenario and achieve significantly higher packet delivery ratio. Clearly this is due to frequent route discoveries happening in the case of target tracking scenario. As more and more traffic is generated in the network, the probability that a protocol would be able to discover route in the fewer attempts decreases. Consequently, retries in the route discovery process makes things even worse. This not only increases the total energy consumption, but also reduces the packet delivery ratio. This argument is also supported by a comparatively smaller difference in the energy efficiency values in the case of converge-cast scenario.

3.7.5

Algorithmic Complexity

As sensor nodes are equipped with low end processors, algorithmic complexity is also a critical parameter. The algorithmic complexity depends upon a number of factors as mentioned below.

✓ The complexity of the routing protocol itself which involves the processing of a control packet, routing table updates, forwarding logic and route discovery and maintenance. ✓ The second factor is the number of control packets injected into the network. If nodes have to process higher number of such messages, the complexity will increase. ✓ The equations or functions used to evaluate the path quality can also raise the complexity level of an algorithm. This is even more applicable to ACO based routing algorithms make use of exponentials in these functions. The results of algorithmic complexity are shown in Fig. 3.10(a) and 3.10(b) (y-axes in these figures are also on logarithmic scale). It is evident that BeeSensor is the best protocol and has

95


(a) Cyclic complexity: Converge-cast

(b) Cyclic complexity: Target tracking

Figure 3.10: Cyclic complexities for the two scenarios significantly smaller cyclic complexity as compared to other protocols in both scenarios. The simplicity of BeeSensor is primarily due to three main reasons. 1. The simple agent model which makes the processing of these agents at intermediate nodes fast and energy efficient (remember that equation (3.1) is proposed to evaluate path quality). 2. BeeSensor restrict the total number of control packets generated in the network and therefore nodes have to process fewer such messages. 3. Nodes in BeeSensor do not make routing decisions at intermediate nodes like the ACO based algorithms. Rather foragers are switched to next using a path ID as described earlier. AODV performs much better than EEABR and FP-Ant in the converge-cast scenario but suffers in the target tracking scenario. This provides us a valuable insight about a reactive protocol that pure flooding of the control packets can lead to high algorithmic complexity. On the other hand, high complexity of FP-Ant is due to two main reasons. 1. It generates significantly higher number of control packets. 2. Intermediate nodes utilize complex logic to decide whether to rebroadcast a data ant or not. As a result, complexity of the protocol increases significantly.

96


One can clearly see in Fig. 3.10(a) and 3.10(b) that the cyclic complexity of the algorithms increases significantly in the target tracking scenario. The increase in the complexity of reactive algorithms, AODV and BeeSensor, is about 5 to 6 times in the dynamic scenario as compared to the static scenario. This provides us another important insight into the serious shortcomings of reactive algorithms i.e. under highly dynamic conditions. However, even after this substantial increase in the processing complexity, the reported figures of AODV and BeeSensor are still significantly smaller compared with FP-Ant and EEABR.

3.7.6

Control Overhead

Control overhead of a protocol directly affect many other performance measures e.g. total energy consumption, algorithmic complexity etc. Therefore, routing protocol must restrict the total number of routing messages to control the overshoot of the related parameters. The control overhead of all protocols is shown in Fig. 3.11(a) and 3.11(b). BeeSensor has the least values among all the protocols. It is worth mentioning here that the simulation results reported in this section do not incorporate suppression of parallel scoutings. Therefore, the reduction in the number of control packets is due to restrictive flooding of forward scouts. Consequently, the protocol converges pretty quickly and starts routing the events. It is also important to note that decrease in the control overhead does not adversely affect the performance of BeeSensor i.e. packet delivery ratio. AODV performs better in the converge-cast application and has

(a) Control overhead: Converge-cast

(b) Control overhead: Target tracking

Figure 3.11: Control overhead for the two scenarios comparable overhead with the best performing protocol i.e. BeeSensor. As sources do not

97


change during run time, the route discovery frequency is negligible. Consequently, AODV is able to discover route quickly and deliver higher number packets at less control overhead. However, AODV control overhead substantially increases in the case of target tracking. As the frequency of route discovery increases in the target tracking, the protocol convergence time increases. This results in even further increase in the number of route discoveries. Consequently, events start losing and bulk of the nodes are involved only in processing the RREQs. Therefore, control overhead increases. Higher control overhead of EEABR is due to its proactive nature and becomes more pronounced when the packet delivery ratio is low (control bits / Kbits). FP-Ant suffers as its control overhead is proportional to the number of generated events (remember a forward ant carries a data ant). In addition, the ants also build the source routing header of the followed path which further increases the size of the forward ant resulting in even higher control overhead. It is also evident from the figures that the targeting tracking application, due to its dynamic nature, increases the control overhead of all protocols.

3.7.7

Control Complexity

This parameter is calculated separately from the algorithmic complexity just to highlight the amount of processing power wasted in handling the control traffic. The complexity values are listed in Table 3.1. BeeSensor’s performance is again superior as compared to rest of the Table 3.1: Control complexity Application scenario

Converge-cast

Target tracking

Number of nodes 49 64 81 100 121 144 49 64 81 100 121 144

CPU cycles (in millions)/Kbits of data FP-Ant EEABR BeeSensor AODV 4428 978 24 95 8011 1208 28 173 11936 4845 35 252 17815 2574 40 369 23118 6762 50 655 29573 6688 56 1219 5801 2804 866 2984 10663 2518 943 3686 15727 4216 1208 5634 26759 5670 1646 5485 34372 11456 1670 6809 40905 14034 2112 8307

%age Diff. from the lowest value FP-Ant EEABR AODV 18435 3994 297 28469 4209 517 33953 13722 620 43922 6260 812 45904 13355 1203 52691 11839 2077 570 224 245 1031 167 291 1202 249 366 1526 244 233 1958 586 308 1837 565 293

protocols followed by AODV. The difference from the lowest value is also tabulated to provide a quantitative insight into the merits/demerits of reactive or proactive protocols in different scenarios. Take the case of target tracking application in a network 81 nodes in which the packet

98


delivery ratio of AODV is higher than EEABR (refer to Fig. 3.6(b)) and compare it with the control complexities in the same scenario shown in Table 3.1. Interestingly, EEABR has better control complexity compared with AODV. This demonstrates the significance of optimizing the route discovery process. The results clearly indicate that a simple route discovery mechanism coupled with agents that have a simple behavior is the key to best performing protocols. It should also be noted that in case of the static scenario, reactive protocols are matchless in terms of energy consumption, control overhead and cyclic complexity.

3.7.8

Lifetime

The lifetime of the network at the end of each experiment is listed in Table 3.2. The results show that BeeSensor has better or equal lifetimes than AODV. It is interesting to note that the primary objective of EEABR is to achieve better average remaining energy and its standard deviation. However, when compared with AODV and BeeSensor, its energy consumption is significantly higher due to its relatively large control overhead. As a result, lifetime achieved by EEABR is smaller than AODV and BeeSensor. This is also validated quantitatively by

Application scenarios

Converge-cast

Target tracking

Table 3.2: Lifetime of the network Number of nodes 49 64 81 100 121 144 49 64 81 100 121 144

FP-Ant 65 64 66 66 65 63 90 88 88 88 89 87

% age remaining lifetime EEABR BeeSensor AODV 84 93 91 85 94 93 87 94 93 86 94 93 87 95 95 85 95 96 95 97 89 96 97 95 91 97 91 95 98 98 86 98 98 96 98 98

selecting a small initial energy level of the nodes in case of covergecast scenario. FP-Ant due to its flooding property, consumes more energy and it reduces the network lifetime to 63% which is about 30% less than the best protocol.

99

3.8 Conclusions

3.8

Conclusions

In this chapter, we have proposed a distributed, scalable and energy-efficient bee-inspired routing protocol for wireless sensor networks – BeeSensor. Like other SI algorithms, BeeSensor is designed with the so called “bottom-up approach” in which the behavior of individual nodes is defined keeping in view of the desired network level behavior. However, in contrast to typical ACO-based algorithms, BeeSensor utilizes simple heuristic functions and allows complex stochastic routing function at the source nodes only. This not only results in fast switching of data packets but also provides relief to the low-end processors by reducing the processing overhead. In addition to this, BeeSensor discovers node-disjoint paths only which are not only fault-tolerant but also enable the protocol to consume the nodes battery at an equal rate. The experimental results show that BeeSensor delivers superior performance in terms of packet delivery ratio and latency, but with the least energy consumption compared with other SI algorithms. The important reasons for this behavior of BeeSensor are: (1) a simple routing agent model, (2) agent-agent communication to discover optimal paths, (3) fixed size of route discovery agents that not only saves significant amount of energy during their transmission but also makes the algorithm scale to large networks, (4) distributed and decentralized control, and (5) self-organization to make it resilient to external failures. In the following chapter, we complement the results obtained through simulations by the formal modeling of key performance metrics of BeeSensor algorithm. In addition to this, the formal modeling process also enabled us to further analyze the strengths and weaknesses of BeeSensor protocol which are subsequently utilized to improve the initial design proposed in this chapter.

100

Chapter 4

Formal Evaluation Framework for Ad Hoc Routing Algorithms 4.1

Introduction

Routing in ad hoc networks has been under intense research for the past several years resulting in several classical [17, 24, 25, 82] as well as Bio-Inspired [13, 16, 23, 90, 91, 92] protocols. Although these protocols are based on different design doctrines, we observe that the authors of both communities predominantly used simulation studies for the performance evaluation of these algorithms. The use of simulators for evaluation is popular due to three main reasons: (1) it is the most suitable way to code and execute complex algorithmic logic in a network that is much closer to reality, (2) it is the easiest method when compared to mathematical verification process / evaluation on real networks, and (3) it also allows the designers to produce results of their own choice through simple programming tricks. The last reason for the choice of simulation analysis is the most dominant one and has been questioned seriously in earlier studies. Kurkowski et al. (2005) [14] conducted a statistical survey on the accuracy and the use of proper scientific practices in the simulation studies reported in the published papers of MobiHoc – one of the prestigious conference on ad hoc networking. The authors observed that out of a total of 75% simulation-based papers, approximately 30% did not even mention the name of the simulator. While node density, simulation area and node transmission range are the three fundamental parameters of an ad hoc network, 56% of the papers did not report either of them. Similarly, 58% of the papers did not describe the type (terminating or steady-state) of simulations used in the study and about 87.5% papers did not show confidence intervals

101

4.1 Introduction

on the plots. These alarming statistics have cast a doubt on the credibility and reliability of simulation-based evaluation. Furthermore, it is also a well-known fact that simulation studies is an extremely time consuming as well as resource demanding process. Finally, freely available simulators are infeasible to simulate large scale networks. Inspite of the deficiencies of the simulation process, it is still the only way in which a protocol can be analyzed in a real network environment. The importance of simulations can even be further enhanced by scientific execution of the whole process. Therefore, network simulations have probably no replacement at this point in time. However, keeping in view of the highlighted deficiencies, we believe that simulation-based evaluation should be complemented with mathematical modeling of the key performance parameters of ad hoc routing protocols. This approach will have several advantages. 1. It will evaluate the novel ideas in an unbiased manner and the performance results would be consistent as well as generalizable. 2. It will allow the designer to analyze the strengths and weaknesses of his / her protocol at an early protocol engineering cycle. 3. It will save significant amount of time and resources because the results of mathematical models are almost instantly available. 4. The mathematical models are scalable to infinitely large topologies and therefore provide an opportunity to the designers to monitor the scalability characteristics of their algorithm. 5. Mathematical expressions often contain more information than the ones that engineers have originally put into it. Therefore, the analytical models have the potential to unleash some interesting insights that otherwise would have been simply impossible to infer. With this motivation, in this chapter, we develop a formal evaluation framework to model the two most widely-used performance metrics of wireless ad hoc routing algorithms [2], namely routing overhead and route optimality. Speaking more specifically, we do the following. ✓ We develop a generic routing overhead model for ad hoc routing protocol in terms of the predominant route discovery process.

102

4.1 Introduction

✓ We also model the probability of optimal and suboptimal route discoveries for single as well as multipath ad hoc routing protocols. In addition to this, we develop generalized expressions for the route discovery probability – for single and multipath routing protocols – irrespective of the path length. We call it marginal probability of route establishment. ✓ Along with the channel impairments, collisions at the medium access control (MAC) layer cause packet loss. We, therefore, also incorporate channel contention and error affects in the proposed modeling framework. ✓ The prime focus of this work is to develop performance models for BeeeSensor protocol. However, the derived metrics in the proposed framework are parameterized such that they can be adapted to proactive ad hoc routing protocols. As a proof-of-concept, we use the proposed framework to develop specific models of the two metrics for DSDV, DSR and AODV. ✓ Simulation studies require significant time in the execution and implementation phases. To emphasize this statement and study the effect of modeling assumptions on the evaluated routing metrics, we present a comparison of the analytical results obtained in a fraction of second from our analytical models with an independently-conducted simulation results [2] which may have taken several weeks to reach the compilation stage. ✓ We then develop the routing overhead and route optimality models for BeeSensor using the generic framework and compare its performance with AODV. Based on the comparison and analysis, we infer several insights about the impact of different parameters on the performance of BeeSensor protocol. The insights will be used to develop an improved design of BeeSensor protocol in Chapter 6. We believe that the proposed formal framework can be instrumental in two ways: (1) to expose the inherent weaknesses of a typical flooding-based route discovery procedures, and (2) to serve as a baseline for future research on performance modeling of ad hoc routing algorithms. We now present a summary of the related work. This will benefit our cause in two ways. First, it will help the reader to infer that performance modeling is still a potential area for future research. On the other hand, it will also demonstrate that the work reported in this chapter is novel.

103

4.1 Introduction

4.1.1

Related Work

Roth (2007) [93] has developed an analytical framework based on the Markov chains for the analysis of probabilistic routing protocols. He argued that routing sensitivity, routing threshold/noise and a metric estimator are the key parameters that define the overall behavior of probabilistic routing algorithms. Roth has then provided an estimation of these parameters in his work. Roth and Wicker (2004) [94] have provided an analytical justification of the three pheromone update mechanisms used in Termite [91]. Zahid et al. (2007) [95] have proposed a framework for theoretical evaluation of Bio-inspired routing protocols for fixed networks. As an example, they developed mathematical models of the throughput, packet delivery ratio, packet delay and routing overhead of BeeHive protocol. The authors of [95] have also shown that their analytical results are consistent with the ones obtained through simulations. One of the most prominent analytical study in the ad hoc routing domain is done by Bettstetter (2002) [96], in which he modeled an ad hoc network as a random graph. The model provides the node transmission radius, 𝑟0 , that ensures a 𝑘-connected network for a given node density. Bettstetter’s connectivity model serves as a foundation of the work reported in this chapter. Wang et al. (2004) [97] have proposed a bi-dimensional Markov chain model for the analysis of distributed, dynamic and randomized clustering techniques. Based on this model, they evaluated stochastic properties of the Low Energy Adaptive Clustering Hierarchy (LEACH) [52] protocol. To counter the inherently unreliable nature of ad hoc networks, Tsirigos and Haas (2004) [98] have proposed a routing scheme that makes use of multiple simultaneous paths. With the addition of an overhead to each packet, the authors of [98] fragmented the resulting unit into multiple blocks and routed each one of them through a distinct path. The authors then studied the probability of reconstructing the original information at the destination. They have shown analytically that packet dropping probability decreased with an increase in the number of used paths. The authors extended their work in [99] by relaxing the restrictions e.g. independent or disjoint paths, identical path failure probability. More specifically, the authors have proposed an approximation technique for selecting an optimal path set in order to maximize the successful transmission probability in the cases of non-independent paths and the ones in which failure probability also varies. Zhou and Abouzeid (2005) [100] have derived expressions for minimum length of control packets exchanged by cluster-based proactive ad hoc routing protocols. They have performed scalability analysis of routing overhead with respect to network and cluster sizes. Furthermore,

104

4.1 Introduction

they derived expressions for optimal cluster sizes to reduce the routing table size and the routing overhead. Xianren et al. (2007) [101] have proposed a theoretical framework for computing the overhead of proactive routing protocols for MANETs. The authors proved that the overhead of the routing protocols increased with mobility. Jacquet and Laouiti (2000) [102] compared the performance of proactive routing protocols with flooding based routing mechanisms through simulations. They also modeled the control overheads. However, a final closed-form solutions of these models are not provided. Santivanez et al. (2002) [103] have done scalability analysis of a set of routing algorithms for mobile ad hoc networks. The authors defined a scalability factor for a routing protocol in terms of minimum traffic load and the total overhead which served as the basis of scalability analysis. The authors have shown that plain flooding scales better in terms of mobility while Hazy Sighted Link State (HSLS) [104] routing scales better with network size. Sadagopan et al. (2005) [33] have built a mathematical model for a WSN query protocol called ACQUIRE. The authors also proposed similar models for Expanding Ring Search (ERS) and Flooding Based Queries (FBQ) for mutual comparison. Heusse et al. (2003) [105] have analyzed the performance anomaly of 802.11b [106] by deriving expressions for throughput, probability of collision and contention time. Cheng and Robertazzi (1989) [107] discussed the effect of node density and the transmission power on the broadcast percolation in multihop wireless networks assuming that the nodes are Poisson distributed on a one-dimensional as well as two dimensional grid.

4.1.2


The rest of the chapter is organized as follows. Section 4.2 provides a brief introduction to the graph theory. Section 4.3 contains system description and modeling assumptions. Definitions of the key terms are described in Section 4.4. Generic routing overhead model is explained in Section 4.5 followed by the route optimality model in Section 4.6. Section 4.7 contains the derivation of expressions for route discovery latency and the total energy consumed by a protocol. Routing overhead and route optimality models of BeeSensor are developed in Section 4.8. Conclusions are summarized in Section 4.9.

105

4.2 Introduction to Graph Theory

4.2

Introduction to Graph Theory

A simple graph 𝐺 = {𝑉, 𝐸} consists of a finite nonempty set of vertices or nodes 𝑉 = {𝑣1 , 𝑣2 , 𝑣3 , . . . , 𝑣𝑛 } and an edge set 𝐸 = {𝑒1 , 𝑒2 , 𝑒3 , . . . , 𝑒𝑛 } connecting the vertices. A graph 𝐺 may be directed or undirected. A directed graph has an ordered pair of edges represented as 𝐸 = {{𝑣1 , 𝑣2 }, {𝑣2 , 𝑣3 }, . . . } while an undirected graph contains unordered edge pairs e.g. 𝐸 = {(𝑣1 , 𝑣2 ), (𝑣2 , 𝑣3 ), . . . } [96, 108]. The term graph in the rest of this chapter refers to an undirected graph unless specified otherwise.

4.2.1

Neighbors or adjacent vertices

Two nodes 𝑢 and 𝑣 in graph 𝐺 are said to be adjacent to / neighbors of each other if 𝑒 = (𝑢, 𝑣) is an edge of the graph. The edge 𝑒 in fact indicates a communication link between nodes 𝑢 and 𝑣.

4.2.2

Degree of a Node

Node degree, represented as 𝑑(𝑥), refers to the number of nodes directly connected with node 𝑥. Minimum degree of 𝐺 is then defined as: 𝑑𝑚𝑖𝑛 (𝐺) = 𝑚𝑖𝑛 {𝑑(𝑥)}

∀x𝜖G

Another important term in this context is the average degree (𝑑𝑎𝑣𝑔 ) of 𝐺 which is defined as: 𝑑𝑎𝑣𝑔 (𝐺) =

𝑛 1∑ 𝑑(𝑥) 𝑛 𝑥=1

A node with a zero degree represents an isolated node.

4.2.3

Connectivity of a graph

Connectivity of a graph refers to whether the vertices of a graph are connected to every other vertex in the graph or not. Specifically, a graph 𝐺 is said to be connected if at least a single path exists between each pair of the vertices (or nodes) of 𝐺. Otherwise, 𝐺 is said to be a disconnected graph. Graph 𝐺 having at least 𝑘 mutually independent paths between each pair of nodes is known as a k-connected graph (see Fig. 4.1). It also describes that in a 𝑘-connected graph, there are no 𝑘 − 1 nodes whose removal will result in disconnected graphs. For instance,

106

4.3 System Description and Modeling Assumptions

Figure 4.1: Connectivity of a graph in Fig. 4.1, if we remove any single node from the graph, it will not result in a disconnected graph. 𝑘-connected graph may be disconnected by removing at least 𝑘 nodes from the graph. Another relevant term is edge-connectivity. A graph 𝐺 is said to be 𝑘-edge connected if and only if 𝑘 edge-disjoint paths exist between each pair of vertices. A 𝑘-connected graph is also a 𝑘-edge connected graph. For instance, the graph shown in Fig. 4.1 is also 2-edge connected graph. However, 𝑘-edge connected graph may or may not be a 𝑘-connected graph.

4.3 4.3.1

System Description and Modeling Assumptions Modeling Assumptions

We consider a dense ad hoc network of 𝑁 nodes which are distributed on a two-dimensional plane using a homogeneous Poisson distribution with node density 𝜌. The resultant graph is assumed to be connected and all links (or edges) are symmetric. A link between two nodes exists if they lie within the transmission radius of each other. However, the presence of a link does not in anyway guarantees the delivery of packet in either direction. Two nodes are adjacent - neighbors - to each other if there exists a direct link between them. We assume an ad hoc network with a CSMA/CA-based MAC layer protocol for contention resolution. Even in the case of no contention, we account for the possibility that a packet may be lost due to channel errors (such as interference, fading etc.). For simplicity, we assume that the network topology does not change during a route discovery process. This assumption is realistic because

107

4.3 System Description and Modeling Assumptions

timescale of mobility is much smaller than the timescale of a single route discovery. The routes may, however, change considerably from one route discovery to another. Similarly, we assume that the channel conditions do not change considerably during an RREQ transmission between two nodes. Finally, we assume that the nodes can transmit at a single uniform rate only.

4.3.2

Network Topology

For the system described above, Bettstetter (2002) [96] derived the transmission range 𝑟0 to ensure that all nodes will have exactly 𝑛0 neighbors. Specifically, probability 𝑃 that a node has exactly 𝑛0 neighbors is given by 𝑃 (𝑑 = 𝑛0 ) =

(𝜌𝜋𝑟02 )𝑛0 −𝜌𝜋𝑟02 ⋅𝑒 . 𝑛0 !

(4.1)

Putting 𝑛0 = 0 in (4.1) gives the probability that a node selected at random will be an isolated node. Mathematically, we write it as 2

𝑃 (𝑑 = 0) = 𝑒−𝜌𝜋𝑟0 . One of the most important term that we use frequently in our model is the average degree of a node which – for the assumed network – is given by 𝐸(𝑑) = 𝑑𝑎𝑣𝑔 = 𝜌𝜋𝑟02 .

(4.2)

Eq. (4.2) is pretty much self explanatory. The term 𝜋𝑟02 gives the area of the transmission circle of a node and multiplying it with the node density 𝜌 gives the total number of nodes located within the transmission circle of a node. To be sure with a certain probability 𝑝 that the network having 𝑁 ≫ 1 nodes is connected, the transmission radius 𝑟0 must be set to 𝑟0 ≥

√

1

− ln(1 − 𝑝 𝑁 ) . 𝜌𝜋

(4.3)

Equations (4.2) and (4.3) can be used to create an ad hoc network with desired on-average topology characteristics. For example, assume that a network consists of 10, 000 nodes (𝑁 ) deployed randomly in an area of 106 𝑚2 . We are interested in finding the minimum transmission radius 𝑟0 that can keep the network connected. Now, the density of the given network 𝜌 can be computed by dividing the number of nodes by the given area. Now, we can calculate the value of 𝑟0 using (4.3). For the given network, the transmission radius 𝑟0 of each node must be

108

4.4 Definitions

set to a value of 21 𝑚 to predict with substantially high probability (99% in this case) that the network is connected.

4.4

Definitions

This section contains the definitions of key terms that are used in the rest of this chapter.

4.4.1

Routing Overhead

Discovery of fresh routes in on-demand ad hoc routing protocols primarily consists of two main components; flooding of route discovery messages e.g.RREQs, forward ants / scouts and the propagation of response packets. We refer to the first component of this process as the route discovery mechanism. Being the predominant source of control traffic generation, we define the routing overhead in terms of the route discovery process as given below. Definition: Routing overhead of a reactive protocol is the total number of control packets launched in the network by the protocol in response to a route request (RREQ) message up to an arbitrary number of hops from the source node.

4.4.2

Optimal and suboptimal routes

Route optimality is a protocol dependent term and therefore may be defined in several ways. A protocol may define an optimal route in terms of number of hops, energy, reliability, latency, etc. For instance, an optimal route might be the route which has the lowest packet latency. Alternatively, it might be a route which contains the maximum residual energy. We use the most common and widely-used definition as given below. Definition: Among all possible routes between a given pair, an optimal route is the one with the minimum number of hops. Another relevant term in this context is the suboptimal route. We define it as: Definition: An 𝑛-suboptimal route between a source-destination pair is a route of length 𝑡 + 𝑛 hops, where 𝑡 is the optimal route length and 𝑛 = 1, 2, . . . , 𝑛 For instance, 1-suboptimal route is a route of length 𝑡 + 1 hops i.e. 1 hop longer than the optimal path. Similarly, 2-suboptimal route is a route of length 𝑡 + 2 hops and so on.

109

4.4 Definitions

Table 4.1: Description of Modeling Variables Symbols/category

Description

Topology 𝑝𝑠 𝑝𝑟 /𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔 /𝑟0 𝑁/𝜌

Broadcast forwarding probability Rebroadcasting / no collision probability Channel error probability Average degree / Tr. radius of a node Total nodes / node density

Routing overhead ℎ 𝐷 𝑇𝑠 𝐶𝑊𝑚𝑖𝑛 𝑆𝐿𝑂𝑇 𝑡𝑐𝑜𝑛𝑡 𝛼 𝑑𝑓 [𝑗] 𝐶𝑝 (𝑥) 𝐶𝑝 (𝑙𝑜𝑠𝑡) 𝐶𝑝

Number of hops from the source node Diameter of the network (in hops) Total simulation time Minimum contention window size Duration of a wait slot in 802.11b Contention time at a node Rate of advertising routing table updates Exp. forward degree of a node at 𝑗 hops Generic routing overhead (packets) Routing overhead of protocol x RREQs lost in collisions/channel errors

Route optimality 𝑡 𝑘 𝑤[𝑖] 𝜖 𝑋[𝑡] 𝑃 𝐸{𝑋} 𝜇

Length of an optimal path Total number of edge-disjoint paths Normalized weight of paths of length 𝑖 Optimal path discovery probability No. of 𝑡 hops paths discovered successfully Probability of path discovery Expected probability (Generic) Number of tries to discover a link

Derivatives 𝐸𝑡𝑜𝑡𝑎𝑙 𝐸𝑡 /𝐸𝑟 𝐵𝑟𝑟𝑒𝑞 /𝐵𝑟𝑟𝑒𝑝 /𝐵𝑑 𝑀 𝐿𝑎 𝑡𝑑 𝑚

Total energy consumed Tx / Rx energy per bit Size of RREQ / RREP / data packets (bits) Total number of data packets Average path length Route discovery latency Number of paths discovered by a protocol

110

4.4 Definitions

4.4.3

Broadcast forwarding probability

Intermediate nodes in a flooding based protocol forward (i.e. broadcast) the route request messages conditionally or unconditionally. However, forwarded RREQs may get lost due to collisions, channel errors or changes in the topology of an ad hoc network. We exclude the lost RREQs in calculation of the number of transmissions at the next hop because they do not propagate further in the network. We do count these transmissions at the previous hop. Therefore, we introduce a generic parameter, known as broadcast forwarding probability, into the proposed framework to factor out the lost packets. We define it as: Definition: Broadcast forwarding probability is the probability that a node will forward a RREQ message to its neighbors and the message will be successfully delivered to them. We may express broadcast forwarding probability 𝑝𝑠 mathematically as 𝑝𝑠 = 𝑝𝑟 ⋅ 𝑝𝑐 ⋅ 𝑝𝑒 ,

(4.4)

where 𝑝𝑐 is the probability of not experiencing a collision at the MAC layer and 𝑝𝑒 is the probability that the RREQ is not lost due to channel errors (we derive expressions for 𝑝𝑐 and 𝑝𝑒 in Sections 4.5.1.2 and 4.5.1.3, respectively.). Finally, 𝑝𝑟 is the probability with which a node will forward a RREQ to its neighbors; for instance, 𝑝𝑟 = 1 for AODV [17], while 𝑝𝑟 = 𝑝𝑔 for the GOSSIP1 (𝑝𝑔 ) protocol [82]. We provide further discussion on 𝑝𝑟 once we discuss the specific routing overhead models later in the chapter. 4.4.3.1

Expected Forward Degree

This definition is the key to develop an understanding of routing overhead model. To visualize the concept of forward degree, consider node 𝑇 in Fig. 4.2 that has just received an RREQ broadcast by the source node 𝑆. Now assume that node 𝑇 has decided to forward this RREQ. The transmission of node 𝑇 will be received by all its neighbors (located in ring 𝐼 as well as within the transmission circle of source 𝑆). The question then is: how many neighbors of node 𝑇 are likely to forward this RREQ? In general, if a neighbor has already received a copy of the RREQ packet (i.e., it has seen the RREQ’s sequence number), it will simply drop the future RREQs. However, if a neighbor has seen this RREQ for the first time, it may decide to forward it with a certain probability 𝑝𝑟 depending on the protocol under consideration. Now, with reference to Fig. 4.2, the neighbors of 𝑇 lying in ring 𝐼 are expected to forward the RREQ because they will be hearing the RREQ for the first time. The total number of these neighbors

111

4.5 The Routing Overhead Model

f[1]=3 R

T

S r0

ring I r0-Ȝ

r0-Ȝ ring II

Figure 4.2: Propagation of route discovery messages in an ad hoc network (i.e the ones expected to forward the RREQ) is the forward degree of node 𝑇 . Having said this, we define expected forward degree of a node as Definition: Expected forward degree of a node is the average (or mean) number of neighbors of a node that, after receiving the RREQ, forward it to the next hop with probability 𝑝𝑟 . We represent the expected forward degree of nodes at 𝑗 hops from the source node as 𝑑𝑓 [𝑗] (see Table 4.1 for the description of modeling variables).

4.5

The Routing Overhead Model

As topology of ad hoc networks is dynamic, keeping up-to-date routing tables is extremely expensive in terms of network resources. Therefore, majority of ad hoc routing algorithms discover routes only when required e.g. BeeSensor, BeeAdHoc [13], AODV[17], AntHocNet [23] etc. This reactive routing strategy consumes less resources as compared to proactive approach. The prime focus of our performance evaluation framework is to model the performance metrics for on-demand ad hoc routing algorithms. However, being generic enough, they can also be ported to model the same metrics for proactive routing protocols. Reactive ad hoc routing algorithms use flooding for dissemination of route discovery messages in the whole or a part of the network. To calculate the routing overhead of such a flooding based protocol, we need to keep count of the number of transmissions at each hop of the network. It is one of the trickiest problems to resolve due to the following reasons.

112


✓ First, a node may or may not take part in the flooding of route request messages. In other words, nodes may forward a RREQ in a stochastic manner [82]. ✓ Even in blind flooding, each node in the network forwards a RREQ once and discards the future copies of RREQs. Therefore, we need to factor out the nodes which do not take part in the forwarding process at every step. ✓ The broadcast RREQs may get lost due to collisions or channel impairments. As lost packets do not propagate further into the network, their effect must be neglected in the next hop calculations. ✓ Protocols may flood RREQs in a part of the network e.g. ring search algorithms [13, 90]. Therefore, we need to count RREQs up to a certain number of hops from the source (note that this is one of the motivations behind the proposed definition of routing overhead). To start with, assume that source node 𝑆 initiates a route discovery by broadcasting a RREQ to all its neighbors as shown in Fig. 4.2. Since we are modeling a generic case, we assume that every receiving neighbor of 𝑆 will forward the RREQ with a probability 𝑝𝑟 . The neighbors of 𝑆 are the first hop nodes. When the first hop nodes repeat this broadcast, it will be received by the nodes located at two hops from the source which further forward the received RREQs with probability 𝑝𝑟 and the process continues. Intermediate nodes keep repeating this process until it reaches the final destination. Our main objective is to track the number of transmitting nodes at each hop up to an arbitrary number of ℎ hops from the source and accumulate all these terms to derive a generic expression for computing the total routing overhead.

4.5.1

The generic routing overhead model in terms of expected forward degree

The first RREQ broadcast by source node 𝑆 is received by 𝑑𝑎𝑣𝑔 nodes, the average degree of a node in the network. The broadcast RREQ may or may not be received by the neighbors of 𝑆 due to collisions or channel errors. Now, the neighbors of 𝑆 that receive it correctly equals 𝑝𝑐 × 𝑝𝑒 × 𝑑𝑎𝑣𝑔 . Since each one of them forward this RREQ with probability 𝑝𝑟 , the total number of 1-hop neighbors that repeat the broadcast of RREQ equal 𝑝𝑟 × 𝑝𝑐 × 𝑝𝑒 × 𝑑𝑎𝑣𝑔 or simply 𝑝𝑠 × 𝑑𝑎𝑣𝑔 . Now to calculate the number of 2-hop forwarding nodes, we use the concept of expected forward degree. Recall that expected forward degree 𝑑𝑓 [𝑗] represents the newer nodes that can

113


be reached by a 𝑗-hop node. Therefore, multiplying the number of 𝑗-hop forwarding nodes with the expected forward degree 𝑑𝑓 [𝑗] will give us the maximum number of 𝑗 + 1-hop forwarding nodes. Therefore, after incorporating the lost RREQs, the number of 2-hop forwarding nodes equals (𝑝𝑠 .𝑑𝑎𝑣𝑔 ) × 𝑝𝑠 .𝑑𝑓 [1]. In a similar way, we can calculate the number of 3-hop forwarding nodes. Now, the total routing overhead is the sum of all the transmissions at each hop up to an arbitrary number of ℎ hops as given by the following expression.

𝐶𝑝

=

1 + 𝑝𝑠 ⋅ 𝑑𝑎𝑣𝑔 + 𝑝𝑠 (𝑝𝑠 ⋅ 𝑑𝑎𝑣𝑔 ) × 𝑑𝑓 [1] + ) ( 𝑝𝑠 𝑝2𝑠 ⋅ 𝑑𝑎𝑣𝑔 .𝑑𝑓 [1] × 𝑑𝑓 [2] + ( ) 𝑝𝑠 𝑝3𝑠 ⋅ 𝑑𝑎𝑣𝑔 .𝑑𝑓 [1].𝑑𝑓 [2] × 𝑑𝑓 [3] + . . . + ( ) 𝑝𝑠 𝑝ℎ−1 ⋅ 𝑑𝑎𝑣𝑔 .𝑑𝑓 [1] . . . 𝑑𝑓 [ℎ − 2] × 𝑑𝑓 [ℎ − 1] 𝑠 −1, (4.5)

where 𝑑𝑓 [1], 𝑑𝑓 [2], 𝑑𝑓 [3]..., 𝑑𝑓 [ℎ−1] represent the expected forward degree of nodes at 1, 2, 3, ..., ℎ− 1 hops from the source node respectively. The first term in (4.5) indicates the transmission of the source node and the last term shows that the destination will not take part in the RREQ broadcast. The concise form of (4.5) is given below.

𝐶𝑝 =

⎧ 𝑝𝑠 𝑑𝑎𝑣𝑔    ⎨  𝑝𝑠 𝑑𝑎𝑣𝑔 + 𝑑𝑎𝑣𝑔   ⎩

if ℎ = 1 ∑ℎ−1 𝑖=1

(𝑝𝑠 )𝑖+1

∏𝑖

𝑑𝑓 [𝑗]. otherwise

(4.6)

𝑗=1

Equation (4.6) shows that 𝐶𝑝 is directly related to the number of hops traversed by a RREQ, probability 𝑝𝑟 and the expected forward degree of nodes. It can be intuitively validated as well. For instance, pure flooding algorithms have higher routing overhead because 𝑝𝑟 = 1. Similarly, the routing overhead increases with an increase in path length between a given pair. Equation (4.6) provides an interesting insight that the RREQ storm exponentially decreases with an increase in the path length. We shall talk about these insights in more detail in the context of BeeSensor protocol in Section 4.8. Now the routing overhead model (4.6) contains three unknown parameters; expected forward degree 𝑑𝑓 [𝑗], probability of no collision 𝑝𝑐 and the probability of zero channel error 𝑝𝑒 . The following three subsections model these three parameters.

114


4.5.1.1

Expected forward degree

Expected forward degree is the key parameter used in the derivation of routing overhead model. Before we proceed with the modeling of expected forward degree, we briefly summarize the major issues and the mechanism used to resolve them in the proposed model of expected forward degree. 1. First problem is the exclusion of nodes that have already received a copy of RREQ and are not expected to participate in the forwarding process. For instance, suppose that node 𝑆 in Fig. 4.3 has started a route discovery process. Assuming that every neighbor of 𝑆 will forward the RREQ, broadcast of node 𝐴 will be heard by nodes 𝐿, 𝑀, 𝑁, 𝑅, 𝑆 and 𝑇 . However, nodes 𝑅, 𝑆 and 𝑇 have already seen such a RREQ and therefore shall drop the duplicate. Only the neighbors of 𝐴 located in ring 𝐼 are expected to forward the RREQ which is hereby referred to as the forward degree of 𝐴. To address this problem, we divide the whole network regions into symmetrical rings (see Fig. 4.3). While calculating the expected forward degree of nodes lying in a ring, we only consider the nodes in the outer uncovered ring resulting in the exclusion of the nodes counted earlier. 2. Second issue is to handle the forward degrees of individual nodes which may differ significantly from each other. For instance, nodes 𝐴, 𝑈 and 𝑉 shown in Fig. 4.3 have a forward degree of 3, 2, and 5 respectively. In addition, the individual forward degrees might contain overlapping nodes. For instance, node 𝐽 in Fig. 4.3 receives two copies of the RREQ. To mitigate these two problems, we take an average of forward degrees of all the nodes in a ring. Speaking more specifically, we express the expected forward degree of nodes with respect to their distance in hops from the source node i.e. nodes located at 𝑗 hops from the source will have the same expected forward degree 𝑑𝑓 [𝑗]. Now we are in a position to describe the model of expected forward degree. In this context, we developed two models of expected forward degree. The first model was developed by computing the area covered by the broadcast of a node and its relation to neighboring broadcasts – the so-called geometrical model published in [109] (see Appendix A). This model is suitable for small networks only and produces incorrect results on large-scale networks. Therefore, we developed a more comprehensive and accurate model of the expected forward degree which we describe in the following subsection. Expected forward degree model

115


G H

F L

I

V

M

R N f[1]=3

ring I

J S

A

U

K

T

Figure 4.3: Illustration of forward degree Forward degree of a node depends upon its relative position from the broadcasting node. Generally speaking, the neighbors located at a longer distance from the broadcasting node have higher forward degree. For instance, node 𝐴 (Fig. 4.3) – being at the periphery of the circle – can reach more newer nodes than node 𝑅 and therefore has a higher forward degree. As discussed earlier, due to significant variance in the values of forward degrees, we derive expressions for an expected or mean forward degree of a node with respect to its hop distance from the source. Consider the network shown in Fig. 4.4 containing a source node 𝑆 in the center of the innermost ring. Assume that this node broadcasts a RREQ to start the route discovery process. Ideally, in the case of zero channel error and contention, RREQ of node 𝑆 is received by all the 𝜌𝜋𝑟02 − 1 neighbors located within its transmission range. This is illustrated in Fig. 4.5 in which the broadcast reception area is colored green while the transmitting source is shown red. Now, in the second series of broadcast, the neighbors of 𝑆 repeat the broadcast. We have illustrated this behavior in Fig. 4.6 by showing the transmission area in red color. Broadcast of the neighbors of node 𝑆 may be received by nodes within 𝑟0 − 𝜆 radius of these neighbors where 0 ≤ 𝜆 ≤ 𝑟0 . Note that 𝜆 is a function of node density and 𝜆 → 0 for dense ad hoc networks. Therefore, for the presently-considered dense ad hoc network, the total number of new nodes that will hear the broadcast of the neighbors of 𝑆 is approximately 3𝜌𝜋𝑟02 ; i.e., nodes within the green ring 𝐼 shown in Fig. 4.6. Remember, that this broadcast will also be heard in the red ring. However, we ignore them because they have already received a copy of RREQ from

116


Ring IV

Ring III r0-Ȝ

Ring II r0-Ȝ r0-Ȝ

Ring I r0-Ȝ r0 s

Figure 4.4: An ad hoc network with source node 𝑆 at the center. Each ring has a radius of 𝑟0 − 𝜆 except the innermost ring with a radius 𝑟0 .

Ring IV

Ring III r0-Ȝ

Ring II r0-Ȝ r0-Ȝ

Ring I r0-Ȝ r0 s

Figure 4.5: Start of route discovery: Red color shows that source node 𝑆 transmits a RREQ which is received by nodes in the green ring of radius 𝑟0 .

117


Ring IV

Ring III r0-Ȝ

Ring II r0-Ȝ r0-Ȝ

Ring I r0-Ȝ r0 s

Figure 4.6: Neighbors of 𝑆 – nodes in red ring – broadcast which is received by nodes in the green ring i.e. Ring 𝐼. Arrows at the periphery of the ring shows that the nodes within the ring are currently transmitting.

Ring IV

Ring III Ring II

r0-Ȝ r0-Ȝ

Ring I

r0-Ȝ r0-Ȝ

r0 s

Figure 4.7: Nodes in red ring – i.e. Ring 𝐼 – broadcast which is heard in Ring 𝐼𝐼 – shaded green. The inactive area is shown in gray color.

118


Ring IV

Ring III r0-Ȝ

Ring II r0-Ȝ r0-Ȝ

Ring I r0-Ȝ r0 s

Figure 4.8: Nodes in ring 𝐼𝐼 broadcast which is heard in ring 𝐼𝐼𝐼. Inner rings are inactive and hence are grayed source 𝑆. Now, the expected forward degree of 1-hop neighbors is given by 𝑑𝑓 [1] ≃

3𝜌𝜋𝑟02 . 𝜌𝜋𝑟02 − 1

(4.7)

In the next iteration, nodes located in ring 𝐼 will broadcast RREQ – shaded red in Fig. 4.7 which will be heard in ring 𝐼𝐼 – colored green in Fig. 4.7. Therefore, expected forward degree of 2-hop neighbors is computed by dividing the number of nodes in ring 𝐼𝐼 to the number of nodes in ring 𝐼 i.e. 𝑑𝑓 [2] = 5/3. Now, when the nodes in ring 𝐼𝐼 broadcast, it is heard in ring 𝐼𝐼𝐼 (see Fig. 4.8). Dividing the number of nodes in ring 𝐼𝐼𝐼 with the nodes in ring 𝐼𝐼 will give the expected forward degree of 3-hop nodes. Broadcast storm continues to ripple across the network in the same manner (Fig. 4.9). In general, expected forward degree of a node located at 𝑗 hops from the source is 𝑑𝑓 [𝑗] ≃

2𝑗 + 1 2𝑗 − 1

where 1 < 𝑗 < ℎ − 1

(4.8)

We have excluded the nodes located in the second last ring i.e. nodes at ℎ − 1 hops from eq. (4.8). The reason is our inherent assumption in the derivation of (4.8) according to which the outer ring contains the maximum possible nodes. Look at this number 3𝜌𝜋𝑟02 which represents the number of nodes in ring 𝐼. We simply multiplied the area of ring 𝐼 i.e. 3𝜋𝑟02 with the node

119


Ring IV

Ring III Ring II

r0-Ȝ r0-Ȝ r0-Ȝ

Ring I r0-Ȝ r0 s

Figure 4.9: Nodes in ring 𝐼𝐼𝐼 broadcast which is heard in ring 𝐼𝑉 . density 𝜌 which is possible only if the ring is full. Now just imagine the case in which ring 𝐼 has far less number of nodes than this i.e. (Nodes in ring 𝐼 ≪ 3𝜋𝑟02 ). Of course (4.8) will not hold here. We explain it with the help of an example. Consider an ad hoc network of 50 nodes. Now these nodes will be distributed in different rings around the source. 𝑑𝑎𝑣𝑔 nodes will be lying in the neighborhood of 𝑆, then about 3 × 𝑑𝑎𝑣𝑔 in ring 𝐼, 5 × 𝑑𝑎𝑣𝑔 in ring 𝐼𝐼 and so on. For instance, if 𝑑𝑎𝑣𝑔 = 8 nodes lie in the transmission circle of 𝑆, 21 will lie in ring 𝐼 and the remaining 21 nodes in ring 𝐼𝐼 which will be the last ring in this case. Ideally, if ring 𝐼𝐼 is full, it must contain approximately 5 × 𝑑𝑎𝑣𝑔 where 𝑑𝑎𝑣𝑔 in the given example is 8 i.e. 40 nodes. However, in the given network, ring 𝐼𝐼 contains significantly smaller number of nodes than expected. For the reasons mentioned above, we need to calculate the number of nodes in the last ring as well as the nodes at ℎ − 2 hops i.e. second last ring. Now, we know that nodes at ℎ − 2 hops are 2(ℎ − 2) + 1 = (2ℎ − 3) × 𝜌𝜋𝑟02 . For calculating the number of nodes in the last ring, we subtract the total number of nodes distributed in the inner rings from the network size which equals 𝑁 − (ℎ − 1)2 ⋅ 𝜌𝜋𝑟02 with ℎ > 1. Therefore the forward degree of nodes at ℎ − 1 hops is 𝑑𝑓 [ℎ − 1] ≃

𝑁 − (ℎ − 1)2 ⋅ 𝜌𝜋𝑟02 . (2ℎ − 3) ⋅ 𝜌𝜋𝑟02

120

(4.9)


Combining all the three cases i.e. (4.7), (4.8) and (4.9), we get the following expression:

𝑑𝑓 [𝑗] ≃

⎧ 3𝜌𝜋𝑟02    𝜌𝜋𝑟02 −1     ⎨

if 𝑗 = 1

𝑁 −(ℎ−1)2 ⋅𝜌𝜋𝑟02

if 𝑗 = ℎ − 1 where ℎ > 1

(2ℎ−3)⋅𝜌𝜋𝑟02        ⎩ 2𝑗+1 ,

(4.10)

otherwise

2𝑗−1

Remember that ℎ in (4.10) represents the number of hops from the source node up to which we want to calculate the routing overhead. For protocols that flood the RREQs in the entire network e.g. DSR, ℎ =

𝐷 2

where 𝐷 is the diameter of the region measured in terms of hops.

Equation (4.10) is more suitable for pure flooding protocol because we assume that broadcast of nodes within an inner region (e.g. ring 𝐼 in Fig. 4.2) is heard in the entire outer region (ring 𝐼𝐼). In stochastic broadcasting protocols, however, we need to factor out those nodes that do not forward RREQ. Now, with reduction in the number of forwarding nodes, potential receivers reduce proportionally in the outer ring. Therefore, we expect that the expected forward degree will still be the same because it is the ratio of nodes in the two rings. The expected forward degree of nodes decreases with an increase in the number of hops (i.e. 𝑑𝑓 [1] > 𝑑𝑓 [2] > . . .). We have shown this trend by plotting (4.10) for a network of 1000 nodes. This is because of an increase in the number of potential forwarding nodes as the RREQ storm sweeps across a continuously decreasing uncovered area. Steady state phase shown in Fig. 4.10 shows that each node in this case is only able to deliver a packet to 1 new node on average i.e. a broadcast is effectively a unicast transmission. If we think of a connected network in which every node is connected to approximately 𝑑𝑎𝑣𝑔 nodes, broadcast coverage per node reduces to

1 𝑑𝑎𝑣𝑔

which is a significantly smaller value. This clearly leads to an important

conclusion: unconditional broadcast in the surroundings of a source node is more effective while its performance deteriorates as we move away from the source. Therefore, it is more appropriate to perform conditional broadcast in the distant region. This supports the broadcast pattern used in BeeSensor protocol. We also emphasize that RREQ storm in real networks would not follow perfect ring styles as depicted in Fig. 4.4 – 4.9. Consequently, the routing overhead estimated by our model may be slightly higher than actual. A similar argument holds for sparse networks (or the cases where 𝑝𝑟 is significantly smaller) where 𝜆 > 0.

121


Expected forward degree

4

Network size = 1000, area = 450000 meter sq.

3.5 3 2.5 2 1.5 1 0.5 0 1

2

3

4

5

6

7

8

9

10

Number of hops

Figure 4.10: Expected forward degree at different hops from the source node 4.5.1.2

Collision and contention modeling

Collision refer to a scenario in which multiple nodes lying in the same collision domain start transmitting simultaneously resulting in the loss of data packets. A collision domain refers to a part of the network – wired or wireless – where data packets can interfere / collide with one other. Collisions occur in the networks that use a shared channel – wireless or wired – for transmission. Therefore it is compulsory that the nodes lying in a common collision domain must transmit on individual basis. This is normally achieved by following the rules of a medium access control (MAC) layer protocol. Nodes in ad hoc networks use wireless communication for transmitting their packets which is inherently a broadcast channel. Therefore, transmission of a node is heard by all the nodes lying within the transmission range of that node. The wireless channel is therefore more vulnerable to collision problem. In addition to this, ad hoc nodes not lying within transmission range of each other can also cause collisions at a common destination – commonly referred to as the hidden node problem. The collision problem gets even more severe partly because of the distributed nature of wireless MAC layer protocols. Therefore, it is compulsory to cater for the collided RREQs in the proposed evaluation framework. In this context, we model the probability that a broadcast packet will not collide with any other transmission. We also model the contention time – the time required to acquire the channel before starting the actual data transmission which is subsequently used for modeling of the route discovery latency.

122


Collision modeling We assume standardized 802.11b [106] distributed coordination function (DCF) as a MAC layer protocol. Our collision model is based on the following assumptions [105]. ✓ The network is busy. More specifically, every node will find the channel busy in the first attempt resulting in back-off. ✓ Multiple transmissions that are subject to collisions are negligible. In other words, either a node is able to transmit in the contention window 𝐶𝑊 = {0, . . . , 𝐶𝑊𝑚𝑖𝑛 } or 𝐶𝑊 = {0, . . . , 2 × 𝐶𝑊𝑚𝑖𝑛 }. Probability of collision is the probability that two or more hosts pick the same slot from the contention window. Let us assume that there are 𝑑𝑎𝑣𝑔 nodes contending for the channel access labeled as 𝑁1 , 𝑁2 , 𝑁3 , . . . , 𝑁𝑑𝑎𝑣𝑔 . If a node, say 𝑁1 , picks up slot 𝑖, there will be no collision if none of the other nodes pick slot 𝑖. Now, the probability of no collision may be written as

𝑝𝑐 =

𝑃 𝑟{𝑁2 𝑑𝑜𝑒𝑠 𝑛𝑜𝑡 𝑝𝑖𝑐𝑘 𝑠𝑙𝑜𝑡 𝑖∣𝑁1 𝑝𝑖𝑐𝑘𝑒𝑑 𝑠𝑙𝑜𝑡 𝑖} × 𝑃 𝑟{𝑁3 𝑑𝑜𝑒𝑠 𝑛𝑜𝑡 𝑝𝑖𝑐𝑘 𝑠𝑙𝑜𝑡 𝑖∣𝑁1 𝑝𝑖𝑐𝑘𝑒𝑑 𝑠𝑙𝑜𝑡 𝑖} × .. . 𝑃 𝑟{𝑁𝑑𝑎𝑣𝑔 𝑑𝑜𝑒𝑠 𝑛𝑜𝑡 𝑝𝑖𝑐𝑘 𝑠𝑙𝑜𝑡 𝑖∣𝑁1 𝑝𝑖𝑐𝑘𝑒𝑑 𝑠𝑙𝑜𝑡 𝑖} × (4.11)

As slots are equiprobable, probability of picking up a slot is 1/𝐶𝑊𝑚𝑖𝑛 and the probability of not picking up any given slot is 1 −

1 𝐶𝑊𝑚𝑖𝑛 .

𝑝𝑐 =

( 1−

As there are 𝑑𝑎𝑣𝑔 − 1 terms in (4.11), it reduces to 1 𝐶𝑊𝑚𝑖𝑛

)𝑑𝑎𝑣𝑔 −1

,

(4.12)

where 𝐶𝑊𝑚𝑖𝑛 (= 31 as defined in 802.11b standard) is the minimum contention window. Equation (4.12) shows that the probability of no collision is dependent upon the number of competing nodes i.e. 𝑑𝑎𝑣𝑔 . If the network is dense, it will result in higher average degree and higher number of collisions. It can also be verified intuitively. Contention modeling

123


Contention time is important because it contributes to the overall time consumed in a route discovery. We proceed with the same assumption as used in the derivation of 𝑝𝑐 . Since broadcast traffic is never retransmitted, 𝑡𝑐𝑜𝑛𝑡 may be written as 𝑡𝑐𝑜𝑛𝑡 ≃

𝑆𝐿𝑂𝑇 × [(1 − 𝑝𝑐 ) × 𝐸{𝑑𝑖𝑠𝑐𝑟𝑒𝑡𝑒 𝑢𝑛𝑖𝑓. 𝑟𝑎𝑛𝑑𝑜𝑚 𝑣𝑎𝑟. 𝑜𝑛[0, 𝐶𝑊𝑚𝑖𝑛 ]}

(4.13)

Since, 𝐸{𝑑𝑖𝑠𝑐𝑟𝑒𝑡𝑒 𝑢𝑛𝑖𝑓. 𝑟𝑎𝑛𝑑𝑜𝑚 𝑣𝑎𝑟. 𝑜𝑛[0, 𝐶𝑊𝑚𝑖𝑛 ]} = 𝐶𝑊𝑚𝑖𝑛 /2, Eq. (4.13) results in 𝑡𝑐𝑜𝑛𝑡 =

𝑆𝐿𝑂𝑇 × 𝑝𝑐 × 𝐶𝑊𝑚𝑖𝑛 , 2

(4.14)

where 𝑆𝐿𝑂𝑇 (= 20𝜇𝑠 for 802.11b standard) is the duration of each wait slot. For a given network, all variables in (4.14) are constants (𝑑𝑎𝑣𝑔 , 𝐶𝑊𝑚𝑖𝑛 , 𝑆𝐿𝑂𝑇 ) and hence a node experiences a constant delay in order to get access to the channel for transmission of a RREQ. 4.5.1.3

Channel error modeling

We now briefly describe two prominent approaches that translate a channel model into the packet error probability 𝑝𝑒 . These two approaches respectively involve physical and MAC layer channel models. SNR-based physical layer channel error modeling A commonly-used physical layer channel model for wireless ad hoc networks is the log-normal shadow fading model. This model characterizes the physical channel in a fading environment using two additive components: (1) a deterministic distance-dependent attenuation component with a path-loss exponent 𝛼, and (2) a SNR-based fading component defined as a normal random variable with a zero mean and variance 𝜎 2 . The probability of a packet loss between two nodes communicating over this channel is given in [110]: ( ) 𝛽𝑡ℎ − 𝛼 × 10 log(𝑧) 1 1 √ 𝑝𝑒 = + erf , 2 2 2𝜎

(4.15)

where erf(.) is the standard error function, 𝑧 is the distance between the two nodes and 𝛽𝑡ℎ is the lowest threshold attenuation which is required to deliver a packet between the nodes. Probability of no channel error is then 𝑝𝑒 = 1 − 𝑝𝑒 . MAC layer channel error modeling

124


An alternative approach of modeling a wireless channel is to include physical layer errors as a part of the underlying channel model and then model the residual channel (i.e., the channel observed after physical layer processing) at the MAC layer. It has been shown that the bit-errors over a residual wireless channel exhibit bursty behavior where each successful and unsuccessful packet transmission is dependent upon whether or not the previous 𝐾 packet transmissions were successful [111, 112]. Such a channel is adequately modeled using a 𝐾-th order Markov channel model in which the states of the model correspond to all possible combinations of correctly – and erroneously-received 𝐾 previous packets. Then the total probability of packet error over a 𝐾-th order residual channel is: 𝑝𝑒 =

2𝐾−1 ∑−1

𝜋2𝑖+1 ,

(4.16)

𝑖=0

where 𝜋𝑖 is the steady-state probability of Markov state 𝑖. Interested readers are referred to [111] and [112] for further details of Markov models of residual MAC layer channels. 4.5.1.4

Discussion

This completes our routing overhead model. The final expression for routing overhead model is given below.

𝐶𝑝 =

⎧ 𝑝𝑟 𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔    ⎨  𝑝𝑟 𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔 + 𝑑𝑎𝑣𝑔   ⎩

if ℎ = 1 ∑ℎ−1 𝑖=1

∏𝑖 (𝑝𝑟 𝑝𝑐 𝑝𝑒 )𝑖+1 𝑗=1 𝑑𝑓 [𝑗]. otherwise

(4.17)

In the following subsections, we discuss different optimizations to blind flooding of RREQs and the way they can be modeled using (4.17).

4.5.2

Optimized flooding of RREQs

Blind flooding of RREQs in the entire network may lead to broadcast storm problem [113]. Therefore, on-demand ad hoc routing protocols use a number of optimizations to this basic flooding scheme. The proposed routing overhead model incorporates these optimizations. In the following subsections, we mention the most common optimizations that can easily be modeled using (4.17). 4.5.2.1

Ring search

This is one of the well-known method in which source nodes set a 𝑇 𝑇 𝐿 value in the broadcast RREQ indicating the number of hops it can travel. If 𝑇 𝑇 𝐿 > 0, the receiving node (s) repeat

125


the broadcast after decrementing the 𝑇 𝑇 𝐿 value. Equation (4.17) provides a straight forward implementation of this process in which ℎ represents the size of a ring. Setting the ring size to ℎ=

𝐷 2

in (4.17) gives the routing overhead of a protocol that floods the RREQs in the entire

network (see eq. (4.19) ) . 4.5.2.2

Stochastic flooding / gossiping

In this optimization, nodes forward RREQs with a certain probability 𝑝𝑟 which may or may not vary with the hop distance. A number of variants of this basic technique are reported in [82]. In its most basic form, each node – irrespective of its distance from the source node – broadcasts RREQ with probability 𝑝𝑔 . Transformation of (4.17) to model such a stochastic flooding of RREQs is straight forward. For example, for GOSSIP1(𝑝𝑔 ) protocol proposed in [82], in which intermediate nodes broadcast RREQ with probability 𝑝𝑔 , (4.17) may be written as (𝑔𝑜𝑠𝑠𝑖𝑝)

𝐶𝑝

⎧  𝑝𝑔 𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔 if ℎ = 1      ⎨ = 𝑝𝑔 𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔 +  ∑ ∏  𝑑𝑎𝑣𝑔 ℎ−1 (𝑝𝑔 𝑝𝑐 𝑝𝑒 )𝑖+1 𝑖 𝑑𝑓 [𝑗].  𝑖=1 𝑗=1   ⎩ otherwise

(4.18)

In other forms, 𝑝𝑔 /𝑝𝑟 varies for different nodes. For instance, nodes within a radius of ℎ1 hops from the source are allowed to broadcast unconditionally i.e. 𝑝𝑔 = 1 while the rest do it with 𝑝𝑔 < 1. This is a pretty complex case to model and BeeSensor flooding pattern is a typical example of it. We discuss the adaptation of generic model to BeeSensor in Section 4.8. 4.5.2.3

A hybrid approach

The optimizations techniques mentioned above may even be combined to further optimize the flooding process. For instance, ring search may be combined with stochastic flooding. It should now be evident that the proposed routing overhead model is able to handle such a hybrid case as transparently as the rest of the optimizations techniques. To further elaborate the transformation process, in the following two subsections, we adapt the generic routing overhead model to three prominent ad hoc routing algorithms AODV, DSR and DSDV. We then compare the analytical results of these models with the simulation results to elaborate the impact of our modeling assumptions on the proposed model.

126


4.5.3

Comparison of analytical and simulation results

We divide this section into two subsections. In the first section, we describe the adaptation of the generic routing overhead model to AODV, DSR and DSDV. Subsequently, we compare the results of these models with the results obtained in an independently conducted simulation study reported in [2]. 4.5.3.1

Protocol specific routing overheads

Dynamic Source Routing (DSR) DSR [24] is an on-demand multipath ad hoc routing protocol with two main components; route discovery and route maintenance. During route discovery, source node broadcasts a RREQ packet to all its neighbors. Intermediate nodes keep rebroadcasting RREQs unconditionally (i.e. with 𝑝𝑟 = 1) unless it reaches the destination which responds with a route reply (RREP). If an active route is available at an intermediate node, it also responds with a RREP. Route error (RERR) messages are used to inform the source node 𝑆 that the current route is broken. AODV [17] route discovery mechanism is similar to that of DSR and hence routing overhead model of DSR also applies to AODV. As intermediate nodes in DSR forward RREQs with 𝑝𝑟 = 1 in the entire network, (4.17) may be rewritten for DSR / AODV as

(𝑑𝑠𝑟)

𝐶𝑝

=

⎧  𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔    ⎨

if ℎ =

 𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔 + 𝑑𝑎𝑣𝑔    ⎩

∑ 𝐷2 −1 𝑖=1

(𝑝𝑐 𝑝𝑒 )𝑖

∏𝑖

𝐷 2

=1

𝑑𝑓 [𝑗]. otherwise

(4.19)

𝑗=1

𝑝𝑐 𝑝𝑒 is the limiting factor in (4.19) that reduces the effective routing overhead. Note that the collided RREQs waste limited network resources like battery, bandwidth, etc., without contributing towards the route discovery process. Destination-Sequenced Distance Vector (DSDV) DSDV [25] is a proactive routing protocol in which each node maintains a next hop lying on the shortest path for all the reachable destinations in its routing table. In addition, it also stores its estimate of distance for reaching the destination. A node periodically exchanges its distance vector routing tables with its neighbors. The loops are avoided by using sequence numbers in the exchanged messages.

127


All terms in (4.5), except the first one, refer to forwarding of RREQs which is not done in DSDV. Let the nodes exchange their distance vector table entries at a rate of 𝛼 per second, total number of routing messages exchanged during an entire run of experiment is 𝐶𝑝(𝑑𝑠𝑑𝑣) = 𝑁 ⋅ 𝑇𝑠 ⋅ 𝛼, (𝑑𝑠𝑑𝑣)

where 𝑇𝑠 is the total time of an experiment. 𝐶𝑝

(4.20)

has mostly constant parameters with

the exception of 𝛼 that can vary with changing topologies. As a result, the routing overhead of DSDV approximately remains constant with little variation under dynamic conditions [2]. 4.5.3.2

Comparison of routing overhead model with simulation results

We used a number of assumptions to simplify our routing overhead model, and therefore, we must compare the analytical and simulation results. For this purpose, we performed comparison in three different scenarios. We discuss them in the following paragraphs in more detail. 1. Our first comparison is intended to analyze the performance of the routing overhead models in a lossless network. For such a network of 𝑁 nodes with a pair, the total number of RREQs generated by a pure flooding protocol like DSR must be equal to 𝑁 − 1 because every node broadcasts except the destination node. We verified this behavior in the following way. We generated a topology of 200 nodes deployed in an area of 1000 m2 using a homogeneous Poisson distribution. For this purpose, we made use of Eq. (4.3) to compute the transmission radius 𝑟0 that ensures a connected network. The computed value of 𝑟0 equals 4 m with an average node degree of 9. We then computed the number of RREQs generated by DSR using (4.19) by assuming 𝑝𝑐 𝑝𝑒 = 1. To collect the simulation results, we performed an experiment using the same topology parameters for DSR protocol in NS-2 with a single pair assuming zero packet loss. The reported values are listed in Table 4.2 under no collision case. In a network of 200 nodes deployed in an area of 1000 m2 our model estimated 199 RREQs that is in complete agreement with the NS-2 results. 2. The next comparison is done under realistic network conditions. In this set of experiments, we used an impartial and a rather unusual methodology for comparison. In this context, we compare the results of our model with the results obtained in an independent simulation study conducted by Broch et al. (1998) [2] about a decade ago. As a first

128


Table 4.2: Routing overhead: Simulation results reported by Broch et al. [2] Vs. the analytical results No collision case Protocol AODV/DSR

Analytical results 199

NS-2 results 199

Analytical results 1147 1147 45000

Simulation results [2] 1200 1260 42000

Analytical results 1147

NS-2 results 1135

Simulation comparison with results of [2] Protocol DSR AODV DSDV No retries case Protocol DSR

step, we generated the network topology parameters using the network size and the area reported in [2] i.e. 50 nodes placed randomly in an area of 1500 m × 300 m. We used eq. (4.3) to calculate the transmission radius of each node which equals 156.2 m. The authors of [2] reported results for 30 source nodes working in parallel. Since we are modeling a single route discovery attempt, we have multiplied the results of our model with 30 to compute the total number of RREQS generated by all the sources. The simulation results [2] for 900 s pause time (in 30 sources scenario) and the corresponding formal model results are listed in Table 4.2. One can see in Table 4.2 that the routing overhead estimated by our model is 4% less than that of DSR compared with NS-2 results. Keeping in view of the fact that we do not count the RERR messages, RREPs and the HELLO messages, 4% difference between the estimated routing overhead and the simulation results (AODV and DSR) is reasonably accurate. The prime reason for this is that – although we do not count RERR, RREP and HELLO messages – we are slightly over-estimating the number of RREQs generated in a route discovery which indirectly balances the exclusion of other control messages. We also repeated the same experiment for DSDV by assuming (𝛼 = 1, 𝑇𝑠 = 900) with results depicted in Table 4.2. Difference of 6.7% in the estimated result over 900 seconds is acceptable if we consider the dynamic nature of wireless medium in ad hoc networks. Finally, we point out that the 0-order approximations (average values) also lead to discrepancies between simulation and analytical results.

129

4.6 Route Optimality

3. Recall that we do not model the retries of a source node. For instance, if a source is unable to discover route in the first attempt, it will launch another series of RREQs. We were interested in comparing the results of our model directly with the no retries case. For this purpose, we repeated the NS-2 experiments using the parameters reported in [2] by disabling the retries in DSR code. The results of these experiments are shown in the last row of Table 4.2. Now the results of the proposed model are extremely close to the simulation results. This clearly proves that our routing overhead is accurate and realistic. It is also important to note that the model shows slightly higher routing overhead. This is expected as we described in Section 4.5.1.1. This concludes our discussion on the routing overhead model. We now move to the modeling of route optimality.

4.6

Route Optimality

The word optimal – according to the Cambridge dictionary – means best or most likely to bring success or advantage [114]. Computing dictionary defines it as a solution that minimizes a cost function [115]. Ad hoc routing protocol designers more or less follow the later definition. However, the cost function is a choice of the designer. A designer may like to minimize the overall packet latency and hence define the cost as a function of all related parameters e.g. queue size, propagation delay etc. On the other hand, an optimal path may be the one that consumes least amount of energy required to transport a packet between a pair of nodes. We defined the optimality of a route in terms of hop distance Section 4.4 i.e. an optimal route is the least hops path. This in fact is one of the most common and well-known definition of an optimal route. All other routes connecting the pair of nodes will be suboptimal i.e. routes with hops greater than the optimal length. In the following subsection, we develop generic models for: 1. The probability that an ad hoc routing protocol will discover an optimal route i.e. shortest route. 2. The probability that an ad hoc routing protocol will discover an 𝑛-suboptimal route i.e. a route which is 𝑛 hops longer than the optimal route. We develop models for single and multipath routing protocols separately.

130


3. The expected route establishment probability – we call it marginal probability of route discovery. In subsequent subsections, we use the generic equations to develop protocol specific route optimality models and compare their results with the simulation studies reported in [2].

4.6.1

The generic route optimality models

We now introduce our generic route optimality model for ad hoc routing protocols. Before we proceed, we would like to define the two terms, flooding and node-disjoint paths, that are used – in addition to the ones defined in Section 4.4 – in the rest of this section. Definition: Flooding is the process in which each node in an ad hoc network, except the destination, broadcasts a unique copy of a RREQ packet at most once to its neighbors. Definition: Node-disjoint paths refer to a set of paths between a pair that do not contain any overlapping node(s). Now we argue that a typical ad hoc routing algorithm e.g. DSR that uses flooding of RREQs for route discovery can only discover node-disjoint paths. We support our argument with an example. Consider the network shown in Fig. 4.11 in which source node 𝑆 floods a RREQ for destination 𝐷. Each intermediate node broadcasts a copy of RREQ until it reaches the destination. Now destination 𝐷 may potentially receive as many RREQs as the number of its neighbors. In case of source routing protocols, each RREQ builds a source routing header of the path followed by it. We have shown a copy of such RREQ received at 𝐷 in Fig. 4.11. Now the question is: is it possible that a node may be present in the source routing headers of more than one RREQs received at 𝐷? The answer is no because the presence of a node in multiple RREQs means that the node has rebroadcast multiple copies of identical RREQs which is not possible. Therefore, a node can lie on single route only supporting the argument that ad hoc routing protocols based on flooding discover node-disjoint paths. In the rest of our discussion, the term path(s) always refer to node-disjoint path(s) unless specified otherwise. We assume that there are 𝑘 node-disjoint paths between a given pair with an optimal path length of 𝑡 hops. Now the available paths may be optimal or suboptimal. This depends upon the network topology / deployment of ad hoc nodes. To keep our route optimal models generic, we do not assume any fixed distribution of available paths. Rather, a function 𝑓 [𝑖 − 𝑡] provides the total number of paths of length 𝑖 between a given pair. For instance, if there exist 6 optimal paths of length 𝑡 and 3 paths of length 𝑡 + 1 between a pair of nodes, then 𝑓 [0] = 6 and 𝑓 [1] = 3. 4.6.1.1

Probability of optimal path discovery

The optimal paths are 𝑡 hops long. Now recall the definition of broadcast forwarding probability 𝑝𝑠 which in fact is the probability of a link discovery. Since there are a total of 𝑡 links that need to be discovered, the probability of an optimal path discovery is 𝜖 = (𝑝𝑠 )𝑡 . Hence, the probability of failure in discovering an optimal path is (1 − 𝜖). With reference to the path distribution function 𝑓 [𝑖 − 𝑡], we have a total of 𝑓 [0] optimal paths. We are interested in finding the probability of discovering 𝑗 optimal paths out of a total of 𝑓 [0] optimal paths. Now discovery of an optimal paths is in fact a Bernoulli trial with 𝜖 as the probability of success and (1 − 𝜖) as the probability of failure. Therefore, the probability of finding 𝑗 optimal paths out of a total of 𝑓 [0] optimal paths is a binomial distribution given by ( ) 𝑓 [0] (4.21) 𝑏(𝑗; 𝑓 [0], 𝜖) = 𝑃 (𝑋[𝑡] = 𝑗) = 𝜖𝑗 (1 − 𝜖)𝑓 [0]−𝑗 , 𝑗 where 𝑋[𝑡] is a random variable representing the number of optimal paths discovered successfully. Putting 𝑗 = 0 in (4.21) gives the probability that no optimal paths will be discovered. Solving (4.21) for 𝑗 = 0, we get 𝑏(0; 𝑓 [0], 𝜖) = 𝑃 (𝑋[𝑡] = 0) = (1 − 𝜖)𝑓 [0] ,

132

(4.22)


Clearly, if the number of optimal paths 𝑓 [0] is higher, probability of failing to find an optimal path will be lower. Now, using (4.22), the probability of discovering at least a single optimal path equals 𝑃 (𝑋[𝑡] ≥ 1) = 1 − (1 − 𝜖)𝑓 [0]⋅𝜇 ,

(4.23)

where 𝜖 = (𝑝𝑠 )𝑡 is the probability of discovering an optimal path and 𝜇 is the number of tries to discover a link. The term (1 − 𝜖)𝑓 [0] in (4.23) is the probability that a routing algorithm fails to discover an optimal path in one attempt. Not to mention that one will always like to minimize the failure probability or maximize the success probability 𝑃 (𝑋[𝑡] ≥ 1). Equation (4.23) suggests two ways of achieving this objective. 1. The first method is to increase the number of available paths i.e. 𝑓 [0]. How can we do it then? The simple answer is to increase the node density. Higher the number of nodes per unit area, higher will be the number of available paths between a pair. 2. Second method is to increase the value of 𝑝𝑠 and hence the 𝜖. This can be done by increasing the components of 𝑝𝑠 i.e. 𝑝𝑐 , 𝑝𝑒 and 𝑝𝑟 (see eq. (4.4 ). Now the question is: can we maximize all the three probabilities? The answer, unfortunately, is no. We can maximize i.e. 𝑝𝑟 = 1 by allowing every node to broadcast at least once. We may also maximize 𝑝𝑐 by using some centralized MAC protocol e.g. Point Coordination Function (PCF) [106]. However, there is nothing like an ideal wireless channel and hence 𝑝𝑒 is always less than 1. As a matter of fact, most MAC layer protocols are distributed in nature and hence collisions are bound to happen resulting in 𝑝𝑐 < 1. Interesting point to note – in such cases – is that an increase in 𝑓 [0] may be accompanied by decrease in the value of 𝑝𝑠 . This is simple to infer. For instance, an increase in the node density will result in higher value of 𝑑𝑎𝑣𝑔 which in turn will increase the number of nodes contending for channel access. Consequently, collisions / interference will rise resulting in lower value of 𝑝𝑠 . Therefore, the above two methods for increasing 𝑃 (𝑋[𝑡] ≥ 1) should not be considered as isolated mechanisms. Finally, also note that the limiting case of 𝑝𝑠 = 1 results in a zero failure probability. 4.6.1.2

Probability of suboptimal path discovery

We now move on to our next objective – mentioned at the start of the section – and that is to model the probability of discovering a suboptimal path. We address this problem separately

133


for single and multipath ad hoc routing algorithms.

Single path ad hoc routing protocols Single path ad hoc routing algorithms prefer optimal path(s) connecting a pair of nodes. However, if they happen to discover a suboptimal path only, they start using it for the transportation of data packets. If an optimal path is discovered later on, the older suboptimal path is discarded. We use this rule and the model of optimal path discovery i.e. eq. (4.23) to find the probability of discovering a suboptimal route. Suboptimal routes are the routes of length 𝑡 + 𝑛 hops where 𝑛 = 1, 2, . . .. The question that we are trying to address is: What is the probability of discovering at least a single route of 𝑡 + 1 hops – hereby referred to as 1-suboptimal route? Discovering a 1-suboptimal path automatically implies that an optimal path has not been discovered because if the optimal path is available then the suboptimal routes would be discarded by the source or intermediate nodes. Mathematically, we may write it as ) ( 𝑓 [1]⋅𝜇 𝑓 [0]⋅𝜇 × (1 − 𝜖) . 𝑃 (𝑋[𝑡 + 1] ≥ 1) = 1 − (1 − 𝜖𝑝𝑠 ) Similarly, the probability of discovering at least a 2-suboptimal path assumes that none of the optimal or 1-suboptimal paths have been discovered. A similar argument holds for the discovery of at least a 3-suboptimal path. ( )𝑓 [2]⋅𝜇 ) ( × (1 − 𝜖𝑝𝑠 )𝑓 [1]⋅𝜇 × (1 − 𝜖)𝑓 [0]⋅𝜇 𝑃 (𝑋[𝑡 + 2] ≥ 1) = 1 − 1 − 𝜖(𝑝𝑠 )2 𝑃 (𝑋[𝑡 + 3] ≥ 1) =

)𝑓 [3]⋅𝜇 ) ( × 1 − 1 − 𝜖(𝑝𝑠 )3 ( ) 𝑓 [2]⋅𝜇 1 − 𝜖(𝑝𝑠 )2 × (1 − 𝜖𝑝𝑠 )𝑓 [1]⋅𝜇 × (1 − 𝜖)𝑓 [0]⋅𝜇 .

(

The above chain rule can easily be extended to find the probability of discovering at least a 𝑛-suboptimal route as given below. 𝑃 (𝑠𝑝) (𝑋[𝑡 + 𝑛] ≥ 1) =

) ( 1 − (1 − 𝜖(𝑝𝑠 )𝑛 )𝑓 [𝑛]⋅𝜇 × ) ∏𝑛−1 ( 𝑗 𝑓 [𝑗]⋅𝜇 , 𝑗=0 1 − 𝜖(𝑝𝑠 )

(4.24)

where 𝑓 [𝑛 − 1], 𝑓 [𝑛] provide the total number of available node-disjoint paths of length 𝑡 + 𝑛 − 1 and 𝑡 + 𝑛 hops respectively. In equation (4.24), as 𝑛 → ∞, the probability of finding a 𝑛suboptimal route approaches to zero. However, it has complex relation with 𝑓 [𝑛]. For instance, suboptimal paths are less probable as compared to optimal paths provided that the paths distributed evenly i.e. 𝑓 [0] = 𝑓 [1] = 𝑓 [2] = ... = 𝑓 [𝑛]. This is also true if 𝑓 [0] > 𝑓 [1] > 𝑓 [2].... > 𝑓 [𝑛] and so on.

134


Multiple path ad hoc routing protocols Multipath ad hoc routing protocols do not follow the chain rule described above. They maintain multiple paths between a given pair of nodes and therefore do not discard routes strictly as done by single path routing protocols. Now, multipath protocols may maintain all the available paths or a subset of the given path. In the following model, we assume that source nodes maintain all the available paths to a given destination. This is commonly the case in Bio-inspired routing protocols [23, 92] for stochastic distribution of data packets across multiple paths. Now, with this assumption, the probability of discovering a 𝑛-suboptimal path for multipath ad hoc routing protocols can directly be derived from (4.23) as given below. ) ( 𝑃 (𝑚𝑝) (𝑋[𝑡 + 𝑛] ≥ 1) = 1 − (1 − 𝜖(𝑝𝑠 )𝑛 )𝑓 [𝑛]⋅𝜇 .

(4.25)

A simple comparison of (4.24) and (4.25) shows that the probability of discovering 𝑛-suboptimal paths in multipath routing protocols is greater than in single path routing protocols. 4.6.1.3

Expected probability of path establishment

In addition to the path optimality problem, in the present framework, it is important to evaluate the marginal probability of path discovery. Expected or marginal probability refers to the probability of discovering a path irrespective of the route length. It is important for two reasons. ✓ Ad hoc routing protocols are not always guaranteed to discover paths especially the ones that use stochastic rebroadcasting of RREQs. This can easily be inferred from (4.25). ✓ Expected probability of path establishment also provides us with an estimated path length that is discovered by a protocol. We will discuss in Section 4.7.1 that average path length is handy in modeling the derivatives of routing overhead and route optimality metrics. We again address this problem separately for the two classes of algorithms. Single path ad hoc routing protocols A simple and common way of computing an average value is to divide the sum of the numbers by the total number of values present in the sample space. However, speaking strictly, this method inherently assumes that each one of the values has the same weight-age / frequency of occurrence. Therefore, a generic and accurate method is to take the weighted average of all these values. This also applies to random variables – the case we are currently dealing with.

135


Now, assuming that we have a list of 𝑛 discrete random variables 𝑥1 , 𝑥2 , 𝑥3 , . . . , 𝑥𝑛 with associated weights 𝑤1 , 𝑤2 , 𝑤3 , . . . , 𝑤𝑛 , the expected value of these numbers equal, 𝐸{𝑋} = 𝑤1 .𝑥1 + 𝑤2 .𝑥2 + 𝑤3 .𝑥3 + ⋅ ⋅ ⋅ + 𝑤𝑛 .𝑥𝑛

(4.26)

where 𝑤1 + 𝑤2 + 𝑤3 + . . . + 𝑤𝑛 = 1 are called the normalized weights [116]. We use (4.26) to find the expected probability of route establishment. Now we first address this problem for single path routing protocols. In this context, equations (4.23) and (4.24) are relevant and we have to take the average of these two probabilities using (4.26). Therefore, the expected probability of path establishment for a single path protocol is: ) ( 𝑓 [0]⋅𝜇 𝐸 (𝑠𝑝) {𝑋} ≃ 𝑤[0] 1 − (1 − 𝜖) + 𝑛 ∑

( )𝑓 [𝑖]⋅𝜇 ) ( × 𝑤[𝑖] 1 − 1 − 𝜖(𝑝𝑠 )𝑖

𝑖=1 𝑖 ∏ ( )𝑓 [𝑖−𝑗]⋅𝜇 1 − 𝜖(𝑝𝑠 )𝑖−𝑗 ,

(4.27)

𝑗=1

where 𝑤[𝑖] =

𝑓 [𝑖] 𝑘

and 𝑤[0] =

𝑓 [0] 𝑘

are the normalized weights of the paths of length 𝑡 + 𝑖 and

optimal paths respectively.

Multi-path ad hoc routing protocols We apply the same rule to (4.23) and (4.25) to model the expected probability of route discovery for a multipath ad hoc routing protocol. Therefore, we have 𝐸

(𝑚𝑝)

{𝑋} =

𝑛 ∑

( ( )𝑓 [𝑖]⋅𝜇 ) . 𝑤[𝑖] 1 − 1 − 𝜖(𝑝𝑠 )𝑖

𝑖=0

(4.28) Expected probability is a function of the normalized weights 𝑤[𝑖]. Weights in turn are dependent upon the number of available paths (𝑤[𝑖] =

𝑓 [𝑖] 𝑘 )

of a particular length. Therefore, expected

probability degrades if the paths are evenly distributed (𝑤[0] = 𝑤[1] = 𝑤[2] = . . . = 𝑤[𝑛]). A higher value of expected probability can result in discovery of more optimal paths. A comparison of (4.27) and (4.28) shows that multipath ad hoc routing algorithms have significantly higher probability of a route discovery as compared to single path algorithms. This can also be verified from the simulation results shown in Fig. 4.12 where DSR has higher optimal path routing probability than AODV.

136


4.6.2

Protocol specific route optimality models

Before we move on to develop protocol specific models, it is important to note that the value of 𝜇 in the generic route optimality / discovery models – described in (4.23), (4.24), (4.25), (4.27) and (4.28) – is related to the reactive / proactive nature of a given protocol. If a routing protocol discovers routes on demand only, it generally makes use of RREQ flooding / broadcasting. Now recall that 𝜇 represents the number of tries to discover a link and the fact that a broadcast packet is never retransmitted, 𝜇 = 1 for reactive protocols. However, it will be greater than 1 for proactive protocols which discover their neighboring links on periodic basis. 4.6.2.1

DSR and AODV

We described in Section 4.5.3.1 that intermediate nodes – both in AODV and DSR – forward the RREQs unconditionally and therefore 𝑝𝑟 = 1 in both cases. The only difference between the two protocols is that AODV is a single path while DSR is a multipath routing protocol. Now route optimality models for both the protocols can easily be derived from their respective generic models by putting 𝑝𝑠 = 𝑝𝑐𝑝𝑒 and 𝜇 = 1. We provide these equations for AODV and DSR below. AODV The probability of discovering at least an optimal path for AODV is given by 𝑃 (𝑎𝑜𝑑𝑣/𝑑𝑠𝑟) (𝑋[𝑡] ≥ 1) = 1 − (1 − 𝜖)𝑓 [0] . Similarly, the probability of discovering at least a 𝑛-suboptimal route is ) ( 𝑃 (𝑎𝑜𝑑𝑣) (𝑋[𝑡 + 𝑛] ≥ 1) = 1 − (1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑛 )𝑓 [𝑛] × ( ) ∏𝑛−1 𝑗 𝑓 [𝑗] . 𝑗=0 1 − 𝜖(𝑝𝑐 𝑝𝑒 )

(4.29)

(4.30)

Finally, the expected route discovery probability of AODV is 𝐸 (𝑎𝑜𝑑𝑣) {𝑋} ≃

) ( 𝑓 [0] + 𝑤[0] 1 − (1 − 𝜖) 𝑛 ∑

( )𝑓 [𝑖] ) ( × 𝑤[𝑖] 1 − 1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑖

𝑖=1 𝑖 ∏ ( )𝑓 [𝑖−𝑗] 1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑖−𝑗 ,

(4.31)

𝑗=1

It is important to note here that 𝜖 = (𝑝𝑐 𝑝𝑒 )𝑡 for all the models of AODV, DSR and DSDV. DSR

137


Optimal path discovery probability of DSR is the same as that of AODV and given by (4.29). Therefore, we only solve (4.25) and (4.28) for DSR protocol. Now the probability of discovering at least a 𝑛-suboptimal path for DSR is ) ( 𝑃 (𝑑𝑠𝑟) (𝑋[𝑡 + 𝑛] ≥ 1) = 1 − (1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑛 )𝑓 [𝑛] .

(4.32)

Similarly, the expected route discovery probability for DSR is 𝐸

(𝑑𝑠𝑟)

{𝑋} =

𝑛 ∑

( )𝑓 [𝑖] ) ( 𝑤[𝑖] 1 − 1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑖 .

𝑖=0

(4.33) An interesting observation is that 𝑝𝑐 𝑝𝑒 is a common term that models both AODV and DSR as stochastic flooding protocols. Therefore, both of them shall fail to discover a destination located beyond a certain hop length. This really is an important insight that can not be inferred through simple simulation analysis. 4.6.2.2

DSDV

DSDV proactively maintains a shortest path to each possible destination. Each node in the network tries to discover a link with all its neighbors 𝑇𝑠 .𝛼 times in a given run of the experiment. Therefore, putting 𝜇 = 𝑇𝑠 .𝛼 and 𝑝𝑠 = 𝑝𝑐 𝑝𝑒 in (4.23) and (4.24) will produce the optimal and suboptimal path discovery probabilities for DSDV as given below. 𝑃 (𝑑𝑠𝑑𝑣) (𝑋[𝑡] ≥ 1) = 1 − (1 − 𝜖)𝑓 [0]×𝑇𝑠 ⋅𝛼 . Similarly, the probability of discovering at least a 𝑛-suboptimal route is ) ( 𝑃 (𝑑𝑠𝑑𝑣) (𝑋[𝑡 + 𝑛] ≥ 1) = 1 − (1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑛 )𝑓 [𝑛]×𝑇𝑠 ⋅𝛼 × ) ∏𝑛−1 ( 𝑗 𝑓 [𝑗]×𝑇𝑠 ⋅𝛼 . 𝑗=0 1 − 𝜖(𝑝𝑐 𝑝𝑒 )

(4.34)

(4.35)

Now, using (4.27), the expected probability of route establishment for DSDV protocol is ) ( 𝑓 [0]×𝑇𝑠 ⋅𝛼 𝐸 (𝑑𝑠𝑑𝑣) {𝑋} ≃ 𝑤[0] 1 − (1 − 𝜖) + 𝑛 ∑

( )𝑓 [𝑖]×𝑇𝑠 ⋅𝛼 ) ( × 𝑤[𝑖] 1 − 1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑖

𝑖=1 𝑖 ∏ ( )𝑓 [𝑖−𝑗]×𝑇𝑠 ⋅𝛼 1 − 𝜖(𝑝𝑐 𝑝𝑒 )𝑖−𝑗 ,

(4.36)

𝑗=1

Note that the term 𝑇𝑠 𝛼 increases the probability of optimal route discovery in DSDV. Consequently, the probability of discovering suboptimal paths is substantially reduced (see Fig 4.13).

138


We now compare the performance of the route optimality models of AODV, DSR and DSDV with the simulation results in the following subsection.

4.6.3

Comparison of route optimality model with simulation results

We followed the same procedure – as in case of the routing overheads – to compare the performance of route optimality models with the simulation results. The authors of [2] report the total number of packets – routed by AODV, DSR and DSDV – through optimal, 1-suboptimal, 2-suboptimal and 3-suboptimal routes. Since, we are discussing the probabilistic route optimality models, we have to convert these numbers into probabilities to express both results – analytical and experimental – in a comparable format. For this purpose, we first calculated the total number of packets – routed by each protocol – through the optimal and suboptimal paths. In the next stage, we divided the number of packets routed through each category of path i.e. optimal / suboptimal by the grand total to compute the probability values. For instance, dividing the number of packets sent through optimal paths by the grand total will produce the probability of routing through an optimal path. We repeated this process for all the three protocols – AODV, DSR and DSDV. The resulting values are plotted in Fig. 4.12. In comparison, we computed the results of the route optimality models of AODV, DSR and DSDV, using (4.29) − (4.35), assuming the same topology parameters as reported by the authors of [2]. We assume 𝑘 = 𝑑𝑎𝑣𝑔 , 𝑡 = 4 and an exponential paths distribution i.e. 𝑓 [0] ≫ 𝑓 [1] ≫ 𝑓 [2] . . . and so on. The resulting analytical values for all the three protocols are shown in Fig. 4.13. We note the following points. ✓ The bar graphs of simulation results and analytical results shown in Fig. 4.12 and 4.13 have approximately similar trends. Each protocol has higher optimal path probability while suboptimal paths are rarely discovered or used. The deviation from simulation results is expected due to our simplifying assumptions. ✓ A noticeable discrepancy in the analytical results is the longer tail of DSR. Recall that DSR route optimality model is based on the assumption of maintaining all available paths. Therefore, the probability of suboptimal paths discovery is independent of the number of optimal paths. However, implementation usually maintains a subset of the total available paths in which preference is given to the optimal paths. Consequently, suboptimal paths discovery probabilities decrease at a faster rate.

139


probability of packet routing

AODV

DSR

DSDV

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

1

2

3

path length difference from optimal (hops)

Figure 4.12: Packet routing probability through optimal / suboptimal paths reported in [2].

probability of path discovery

AODV

DSR

DSDV

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0

1

2

3

path length difference from optimal (hops)

Figure 4.13: Optimal / suboptimal path discovery probabilities: analytical results. This concludes the route optimality discussion. In the following section, we demonstrate that routing overhead and route optimality models can be used to derive some other interesting metrics that are relevant to ad hoc and sensor networks.

140

4.7 Derivatives of Routing Overhead and Route Optimality

4.7

Derivatives of Routing Overhead and Route Optimality

Route optimality and control overhead are the baseline metrics that can be used to derive a number of other metrics. As a proof of concept, in this section, we derive expressions for two additional metrics commonly reported for ad hoc routing protocols: energy consumption and route discovery latency. We use the symbols in Table 4.1 for the following derivations.

4.7.1

Energy consumption model

Energy efficiency is the most important objective in the design of a routing protocol for WSNs. Transmission and reception of packets (control and data) are the major sources of battery depletion in mobile devices. We, therefore, derive expression for energy consumed during these two processes. Now the total energy consumed by a protocol is the sum of energy consumed during route discovery 𝐺𝑟𝑑 and data transmission phases 𝐺𝑑𝑎𝑡𝑎 . Mathematically, we express it as: 𝐺𝑡𝑜𝑡𝑎𝑙 = 𝐺𝑟𝑑 + 𝐺𝑑𝑎𝑡𝑎

(4.37)

Now, is the sum of energy consumed during the flooding of RREQs 𝐺𝑟𝑟𝑒𝑞 and the propagation of RREPs 𝐺𝑟𝑟𝑒𝑝 to the source node. Therefore, we have 𝐺𝑟𝑑 = 𝐺𝑟𝑟𝑒𝑞 + 𝐺𝑟𝑟𝑒𝑝

(4.38)

Assuming that 𝐵𝑟𝑟𝑒𝑞 is the size of a RREQ, 𝐺𝑟𝑟𝑒𝑞 may be expressed as 𝐺𝑟𝑟𝑒𝑞 = 𝐶𝑝 𝐵𝑟𝑟𝑒𝑞 × (𝑇𝑔 + 𝑑𝑎𝑣𝑔 ⋅ 𝑅𝑔 )

(4.39)

where 𝑇𝑔 and 𝑅𝑔 represents the energy consumed in transmission and reception of a bit. Similarly, assuming that the average path length discovered by a protocol equals 𝐿𝑎 (can be computing using equations (4.27) & (4.28))), 𝐺𝑟𝑟𝑒𝑝 equals 𝐺𝑟𝑟𝑒𝑝 = 𝐿𝑎 ⋅ 𝐵𝑟𝑟𝑒𝑝 ⋅ 𝑚 × (𝑇𝑔 + 𝑅𝑔 )

(4.40)

where 𝑚 is the total number of paths discovered by a protocol. If 𝑀 is the total number of packets delivered successfully by a protocol, then 𝐺𝑑𝑎𝑡𝑎 may be written as 𝐺𝑑𝑎𝑡𝑎 = 𝐿𝑎 ⋅ 𝐵𝑑 ⋅ 𝑀 × (𝑇𝑔 + 𝑅𝑔 )

141

(4.41)

4.8 Routing Overhead and Route Optimality Models of BeeSensor

Now combining all the above equations, (4.37) − (4.41), the final expression for the total energy consumed by a protocol is 𝐺𝑡𝑜𝑡𝑎𝑙

= 𝐿𝑎 (𝑀 𝐵𝑑 + 𝑚𝐵𝑟𝑟𝑒𝑝 )(𝑇𝑔 + 𝑅𝑔 ) + 𝐶𝑝 𝐵𝑟𝑟𝑒𝑞 (𝑇𝑔 + 𝑑𝑎𝑣𝑔 𝑅𝑔 ).

(4.42)

An interesting point to note in (4.42) is that majority of energy consumed in a route discovery process is due to the reception of broadcast traffic which is approximately double the energy consumed for transmitting RREQs.

4.7.2

Route discovery latency

Route discovery latency is an important metric, especially for time critical applications. Using the average path length discovered by a protocol (i.e. 𝐿𝑎 ) and the contention time given by (4.14), route discovery latency is given by 𝑡𝑑 = 2 × 𝐿𝑎 × 𝑡𝑐𝑜𝑛𝑡 .

(4.43)

We ignore the transmission and propagation delays because of their dependence on technology but they can be embedded in (4.43). For a particular device type, the latency of route discovery is directly dependent on the path length. Higher the path length, more channel accesses are required that ultimately lead to a higher route discovery latency.

4.8

Routing Overhead and Route Optimality Models of BeeSensor

BeeSensor employs some optimizations to basic flooding process to control the number of control packets – hereby referred to as forward scouts. The purpose of this section is to investigate – through probabilistic modeling of BeeSensor’s routing overhead and route optimality – the impact of optimizations on the performance of BeeSensor protocol. This will help us to review the design and make necessary modifications in order to make BeeSensor scalable, performance as well as energy efficient. Improvement in the design of BeeSensor is the topic of our remaining discussion in this chapter and the chapters to follow. In totality, it is a three step process. 1. We first adapt the generic models proposed in Section 4.5 and 4.6 to develop the routing overhead and route optimality expressions for BeeSensor protocol.

142


2. We then analyze the performance of BeeSensor – using the developed models – in different network topologies and protocol parameters. The analysis will continue in the next chapter – Chapter 5 – in which we model the reliability of BeeSensor in terms of event delivery. We also investigate the packet delivery reliability of ad hoc routing algorithms from an application perspective in Chapter 5. 3. Based on the findings of the mathematical analysis, we revise the design of BeeSensor in Chapter 6 to overcome the weaknesses of its initial design proposed in Chapter 3. We then perform extensive simulations to compare the performance of BeeSensor protocol with other existing ad hoc routing protocols – both in mobile as well as static scenarios – and show that the revised version is scalable, energy as well as performance efficient. Now before we adapt the generic models to BeeSensor protocol, we would like to revise the features of BeeSensor which shall be used in the adaptation process. We summarize them in the following. ✓ BeeSensor uses a variant of flooding to disseminate the forward scouts in search of a potential sink node. In this scheme, it allows the nodes lying within the 𝐻𝑙 radius of the source node to broadcast forward scouts with probability 1 i.e. unconditionally. The nodes lying beyond 𝐻𝑙 hops broadcast forward scouts with probability 𝑝𝑏 . ✓ BeeSensor floods the scouts in the entire network. Therefore, to model this flooding pattern, we use the same rule as described in case of AODV and DSR i.e. set ℎ =

𝐷 2

in

the generic routing overhead model – equation (4.17). ✓ Ring search is a well-known method used for controlling the RREQ flooding [117]. Therefore, we are interested in analyzing the performance of BeeSensor with a ring search mechanism. In this context, we develop a routing overhead model for a variant of BeeSensor protocol that performs ring search to locate a sink node – hereby referred to as BeeSensorR. In the following subsections, we first develop the routing overhead models of BeeSensor and BeeSensor-R and compare their performance with AODV. We then investigate the impact of broadcast forwarding probability on the routing overhead of BeeSensor independently. Furthermore, we also evaluate the performance of BeeSensor in mobile scenarios. We then model the route optimality of BeeSensor and compare it with that of AODV protocol. We also analyze the effect of broadcast forwarding probability on the route discovery probability of BeeSensor.

143


Finally, in the last subsection, we summarize the insights provided by the formal analysis of BeeSensor that will be used subsequently for the design improvement.

4.8.1

Routing overhead

As discussed above, nodes within a radius of 𝐻𝑙 of hops from the source broadcast forward scouts with 𝑝𝑟 = 1, therefore the routing overhead model of BeeSensor in this case equals ⎧ if ℎ = 𝐷  2 =1 𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔      ( )  ∑𝐻𝑙 −1 ∏𝑖  𝑖+1  × 𝑝 𝑝 + (𝑝 𝑝 ) 𝑑 [𝑗] . if 𝐻𝑙 ≤ 𝐷 𝑑  𝑎𝑣𝑔 𝑐 𝑒 𝑐 𝑒 𝑓 𝑖=1 𝑗=1 2  ⎨ (𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) = 𝐶𝑝 ( )  ∑𝐻𝑙 −1 ∏𝑖  𝑖+1  𝑑 × 𝑝 𝑝 + (𝑝 𝑝 ) 𝑑 [𝑗] +  𝑎𝑣𝑔 𝑐 𝑒 𝑐 𝑒 𝑖=1 𝑗=1 𝑓   (∑ 𝐷 )  ∏𝑖 −1  𝑖+1−𝐻𝑙 𝑖+1 2  × (𝑝 ) × (𝑝 𝑝 ) 𝑑 [𝑗] . 𝑑  𝑎𝑣𝑔 𝑏 𝑐 𝑒 𝑓 𝑖=𝐻𝑙 𝑗=1   ⎩ otherwise (4.44) Equation (4.44) apparently looks complicated and difficult to interpret. However if we look closely, we observe that the terms like (𝑝𝑏 𝑝𝑐 𝑝𝑒 )𝑖+1 unfold the fact that the storm of forward scouts will decay as we move away from the source nodes. In other words, the number of forwarding nodes will decrease exponentially. We elaborate this behavior with the help of diagrams shortly. Now, the second step is to model BeeSensor as a ring search protocol i.e. BeeSensor-R. For this purpose, we assume the same basic rule of BeeSensor i.e. allow the nodes within 𝐻𝑙 hops radius to forward the scouts unconditionally while the rest do it with probability 𝑝𝑏 . However, we do not flood the forward scouts in the entire network. Rather, we start looking for a sink in a ring of size 𝑅𝑠 hops. If unsuccessful, we let the 𝑅𝑠 = 𝑅𝑠 + 1 and launch another generation of forward scouts. Now assuming that a pair are 𝑑 m apart, the routing

144


overhead model of BeeSensor-R equals ⎧ if ⌈ 𝑟𝑑0 ⌉ = 𝐷  𝑝𝑐 𝑝𝑒 𝑑𝑎𝑣𝑔 2 = 1      ( )   ∑⌈ 𝑟𝑑0 ⌉ ∑⌈ 𝑟𝑑0 ⌉ ∑𝑘−1 ∏𝑖  𝑖+1   × 𝑝 𝑝 + (𝑝 𝑝 ) 𝑑 [𝑗] , 𝑑 𝑎𝑣𝑔 𝑐 𝑒  𝑘=𝑅𝑠 𝑐 𝑒 𝑘=𝑅𝑠 +1 𝑖=1 𝑗=1 𝑓      if ⌈ 𝑟𝑑0 ⌉ = 𝐻𝑙 where 𝐻𝑙 > 1 and 𝑅𝑠 = 1       ( ) ⎨ (𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟−𝑅) ∑⌈ 𝑟𝑑0 ⌉ ∏𝑖 ∑⌈ 𝑟𝑑0 ⌉ ∑𝑘−1 𝑖+1 𝐶𝑝 = 𝑑𝑎𝑣𝑔 × 𝑝 𝑝 + (𝑝 𝑝 ) 𝑑 [𝑗] , 𝑐 𝑒 𝑘=𝑅𝑠 𝑐 𝑒 𝑘=𝑅𝑠 𝑖=1 𝑗=1 𝑓       if ⌈ 𝑟𝑑0 ⌉ = 𝐻𝑙 where 𝐻𝑙 >  ( ) 1 and 𝑅𝑠 > 1   𝑑  ∑ ∑ ∏ ∑ ⌈ ⌉ ⌈𝐻𝑙 ⌉ 𝑘−1 𝑖 𝑟0  𝑖+1  𝑑𝑎𝑣𝑔 ×  𝑖=1 (𝑝𝑐 𝑝𝑒 ) 𝑗=1 𝑑𝑓 [𝑗] + 𝑘=𝑅𝑠 𝑝𝑐 𝑝𝑒 + 𝑘=𝑅𝑠   ( )   𝑑  ∑⌈ 𝑟0 ⌉ ∑𝑘−1 ∏𝑖  𝑖+1−𝐻 𝑖+1 𝑙  × (𝑝𝑐 𝑝𝑒 ) 𝑑𝑎𝑣𝑔 ×  𝑘=𝐻𝑙 𝑖=1 (𝑝𝑏 ) 𝑗=1 𝑑𝑓 [𝑗]    ⎩ otherwise (4.45) where 𝑑 is the Euclidean distance between the pair. It must be noted that a ring size of 𝑅𝑠 means that the nodes located at 𝑅𝑠 hops from the source or less are allowed to broadcast forward scouts. If 𝑅𝑠 < 𝐻𝑙 , they broadcast unconditionally while they do it with probability 𝑝𝑏 otherwise. Remember, we do not assume any fixed value of the initial ring size. Keeping it as a variable will allow us to study its impact on the performance of BeeSensor-R. 4.8.1.1

Analytical results

Before we compare the performance of BeeSensor with other protocols, we first study the impact of broadcast forwarding probability on the routing overhead. In this context, we assume a network of 1000 nodes deployed in an area of 225, 00, 00 𝑚2 following a Poisson distribution. We then compute the routing overheads of BeeSensor using (4.44) for different values of 𝑝𝑠 = 𝑝𝑏 × 𝑝𝑐 × 𝑝𝑒 . The results are plotted in Fig. 4.14. With zero packet loss i.e. 𝑝𝑠 = 1, as expected, the routing overhead of BeeSensor approaches the maximum possible value 999. It shows the correctness of the proposed routing overhead model because – if every node is allowed to broadcast once – the total number of transmissions must be equal to 999 under ideal conditions. Now as the value of 𝑝𝑠 decreases, the routing overhead decreases exponentially. At 𝑝𝑠 = 0.7, there are only 61 nodes that participate in broadcasting. If we are merely interested in decreasing the overhead, it might be fascinating to have such a low value. However, it encapsulates some other information that must be taken care of. For instance, at lower values of 𝑝𝑠 , there might be a vast majority of nodes that

145


Routing overhead (Pkts)

1000

BeeSensor

800 600 400 200 0 0.65

0.7

0.75

0.8

0.85

0.9

0.95

1


Figure 4.14: Routing overhead of BeeSensor for different values of broadcast forwarding probabilities (𝑝𝑠 = 𝑝𝑏 × 𝑝𝑐 × 𝑝𝑒 ) will not receive a copy of the broadcast packet. This can be detrimental because a sink node located beyond a certain threshold hop limit may not get a forward scout and hence becomes inaccessible. While describing all these points, we must emphasize here that all these results assume minimum value of transmission radius 𝑟0 – computed through (4.3) – that can keep the network connected. Higher transmission radius, of course, will decrease the hop distance effectively improving the criticality of the problem mentioned above. To compare the performance of BeeSensor, BeeSensor-R and AODV, we compute their respective routing overheads under different network topologies. The computed values assume 12 source nodes communicating with a sink node. The results are shown in Fig. 4.15. First of all, we notice that the routing overhead of BeeSensor is minimum and rises slowly as the network size gets bigger. Secondly, the difference between AODV and BeeSensor is lower in small sized network and rises as the number of nodes in the network is increased. This is expected because the average hop count between a source and the sink rises as the network size increases forcing stochastic broadcasting to play its role. Ring search is supposed to generate less routing overhead. However, we notice that the routing overhead of BeeSensor-R is the highest in most cases which contradicts with its expected behavior. As the network size goes bigger, its routing overhead rises as well. However, AODV finally takes over because its routing overhead rises rapidly with the network size. We explain the behavior of BeeSensor-R as follows. First point to note is that we are reporting the results of BeeSensor-R with an initial ring size

146


BeeSensor

AODV

BeeSensorŦR

Routing overhead (pkts)

2000

1500

1000

500

0 50

100

200

500

1000

Network size

Figure 4.15: Routing overheads of BeeSensor, BeeSensor-R and AODV for different network topologies.

y

D 24 y

y y

S 32

Figure 4.16: Example illustration of mobile scenarios. of 𝑅𝑠 = 2. Every time it fails to find a sink node, it regenerates a new generation of forward scouts by incrementing 𝑅𝑠 . Now as the distance between a pair gets higher than 2, BeeSensor-R has to repeat scouting process leading to an increase in the routing overhead. We assumed fixed locations of pair and therefore, for higher network topologies, routing overhead of BeeSensor-R remains approximately constant. We further investigate the impact of initial ring size on the routing overhead of BeeSensor-R in the following subsection.

147


Table 4.3: Routing overhead of BeeSensor-R under mobility No. of nodes=200, Area=500,000 𝑚2 𝑅𝑠 = 1 𝑅𝑠 = 2 Square size 100 m × 100 m 150 m × 150 m 200 m × 200 m

𝑅𝑠 = 3

Total / Per RD 316 / 79 488 / 122 485 / 121

Total / Per RD 312 / 78 485 / 121 457 / 114

Total / Per RD 295 / 74 425 / 106 353 / 88

416 / 104 538 / 135 493 / 123

384 / 96 506 / 127 461 / 115

368 / 92 446 / 112 357 / 89

667 / 167 438 / 110 856 / 214

634 / 159 406 / 102 824 / 206

571 / 143 298 / 75 716 / 179

No. of nodes=500, Area=1000,000 𝑚2 Square size 100 m × 100 m 150 m × 150 m 200 m × 200 m No. of nodes=1000, Area=225, 0000 𝑚2 Square size 200 m × 200 m 300 m × 300 m 400 m × 400 m 4.8.1.2

Evaluation of BeeSensor in mobile scenarios

The purpose of this section is two fold. First, we illustrate the use of the proposed modeling framework in mobile scenarios. Secondly, we investigate the impact of initial ring estimate on the routing overhead of BeeSensor-R. Consider the network shown in Fig. 4.16. The square around a node represents the area in which the node is allowed to move between two consecutive route discoveries. We simulate the movement of nodes by assuming a Poissonian RREQ generation pattern. Assuming squares of varying dimensions, we simulate different mobility patterns i.e. larger square size represents higher mobility and vice versa. We then performed experiments with different network topologies – 200, 500, and 1000 nodes – and different values of 𝑅𝑠 . We report the total and the average routing overhead (per route discovery) generated by a pair of nodes in Table 4.3. It can easily be noticed that number of forward scouts generated under high mobility conditions are comparatively higher in most of the cases. Second important point to note is that the initial ring size 𝑅𝑠 has significant impact on the routing overhead. For instance, 𝑅𝑠 = 3 produces the least routing overhead in all assumed scenarios. We also notice that too low values of 𝑅𝑠 – in smaller networks – can almost nullify the impact of ring search method. This can easily be explained as follows. If the distance between the pair is comparatively

148


higher than the initial ring size, the source node will have to initiate multiple scoutings to locate the sink node which ultimately leads to higher routing overhead. Therefore, correct estimation of 𝑅𝑠 is the fundamental requirement to keep the routing overhead to an optimum value.

4.8.2

Route optimality

First of all, we model the probability of optimal path discovery in BeeSensor. Recall that BeeSensor is a multipath routing protocol. Therefore, its optimal path discovery probability – using (4.23) – equals 𝑃 (𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑋[𝑡] ≥ 1) =

⎧ 𝑓 [0]  ⎨1 − (1 − 𝜖)  ⎩

( )𝑓 [0] 1 − 1 − 𝜖 × (𝑝𝑏 𝑝𝑐 𝑝𝑒 )𝑡−𝐻𝑙 .

if 𝑡 ≤ 𝐻𝑙 otherwise

(4.46)

In a similar way, the probability of discovering at least a 𝑛-suboptimal path is, ⎧( ) 𝑛 𝑓 [𝑛]  if 𝑡 + 𝑛 ≤ 𝐻𝑙 ⎨ 1 − (1 − 𝜖(𝑝𝑐 𝑝𝑒 ) ) 𝑃 (𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑋[𝑡 + 𝑛] ≥ 1) =  ) ⎩( 1 − (1 − 𝜖(𝑝𝑏 𝑝𝑐 𝑝𝑒 )𝑡+𝑛−𝐻𝑙 )𝑓 [𝑛] . otherwise (4.47) Finally, to compute the expected probability of path discovery of BeeSensor protocol, we take the weighted average of probabilities given in (4.46) and (4.47) as given below. ( ⎧∑ ( ) ) 𝑛 𝑖 𝑓 [𝑖]  𝑤[𝑖] 1 − 1 − 𝜖(𝑝 𝑝 ) if 𝑡 + 𝑛 ≤ 𝐻𝑙 𝑐 𝑒  𝑖=0 ⎨ (𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) ≃ 𝐸{𝑋} ( )   ⎩∑𝑛 𝑤[𝑖] 1 − (1 − 𝜖(𝑝 𝑝 𝑝 )𝑖 )𝑓 [𝑖] . otherwise 𝑐 𝑒 𝑏 𝑖=0 (4.48) where 𝜖 in (4.46) − (4.48) equals (𝑝𝑐 𝑝𝑒 )𝑡 . All these models depict that, with an increase in the number of hops between a source and the sink node, probability of path discovery will reduce. Now, if we compare it with the models developed earlier for AODV (for instance equation (4.31)), we note that the probability of route discovery for BeeSensor will fall more rapidly with the path length. This is valid for paths of length greater than 𝐻𝑙 hops. We elaborate this point in the following subsection where we compare the route optimality of BeeSensor and AODV. 4.8.2.1

Analytical results

First of all, we present a comparison of optimal and suboptimal path discovery probabilities of BeeSensor and AODV. For this purpose, we simulate a network of 1000 nodes deployed in an

149


BeeSensor

AODV

Path discovery probability

1 0.8 0.6 0.4 0.2 0 0

1

2

3

Path length difference from optimal (hops)

Figure 4.17: Optimal and suboptimal path discovery probabilities with 𝑡 = 2 BeeSensor

AODV

Path discovery probability

1 0.8 0.6 0.4 0.2 0 0

1

2

3

Path length difference from optimal (hops)

Figure 4.18: Optimal and suboptimal path discovery probabilities with 𝑡 = 3 area of 225, 00, 00 𝑚2 . We collected two different sets of measurements. First set values are calculated by assuming an optimal path length 𝑡 of 2 hops while for the second set of values, we assume 𝑡 = 3. The computed values of optimal and suboptimal path discovery probabilities are shown in Fig. 4.17 and 4.18 respectively. We note that the optimal path discovery probability of BeeSensor is equal to that of AODV in the first case. This is understandable because of the fact that 𝑡 = 𝐻𝑙 . However, as the path length is increased (Fig. 4.18), the probability of optimal path discovery of BeeSensor

150


Probability of path discovery

AODV

BeeSensor

1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1 0 2

3

4

5

Optimal path length (hops)

Expected route discovery probability

Figure 4.19: Expected probability of route discovery of BeeSensor and AODV.

1 BeeSensor 0.8

0.6

0.4

0.2

0 0.65

0.7

0.75

0.8

0.85

0.9

0.95

1


Figure 4.20: Expected probability of route discovery of BeeSensor at various values of 𝑝𝑠 = 𝑝𝑏 × 𝑝𝑐 × 𝑝𝑒 decreases. This is due to stochastic forwarding behavior of the nodes in BeeSensor beyond 𝐻𝑙 hops. It should also be noted that BeeSensor has significantly higher probability of discovering suboptimal paths due to its multipath nature. Consequently, its marginal probability of path establishment rises. We illustrate this behavior of BeeSensor by computing the expected path discovery probabilities of both the protocols for different path lengths. The results are plotted in Fig. 4.19. The figure clearly shows that BeeSensor performance in terms of its ability to discover

151


paths between a given pair of nodes is higher than that of AODV. The trend continues even for higher path lengths. However, due to stochastic forwarding behavior of nodes, probability of discovering much longer paths deteriorates. Consequently, it falls below to that of AODV. This really is an important insight and should be rectified in order to make BeeSensor scale to larger network topologies. In the last phase of our discussion, we plot the values of expected route discovery probability of BeeSensor at various values of broadcast forwarding probability 𝑝𝑠 = 𝑝𝑏 ×𝑝𝑐 ×𝑝𝑒 . The results are plotted in Fig. 4.20. Under ideal conditions i.e. 𝑝𝑠 = 1, probability of route discovery is maximum. As we go from ideal to practical networks, the probability of path discovery reduces. If we study this plot in conjunction with the one shown in Fig. 4.14, we can easily infer the merits and demerits of stochastic broadcasting. On one hand, it leads to substantial decrease in the routing overhead while on the other hand, it affects the route discovery capability of BeeSensor protocol. Therefore, we have to make an intelligent design so that BeeSensor is not only able to scale, but does so at minimum of routing overhead.

4.8.3

Discussion

We mentioned at the start of this chapter that mathematical equations normally contain more information than the expectation of the engineer. Therefore, performance models developed here for evaluation of ad hoc routing protocols are no exception to this rule. We have been briefly describing the key insights provided by different models where necessary. However, their detailed analysis and relevance to ad hoc routing protocols need to be established in more detail. With this motivation, in this section, we collect all these insights and discuss their significance with special focus on BeeSensor protocol. The discussion is relevant to all ad hoc routing protocols based on the same fundamental principles e.g. on-demand route discovery, flooding of routing messages etc. However, to keep things simple and in logical order, our discussion will only be referring to BeeSensor. 1. The first insight is provided by the model of expected forward degree developed in Section 4.5. Expected forward degree actually shows the number of new nodes that are covered by the broadcast of a node. Now, with reference to Fig. 4.10, we note that as we move away from the source node, the number of nodes (or the area) covered by each node reduces. This clearly points towards the fact that allowing every node to repeat such a broadcast packet is resource consuming with negligible output. The nodes lying closer to the source

152


cover more area and hence may be allowed to broadcast unconditionally. However, when broadcast propagates in the network, the overlapping area (the area in which broadcast of multiple nodes can be received correctly) increases leading to decrease in the effective area covered by individual nodes. Therefore, distant nodes should only be allowed to perform conditional broadcast. Interestingly, BeeSensor is based on the same broadcast pattern. We would like to highlight another important reason for selection of the broadcast pattern used in BeeSensor. If we allow the nodes to perform selective forwarding from the very first hop, there is always a chance that broadcast may decay more quickly in the direction of the sink node. It is extremely important to look for a sink node in all directions of the source node. Therefore, allowing the first 𝐻𝑙 hop neighbors to perform unconditional forwarding will enable the broadcast to propagate equally in all directions. 2. Stochastic forwarding helps in controlling the storm of forward scouts. This is clearly demonstrated by the plot of equation (4.44) shown in Fig. 4.14. The Lower broadcast forwarding probability generates less routing overhead. However, the price we have to pay for lower routing overhead is illustrated in the plot of equation (4.48) shown in Fig. 4.20. Lower the broadcast forwarding probability is, lower is the routing overhead as well as the path discovery probability. This is undesirable because we always want the path discovery probability to be as high as possible. This leads to an important conclusion and that is: we can not fix the value of 𝑝𝑏 too low merely to reduce the routing overhead of BeeSensor. We have to keep it above a certain threshold and look for some alternate options to reduce the control overhead. 3. Path discovery probability does not merely depend upon the broadcasting forwarding probability. It also depends upon the number of hops between the pair (equations (4.46) – (4.48)). As we move away from the source i.e. hops increase, the path discovery probability decreases rapidly (see Fig. 4.17 – 4.19). This in fact is a more serious issue that can not be resolved by even allowing every node to broadcast 𝑝𝑏 = 1 and making the network collision free. Recall that broadcast forwarding probability equals 𝑝𝑠 = 𝑝𝑏 ×𝑝𝑐 ×𝑝𝑒 . Clearly, we can not have a wireless ad hoc network with no channel errors. This is even more true for resource constrained sensor nodes which are not equipped with powerful transceivers and therefore are less resilient to channel errors.

153


There is one – and to the best of our knowledge the only – solution to this problem is to keep the hop distance between a pair within a certain threshold limit. Now a relevant question at this point might be: what is the safe hop distance? Said another way, at what distance a sink must be placed from a source node in-order to get it discovered with fairly high probability? We shall address this issue in the next chapter. However, not much apparent from the question itself, one might ask yet another relevant question: how can we keep a sink node equi-distant from all the sensor nodes? We stop here and come back to these two questions in the next chapter. 4. Maintaining multiple paths is beneficial as shown in Fig. 4.17 – 4.19 in which BeeSensor, inspite of its stochastic nature, has significantly better path discovery probability than AODV. Recall that in the initial design of BeeSensor, we have opted to maintain all the discovered paths. Now, a pair of nodes in an ad hoc network may be connected through a several independent / node-disjoint paths. The number of paths may even be higher for sensor networks where nodes are generally deployed in high density. Keeping in mind that maintenance of each path requires extra overhead, we have to determine whether maintenance of the maximum possible paths connecting the source with a sink node is always justified. The above mentioned problem may be rephrased in the form of a question: does the maintenance of an additional path always carries the same level of advantage? To answer to this question, we need to establish some sort of relationship between the number of paths and the packet delivery reliability / path discovery probability. We keep this question unanswered – like the previous two – and come back to it in the next chapter. 5. Remember we proposed two routing overhead models for BeeSensor. The one is based on the initial design described in Chapter 3. The second model assumes one more optimizations to this design and that is the use of ring-search mechanism i.e. BeeSensor-R. Now, with reference to the results of equation (4.45) shown in Table 4.3, we notice that the initial ring size has significant impact on the routing overhead of BeeSensor-R. For instance, if it is too small than the distance between a pair, the routing overhead will be too high. Therefore, optimal estimation of the starting ring size is critical. An appropriate way is to keep it dynamic so that it can be adjusted according to the existing network topology. We shall elaborate this point when we describe the final design of BeeSensor.

154

4.9 Conclusions

4.9

Conclusions

In this chapter, we developed a formal framework to model the two prominent metrics used for the evaluation of ad hoc routing protocols; routing overhead and route optimality. We have demonstrated that the proposed metrics can easily be adapted to several ad hoc routing algorithms. We also compared the results of the proposed models with the simulations. The comparison shows that the analytical results are consistent with the simulation studies. The routing overhead and the route optimality are the two fundamental metrics that can be used to develop other relevant performance measures. As an example, we derived the models for total energy consumption and the route discovery latency. We then adapted the generic models of the two metrics for BeeSensor protocol. The extensive analysis – through the developed models – yield interesting insights about the impact of different parameters on the performance of BeeSensor protocol especially in large scale sensor networks. Consequently, we are able to identify the shortcomings of BeeSensor which otherwise would have been extremely difficult to infer through simulations only. In the next chapter, we continue the theoretical analysis of BeeSensor in-order to gain more insights and rectify the problems identified in the afore-mentioned analysis.

155

Chapter 5

Reliability Theoretic Analysis of Ad Hoc Routing Protocols 5.1

Introduction

Several real world applications of wireless ad hoc and sensor networks demand higher levels of data reliability. For instance, reliability is one of the fundamental requirements for missioncritical systems; e.g., networks deployed in the battlefield, remote patient management, home automation, monitoring of disaster-struck regions etc. Researchers have been working on the provision of reliability at the medium access control (MAC) layer – the so-called hop-by-hop reliability – and the transport layer [118, 119, 120]. However, reliability analysis of floodingbased routing protocols in an ad hoc setting is largely unexplored. The roots of reliability theory date back to nineteenth century where it was used by the insurance companies to compute their profits / losses [121]. However, it now is used extensively by the engineers of every discipline to model their systems performance. In a nut shell, it refers to the ability of a system to perform its intended function. Reliability theory models the system as a set of components connected in series, parallel or any hybrid combination. It then models the working of a system in terms of the reliability of its components. Therefore, reliability is an elegant tool that may be applied to model the packet delivery reliability of an ad hoc routing protocol. In this chapter, we use the theory of reliability to analyze the packet delivery reliability of ad hoc routing algorithms in general and BeeSensor in particular in-order to answer the questions raised in Chapter 4. More specifically, we do the following.

156

5.2 Background on Reliability Theory

✓ Assuming that a node-disjoint path resembles a series system – a set of components connected in series, we model the packet delivery reliability of BeeSensor protocol in which a pair is linked through multiple node-disjoint paths. ✓ Using the reliability model of BeeSensor, we establish a relationship between the reliability function and the number of paths maintained by a source node. We use this relationship to answer one of the questions raised in Section 4.8.3 Chapter 4 and that is: does the maintenance of an additional path always carries the same level of advantage? ✓ We then use the reliability model of BeeSensor to derive an expression for the hop distance at which a packet may be flooded under the given reliability constraints. This provides an answer to the question raised in Section 4.8.3 Chapter 4 and that is: at what distance a sink must be placed from a source node in-order to get it discovered with fairly high probability? ✓ Finally, we analyze the reliability of ad hoc routing algorithms, in general, in the context of loss-and-delay sensitive applications. To this end, we investigate the use of multiple paths – node-disjoint paths and partially-disjoint paths – simultaneously. We show – through theoretic analysis and simulations – that the performance of partially-disjoint paths is superior than node-disjoint paths. This will conclude our formal modeling process.

5.1.1


The rest of the chapter is organized as follows. Section 5.2 describes the basics of the theory of reliability. Section 5.3 contains the modeling assumptions and the definitions. The reliability of BeeSensor is modeled in Section 5.4. Section 5.5 derives a lower bound on the hop distance at which a packet may be flooded under the given reliability constraints. Reliability analysis of ad hoc routing algorithms from an application perspective is presented in Section 5.6. The key conclusions of the chapter are listed in Section 5.7.

5.2

Background on Reliability Theory

Reliability theory provides a model of a multicomponent system which can be used to find the probability that the system is functional under a given set of constraints. The theory models the system as a set of components connected in series, parallel or hybrid (series-parallel) configurations. The reliability of the complete system is then computed as a function of the reliability

157


of the individual components. In this section, we introduce basic concepts and definitions used in reliability theory literature [122].

5.2.1

Structure functions

Let indicator variable (𝑥𝑖 ) be the state of 𝑖𝑡ℎ component. Mathematically, ⎧  if the 𝑖𝑡ℎ component is functional ⎨1, 𝑥𝑖 =  ⎩ 0, if the 𝑖𝑡ℎ component has failed. A state vector 𝑋 = {𝑥1 , 𝑥2 , . . . , 𝑥𝑛 } shows indicator variables of all 𝑛 components of a system. From the state vector, one can determine whether the overall system is functional or failed. A structure function 𝜙(𝑋) then determines the working of a system by utilizing 𝑋. Mathematically, 𝜙(𝑋) is defined as ⎧  1,      ⎨ 𝜙(𝑋) =   0,    ⎩

5.2.2

if the system is functional when the state vector is 𝑋 if the system has failed when the state vector is 𝑋.

System and component reliabilities

The state of 𝑖𝑡ℎ component can also be represented by a random variable 𝑋𝑖 such that 𝑃 {𝑋𝑖 = 1} = 𝑝𝑖 = 1 − 𝑃 {𝑋𝑖 = 0}, where 𝑝𝑖 is the probability that 𝑖𝑡ℎ component is functional, also referred as its reliability. The overall reliability of a system is then 𝑟 = 𝑃 {𝜙(𝑋) = 1}, where 𝑋 = {𝑋1 , 𝑋2 , . . . , 𝑋𝑛 } . If 𝑝 = {𝑝1 , 𝑝2 , 𝑝3 , . . . , 𝑝𝑛 } is a state vector representing the reliabilities of individual components, the system’s reliability function is 𝑟 = 𝑟(𝑝).

5.2.3

Series and parallel systems

A series system consists of 𝑛 components connected in a series fashion as shown in Fig. 5.1(a). Such a system is only functional if all of its components are functional. The reliability function 𝑟(𝑝) of a series system is 𝑟(𝑝) =

𝑛 ∏ 𝑖=1

158

𝑝𝑖 .

(5.1)


Figure 5.1: A series and a parallel system. A parallel system, on the other hand, consists of components connected in a parallel fashion (Fig. 5.1 (b)). In this case, the system is functional if at least one of its components is functional. Therefore, the reliability function of a parallel system is 𝑟(𝑝) = 1 −

𝑛 ∏

(1 − 𝑝𝑖 ).

(5.2)

𝑖=1

5.2.4

𝑘-out-of-𝑛 system with equal reliabilities

Another related term is a 𝑘-out-of-𝑛 system. This system works if at least 𝑘 out of a total of 𝑛 components are working. Assuming that each component has the same reliability, 𝑝𝑖 = 𝑝, the reliability function of a 𝑘-out-of-𝑛 system is given by 𝑟(𝑝) =

𝑛 ( ) ∑ 𝑛 𝑖=𝑘

𝑖

𝑝𝑖 (1 − 𝑝)𝑛−𝑖 .

(5.3)

Equations (5.1), (5.2) and (5.3) assume that states of different components are independent of each other.

5.2.5

Path sets

A system can also be represented as a series arrangement of parallel structures or a parallel arrangement of series structures. A state vector 𝑋 is known as a path vector if 𝜙(𝑋) = 1. A minimal path set is a minimal set of components whose working ensures the working of the whole system. For instance, consider a series system shown in Fig. 5.1(a). This system functions if

159

5.3 System Description and Definitions

all the three components are functioning. This set, i.e. components 1, 2 and 3, is a minimal path set of the system.

5.3 5.3.1

System Description and Definitions System description

We consider an ad hoc network in which nodes are distributed randomly on a two-dimensional plane. The resultant graph is assumed to be connected and all links (or edges) are symmetric. We assume an ad hoc network with a CSMA/CA-based MAC layer protocol for contention resolution. Even in the case of no contention, we account for the possibility that a packet may be lost due to channel errors (such as interference, fading, mobility, etc.). We assume that there is no transport layer protocol to provide additional data delivery reliability.

5.3.2

Definitions

We now provide formal definitions of some of the key concepts. Definition: Flooding is the process in which each node in an ad hoc network, except the destination, broadcasts a unique copy of an information packet only once to its neighbors. Another relevant term in this context is the flooding distance. Definition: . The total number of hops between a pair is known as the flooding distance. A shortest path therefore has the minimum flooding distance. Definition: Packet Forwarding Probability (𝑝𝑓 ) is the probability that a forwarded unicast packet will be delivered successfully to the next hop node. Packet forwarding probability can be expressed in terms of 𝑝𝑐 and 𝑝𝑒 – derived in Chapter 4 – as given below. 𝑝𝑓 = 1 − (1 − 𝑝𝑐 × 𝑝𝑒 )

𝑇

(5.4)

where 𝑇 represents the number of retransmission attempts. Remember 𝑝𝑓 is different from 𝑝𝑠 in the sense that 𝑝𝑓 deals with the unicast transmissions only. Therefore, we do not incorporate the term 𝑝𝑟 in (5.4) which is relevant for stochastic broadcast of RREQ messages. As the number of retransmission attempts 𝑇 gets higher, the second term in (5.4) gets lower. This leads to higher value of 𝑝𝑓 .

160

5.4 Packet Delivery Reliability of BeeSensor

We have already defined a node-disjoint path in Chapter 4. We reproduce it here in-order to keep the chapter self-contained. Definition: Node-disjoint paths refer to a set of paths between a pair that do not contain any overlapping node(s). Since we use ad hoc networking and reliability theory terms interchangeably, therefore, we introduce few definitions to bridge the gap between the two domains. Definition: A subsystem is a nod-disjoint path between a pair. Definition: Wireless nodes in an ad hoc network are referred as the routing components or simply the components of a subsystem. Definition: A system is a parallel combination of multiple subsystems. The definition of system ensures that all paths maintained between a pair are node-disjoint. Thus if a subsystem contains 𝑡 components, it represents a node-disjoint path with flooding distance 𝑡. Using the given definitions, we can infer that reliability of a component in a subsystem equals the packet forwarding probability 𝑝𝑓 . Similarly, the components in a subsystem form a minimal path set of the whole system. The rest of our discussion addresses the reliability of BeeSensor protocol. However, the discussion is valid for flooding-based ad hoc routing protocols in general.

5.4

Packet Delivery Reliability of BeeSensor

Packet delivery reliability refers to the probability that a given packet / event will be delivered to its final destination i.e. a sink node. Now, we know that BeeSensor uses a variant of flooding to discover routes reactively. We have also established the fact in Chapter 4 that such a route discovery process results in node-disjoint paths only. Therefore, in-order to analyze the reliability of BeeSensor protocol, we model it as a system containing 𝑚 subsystems – a subsystem refers to a node-disjoint path. Such a system is illustrated in Fig. 5.2. In the following subsections, we first develop the reliability model of BeeSensor 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) and discuss its significance. Subsequently, we investigate the relationship of the number of node-disjoint paths 𝑚 to the system reliability.

161


1

2

S

L1

3

L2

L3

Lt

D

m

Figure 5.2: A pair connected through 𝑚 node-disjoint paths.

5.4.1

The reliability model

We assume that a node-disjoint path is 𝑡 hops long. Now, with reference to Fig. 5.2, we observe that a node-disjoint path is actually a series combination of different components (see Section 5.2). Therefore, a subsystem in our case is a set of 𝑡 components connected in series. Clearly, for a subsystem to work, all the components must be working. In other words, an event sent by node 𝑆 must traverse all the 𝑡 links before being delivered to sink 𝐷. Therefore, the reliability 𝑅𝑛𝑑 (𝑝𝑓 , 𝑡) of a node-disjoint path, using (5.1), is given by 𝑅𝑛𝑑 (𝑝𝑓 , 𝑡) = (𝑝𝑓 )𝑡 .

(5.5)

Clearly, and as can be intuitively argued, the reliability that a packet would be delivered to sink 𝐷 decreases as 𝑡 increases. Now, BeeSensor maintains multiple node-disjoint paths. This is equivalent to multiple subsystems working in parallel i.e. a parallel combination of series subsystems. The overall system will be working if at least one of the 𝑚 subsystems is working. Therefore, using (5.2) and (5.5), the reliability of BeeSensor protocol is: 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) = 1 − (1 − 𝑝𝑡𝑓 )𝑚 .

162

(5.6)


Packet delivery reliability

1

0.8

0.6

0.4 pf=0.85,t=8 0.2

pf=0.95,t=8 pf=0.95,t=16

0 0

5

10

15

20

Number of paths

Figure 5.3: Packet delivery reliability of BeeSensor. The above expression assumes that all paths connecting 𝑆 and 𝐷 have the same flooding distance which is equal to the minimum flooding distance 𝑡. In other words, all discovered paths are assumed to be optimal. While this assumption is unrealistic, it allows us to quantify the best-case reliability of BeeSensor protocol. Now recall the question raised in Chapter 4. Q: Does the maintenance of an additional path always carries the same level of advantage? We shall answer this question in two ways. First, we plot the reliability of BeeSensor protocol against different values of 𝑚. Second, we formally prove a relation between 𝑚 and the reliability function 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡). The plot of (5.6) for different values of node-disjoint paths 𝑚 is shown in Fig. 5.3. Note that an increase in the value of 𝑚 does not always result in a proportional increase in packet delivery reliability. In fact, addition of the first few paths results in an exponential increase in the BeeSensor reliability which then reaches a saturation point after which the curve flattens. In other words, 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) is concave with respect to 𝑚. Therefore, addition of redundant paths beyond a certain threshold will simply increase the route discovery and maintenance overhead but will not provide a proportional dividend in terms of packet delivery reliability. It can also be observed from Fig. 5.3 that for higher values of 𝑝𝑓 , saturation point is achieved with significantly less number of paths. If we are able to minimize the number of collisions and channel errors to increase 𝑝𝑓 , we can attain a significantly higher reliability by maintaining fewer number of node-disjoint paths. As a result, the discovery and maintenance overhead shall

163


be reduced accordingly. We also derived bounds on the reliability function of BeeSensor in Appendix A. In the following subsection, we formally prove the concavity of the reliability function of BeeSensor.

5.4.2

Concavity of the reliability function

The empirical study about the reliability function of BeeSensor can be proven formally if we show that 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) is a concave function of 𝑚. The function 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) is said to be concave with respect to 𝑚 if its value increases exponentially with an increase in the value of 𝑚. But a strictly concave function is the one in which the exponential rise is followed by an exponential fall in the function value. We state this observation as a lemma: Lemma 5.4.1 The reliability function of a system with 𝑚 subsystems is a concave function of 𝑚. Proof We can rewrite (5.6) as 1 − 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) = (1 − 𝜖)𝑚 ,

(5.7)

where 𝜖 = 𝑝𝑡𝑓 . Taking the log of both sides and differentiating w.r.t. 𝑚 yields: 1 (1 −

𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝

𝑓 , 𝑡))

´ × −𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) = ln(1 − 𝜖).

Replacing 1 − 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) with (5.7) and rearranging, we get ´ (𝑚, 𝑝𝑓 , 𝑡) = −(1 − 𝜖)𝑚 ln(1 − 𝜖). 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟)

(5.8)

´ Note that 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) > 0. We again differentiate (5.8) w.r.t. 𝑚 to obtain ´´ 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) = −(1 − 𝜖)𝑚 (ln(1 − 𝜖))2 ´ ´ As second derivative of the reliability function 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) w.r.t. to 𝑚 is less than zero, 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) is a concave function of 𝑚. ´ ´ (𝑚, 𝑝𝑓 , 𝑡) is negative Note that 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) is not strictly concave as 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) for all values of 𝑚. Therefore, the graph of 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) – Fig. 5.3 – does not show an exponential decrease as 𝑚 increases.

164

5.5 The Safe Flooding Distance

5.5

The Safe Flooding Distance

The purpose of this section is to provide answer to another question raised in Chapter 4. We first reproduce this question and then proceed with the description of the proposed solution. Here it is: Q: At what distance a sink must be placed from a source node in-order to get it discovered with fairly high probability? We call it a safe flooding distance and define it as: Definition: Safe flooding distance is the distance to which a packet may be flooded under a given reliability constraint. Now to answer the above question, we follow a two step method. In the first method, we develop the reliability model of flooding itself and then use it to model the safe flooding distance.

5.5.1

Reliability model of information flooding

A typical flooding pattern is illustrated in Fig. 5.4. Node 𝑆 initiates the flooding process by broadcasting a packet to all its neighbors (nodes 𝐴, 𝑇 and 𝐾 in Fig. 5.4). The neighbors in turn broadcast the packet to their neighbors and the flooded packet continues to propagate in the network. Since flooding is a broadcast system, it suffers from the broadcast storm problem [123]. To avoid these storms, broadcast transmissions in an hoc network are best-effort and flooded packets are never acknowledged. We model a path from source 𝑆 to destination 𝐷 as a subsystem with routing components connected in series. For instance, a subsystem from 𝑆 to 𝐷 shown in Fig. 5.4 is modeled as a series combination of components 𝑇, 𝑈, 𝑉, . . . , 𝑍. In this model, the probability of packet loss is incorporated as the failure probability of the receiving component (i.e. receiving node). Using this model, the following lemma states a simple result to explain the reliability of the flooding process: Lemma 5.5.1 The packet delivery reliability of flooding in an ad hoc network approaches zero for asymptotically large flooding distance. Proof If we assume that each node, on average, is connected to 𝑑𝑎𝑣𝑔 neighbors, a pair would be connected at most through 𝑑𝑎𝑣𝑔 subsystems. 𝑑𝑎𝑣𝑔 subsystems are further categorized into optimal and suboptimal subsystems. Let 𝑁𝑜𝑝𝑡 , 𝑁1 , 𝑁2 , . . . , 𝑁 𝑛 be the

165


Figure 5.4: Flooding as a series system. number of optimal subsystems (i.e. optimal node-disjoint paths), 1-suboptimal subsystems, 2suboptimal subsystems and 𝑛-suboptimal subsystems respectively such that 𝑑𝑎𝑣𝑔 = 𝑁𝑜𝑝𝑡 +𝑁1 + 𝑁2 + ⋅ ⋅ ⋅ + 𝑁 𝑛. Since components of a subsystem form a minimal path set of the whole system, there are 𝑑𝑎𝑣𝑔 minimal path sets in this system and the system is functional if all components of at least one minimal path set are functional. For instance, in Fig. 5.4, if components 𝑇, 𝑈, 𝑉, . . . , 𝑍 are functional, the system is functional. Let ℎ − 1 be the number of components in an optimal subsystem. Then the reliability of the system 𝑟𝐹 (𝑝), using (5.1), is (𝑁𝑜𝑝𝑡 + 𝑁1 𝑝𝑠 + 𝑁2 𝑝2𝑠 + ⋅ ⋅ ⋅ + 𝑁𝑛 𝑝𝑛𝑠 ), 𝑅𝑓 𝑙𝑜𝑜𝑑 (𝑝𝑠 ) = 𝑝ℎ−1 𝑠

(5.9)

where 𝑝𝑠 is the reliability of a component. Recall that it actually is the broadcast forwarding probability defined in Chapter 4. Applying the limit ℎ → +∞, we obtain (𝑁𝑜𝑝𝑡 + 𝑁1 𝑝𝑠 + 𝑁2 𝑝2𝑠 + ⋅ ⋅ ⋅ + 𝑁𝑛 𝑝𝑛𝑠 ) = 0 𝑅𝑓 𝑙𝑜𝑜𝑑 (𝑝𝑠 ) = lim 𝑝ℎ−1 𝑠 ℎ→+∞

(5.10)

which proves the lemma. Equation (5.10) shows that as the number of hops ℎ → +∞, reliability of the overall system approaches zero. We, therefore, conclude that flooding (or any of its derivatives) is not scalable to large flooding distance. This result is in agreement to the outcomes of our routing overhead and route optimality models developed in the previous chapter. In the following subsection, we address the question raised at the start of this section.

166


5.5.2

The model of safe flooding distance

The reliability of flooding (5.9) can improve if we are able to control the topology of sensor networks in such a way that the distance between a pair of nodes should not increase beyond a threshold limit. We shall discuss the topology control mechanism once we revise the initial BeeSensor design. At this point, we are only interested in an answer to the question which may be rephrased as: what is the maximum flooding distance to which a packet can be delivered under the given reliability constraints? The following lemma provides a bound on the safe flooding distance in terms of optimal node-disjoint paths. Lemma 5.5.2 The safe flooding distance for a given minimum reliability 𝑅 in an ad hoc network is bounded by 1 ln(1 − (1 − 𝑅) 𝑁𝑜𝑝𝑡 ) , (5.11) ℎ≤ ln(𝑝𝑠 ) where 𝑁𝑜𝑝𝑡 is the number of optimal subsystems of ℎ components each and 𝑝𝑠 is the reliability of a component. Proof Since the present system has 𝑁𝑜𝑝𝑡 optimal subsystems of ℎ components each, we can rewrite (5.9) as

𝑁𝑜𝑝𝑡

𝑅=

∑

𝑝ℎ𝑠 .

(5.12)

𝑖=1

Equation (5.12) provides the desired reliability level through optimal subsystems. Without loss of generality, inclusion of suboptimal subsystems will only enhance 𝑅. Thus (5.12) can be expressed as 𝑅 = 1 − (1 − 𝑝ℎ𝑠 )𝑁𝑜𝑝𝑡 .

(5.13)

Simplifying and rearranging (5.13), we get 1

𝑝ℎ𝑠 = 1 − (1 − 𝑅) 𝑁𝑜𝑝𝑡 . Taking log on both sides and simplifying the resulting expression yields (5.11) which proves the lemma. We calculated the safe flooding distance using (5.11) for different values of 𝑅 and optimal subsystems 𝑁𝑜𝑝𝑡 by assuming 𝑝𝑟 = 0.97. Results are plotted in Figure 5.5. The bar graph demonstrates two important findings. First, if a packet need to be delivered with higher reliability level 𝑅, it can only be delivered to small flooding distance. This can also be verified

167

5.6 Reliability Analysis of Ad Hoc Routing Algorithms: An Application Perspective

Nopt=2

Nopt=4

Nopt = 5

Nopt = 6

0.8

0.9

Safe flooding distance (h)

12 10 8 6 4 2 0 0.5

0.6

0.7

1

R

Figure 5.5: Safe flooding distance at various reliabilities levels. intuitively. Second important point to note is that for lower values of 𝑁𝑜𝑝𝑡 , packet can be delivered to a larger distance with the same reliability level. This result can not be argued intuitively. The difference is more obvious at lower values of 𝑅. As the level of reliability gets higher, difference between the values of ℎ reduces until it almost gets to the same value of 𝑅 = 1. With these result, we conclude our discussions on the analysis of BeeSensor protocol. In the following section, we extend the reliability analysis presented in this section in the context of loss-and-delay sensitive applications.

5.6

Reliability Analysis of Ad Hoc Routing Algorithms: An Application Perspective

In this section, we analyze the packet delivery reliability of ad hoc routing protocols for loss-anddelay sensitive applications. The reliability analysis is based on the following two constraints: 1. The data packets must be routed reliably to the destination node with a lower delay. 2. Energy required for reliable delivery of packets must be kept to a low value. Retransmission of packets at the medium access control layer (MAC) is a common method used to achieve higher reliability. However, we ignore these retransmissions because they adversely affect Constraint 1.

168


As an alternative to retransmissions, we investigate the use of multiple simultaneous paths for delivering a data packet to its final destination i.e. routing a copy through more than one paths. We have already shown in Chapter 5 that RREQ-based ad hoc routing algorithms discover node-disjoint paths only. We also modeled the reliability function of node-disjoint paths. In this section, we model and compare the reliability of partially-disjoint paths [124] with that of node-disjoint paths. We show that a partially-disjoint path is more reliable and energy-efficient than a node-disjoint path. Hence, we argue that ad hoc routing protocols should discover and maintain a small set of partially-disjoint paths rather than the conventional nodedisjoint paths. Based on this outcome, we suggest modifications to a typical RREQ-based route discovery mechanism to discover partially-disjoint paths. Furthermore, to complement the reliability analysis, we compare the performance of the two variants of Dynamic Source Routing (DSR) protocol namely DSR-PD (where PD refers to partially-disjoint) and DSRFD (where FD refers to fully-disjoint) through extensive simulations. The empirical results demonstrate that DSR-PD performs extremely well than DSR-FD in all assumed scenarios which is completely in agreement with the theoretical findings of this section.

5.6.1

Improving packet delivery reliability using partially-disjoint paths

We propose to improve the reliability of a node-disjoint path by adding node or edge level redundancy. The resulting path is partially-disjoint – the concept of partially-disjoint paths already exists in ad hoc routing literature [124, 125]. We now provide a formal definition of partially-disjoint path in the following. Definition: Partially-disjoint paths are the paths between a pair with one or more overlapping nodes. A partially-disjoint path provides parallel links through which a packet can be forwarded to a next hop node. For instance, node 2 in Figure 5.6(b) can receive a copy of packet either from node 1 or node 3. Consequently, it is more reliable than a node-disjoint path shown in Figure 5.6(a). The reliability of a partially-disjoint path increases as more redundant links are added. To compare the reliabilities of node-disjoint and partially-disjoint paths, we consider two cases. In the first case, a pair of nodes, 𝑆 and 𝐷, is connected through 𝑚 + 1 node disjoint paths each with the minimum flooding distance 𝑡 – Figure 5.7(a). In the second case, the same pair of nodes are linked through 𝑚 partially-disjoint paths – Figure 5.7(b). Nodes labeled 𝑅 provide node/edge level redundancy. This leads us to the following lemma.

169


Figure 5.6: Example of a node-disjoint and a partially-disjoint path. Lemma 5.6.1 The reliability of 𝑚 partially-disjoint paths is higher than 𝑚 + 1 node-disjoint paths. Proof Recall that 𝑝𝑓 is the packet forwarding probability on a link. Then, the reliability of 𝑚 + 1 node-disjoint paths, may be written as 𝑅𝑁 𝐷 (𝑚, 𝑝𝑓 , 𝑡) = 1 − (1 − 𝜖)𝑚+1 ,

(5.14)

where 𝜖 = 𝑝𝑡𝑓 . To model the reliability of 𝑚 partially-disjoint paths, we first find the reliability of a single partially-disjoint path and then combine the reliabilities of 𝑚 paths. Now, the reliability of a partially-disjoint path of 𝑡 hops long 𝑟𝑝𝑑 (𝑚, 𝑝𝑓 , 𝑡) is given by 𝑟𝑝𝑑 (𝑚, 𝑝𝑓 , 𝑡) = 𝛽𝜖,

(5.15)

where 𝛽 = 𝑡(1 − 𝑝𝑓 ) + 1 which is always greater than 1. Now the overall reliability of 𝑚 partially-disjoint paths using (5.6) provided in Chapter 5) and (5.15) is 𝑅𝑃 𝐷 (𝑚, 𝑝𝑓 , 𝑡) = 1 − (1 − 𝛽𝜖)𝑚 .

(5.16)

Comparing (5.14) and (5.16), we observe that 𝜖 ≤ 𝛽𝜖 (where 0 ≤ 𝜖, 𝛽𝜖 ≤ 1) because 𝛽 > 1. This leads to (1 − 𝜖)𝑚 ≥ (1 − 𝛽𝜖)𝑚 . Thus we can write (1 − 𝜖)𝑚+1 ≥ (1 − 𝛽𝜖)𝑚

170


R 1 1

2 R S

L1

3

L2

L3

Lt

S

D

L1

3

L2

L3

Lt

D

R M+1 M

(a) 𝑚 + 1 node-disjoint 𝑆 → 𝐷 paths

(b) 𝑚 partially-disjoint 𝑆 → 𝐷 paths

Figure 5.7: A pair of nodes, separated by flooding distance 𝑡, linked through a set of nodedisjoint / partially-disjoint paths. since (1 − 𝜖)𝑚+1 = (1 − 𝜖)𝑚 − 𝜖(1 − 𝜖)𝑚 and the difference between (1 − 𝜖)𝑚 and (1 − 𝛽𝜖)𝑚 approximately equals 𝑚𝜖(𝛽 − 1) which is greater than 𝜖(1 − 𝜖)𝑚 . Hence, 𝑅𝑃 𝐷 (𝑚, 𝑝𝑓 , 𝑡) ≥ 𝑅𝑁 𝐷 (𝑚, 𝑝𝑓 , 𝑡)

(5.17)

which proves the lemma. Lemma 5.6.1 clearly leads to the conclusion that partially-disjoint paths are more reliable thereby providing a viable alternative to node-disjoint paths. We present a detailed discussion on the practical aspects of this finding in the following subsection.

5.6.2

Discussion

To elaborate the reliabilities achieved by a set of node-disjoint paths and partially-disjoint paths, we plot (5.14) and (5.16) for different combinations of packet forwarding probabilities 𝑝𝑓 and flooding distance 𝑡. The results are shown in Figure 5.8. The reliability curves lead to two important results. First, for the same number of paths 𝑚, reliability of partially disjoint paths is significantly higher than that of node-disjoint paths. Consequently, reliability curve of partially-disjoint paths saturates with few number of paths. Second, Figure 5.8(b) shows that, for longer paths, partially-disjoint paths attain higher reliability than node-disjoint paths. Therefore, partially-disjoint paths scale better with an increase in the flooding distance.

171


1.2

1 1

Reliability, R

Reliability, R

0.8 0.8 0.6 0.4 NodeŦdisjoint, pf=0.9, t=8 PartiallyŦdisjoint, pf=0.9, t=8

0.2

0.6

0.4 NodeŦdisjoint, pf=0.9, t=16 PartiallyŦdisjoint, pf=0.9, t=16

0.2

0

0 0

5

10

15

0

20

5

10

15

20

Number of paths (m)

Number of paths (m) (a) Reliability curves at 𝑝𝑓 = 0.9, 𝑡 = 8.

(b) Reliability curves at 𝑝𝑓 = 0.9, 𝑡 = 16.

Figure 5.8: Reliability comparison of node-disjoint and partially-disjoint paths. In the next phase, we compute the total number of transmissions required to deliver a packet to its final destination at a desired reliability level. Results shown in Table 5.1 compare the number of paths and the corresponding transmissions required for both types of paths. It is interesting to note that a single partially-disjoint path can deliver a packet with higher reliability and lower number of transmissions. For longer paths, the number of transmissions required in case of node-disjoint paths is substantially higher than that of partially-disjoint paths. For instance, for 𝑝𝑓 = 0.9 and 𝑡 = 8, transmissions required to deliver a packet with reliability of 0.99 are almost 2.5 times higher than that of node-disjoint paths. Therefore, we conclude that partially-disjoint paths are more reliable, scalable and energy efficient than nodedisjoint paths. Consequently, even in case of conventional routing schemes – single path routing relying on MAC / transport layer for higher reliability – use of partially-disjoint paths can be instrumental in improving a protocol performance over a large operational landscape. Since flooding-based route discovery mechanism is only able to find node-disjoint paths, in the next section, we suggest modifications to this method to discover partially-disjoint paths.

5.6.3

Discovering partially-disjoint paths in ad hoc routing protocols

In a typical on-demand route discovery mechanism, a source node broadcasts a route request (RREQ) message to all its neighbors. The receiving nodes forward (i.e. broadcast) the first copy of RREQ to their neighbors and the process continues. Nodes may receive multiple copies of RREQ as every one of their neighbors is expected to broadcast at-least (as well as at-most)

172


Table 5.1: Total transmissions required to route a packet at a desired reliability level Values of 𝑝𝑓 and 𝑡

𝑝𝑓 = 0.9, 𝑡 = 8

𝑝𝑓 = 0.9, 𝑡 = 16

Node-disjoint paths No. of paths Reliability Transmissions (m) 𝑅𝑁𝐷 (𝑚 × 𝑡) 2 0.73 16 4 0.93 32 8 0.995 64 2 0.37 32 10 0.9 176 20 0.99 320

Partially-disjoint paths No. of paths Reliability Transmissions (m) 𝑅𝑃 𝐷 (𝑚 × (𝑡 + 2)) 1 0.78 10 2 0.95 20 4 0.997 40 1 0.48 18 4 0.93 72 7 0.99 126

once. However, nodes do not broadcast duplicate RREQs and simply discard them. Therefore, intermediate nodes only maintain a single reverse link entry in their routing table/RREQ cache. When this RREQ reaches the destination or a node with a valid route, a route reply (RREP) is returned back to the source node along the reverse links. We now describe modifications to this process to realize partially-disjoint paths. 5.6.3.1

Modifications to route request (RREQ)

To discover partially-disjoint paths, an ad hoc routing protocol needs to keep a record of three additional parameters at intermediate nodes: (1) number of RREQs received by a node with minimum hop count Drreq, (2) terminal node, and (3) minimum hop count mhops. Terminal node refers to a node located at two hops from the current node. For instance, in Figure 5.6(b), node 𝑆 is the terminal node for node 2. This information is contained within a RREQ. When an intermediate node 𝑖 receives a unique RREQ from node 𝑗, identified by the pair, it updates the RREQ cache as before. Additionally, Drreq (duplicate RREQs) is initialized to zero and mhops field is set to the hops carried by the RREQ after incrementing it by one. Finally, terminal node entry in RREQ cache is set to node 𝑗. After updating the cache, node 𝑖 inserts node 𝑗 in the RREQ (it will be a terminal node for the receiving node) and broadcasts it to its neighbors. If node 𝑖 receives a duplicate RREQ, it compares the number of hops traveled by the new RREQ with the one available in its cache. If the hops traveled by new RREQ is less than the current value, node 𝑖 replaces the old cache information with the new one with Drreq field reset to 0. If both values are equal, node 𝑖 only increments the Drreq field and discards the RREQ. If the number of hops traveled by the new RREQ is higher, the new RREQ is discarded without any further processing.

173


5.6.3.2

Modifications to route reply (RREP)

Let the reverse link entry maintained at an intermediate node be termed as PrevHop. A RREP packet, in addition to a next hop field, contains a terminal node field and an adjacent node fields. The terminal node normally contains 0 or valid node ID. When a node receives a RREP packet, it checks the value of Drreq field in its cache. If Drreq is greater than zero, terminal node field in the RREP is set to the entry maintained in cache, adjacent node entry is set to PrevHop and next hop is set to the broadcast address. After updating the routing table, the node broadcasts the RREP. If DRreq is zero, next hop, adjacent node and terminal node field are all set to PrevHop. The node then unicasts the RREP to the next hop after updating its routing table. When neighbors receive the broadcast RREP, they are bound to forward this RREP to the terminal node after updating their local routing table. Terminal node may receive more than one replies but it only maintains two forward links, one to the adjacent node and the other to a randomly selected node. Once the terminal node detects that it has discovered a redundant node on the path, it may stop further redundant node discoveries on the path by setting terminal node entry in the RREP to a negative value before forwarding it to its PrevHop. Figure 5.9 provides a pictorial representation of the modified route discovery process. Here node 3 receives two RREQs, from node 2 and node 5, and rebroadcasts the RREQ received earlier. Next duplicate RREQ increments the Drreq field. When node 4 forwards a reply back to node 3, it sets node 1 – assuming that node 3 forwarded the RREQ received from node 2 – as the terminal node and node 2 as adjacent node and broadcasts the RREP. When node 5 receives this reply, it updates its routing table and unicasts the reply to node 1 and so does node 2. We can improve this mechanism even further to add more redundancy at the node level by setting up a counter in the RREP field which may be decremented once a redundant node is discovered. In the following section, we use this technique for the discovery of partially-disjoint paths in DSR protocol and compare its performance with a protocol that uses node-disjoint paths.

5.6.4

Empirical validation of the reliability models

Theoretical models are generally based on some simplifying assumptions. Therefore, it is compulsory to support the outcome of this analysis through simulation studies. We used NS-2 simulator for this purpose. The major objective of this empirical study is to show that a protocol using partially disjoint paths is more reliable, energy efficient and suitable for time-critical

174


Destination

D

S RREQs launched by S

RREQ received at D S 1 2 3 4 Other fields Source routing header

4 5 1 3 2

6

Figure 5.9: An illustration of flooding-based route discovery in ad hoc networks to discover node-disjoint paths. Solid lines show the links which shall be discovered while red-and-dashed lines represents undiscovered links. A RREQ received at 𝐷 with the source routing header (as in DSR) is also shown to further elaborate the process. applications. In this context, we selected a prominent MANET routing protocol, DSR, and developed two different variants of this protocol. In the first variant, we modified the code of DSR so that it discovers and maintains a set of node-disjoint paths. In addition to this, during the data transmission phase, it routes a copy of packet along each path. We call it DSR-FD where FD stands for fully disjoint. In the second case, we modified the route discovery process of DSR - as described in Section 5.6.1 - so that it discovers multiple partially disjoint paths. We then modified its routing functionality - like DSR-FD - such that a copy of data packet is sent along each partially-disjoint path. We call it DSR-PD where PD stands for partially-disjoint. We assume that underlying medium access control (MAC) layer does not provide any reliability guarantees. It is simply a best-effort MAC protocol. To simulate this functionality, we modified the code of 802.11 MAC layer available in NS-2 simulator. We disabled RTS/CTS and Data/ACK mechanisms. Consequently, the data packets are never retransmitted at the MAC layer. In all our experiments, we assume that the nodes are deployed randomly in an area of 1500m × 300m. The transmission range of each node is set to 250𝑚 while the size of each data packet is 512 bytes. The movement pattern is characterized by random waypoint mobility model in which every node moves to a random destination with a given speed. After reaching

175


the destination, it stops there for 50 seconds and then moves to a next random location. We do not use TCP sources primarily because it modifies the network conditions - packet sending rate for instance - under different network conditions preventing a direct comparison of the protocols [2]. UDP provides a fair environment in which candidate protocols can be evaluated under identical network conditions. We used CBR traffic model in which sources generate packets at the prescribed rate. Our empirical analysis is based on three evaluation metrics; packet delivery ratio, latency and average used energy. We collect the values of these metrics in four different experiments. The details of simulation parameters used in each case are listed in Table 5.2. Each experiment is performed for a duration of 500 seconds and the reported values are an average of 10 independent runs. We now provide formal definitions of the evaluation metrics - in the following subsection - before switching to the description of simulation results. Table 5.2: Simulation parameters Experiment No.

Variable parameter

Speed (m/s)

1

Speed

0 - 20

2

2

100

2

No. flows

10

2-8

2

100

3

Network size

10

2

2

50 - 200

4

Packet sending rate

10

2

2-8

100

5.6.4.1

Parameter values No. of flows Pkt sending rate

Network size

Definitions of the evaluation metrics

Latency. It is defined as the difference between the time of reception of a packet at a destination node and the time of generation of the packet at the source node. We report the average value of all packet latencies. Packet delivery ratio. We define it as the ratio of the total number of packets received at all destinations to the number of packets generated at all the source nodes. Average used energy. It refers to the amount of energy consumed in successful delivery of a data packet to its final destination. We report it in Joules/packet. 5.6.4.2

Discussion on results


176


DSRŦFD

DSRŦPD

DSRŦFD

80 60 40 20 0

80 60 40 20 0

0

5

10

15

20

2

4

Speed (m/s)

DSRŦFD

6

8

No. of flows

(a) Packet delivery ratio Vs. speed (m/s)

(b) Packet delivery ratio Vs. No. of flows

DSRŦPD

DSRŦFD

DSRŦPD

2

4

100

Packet delivery ratio (%)

100


DSRŦPD

100



100

80 60 40 20 0

80 60 40 20 0

50

100

150

200

Network size

6

8

Packet sending rate

(c) Packet delivery ratio Vs. network size

(d) Packet delivery ratio Vs. packet sending rate

Figure 5.10: Packet delivery ratios of DSR-PD and DSR-FD against speed, no. of flows, network size and packet sending rate. Packet delivery ratios of the two protocols in each of the four experiments are shown in Figure 5.10. The results clearly show that DSR-PD performs much better than DSR-FD in all the assumed scenarios. Figure 5.10(a) shows that, in case of static network, packet delivery ratio of DSR-PD is close to the maximum possible value. However, DSR-FD has significantly smaller packet delivery ratio even in the simplest scenario. As the speed goes higher, performance of both the protocols degrades which is expected as the network topology changes rapidly. Figure 5.10(b) and Figure 5.10(d) shows the performance of DSR-PD under high traffic loads. As the number of flows rises, the performance of DSR-PD degrades which primarily is due to an increase in the number collisions in the network. Recall that we do not allow

177


retransmissions at the MAC layer which ultimately results in the packet loss. In all these experiments, the number of paths maintained by a source in DSR-FD - on average - is four. However, source nodes in DSR-PD only maintain two paths and achieve reliability through redundant edges on a path. Therefore, we can improve the reliability of DSR-PD by replicating more than one edges on a path. We did not demonstrate it here in-order to remain consistent with our theoretical study. Another important observation is decrease in the packet delivery ratio with an increase in the network size (Figure 5.10(c)). An increase in the network size leads to an increase in the node density i.e. higher average node degree 𝑑𝑎𝑣𝑔 . This ultimately leads to more collisions and packet loss. Packet latency Latencies of both the protocols in different sets of experiments are shown in Figure 5.11. The results are extremely convincing in which DSR-PD simply outperforms DSR-FD in all the cases. As the node speed rises, the latencies of both the protocols increase as well. Under high traffic loads, Figure 5.11(b), contention at the MAC layer increases thereby resulting in higher packet latency. A similar argument holds for the results shown in Figure 5.11(c). It is however interesting to note that with an initial increase in the packet sending rate, latencies of both the protocols drop sharply and then flatten. This is rather unusual behavior and needs some explanation. With higher packet sending rate, the route breaks are detected more rapidly resulting in quick rediscovery of the fresh paths. This argument is also supported by the results shown in Figure 5.10(d) in which packet delivery ratio does not fall sharply as the packet sending rate is increased. However, the effect is more obvious in the early stage which then decays when the packet sending rate reaches a certain threshold value. Average used energy Average used energy for the two protocols is shown in Figure 5.12. The trend is identical to the results shown earlier. Remember that average used energy depends upon two parameters. First, it depends upon the number of packets delivered successfully. Second, it also depends upon the total energy consumed by a protocol. As DSR-PD has higher packet delivery ratio in all assumed scenarios, it also results in less amount of average used energy. We also argued earlier that DSR-FD maintains a rather bigger set of node-disjoint paths leading to high energy consumption. In addition to this, lower packet delivery ratio of DSR-FD may also lead to the

178


DSRŦFD

DSRŦPD

DSRŦFD

DSRŦPD

8000 14000

7000

12000

Latency(ms)

Latency(ms)

6000 5000 4000 3000

10000 8000 6000

2000

4000

1000

2000

0

0 0

5

10

15

20

2

4

Speed (m/s)

(a) Packet latency Vs. speed (m/s) DSRŦFD

6

8

No. of flows

(b) Packet latency Vs. No. of flows

DSRŦPD

DSRŦFD

DSRŦPD

2

4

5000 14000 4000

Latency(ms)

Latency(ms)

12000 10000 8000 6000

3000 2000

4000 1000 2000 0

0 50

100

150

200

Network size

6

8

Packet sending rate

(c) Packet latency Vs. network size

(d) Packet latency Vs. packet sending rate

Figure 5.11: Packet latencies of DSR-PD and DSR-FD against speed, no. of flows, network size and packet sending rate. activation of repeated route discovery procedures. Consequently, it fails to perform well in this metric as well. In this section and the preceding sections, we identified and evaluated mechanisms to achieve higher packet delivery reliabilities in a homogeneous ad hoc network. However, many ad hoc deployment scenarios are heterogeneous containing nodes with high energy, range and processing capabilities. For instance, vehicular ad hoc networks will be deployed with regularly-spaced info-stations. Most sensor network deployments employ beacon nodes which have higher transmission ranges and energies. In the following section, we analyze the reliability of such a beacon-based ad hoc routing.

179

5.7 Conclusions

DSRŦPD

DSRŦFD

Averaged used energy (J/Pkt)


DSRŦFD 5 4 3 2 1 0 0

5

10

15

12 10 8 6 4 2 0

20

2

4

Speed (m/s)



DSRŦPD

8 6 4 2 0 100

150

8

(b) Average used energy Vs. No. of flows

10

50

6

No. of flows

(a) Average used energy Vs. speed (m/s) DSRŦFD

DSRŦPD

14

200

Network size

DSRŦFD

DSRŦPD

2

4

5 4 3 2 1 0 6

8

Packet sending rate

(c) Average used energy Vs. network size

(d) Average used energy Vs. packet sending rate

Figure 5.12: Average used energy of DSR-PD and DSR-FD against speed, no. of flows, network size and packet sending rate. This concludes our discussion on the reliability theoretic analysis of ad hoc routing algorithms.

5.7

Conclusions

Reliability theory provides an elegant and simple framework to analyze the reliability of ad hoc routing protocols. To illustrate the concept, in this chapter, we modeled the reliability of BeeSensor protocol in terms of packet delivery. The model demonstrates that the packet delivery reliability of BeeSensor varies exponentially with an initial set of paths after which the curve flattens. Consequently, maintenance of a large set of paths does not result in a propor-

180

5.7 Conclusions

tional dividend in terms of packet delivery reliability. Therefore, to reduce the maintenance overhead, a smaller set of the available paths is preferable. We also analyzed the use of reliability of ad hoc routing protocols in the context of loss-anddelay sensitive applications. We have shown that partially-disjoint paths are more reliable and energy-efficient as compared to node-disjoint paths. We have also complemented our theoretical findings through simulations. In the next chapter, we improve the design of BeeSensor protocol using the insights inferred through the mathematical modeling process described in Chapter 4 and the current chapter. We shall conclude this dissertation by extensive empirical analysis of the final BeeSensor design over a large operational landscape.

181

Chapter 6

Design Review and Performance Analysis of BeeSensor 6.1

Introduction

Formal modeling process described in the previous two chapters has unleashed several important insights. For instance, even blind flooding protocol e.g. AODV can not guarantee the discovery of a route between a pair of nodes separated by arbitrarily large number of hops. Furthermore, stochastic flooding protocols, although generate less overhead, have low route discovery probability. These insights are extremely beneficial and can be instrumental in the design of any ad hoc routing algorithm. To this end, we utilize these insights and review the design of BeeSensor protocol to rectify its shortcomings. Now, at this point, it is important to note that few attempts have been made to model the performance of WSN protocols [27, 33]. However, to the best of knowledge, none of these works use the feedback of these models for design improvement which proves the novelty of our work. In this chapter, we do the following. ✓ We first utilize the insights of the formal modeling process and make design changes to the initial BeeSensor design presented in Chapter 3. We also answer the third question raised in Chapter 4 and that is: How can we keep a sink node equi-distant from all the sensor nodes? ✓ we then present the results of our extensive simulations to illustrate the performance of BeeSensor both in static as well as mobile networks. We compare it with several ad hoc

182

6.2 Modifications to BeeSensor Design

routing algorithms. The results of our simulations clearly show that BeeSensor meets its intended objectives.

6.1.1


The rest of the chapter is organized as follows. The initial design of BeeSensor is revised in Section 6.2. Performance evaluation of the final BeeSensor protocol is presented in Section 6.3. The key conclusions of the chapter are listed in Section 6.4.

6.2

Modifications to BeeSensor Design

Based on the theoretical analysis of BeeSensor protocol, we made modifications to the original design explained in Chapter 3. We discuss all these modifications one-by-one in the following subsections.

6.2.1

Aggregation and Suppression of Multiple Scouting

One important consideration in BeeSensor is to reduce the route discovery overhead to make it energy efficient. This objective is achieved by restricting the nodes beyond 𝐻𝑙 hops from the source node to rebroadcast forward scouts with probability 𝑝𝑏 . However, the route optimality models of BeeSensor demonstrate that very low value of 𝑝𝑏 could result in low probability of route discovery. Therefore, we have to devise some alternate way of reducing the routing overhead. This will allow us to keep the value of 𝑝𝑏 to a reasonably higher value in-order to boost the expected route discovery probability of BeeSensor. To illustrate the key concept used here, assume that a source node 𝑆 has detected an event and initiated the forward scouting process. Now, it is highly likely that the neighbors of 𝑆 will also detect this event and start the scouting process. For instance, consider a renowned WSN application of tracking a moving target. If node 𝑆 has detected some target, it is quite likely that the target will be soon in the range of a neighboring node that would cause it to generate an identical event as well. Another example application might be the one in which sensor nodes are deployed to detect fire in a forest. Sensor nodes, in this case, will generate an event as soon as they detect that their ambient temperature has exceeded a certain threshold limit. The event is likely to be detected by multiple nodes resulting in simultaneous multiple scouting processes.

183


These scenarios suggest that we can stop parallel scouting processes for the same event to conserve energy. This will not only minimize the number of transmissions in the scouting process but also allow the aggregation of identical events thereby reducing the in-network traffic. Therefore, we make the following changes to the scouting process. ✓ Source nodes, on detection of an event, wait for a random amount of time before initiating the forward scouting process. If a node does not hear any forward scout during the wait period, it broadcasts a forward scout. ✓ When a source node 𝑆 has started the forward scouting, its immediate neighbors do not initiate the process. Rather, they rely on node 𝑆 to carry their events to a sink node. Like source node 𝑆, events detected by its neighbors during the route discovery are stored in an event cache. ✓ Once a backward scout returns to node 𝑆, it updates its routing table and broadcasts a special beacon to inform its neighbors that it has successfully discovered a route for a global sink interested in the events. The beacon also contains the current energy level of the source. The neighboring nodes consider node 𝑆 as the sink node for this event and communicate the events to 𝑆. ✓ If a neighboring node receives beacons from multiple sources, it selects the one with the highest remaining energy level. The elimination of parallel scouting helps in three ways: 1. It reduces the communication overhead involved in doing multiple scouting that helps in quick convergence of the protocol. 2. It reduces the memory required to store scout cache entries as well as forwarding table entries 3. The application layer at node 𝑆 can process and aggregate the events received from the neighbors. This further reduces the number of transmitted foragers, which in turn saves substantial energy.

184


6.2.2

A hierarchical network architecture

We have shown analytically in Section 5.5 that a packet may be flooded to a safe flooding distance given by equation (5.11) under the desired reliability constraints. Clearly, this also means that none of the nodes in the whole sensing field should be located beyond this hop limit. Now here is the third question raised in Chapter 4 that needs to be resolved now. Q: How can we keep a sink node equi-distant from all the sensor nodes? The answer essentially leads to a multi-sink architecture. Therefore, we advocate the use of long-haul nodes. The idea of long-haul nodes already exists in the literature [126, 127]. In this context, we propose a hierarchical sensor network – or multi-sink architecture – in which sensor nodes lie at the bottom of the hierarchy as shown in Fig. 6.1. The role of sensor node is now to sense and communicate the events to a nearby long-haul node, lying at the middle of the hierarchical network architecture, which then sends them to an access point. The long-haul nodes are resource sufficient nodes and capable of communicating directly with an access point – which is a part of the backbone network – at different signal frequencies. We make the following changes to the scouting process described in Chapter 3 to incorporate the new hierarchical network architecture. ✓ Source node, on detection of an event, do not need to flood the forward scouts in the entire network. Rather, the events need to be communicated to a nearby long-haul node; as a result, search space must be limited. We make use of ring search for this purpose. ✓ On detection of an event, the source node floods a forward scout with a specific initial ring size 𝑅𝑠 keeping in view of the restrictions mentioned in Section 6.2.1. If a backward scout is not received from a long-haul node within a certain time period, the 𝑅𝑠 is incremented and a new generation of forward scouts is launched. Once a backward scout is received from a long-haul node, 𝑅𝑠 is set to the value at which the scouting was successful and this value is used in future scoutings. ✓ The intermediate nodes may estimate the distance to a nearby long-haul node by overhearing the network traffic. Finally, we also point out that a source node may receive response from more than one long-haul nodes. In this case, it will select the one located at least number of hops. If both are located at the same number of hops, a random selection is made.

185


Backbone

Figure 6.1: An hierarchical sensor network equipped with long-haul nodes Apart from reducing the number of transmissions in the network, the suppression of multiple scoutings and hierarchical network design also reduces the memory requirements to maintain forwarding tables or scout cache entries at intermediate nodes because of the following reasons: 1. For a given pair, a sensor node can become part of a single route only. As we reduce the number of distinct pairs by suppressing parallel scouting process, the number of entries are reduced accordingly. 2. Due to hierarchical network architecture, the scope of forward scouts is reduced. For instance, if a source in region 𝐴 launches a forward scout, it will not be received by nodes in region 𝐶 (see Fig. 6.1). Therefore, memory requirements at a sensor node to maintain these entries are significantly reduced.

6.2.3

Fewer node-disjoint paths

Recall that in Chapter 3, we described that BeeSensor maintains all the paths discovered in the scouting process. However, the reliability analysis of BeeSensor does not favor this option as stated in Section 5.4.1. The reliability function – equation (5.6) – is concave with respect to the number of paths 𝑚. Therefore, maintenance of paths beyond a certain threshold limit does

186

6.3 Empirical Evaluation of BeeSensor

not add anything to the reliability level. Therefore, to reduce the overhead, we only discover a subset of the total available path. This set is selected on the basis of the metrics introduced in Chapter 3. This concludes the design revision process. We now describe the empirical evaluation of the final BeeSensor design and compare its performance with several Bio-inspired as well as classical ad hoc routing protocols both in static as well as mobile networks.

6.3

Empirical Evaluation of BeeSensor

The purpose of this section is to show the impact of different design changes proposed in Section 6.2 on the performance of BeeSensor protocol. We divide the empirical evaluation process into three subsections. In the first part of this analysis, we compared the performance of BeeSensor protocol – using Prowler simulator [87] – with the two energy-efficient variant of AntNet protocol proposed in [16]; SC-Ant and FF-Ant. Prowler does not offer the facility of simulating mobile networks / nodes with distinct hardware capabilities. Therefore, we had to choose some alternate simulator. NS-2 is not only the most popular and widely used simulator in the ad hoc networking community but also offers features for in-depth evaluation of the network protocols. Due to its wide spread use, it has now become a de-facto simulator for network simulations. Therefore, we implemented the final design of BeeSensor protocol in NS-2 simulator. We then performed three distinct set of experiments. In the first set of experiment, we evaluated and compared the performance of BeeSensor protocol with classical ad hoc routing protocols AODV and DSDV in static large scale sensor networks. In the second series of experiments, we illustrated the impact of using long-haul nodes on the performance of BeeSensor protocol. We report the results of these experiments in the second subsection. Finally, we also evaluate the performance of BeeSensor protocol in mobile ad hoc networks. In this context, we compared the performance of BeeSensor with three prominent ad hoc routing protocol; AODV, DSR and DSDV. The final subsection contains the discussion on these results. Before we move on to our first set of experiments, we would like to mention here that the metrics used in each set of experiments are defined in their relevant sections with details of the simulation parameters.

187


6.3.1

Comparison of BeeSensor with SC-Ant and FF-Ant

The purpose of experiments reported in this section is to illustrate the impact of enhancements made to the BeeSensor design. As discussed earlier, the results reported here are obtained using the prowler simulator. We explained in Chapter 3 that Routing Modeling Application Simulation Environment (RMASE) [88] is a framework implemented as an application in Prowler. RMASE, by default, collects some fundamental metrics like packet delivery ratio, energy consumption etc. We enhanced the built-in performance model of RMASE to collect several additional metrics. Using the metrics, we compared the performance of enhanced BeeSensor with two ant-based energy efficient protocols, SC-Ant and FF-Ant [16], in large network topologies. We did not include EEABR, AODV and FP-Ant because BeeSensor has consistently outperformed them in similar scenarios. For all these experiments, we used a typical converge-cast scenario in which multiple sources communicate with a single sink node. However, the converge-cast scenario used in these experiments is slightly different to the one used in Section 3.6. In this case, we assumed a circle of smaller radius and increased the number of nodes acting as event sources within the circle. The reason for using small circular region is to demonstrate the impact of elimination of parallel scouting in the revised BeeSensor if the event sources are neighbors of one another. Moreover, in this scenario, we evaluate the performance of protocols under high traffic loads. In this set of experiments, we used five different network topologies containing 49, 100, 150, 196, and 256 sensor nodes. Transmission radius is set to 35m while initial energy levels of the nodes is set to 20 joules. In each one of these experiments, we assumed symmetric links and nodes are deployed randomly in the sensing field. Each experiment is performed for a duration of 300 seconds and the reported values are an average of five independent runs. The comparison is based on five metrics: packet delivery ratio, latency, energy efficiency, control overhead, network lifetime and minimum remaining energy. The definitions of the first five metrics are provided in Chapter 3 Section 3.6. Therefore, we do not reproduce them here. We only provide the definition of the last metric. Minimum remaining energy. It is the lowest energy level of a node in the network at the end of an experiment. We report it in %. 6.3.1.1



188


FFŦAnt

SCŦAnt

BeeSensor


100 90 80 70 60 50 40 30 20 10 0 49

100

150

196

256

Number of nodes Figure 6.2: Packet delivery ratio The packet delivery ratios of BeeSensor, SC-Ant and FF-Ant are shown in Fig. 6.2. BeeSensor consistently outperforms FF-Ant and SC-Ant in terms of the packet delivery ratio. The poor packet delivery ratio of ant-based protocols is primarily due to the fact that they take large amount of time to converge to stable routes even in this simple scenario. SC-Ant, due to its unicast feature, takes longer time to converge and loses too many events in the process. Moveover, FF-Ant and SC-Ant adaptively decrease the launching interval of forward ants if they are unable to find stable routes. This leads to a situation in which the backward ants are lost due to collisions, and as a result, the algorithms do not even discover a single path. This results in further increase in the launching frequency of forward ants until the network is saturated. This explains 60% packet loss of FF-Ant and SC-Ant. Latency The latencies of the protocols are shown in Fig. 6.3. BeeSensor has a better latency compared with other protocols mainly due to two reasons: (1) a simple reward function and (2) exchange of the routing information among different replicas of a forward scout. As a result, the algorithm discovers shorter path length routes. Note that the latency of SC-Ant is more than that of FFAnt especially when the size of network gets bigger. This is expected because of the unicast nature of the forward ants. These ants are unable to discover short path length routes even though they are equipped with the direction sensors. This results in higher latency values.

189


FFŦAnt

SCŦAnt

BeeSensor

0.5

Latency (sec)

0.4 0.3 0.2 0.1 0 49

100

150

196

256

Number of nodes Figure 6.3: Latency It is important to emphasize that the latency of FF-Ant remains almost unaffected by the network size because of its flooding process. Remember that FF-Ant performs pure stochastic flooding of forward ants and therefore it has a low probability of discovering optimal routes (Chapter 4). Consequently, the routes carrying most of the traffic in FF-Ant are suboptimal resulting in a higher latency. Energy efficiency The energy efficiency of the protocols is plotted in Fig. 6.4. The results clearly demonstrate that BeeSensor simply outperforms its competitors in terms of energy efficiency. An interesting point to note is that better energy efficiency of BeeSensor did not result in poor performance. It is worth mentioning here that we made two enhancements to the design of BeeSensor reported in [92]. First, we increased the value of the probability 𝑝𝑏 to broadcast forward scouts for nodes located beyond 𝐻𝑙 hops as suggested by the route optimality model developed in (Chapter 4). But, an increase in 𝑝𝑏 also results in higher control overhead and energy consumption. We, therefore, utilized the option of suppressing multiple scouting that appear to have boosted the energy efficiency of BeeSensor without effecting route optimality.

As expected, FF-Ant

has the worst energy efficiency because it periodically floods the forward ants that lead to high energy consumption. On the other hand, its packet delivery ratio is only marginally better than

190


FFŦAnt

SCŦAnt

BeeSensor

0.5

Joules/Kbits

0.4 0.3 0.2 0.1

49

100

150

196

256

Number of nodes Figure 6.4: Energy efficiency FFŦAnt

SCŦAnt

BeeSensor

Control bits/Kbits

52100 14600 6200 2600 1100 400 100

49

100

150

196

256

Number of nodes Figure 6.5: Control overhead SC-Ant. Note that SC-Ant has better energy efficiency, especially in large networks, compared with FF-Ant due to its unicast forwarding policy for ants. Control overhead The control overhead of all protocols is shown in Fig. 6.5. BeeSensor has the smallest control

191


FFŦAnt

SCŦAnt

BeeSensor

100 90

Lifetime (%)

80 70 60 50 40 30 20 10 0 49

100

150

196

256

Number of nodes Figure 6.6: Network lifetime overhead because of stochastic flooding and suppression of parallel scouting (see previous subsection). The control overhead of SC-Ant is smaller (note that the y-axis is on the logarithmic scale) than FF-Ant due to unicast forwarding policy which also improves its energy efficiency as discussed before. FF-Ant launches forward ants in a pro-active manner that is responsible for its highest control overhead. Network lifetime The network lifetime of the three protocols is shown in Fig. 6.6. The lifetime achieved by BeeSensor is better than rest of the protocols. In a given network, pair is usually connected through multiple paths. Recall BeeSensor prefers a path with a better remaining energy level between two paths of equal lengths. As a result, the paths with higher energy levels carry more traffic that extends the network lifetime. FF-Ant has relatively better network lifetime than SC-Ant because of its flooding policy for ants. Recall that SC-Ant unicasts the forward ants through the least cost path that results in routing most of the traffic on the shortest path. This subsequently leads to fast depletion of energy levels (see Fig. 6.7) of the shortest path nodes; hence the higher deviation in the remaining energy levels of the nodes. This is the main reason for smallest network lifetime for SC-Ant.

192


Min. Remaining Energy (%)

FFŦAnt

SCŦAnt

BeeSensor

90 80 70 60 50 40 30 20 10 0 49

100

150

196

256

Number of nodes Figure 6.7: Minimum remaining energy

6.3.2

Performance analysis of BeeSensor on large-scale sensor networks

NS-2 is the most popular and reliable software tool for network simulations. It was originally developed by Virtual Inter Network Testbed (VINT) project group at Lawrence Berkeley National Laboratory (LBNL) in collaboration with USC/ISI, Xerox PARC and University of California Berkeley. Although under constant upgradation process, NS-2 has gained extreme confidence of the networking community partly because its freely available on the web and has a huge user community. Therefore, extensive on-line technical support is available in the form of documentation, mailing list and free implementations of several network protocols. NS-3, third generation of NS, has also been released recently. Since the introduction of wireless extensions to NS-2 simulator in 1999, it has become a de-facto standard simulator for wireless ad hoc networks. There are several ad hoc routing protocols available in the repository of NS-2 e.g. AODV, DSR, DSDV, OLSR etc. Consequently, it provides immense help to the researchers by eliminating the need of implementing other protocols for comparative study. In addition, it offers a range of other facilities that are difficult to find in other simulators. Therefore, use of NS-2 for empirical evaluation is one of the best choices for researchers working in the area of ad hoc networks. We implemented BeeSensor in NS-2 simulator and the rest of our empirical evaluation of BeeSensor is done in NS-2.

193


Sink

Figure 6.8: Flat network with a global sink node WSNs have unique traffic patterns and hence are hard to realize in NS-2 simulator. Therefore, we used a popular extension to NS-2 simulator - known as Mannasim – for evaluation of BeeSensor in the context of sensor networks [128]. Mannasim extension to NS-2 simulator offers several new modules for design and implementations of WSN applications. The most appealing feature of Mannasim is the provision of defining nodes with different hardware capabilities. More specifically, it allows the user to define flat as well a hierarchical networks. This suits our requirements because we want to demonstrate the impact of our proposed hierarchical network design. We compared the performance of BeeSensor with two ad hoc routing protocols; AODV and DSDV. We used two different types of network topologies in the simulation process. In the first set of experiments, we defined a flat network topology in which all the sensor nodes are required to deliver the detected events to a global sink node – see Fig. 6.8. In the second network topology, we created three distinct types of nodes in a WSN; access points, powerful sensor nodes i.e. long-haul nodes and resource constrained sensor nodes. Fig. 6.9 shows the simulated hierarchical network with four long-haul nodes (LHN), an access point (AP) and a global sink. We simulated BeeSensor in the hierarchical network architecture to show the impact of going from a flat to an hierarchical design. In all the experiments, we assume a target tracking scenario in which multiple sources detect an event and communicate to a sink node. Selection of source nodes is performed randomly.

194


LHN

AP

Sink

LHN

LHN

LHN

Figure 6.9: Hierarchical network with four long-haul nodes (LHN), an access point (AP) and a global sink Source nodes keep generating events for a specific time interval and then another set of sources takes over. Each source generates events at the rate of 10 events per second. Event size is set to 256 bits which is the default value used in Mannasim. Initial energy level of the long-haul nodes is set to 100J with a transmission radius of 250m. Sensor nodes energy is initialized to 40J with 70m of transmission radius. Long-haul nodes are capable of reaching an access point directly. The reported values of the metrics are an average of 5 independent runs where each experiment is performed for a duration of 300 seconds. We now define the metrics used in the evaluation process. 6.3.2.1

Description of the evaluation metrics

Latency. It is defined as the difference between the time of reception of a packet at the global sink node and the time of generation of the packet at the source node. We report the average value of all packet latencies. Packet delivery ratio. We define it as the ratio of the total number of packets received at the global sink node to the number of packets generated at the application layer of all the source nodes. Normalized routing overhead. We define it as the ratio of the total number of control packets generated by a routing protocol to the total number of data packets delivered successfully at

195


the global sink node. Average used energy. It refers to the amount of energy used by a node during the entire run of an experiment. 6.3.2.2


Before we start our discussion on the simulation results, we would like to mention that the reported results of each metric consist of three bar graphs. In the first graph, we show the metric values with varying network sizes. In the second graph of the same metric, we fix the network size to the maximum value – 500 nodes – and show the metric values with varying number of source nodes. Both of these graphs assume the flat network (Fig. 6.8). Finally, we have shown the results of repeating the second set of experiments by assuming the hierarchical network shown in Fig. 6.9. This will actually illustrate the performance enhancement of BeeSensor gained by shifting from a flat to the hierarchical network topology. In parallel, it will also demonstrate the performance comparison of initial BeeSensor design proposed in Chapter 3 – hereby referred to as BeeSensor-Flat – with the final version which is referred to as BeeSensor-Hierarchical Packet delivery ratio Packet delivery ratio of all the three protocols – AODV, BeeSensor and DSDV – at different network sizes is shown in Fig. 6.10. Recall that in this graph, we assume a flat network and 5 sources operating in parallel. It is clear that BeeSensor performs consistently well as the network size varies. We attribute the good performance of BeeSensor due to its controlled flooding of forward scouts which enables the protocol to converge quickly without loss of too much data packets. We must also point out here that the application in these scenarios generates eventdriven data packets. More specifically, a set of source nodes generate data for a specific amount of time and then stop. A second set of nodes then takes over and the process continues. This is quite a challenging scenario for on-demand protocols like AODV as well as BeeSensor. AODV is the second best performing protocol but its performance degrades rapidly as the network size is increased. DSDV is the most inconsistent among all three protocols and the primary reason for this is that it is unable to converge in large scale networks i.e. it takes too longer to converge resulting in low packet delivery ratio. The second graph showing the packet delivery ratio with different number of source nodes is shown in Fig. 6.11. It is important to observe that BeeSensor’s packet delivery ratio – along

196


AODV

BeeSensor

150

300

DSDV


100 80 60 40 20 0 500

Network size Figure 6.10: Packet delivery ratio Vs. network size with AODV – is reasonably higher for the first two cases. However, it falls to a very low value when the number of sources are doubled. Remember, we select the source nodes randomly and therefore they are more likely to be scattered in the entire sensing field. Consequently, they initiate the scoutings in parallel and lead to a network collapse. It should be noted that even the ring search is unable to improve the packet delivery ratio of BeeSensor in flat network. We repeated this experiment for BeeSensor by assuming an hierarchical network and the results are shown in Fig. 6.12. The results clearly demonstrate that performance of BeeSensor in hierarchical network is consistent and substantially better. With the provision of a local sink in the form of a long-haul node, the scope of forward scoutings is reduced. It not only results in better route discovery probability but also avoids network congestion. Therefore, BeeSensor not only handles the large number of nodes but also manages a constantly growing network traffic gracefully. DSDV collapses due to the reasons mentioned earlier. Latency Latencies of all the three protocols with different network sizes is shown in Fig. 6.13. Note that the vertical axis is on a logarithmic scale. It is clear from the results that all protocols have low average delay in small sized networks. However, it continues to rise as the network gets bigger which can also be verified intuitively. Second important thing to note is that BeeSensor has better average delay in most cases and rise in the latency with network size is slower.

197


AODV

BeeSensor

DSDV


100 80 60 40 20 0 2

5

10

No. of sources Figure 6.11: Packet delivery ratio Vs. number of source nodes

BeeSensorŦHierarchical

BeeSensorŦFlat


100 80 60 40 20 0 2

5

10

No. of sources Figure 6.12: Packet delivery ratio of BeeSensor with a flat and hierarchical network against different number of source nodes This clearly demonstrates the effectiveness of the flooding pattern of BeeSensor. On the other hand, AODV routes through the shortest path only but its average packet delay gets higher than BeeSensor which prefers high energy paths. DSDV – being proactive in nature – should

198

Latency(ms)


AODV

BeeSensor

150

300

DSDV

2750 1400 700 350 150 50

500

Network size Figure 6.13: Latency Vs. network size have low latency values because it needs not to store packets and discover routes on-demand. However, as discussed earlier, it is unable to converge quickly resulting in higher delays. The second bar graph showing the latency values with varying number of source nodes is shown in Fig. 6.14. The latency of DSDV – although the highest – is consistent in all scenarios. This is understable due to its proactive nature. The events do not need to be stored in search of a destination node. On the other hand, BeeSensor and AODV produce higher latency values as the number of event sources rises. This behavior is consistent to the one shown in Fig. 6.11. When the protocols take too long to discover routes, event have to wait in cache resulting in higher latency values. The impact of the proposed hierarchical network architecture on latencies is shown in Fig. 6.15. It is clear that BeeSensor latency is lower and consistent in all scenarios. Second important point to note is the amount of reduction in latency of BeeSensor. For instance, latency of BeeSensor with 5 source nodes is 220 ms in the flat topology while in case of the hierarchical network, it equals 114.24 ms resulting in 50% improvement approximately. This improvement is even higher in case of 10 sources. Therefore, we conclude that the proposed network architecture is instrumental in decreasing the latency of BeeSensor. Normalized routing overhead

199


AODV

BeeSensor

DSDV

Latency(ms)

12850 6100 2900 1350 600 250 100 50

2

5

10

No. of sources Figure 6.14: Latency Vs. number of source nodes

Latency(ms)


BeeSensorŦFlat

3850 1950 1000 500 250 100 50

2

5

10

No. of sources Figure 6.15: Latency of BeeSensor with a flat and hierarchical network against different number of source nodes Normalized routing overhead values of the three protocols are plotted in Fig. 6.16. As expected, routing overhead of all the protocols rises with the network size. As the network gets bigger, the distance between the sink and a source node gets higher as well. It ultimately leads to

200

Normalized routing overhead (pkts)


AODV

BeeSensor

150

300

DSDV

94 64 42 28 18 10 6 4 2

500

Network size Figure 6.16: Normalized routing overhead Vs. network size higher routing overhead. Now BeeSensor - apart from the first case - has smaller routing overhead which in this case is mostly due to its restrictive flooding and suppression of parallel scoutings. Consequently, it delivers higher number of packets and attains lower normalized routing overhead. AODV and DSDV suffer in larger networks because of their low packet delivery ratios which are lower in larger topologies. Normalized routing overheads against different number of event sources are shown in Fig. 6.17. Note that vertical axes in all the cases are on a logarithmic scale. BeeSensor has the lowest routing overhead in the first two cases. However, for the reasons mentioned above, it generates substantially higher routing overhead when the source nodes are doubled – although it is still lower than AODV. Interestingly, it even exceeds the routing overhead of DSDV. Therefore, it has negative effect on the performance of BeeSensor as illustrated in the corresponding packet delivery ratio and latency plots. The final routing overhead plot showing the performance of BeeSensor in the flat and the hierarchical network is depicted in Fig. 6.18. BeeSensor has the lowest routing overhead in the hierarchical network which simply outperforms other competitors. The gain in terms of low routing overhead is substantial. For instance, with 500 nodes and 10 sources, BeeSensor routing overhead is 362 in the flat network. In comparison, for the same number of nodes and sources, the routing overhead of BeeSensor in the hierarchical case is merely 1.9.

201



AODV

BeeSensor

DSDV

1228 698 396 224 126 70 38 20 10 4 2

2

5

10

No. of sources


Figure 6.17: Normalized routing overhead Vs. number of source nodes


BeeSensorŦFlat

1228 526 298 168 94 52 28 14 6 2

2

5

10

No. of sources Figure 6.18: Normalized routing overheads of BeeSensor with a flat and hierarchical network against different number of source nodes Average used energy Energy efficient operation of individual sensor nodes is the most dominant constraint posed by WSNs. This primarily is due to limited non-rechargeable battery of a sensor node. Secondly,

202

Average used energy (J)


AODV

BeeSensor

150

300

DSDV

9 7 6 5 4 3 2 1

500

Network size Figure 6.19: Average used energy Vs. network size sensor nodes may be deployed for an extended period of time and operate in an unattended fashion. It is also because of the sheer number of nodes that makes it impossible to service individual nodes on regular basis. We report the average energy consumed by a sensor node in each run of an experiment for all the protocols in Fig. 6.19. Once again it is noticeable that BeeSensor used energy is the lowest in all the network topologies while this is not true for the rest of the two protocols. DSDV attains the highest values which is expected due to its proactive nature. It is interesting to note that BeeSensor delivers higher number of packets but consumes less energy per node. We attribute this behavior due to its low routing overhead and quick convergence of the protocol which avoids repeated discovery of fresh routes. Average used energy of the three protocols with varying number of sources are shown in Fig. 6.20. As expected, the used energy rises with more number of sources operating in parallel. However, in case of DSDV, it is approximately constant in all scenarios showing that the number of active sources do not affect the route discovery / maintenance overhead. Inspite of the fact that the active sources result in significant increase in the average used energy of BeeSensor, it is still the lowest. The last set of results illustrating the performance gain of BeeSensor in hierarchical case is plotted in 6.21. The results are clearly convincing because the gain in terms of energy saving per node is enormous.

203


AODV

BeeSensor

DSDV


10 7 5 4 3 2 1

2

5

10

No. of sources Figure 6.20: Average used energy Vs. number of source nodes


BeeSensorŦFlat


10 7.2 5.6 4.4 3.2 2.4 1.6 1 0.6 0.2 2

5

10

No. of sources Figure 6.21: Average used energy of BeeSensor with a flat and hierarchical network against different number of source nodes This concludes our discussion on the performance analysis of BeeSensor in large-scale static sensor networks. We now move to our last set of experiments in which we analyze the performance of BeeSensor in mobile ad hoc networks.

204


6.3.3

Performance analysis of BeeSensor in mobile ad hoc networks

Sensor nodes in a WSN are generally immobile while a sink may be a mobile node. In addition to this, there are some applications of sensor networks in which sensor nodes are mobile e.g. nodes mounted on a tank in the battle field. The work reported in this section illustrates the performance of BeeSensor in such a mobile scenario. Although BeeSensor is optimized for sensor networks, it inherits some of the features of BeeAdHoc protocol which was designed for MANETs. Therefore, BeeSensor is expected to perform well in MANETs as well. In all our experiments, we assume a network of 50 nodes moving in a rectangular area of 1500𝑚 × 300𝑚. The movement pattern is characterized by Random Waypoint model in which every node moves to a random destination with a speed of 1 - 5 𝑚/𝑠. After reaching the destination, it stops for 60 seconds and then moves to another location. We do not use TCP sources primarily because it modifies the network conditions - packet sending rate for instance - preventing a direct comparison of different protocols. UDP provides a fair environment in which candidate protocols can be evaluated under identical network conditions. We used a CBR traffic generator in which sources send packets at the rate of 10 packets per second where each packet is 512 bits long. Each experiment is performed for a duration of 1000 seconds. We are reporting an average of 5 independent runs. It is also important to note that in all the simulation experiments conducted in NS-2, BeeSensor uses explicit swarm packets to transport foragers back to the hive. We compare the performance of BeeSensor with AODV, DSR and DSDV using the same metrics as reported in Section 6.3.2. 6.3.3.1


Packet delivery ratio Packet delivery ratios of all the four protocols are shown in Fig. 6.22. With 10 flows, packet delivery ratio of BeeSensor, AODV and DSR is close to maximum. However, as the number of flows are doubled, packet delivery ratio of all the protocols drops significantly. With 30 flows, it reaches to an extremely low value. This clearly leads to the conclusion that higher traffic in an ad hoc network leads to an increased number of collisions resulting in the performance degradation. Therefore, it is important to localize the control traffic so that the network may remain stable. An interesting point to note in these results is performance enhancement in DSDV as we move to higher number of flows. When more flows are active, DSDV triggers more frequent

205


AODV

BeeSensor

DSDV

DSR


100 80 60 40 20 0 10

20

30

No. of flows Figure 6.22: Packet delivery ratio Vs. number of flows updates and converges quickly. Consequently, its packet delivery ratio is slightly better than the other protocols in case of 30 flows. However, the settling time of DSDV becomes problematic when the network size goes bigger as shown earlier. Packet delivery ratio of BeeSensor is also affected by frequent link failures caused by mobility. Recall that BeeSensor does not use any explicit route error messages to detect broken links. Rather, it has an inherent mechanism of detecting link breaks. Whenever the forager respository gets empty, BeeSensor assumes that all paths to a given destination are lost. Now foragers are transported back to the source nodes through explicit swarming process which of course is a time dependent process. As a result, BeeSensor detects path break with some delay resulting in loss of the packets. Latency Latency values of the candidate protocols are illustrated in Fig. 6.23. The results are consistent with the packet delivery ratio results. The latency of all the protcols is lower when the number of flows are smaller and rises with the number of flows. Performance of BeeSensor is satisfactory keeping in view of the fact that it contains several optimizations specifically for sensor networks. In fact, the latency of BeeSensor is close to the lowest at 30 flows. The reason for high latency at higher number of flows is due to substantial loss in the number of packets. Furthermore, since protocols are unable to converge quickly, data packets

206


AODV

BeeSensor

DSDV

DSR

9580

Latency(ms)

3300 1620 550 260 120 50 20 10

10

20

30

No. of flows Figure 6.23: Latency Vs. number of flows have to wait longer in the data cache. Consequently, overall latency of the packets rises. It is important to note that AODV, DSR and DSDV prefer the shortest hop path but their latency is low than BeeSensor in some scenarios. Therefore, we can conclude that shortest paths are not always the least delay paths especially under high traffic conditions. Normalized routing overhead Normalized routing overhead the algorithms is shown in Fig. 6.24. AODV generates maximum routing overhead among all the four protocols. Second important point to note is the rise in overhead with the number of flows for the obvious reasons. Normalized routing overhead of BeeSensor rises with the number of flows but is still lower than AODV and DSR. Remember that, due to small network size, the average number of hops between a source destination pair are significantly smaller - around 2.8 hops. Therefore, restricive flooding beyond 2 hops does not leaves any significant impression in these scenarios. DSDV is consistent among all the protocols. Recall our argument above that it converges quickly under higher number of flows after which its update rate slows down and remains constant. Consequently, its overall routing overhead does not vary much between different scenarios. This is also due to proactive nature of DSDV and our proposed routing overhead model also favors the point (Chapter 4).

207


6.4 Conclusions

AODV

BeeSensor

DSDV

DSR

2.5 1.9 1.5 1.1 0.9 0.7 0.5 0.3 0.1 10

20

30

No. of flows Figure 6.24: Normalized routing overheads Vs. number of flows Average used energy The final bar graph illustrating the average used energies is shown in Fig. 6.25. Mobility has clearly affected the performance of BeeSensor in this case. In general, energy consumed by all protocols are close to each other most cases. Higher values of average used energy show that almost every node is involved in the routing function thereby draining the available battery energy. This concludes our discussion on the simulation results.

6.4

Conclusions

The major contribution of this work is a novel protocol engineering cycle. After the requirement engineering phase, we investigate the features of a bee colony in relevance to WSNs and utilize them to develop BeeSensor. Our initial results show performance degradation of BeeSensor in large scale networks. To investigate this shortcoming, we developed a generic mathematical evaluation framework to model the performance of BeeSensor in large-scale networks. We utilize the feedback of the formal modeling process to improve the initial design of BeeSensor. In the last phase of this dissertation, we demonstrated through extensive simulations that BeeSensor is energy-efficient, scalable and performance efficient in WSNs. In addition to this, we have shown

208

6.4 Conclusions

AODV

BeeSensor

DSDV

DSR


400 200 100 50

10

20

30

No. of flows Figure 6.25: Average used energy Vs. number of flows that BeeSensor also performs well in mobile ad hoc networks and hence a suitable candidate for hybrid ad hoc networks.

209

Chapter 7

Conclusions and Future Works 7.1

Conclusions

We have developed a distributed, scalable, energy and performance efficient routing protocol for ad hoc and sensor networks, BeeSensor. The major objective of this dissertation was to engineer a simple – both in terms of processing complexity and communication overhead – routing solution keeping in view of the strict constraints posed by WSNs. Such a routing algorithm is expected to utilize the available network resources efficiently and hence achieve competitive performance compared with the existing protocols. The major guideline in developing such a solution was to combine the power of resource constrained sensor nodes so that they collectively produce the desired network level behavior. Natural insect colonies e.g. a honey bee colony is a well-known example in which system level behavior is achieved through the interaction of minimalist individuals. The insects follow simple rules to cooperate / coordinate their individual activities. Consequently, they show robustness, scalability and adaptivity to a constantly changing environment. According to Seeley (1995) [81], ”Everyone knows that individual bees glean nectar from flowers and transform it into delicious honey, but it is not so widely known that a colony of bees possesses a complex, highly ordered social organization for the gathering of its food”. The scintillating resemblance between a honey bee colony and WSNs provided us a motivation to utilize the foraging principles of honey bees for the design of BeeSensor protocol. In the first phase of BeeSensor engineering, we developed a bee agent model similar to that of a honey bee colony. We defined the function of each bee agent and allowed it to interact with each other to share their view of the network. Consequently, BeeSensor is able to organize itself in a distributed fashion. We implemented the BeeSensor protocol in Prowler simulator

210

7.1 Conclusions

and developed an empirical evaluation framework to record a range of relevant metrics. The simulation results demonstrated that BeeSensor produced promising results in comparison to existing classical and SI-based routing protocols for WSNs. To complement the simulation studies presented in Chapter 3 and gain more insights, we developed a novel theoretical evaluation framework - using the probability theory - to model the routing overhead and the route optimality of BeeSensor protocol in Chapter 4. The models of these metrics unveiled several interesting insights about the parameters that may affect the performance of ad hoc routing protocols in large-scale ad hoc and sensor networks. For instance, stochastic forwarding of route discovery messages although results in low routing overhead but degrades the route discovery probability. Furthermore, the models also demonstrated that even the blind flooding protocols will not scale to arbitrarily large number of hops. The formal modeling process of BeeSensor continued in Chapter 5 in which we analyzed its reliability in terms of packet delivery. The reliability function of BeeSensor protocol is shown to be a concave function of the total number of discovered paths. Consequently, maintenance of a large set of path does not result in a proportional dividend in terms of the packet delivery ratio. Keeping in view of the BeeSensor analysis, we conclude that: 1. In a flat network where a pair of is separated by an arbitrarily large number of hops, BeeSensor fails to discover path. 2. Maintenance of a large set of paths is expensive in terms of memory, energy and processing overhead. Furthermore, its contribution to packet delivery reliability is minimal and hence should be avoided. 3. Stochastic forwarding is beneficial for the reduction of routing overhead. However, low values of rebroadcast probabilities might be detrimental for the overall performance of BeeSensor. Therefore, alternate mechanisms must be explored to reduce the route discovery and maintenance overhead. 4. Memory required to store routing information might become significantly large if we maintain a single entry for each pair of nodes. To address all the above issues and conclude the engineering cycle, we revised the design of BeeSensor protocol in Chapter 5. We proposed a hierarchical sensor network – essentially a multi-sink architecture – which is equipped with special beacon nodes. Sensor nodes are now required to communicate with the local beacon node only instead of a single global sink.

211

7.2 Future Work: Suggestions and Directions

Consequently, scope of the broadcast packets as well as the average hop distance is substantially reduced. The revised design of BeeSensor also contains a component that: (1) favors the use of data aggregation to reduce the in-network traffic, and (2) reduces the number of parallel route discoveries. Therefore, memory required to store the routing information is also reduced significantly. We then performed thorough simulations to compare the performance of the final BeeSensor design with several ad hoc routing protocols using Prowler and NS-2 simulator. The results clearly demonstrate that BeeSensor performed exceptionally well in all WSNs scenarios including the large-scale networks. We have also simulated the performance of BeeSensor in mobile scenarios. The simulation results demonstrate that BeeSensor’s performance is equally good in MANETs as well. Therefore, BeeSensor can also be used in hybrid ad hoc networks. Furthermore, we are also confident that the engineering process followed in this dissertation is somewhat novel and can be instrumental in developing state-of-the-art routing protocols for ad hoc and sensor networks. Based on our experience with the BeeSensor project, we recommend that new protocols must always be evaluated through statistically sound experimental techniques and complemented by mathematical verification. This will enhance the confidence of the community in the new algorithms.

7.2

Future Work: Suggestions and Directions

Protocol engineering is an iterative process. The design goes through several intermediate stages before it gets finalized. The testing and evaluation process is generally a designer’s choice. Therefore, some protocols are evaluated through simulations while others are tested on a real testbed. We believe that empirical analysis is not enough to get a true picture about a protocol’s performance in the real world. In this context, we recommend following guidelines that should be followed in the design cycle of any protocol designed for ad hoc networks.

7.2.1

Formal evaluation

Network protocols in general and ad hoc routing protocols in particular are evaluated through simulation studies. However, even the most thorough and scientific simulation analysis (which is rarely done) does not completely unfold the strengths and weaknesses of the proposed protocol. Therefore, formal modeling of the relevant metrics – keeping in view of the design objectives –

212


is compulsory. We followed the same strategy and conclude that it played a key role in refining the initial BeeSensor design. In fact, mathematical equations contain more information that the engineers expect and we have demonstrated it throughout the dissertation. Unfortunately, the formal modeling has not received much attention of the researchers and therefore, it is still a promising area for future research. We have laid the foundation of a sound formal framework that can easily be extended to other prominent ad hoc routing protocols and the relevant metrics. We believe that serious research efforts can result in an extremely flexible and extensive modeling framework for ad hoc routing protocols. Consequently, it will not only streamline the evaluation process but also save significant time and effort consumed in the empirical evaluation process. An additional point that we would like to highlight here is the generality of such a formal framework. Some scarce attempts have been made to utilize mathematical tools for the evaluation of ad hoc networks. However, to the best of our knowledge, these models are limited in scope and hence can not be generalized to other protocols. Development of mathematical evaluation framework is always a difficult task which requires significant expertise and experience because the proposed models should be generalizable and extensible to other protocols, scenarios and metrics. This dissertation is an important step in this direction.

7.2.2

Scalability

Scalability is a generic term that is used for a variety of different purposes. In its most popular meanings, the scalability is linked to the size of the network. In this context, the claim that a given protocol is scalable to large networks may be interpreted in two ways: (1) it is able to handle the growing number of nodes, and (2) it is able to handle the network deployed in large geographical area. The first interpretation has an implicit meaning that we are actually increasing the node density. In the second interpretation, we assume a fixed node density and hence an increase in the number of nodes leads to a large geographical area. Our experience with the BeeSensor project shows that both cases are extremely difficult to handle. For instance, an increase in the node density usually leads to an increase in the number of collisions at the MAC layer. Consequently, the protocol performance degrades due to packet loss. On the other hand, large geographical deployment of sensor nodes results in a large hop distance between a given pair of nodes. Such an arbitrarily long hop distance may become impossible to handle through common route discovery schemes (blind flooding for instance). Therefore, scalability in terms of network size has several challenges that should be addressed separately.

213


1. First and the foremost problem is to minimize the collisions at the MAC layer. We have elaborated the effect of collisions on the performance of a protocol in Chapter 6 in which we model the reliability of partially-disjoint paths. The situation can get challenging in high density networks and therefore, it must be carefully addressed. 2. The concept of flat and distributed topology is not practical when the size of the network reaches approaches to thousands / million of sensor nodes. With an increase in the hop length, traditional blind flooding fails and hence a protocol requires new mechanisms to tackle the problem. For instance, methods may be developed to make the WSNs as scale-free networks. 3. Claiming the scalability of a protocol and proving it through sound empirical techniques is still an area that needs substantial research efforts. For instance, a sensor network may contain several thousands of nodes or even million of nodes. Is there any simulation tool available in which we can simulate a network of 100, 000 nodes in a scientific fashion and the answer is unfortunately no. Therefore, we need to bridge this gap between theory and practice in case of WSNs.

7.2.3

Real testbeds evaluation

The final target of every protocol is to perform well in real world networks. Therefore, evaluation of protocols on a real sensor network - even in a laboratory - is really important. It is relevant because there are some characteristics of a real network that can not be replicated in a simulator. Consequently, real wireless networks testbeds can force the experimenter to face a wide range of problems leading to an improved protocol design.

7.2.4

Secure routing

Security of WSN routing protocols is another important area that should be targeted in future research. Although networking community has been working in this area for the past several years, SI community has almost done nothing for the security of WSNs. In fact, we believe that security is one of the major concerns in SI-routing protocols in comparison to classical protocols. For instance, stigmergic behavior of mobile agents can be a serious security threat that can result in corruption of the routing information. Therefore, SI community has to undertake security research in WSNs.

214


7.2.5

Bee Colony Optimization (BCO) Metaheuristic

Ant Colony Optimization (ACO) metaheuristic has been extensively used for the past several years. Although originally designed to produce near-optimal solution for traveling salesman problem, it has been applied to several other combinatorial problems e.g. routing in telecommunication networks, job-shop scheduling, vehicles routing etc. With reference to routing in telecommunication networks, we believe that ACO is quickly saturating and therefore, a new direction in the area of SI-based routing has to be identified. To this end, Bee Colony Optimization (BCO) has emerged as a new research direction very recently. Teodorovic (2009) [80] has introduced BCO algorithm and successfully applied to several multiobjective optimization problems e.g. traveling sales problem. We believe that development and application of BCO metaheuristic is a promising field which can lead to new horizons in the area of swarm intelligence.

215

Appendix A

A.1

A Geometrical Model of Expected Forward Degree

The model assumes that each hop nodes has the same expected forward degree i.e. 𝑑𝑓 [1] = 𝑑𝑓 [2] = 𝑑𝑓 [3] = ⋅ ⋅ ⋅ = 𝑑𝑓 . Expected forward degree of a node, 𝑑𝑓 , is dependent upon the geometrical position of the node. Nodes located near the periphery of the transmission circle of a node can cover the maximum uncovered area. For example node T in Figure A.1 is the peripheral node of the source S and is likely to reach higher number of nodes in ring I than the nodes located in the interior part of the transmission circle of node 𝑆. Now the idea to find 𝑑𝑓 is to calculate the maximum forward degree of a neighbor of 𝑆 which is basically the node located right at the periphery (node 𝑇 in Fig. A.1) of the transmission circle. Then using the fact that nodes lying closer to node 𝑆 will approximately have a zero forward degree, we calculate the average of these extreme two values. To calculate the forward degree of node T, we need to calculate the number of nodes common to source S and node T, let us denote it by 𝑑𝑐𝑜𝑚𝑚𝑜𝑛 . Then, the forward degree of node T will be 𝑑𝑎𝑣𝑔 − 𝑑𝑐𝑜𝑚𝑚𝑜𝑛 . Our first target is to calculate the area of overlapping region of 𝑆 and 𝑇 . Once the area is calculated, we can simply multiply it with the node density to calculate the number of common neighbors i.e. 𝑑𝑐𝑜𝑚𝑚𝑜𝑛 . We have shown the overlapping transmission circles of node 𝑆 and node 𝑇 in Fig. A.2. Now consider the transmission circle of node node 𝑇 . Area of the sector 𝑉 𝑇 𝑍𝑆, 𝐴𝑠𝑉 𝑇 𝑍𝑆 , making an angle 𝜃 at the center of the circle is 𝐴𝑠𝑉 𝑇 𝑍𝑆 =

1 2 𝑟 𝜃 2 0

(A.1)

where 𝜃 is in radians. When 𝜃 → 2𝜋 radians, a case of complete overlap, 𝐴𝑠𝑉 𝑇 𝑍𝑆 approaches 𝜋𝑟02 . Using (A.1), we can compute the area of the overlapping region containing black dots

216

A.1 A Geometrical Model of Expected Forward Degree

f[1]=3 R

T

S r0

ring I r0-Ȝ

r0-Ȝ ring II

Figure A.1: Propagation of route discovery messages in an ad hoc network

dot

0

Figure A.2: Overlapping transmission circles of Node S and T i.e. 𝐴𝑑𝑜𝑡 . Then the total area of the overlapping region is simply the twice of this area i.e. 𝐴𝑜𝑣𝑒𝑟𝑙𝑎𝑝 = 2𝐴𝑑𝑜𝑡 . 𝐴𝑑𝑜𝑡 can be obtained by subtracting the area of triangle 𝑉 𝑇 𝑍, 𝐴𝑡𝑉 𝑇 𝑍 =

√ 3 2 4 𝑟0 ,

from the area of sector 𝑉 𝑇 𝑍𝑆, 𝐴𝑠𝑉 𝑇 𝑍𝑆 . Now, using Fig. A.2, area of the triangle 𝑉 𝑇 𝑍 may be written as 𝐴𝑡𝑉 𝑇 𝑍 = 𝑏 ×

𝑟0 2

(A.2)

As △𝑉 𝑇 𝑊 is right angled triangle, we have √ 3𝑟0 𝑏= 2

217

(A.3)

A.1 A Geometrical Model of Expected Forward Degree

Using (A.3) in (A.2), final expression for 𝐴𝑡𝑋𝑌 𝑍 is √ 3 2 𝑡 𝑟 𝐴𝑉 𝑇 𝑍 = 4 0

(A.4)

Now the area of the dotted region shown in Fig. A.2 is 𝐴𝑑𝑜𝑡 = 𝐴𝑠𝑉 𝑇 𝑍𝑆 − 𝐴𝑡𝑉 𝑇 𝑍 =

√ 3 𝑟02 (𝜃 − ) 2 2

Multiplying (A.5) with 2, we get the overlapping area i.e. √ 3 2 𝐴𝑜𝑣𝑒𝑟𝑙𝑎𝑝 = 𝑟0 (𝜃 − ). 2

(A.5)

(A.6)

𝜃 can easily be calculated by considering the right angled triangle 𝑉 𝑇 𝑊 . Finally, we multiply (A.6) with the node density (𝜌) to calculate 𝑑𝑐𝑜𝑚𝑚𝑜𝑛 . 𝑑𝑐𝑜𝑚𝑚𝑜𝑛 =

2𝜋 𝜌𝑟02 ( 3

√

−

3 ). 2

(A.7)

Equation (A.7) shows that the number of common neighbors of any two nodes will vary directly with the node density (𝜌) and the transmission radius of the nodes (𝑟0 ). This can also be verified intuitively. Now forward degree of node T is 𝑑𝑎𝑣𝑔 − 𝑑𝑐𝑜𝑚𝑚𝑜𝑛 which is the maximum possible forward degree of a node within transmission range of the source node S. On the other hand, nodes lying closer to source will have approximately zero forward degree as their rebroadcasts may not be heard by any node in strip I. Hence, the Expected forward degree of a node within the transmission circle of the source S is approximately equal to 𝑑𝑎𝑣𝑔 − 𝜌𝑟02 ( 2𝜋 3 − 𝑑𝑓 ≃ 2

√ 3 2 )

.

(A.8)

Equation (A.8) shows that the Expected forward degree of a node depends upon 𝑑𝑎𝑣𝑔 , node density 𝜌 and the transmission radius 𝑟0 . As we said earlier, this geometrical model assumes a constant value of 𝑑𝑓 at each hop of the network. An example of such a network is shown in Fig. A.3. Each node has three neighbors and none of the node shares more than 1 neighbor with any other node in the network. This model will also be applicable to networks where only few of the total available transmitting nodes forward the broadcast. For instance, source 𝑆 in Fig. A.3 might have more neighbors but we are showing only those nodes that participate in forwarding. Now, putting 𝑑𝑓 [1] = 𝑑𝑓 [2] = 𝑑𝑓 [3] = ⋅ ⋅ ⋅ = 𝑑𝑓 in (4.6), we get a rather simplified form for the routing overhead. { 𝐶𝑔𝑝 =

1 + ℎ𝑝𝑟 𝑑𝑎𝑣𝑔(𝑝𝑠 𝑑𝑓

1 + 𝑝𝑟 𝑑𝑎𝑣𝑔

1−(𝑝𝑠 𝑑𝑓 )ℎ 1−𝑝𝑠 𝑑𝑓

218

)

if 𝑝𝑠 𝑑𝑓 = 1 otherwise

A.2 Bounds on the Reliability Function of BeeSensor

Figure A.3: A sparse network with nodes having equal expected forward degree We replaced 𝐶𝑝 with 𝐶𝑔𝑝 just to differentiate the two expressions. However, in practical connected ad hoc networks, and especially the case when fraction of forwarding nodes is close to 1, concept of constant expected forward degree does not apply. In this case, 𝑑𝑓 will keep decreasing as we move away from the source.

A.2

Bounds on the Reliability Function of BeeSensor

Let 𝑃1 , 𝑃2 , 𝑃3 , . . . , 𝑃𝑚 represent the paths between a given pair, each with a flooding distance of 𝑡, and 𝐸1 , 𝐸2 , 𝐸3 , . . . , 𝐸𝑚 be the events such that 𝐸𝑖 = {𝑃 𝑎𝑡ℎ 𝑃𝑖 𝑖𝑠 𝑎 𝑣𝑎𝑙𝑖𝑑 𝑝𝑎𝑡ℎ}. Now, we can write the reliability function 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) in terms of the union of these events i.e., 𝑅(𝐵𝑒𝑒𝑆𝑒𝑛𝑠𝑜𝑟) (𝑚, 𝑝𝑓 , 𝑡) = 𝑃 (∪𝑚 𝑖 𝐸𝑖 ). Utilizing the formula of inclusion and exclusion bounds on the probability of union of events [122], we obtain: 𝑃 (∪𝑚 𝑖 𝐸𝑖 ) ≤ 𝑃 (∪𝑚 𝑖 𝐸𝑖 ) ≥

∑

𝑃 (𝐸𝑖 ) −

𝑖

∑ 𝑖

Investigating the Agent-based Ad Hoc Routing Algorithms - nexGIN RC

Investigating the Agent-based Ad Hoc Routing Algorithms - nexGIN RC

Suggest Documents

Gossip Based Ad-Hoc Routing

Distributed Routing Algorithms for Wireless Ad Hoc ... - CiteSeerX

Center-Oriented Broadcast Routing Algorithms for Wireless Ad Hoc

Distributed Routing Algorithms for Wireless Ad Hoc ... - CiteSeerX

Self-stabilizing Routing Algorithms for Wireless Ad-Hoc ... - Springer Link

Performance Comparison of Distributed Routing Algorithms in Ad Hoc

Randomized Routing Algorithms in Mobile Ad Hoc Networks ...

Authenticated Routing for Ad hoc Networks - CiteSeerX

Analysis of Mobile Ad-hoc network routing

Authenticated Routing for Ad hoc Networks - CiteSeerX

Authenticated Routing for Ad hoc Networks - CiteSeerX

Evaluation of Ad Hoc Routing Strategies to

Multi-Tier Mobile Ad Hoc Routing - CiteSeerX

HARP - HYBRID AD HOC ROUTING PROTOCOL

Virtual Structure Routing in Ad hoc Networks

Improving Routing Performance of Multipath Ad Hoc

Multi-Tier Mobile Ad Hoc Routing - CiteSeerX

Routing in Ad-Hoc Networks - Google Sites

Dynamic Source Routing in Ad Hoc Wireless

Analysis of Mobile Ad-hoc network routing

Ad Hoc Routing Protocol Validation - DiVA portal

Performance Comparison of Ad-hoc Routing ...

Dynamic Routing for Flying Ad Hoc Networks

Secure Mobile Ad hoc Routing - IEEE Xplore