Reliable Routing in Wireless Ad Hoc Networks: The

0 downloads 0 Views 1MB Size Report
4.1 Ad hoc network(left) with its corresponding graph G(right). . . . . . 75 ... 4.6 Rings of Rings with 3 rings (x = 3) and 3 scouts per unit (s =3). . . 90 ..... Wireless networks are the subject of widening research as they may provide com- ...... address of itself with the destination one, if it matches, x0 = x2, the source already.
` degli Studi di Pisa Universita

Dipartimento di Informatica Dottorato di Ricerca in Informatica

Ph.D. Thesis

Reliable Routing in Wireless Ad Hoc Networks: The Virtual Routing Protocol Luiz Carlos Pessoa Albini

Addr: Via Buonarroti 2, 56127 Pisa, Italy

Thesis supervisor: Prof. Piero Maestrini

Abstract A novel routing protocol for wireless, mobile ad hoc networks is presented, named the Virtual Routing Protocol (VRP ). VRP incorporates features that enhance routing reliability, defined as the ability to provide almost 100% delivery ratio for data messages. VRP is a hybrid source routing protocol. Units running VRP maintain routes to some units proactively, while they construct routes to other units ondemand. To this purpose, VRP defines a logical structure over the network, which is unrelated to the physical network topology. In the logical structure units are connected by virtual links and are responsible for keeping physical routes to their neighbors. A path connecting any two units in the logical structure is called a virtual path. Virtual paths are constructed by the sources of communications without any exchange of messages. Routes between units are built by translating virtual paths into physical routes. This process essentially relies on unicast messages, with sporadic use of floodings. The process of updating the routes to neighbors of the logical structure (called scout update) is started by units when the previously stored information is found to be invalid (mostly due to mobility). Although started reactively, this process is partly proactive and relies on flooding messages. Since the logical structure provides redundant virtual paths between any two units, scout updates are not urgent and can be run on low priority. In fact, VRP uses three priority levels for messages and most floodings, needed for the purpose of scout update, are executed in background using the lowest priority level. Altogether, the above outlined features contribute to reducing the network congestion. By reducing the congestion of the network, VRP succeeds in avoiding units’ buffer overflows, which are a major source of message losses in most routing protocols. VRP has been evaluated and compared with the Dynamic Source Routing (DSR) protocol and the Zone Routing Protocol (ZRP) by means of simulation. Under a wide range of network population, traffic load and units’ mobility, VRP provides a delivery ratio above 95% under light traffic conditions, while DSR and ZRP provide delivery ratios of 70% and 82% respectively. However, under heavy traffic conditions, VRP loses some performance as units are not able to maintain the routes to their logical neighbors up-to-date, though its delivery ratio is still above 75% of the generated data messages. Under such traffic conditions, the delivery ratio of DSR drops to 50%, while the delivery ratio of ZRP is maintained around 80% of the generated data messages.

Acknowledgments To my parents for all tenderness, love and support in all moments of my life, for their presence by my side during happiness and sadness, and also to show me the right path to follow when I had doubts. To my fianc´ee for all the love and support that she gave me. Thanks for being by my side, in spite of the distance, in all good and bad moments during these 3 years. Thanks for being my strength during the difficult times, and to be there for me when I needed your support. Thank you also for all the grammar corrections in the thesis. Thanks specially for all her patience, love and tenderness. A very special thanks to professor Piero Maestrini, who accepted me as his student even without having met me before my arrival in Italy. Thanks for all the insight and support. For being my guide during this work, and for have believed in me. Thanks also to my colleagues, Stefano, Antonio and Davide. Thanks for the time spent on discussions about this thesis. For all their help on developing the protocol. And a special thanks to Antonio for all his help on developing the simulator that was used, and for always being available to search solutions to the problems that appeared. A special thought goes to all my friends in Pisa, who welcomed me into their lives, and for making my life much easier here in Pisa.

Agradecimentos Aos meus pais por toda o carinho, amor e coragem em todos os momentos da minha vida, pelas suas presen¸cas ao meu lado na alegria e na tristeza, e tamb´em por me mostrar o caminho correto a prosseguir quando eu tive d´ uvidas. ` minha noiva por todo o amor e coragem que ela me deu. Obrigado por estar A ao meu lado, mesmo estando distante, em todos os bons a maus momentos desses 3 anos. Obrigado por ser a minha for¸ca durante os momentos de dificuldades, e por estar sempre ao meu lado quando eu precisei da sua ajuda. Obrigado tamb´em por todas as corre¸c˜oes gram´aticais na tese. E obrigado especialmente por toda a sua paciˆencia, amor e carinho. Um agradecimento muito especial vai ao professor Piero Maestrini, que me aceitou como orientado de doutorado mesmo sem termos nos encontrado antes da minha chegada aqui `a It´alia. Obrigado por toda a sua ajuda e incentivo. Por ter sido meu guia durante esse trabalho, e por ter acreditado em mim. Obrigado tamb´em aos meus colegas, Stefano, Antonio e Davide, por todo o tempo que dedicaram a discutir temas desta tese comigo. Obrigado por toda a ajuda que me deram no desenvolvimento desse protocolo. Um agradecimento especial ao Antonio por toda a sua ajuda no desenvolvimento do simulador que foi usado, e por ter sido sempre dispon´ıvel para procurar solu¸c˜oes `a todos os problemas que apareceram. Um pensamento especial vai tambm `a todos os meus amigos de Pisa, os quais me acolheram nas suas vidas e fizeram que a minha estadia em Pisa fosse muito mais f´acil.

To my parents To my fianc´ee

Contents 1 Introduction 1.1

1

Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.1.1

Routing in Ad Hoc Networks . . . . . . . . . . . . . . . . . .

6

1.2

IEEE 802.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.3

Power Consumption

1.4

Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.5

Goals of this dissertation . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Routing Protocols 2.1

2.3

19

Proactive Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.1.1

2.2

. . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Destination-Sequenced Distance Vector . . . . . . . . . . . . . 23

Reactive Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2.1

Dynamic Source Routing . . . . . . . . . . . . . . . . . . . . . 25

2.2.2

Ad Hoc On-Demand Distance Vector . . . . . . . . . . . . . . 30

Hybrid Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.3.1

Zone Routing Protocol . . . . . . . . . . . . . . . . . . . . . . 33

2.3.2

Sharp Hybrid Adaptive Routing Protocol . . . . . . . . . . . . 35

2.3.3

Contact-based Architecture for Resource Discovery . . . . . . 39

iv

2.4

2.5

Geographical Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.4.1

Distance Routing Effect Algorithm for Mobility . . . . . . . . 46

2.4.2

Location-Aided Routing . . . . . . . . . . . . . . . . . . . . . 47

2.4.3

Self Organized Terminode Routing . . . . . . . . . . . . . . . 49

Power Aware Routing

. . . . . . . . . . . . . . . . . . . . . . . . . . 51

2.5.1

Span . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

2.5.2

Max-Min zPmin . . . . . . . . . . . . . . . . . . . . . . . . . . 53

2.6

Hierarchical Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.7

Secure Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.7.1

2.8

Ariadne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Quality of Service Routing . . . . . . . . . . . . . . . . . . . . . . . . 60

3 Reliability

65

3.1

Routing Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

3.2

Reliability evaluation of DSR . . . . . . . . . . . . . . . . . . . . . . 67

3.3

Reliability evaluation of ZRP . . . . . . . . . . . . . . . . . . . . . . 71

3.4

The Approach to Reliability of VRP . . . . . . . . . . . . . . . . . . 73

4 Virtual Routing Protocol 4.1

4.2

75

Logical Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.1.1

Rings of Rings . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.1.2

Hypercube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.1.3

Cube Connected Cycles . . . . . . . . . . . . . . . . . . . . . 83

4.1.4

3D Torus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

4.1.5

Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

v

4.2.1

Route Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . 89

4.2.2

Route Maintenance . . . . . . . . . . . . . . . . . . . . . . . . 100

4.2.3

Scout Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

4.3

Size of the Routing Tables . . . . . . . . . . . . . . . . . . . . . . . . 103

4.4

Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

4.5

4.4.1

Route Translation - RTRANS . . . . . . . . . . . . . . . . . . 103

4.4.2

Route Request - RREQ . . . . . . . . . . . . . . . . . . . . . 106

4.4.3

Route Reply - RREP . . . . . . . . . . . . . . . . . . . . . . . 107

4.4.4

Route Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.4.5

Data messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Loop Free Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 4.5.1

4.6

LoopFree procedure . . . . . . . . . . . . . . . . . . . . . . . . 115

Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.6.1

Scout Update over Received Messages . . . . . . . . . . . . . . 116

4.6.2

Shortcuts in Virtual Path Translation . . . . . . . . . . . . . . 116

4.6.3

Avoiding High Priority Flooding . . . . . . . . . . . . . . . . . 117

4.6.4

Proactive Zone . . . . . . . . . . . . . . . . . . . . . . . . . . 118

5 Simulation Results 5.1

119

Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 5.1.1

Simulator Validation . . . . . . . . . . . . . . . . . . . . . . . 122

5.2

Simulation Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

5.3

Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 5.3.1

Virtual Path Translation . . . . . . . . . . . . . . . . . . . . . 127

5.3.2

Scout Update . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

vi

5.3.3

Proactive Scout Setup . . . . . . . . . . . . . . . . . . . . . . 131

5.3.4

Using Hello Messages . . . . . . . . . . . . . . . . . . . . . . . 132

5.3.5

Delivery Ratio under different Traffic Conditions . . . . . . . . 134

5.3.6

Delivery Ratio and Route Acquisition Delay under different Transmission Ranges . . . . . . . . . . . . . . . . . . . . . . . 135

5.3.7

Delivery Ratio and Route Acquisition Delay under different Pause Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.3.8

Delivery Ratio and Route Acquisition Delay under different Number of Units . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.3.9

Delivery Ratio and Route Acquisition Delay under different Units’ Velocity . . . . . . . . . . . . . . . . . . . . . . . . . . 139

5.4

5.5

VRP compared with DSR . . . . . . . . . . . . . . . . . . . . . . . . 142 5.4.1

Delivery ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

5.4.2

Route Acquisition Delay . . . . . . . . . . . . . . . . . . . . . 148

5.4.3

Normalized Routing Load . . . . . . . . . . . . . . . . . . . . 153

5.4.4

Size of the Routing Tables . . . . . . . . . . . . . . . . . . . . 161

VRP compared with ZRP . . . . . . . . . . . . . . . . . . . . . . . . 162 5.5.1

Delivery ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5.5.2

Route Acquisition Delay . . . . . . . . . . . . . . . . . . . . . 169

5.5.3

Normalized Routing Load . . . . . . . . . . . . . . . . . . . . 174

6 Conclusion and Future Work Bibliography A Algorithms in Pseudo-Code

183 191 201

List of Figures 1.1

Multihop wireless network.

1.2

Hidden unit problem.

2.1

CARD architecture overview. . . . . . . . . . . . . . . . . . . . . . . 40

2.2

Zone Graph of four zones in a square network field. . . . . . . . . . . 55

3.1

DSR delivery ratio for different number of simultaneous source-destination connections.

3.2

. . . . . . . . . . . . . . . . . . . . . . .

3

. . . . . . . . . . . . . . . . . . . . . . . . . .

9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

DSR delivery ratio for different duration of the source-destination connections.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.3

DSR delivery ratio for different units’ pause time.

3.4

Percentage of dropped data messages because units’ buffer overflow for 40 simultaneous connections.

3.5

. . . . . . . . . . . . . . . . . . . . 70

ZRP delivery ratio for different number of simultaneous source-destination connections.

3.6

. . . . . . . . . . 69

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

ZRP delivery ratio for different duration of the source-destination connections.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

3.7

ZRP delivery ratio for different units’ pause time. . . . . . . . . . . . 73

4.1

Ad hoc network(left) with its corresponding graph G(right). . . . . . 75

viii

4.2

Virtual Structure: Ring of Rings. . . . . . . . . . . . . . . . . . . . . 81

4.3

Virtual Structure: Hypercube.

4.4

Virtual Structure: Cube Connected Cycles.

4.5

Virtual Structure: 3D Torus . . . . . . . . . . . . . . . . . . . . . . . 85

4.6

Rings of Rings with 3 rings (x = 3) and 3 scouts per unit (s = 3). . . 90

4.7

Tree T17 , built when a unit wants to send a message to unit 17. . . . 91

4.8

Virtual path computed from the source unit 0 to the destination unit 17.

4.9

. . . . . . . . . . . . . . . . . . . . . 83 . . . . . . . . . . . . . . 84

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Physical route through which the RTRANS should be forwarded. . . 93

4.10 Physical route through which the RTRANS is forwarded.

. . . . . . 93

4.11 Physical route of a RTRANS message. . . . . . . . . . . . . . . . . . 94 4.12 Physical route of a RTRANS message without loops. . . . . . . . . . 94 4.13 Cutting loops at the destination. . . . . . . . . . . . . . . . . . . . . 95 4.14 Cutting loops at the intermediate units. . . . . . . . . . . . . . . . . 95 4.15 Substitution of the virtual path with the detour when unit k finds a broken route: a: virtual path; b: detour; c: new RTRANS virtual path.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

4.16 Route Translation message. . . . . . . . . . . . . . . . . . . . . . . . 103 4.17 Route Request message. . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.18 Route Reply message.

. . . . . . . . . . . . . . . . . . . . . . . . . . 107

4.19 Route Error message.

. . . . . . . . . . . . . . . . . . . . . . . . . . 109

4.20 Route Reply message.

. . . . . . . . . . . . . . . . . . . . . . . . . . 113

4.21 Shortcut in virtual path translation.

. . . . . . . . . . . . . . . . . . 117

ix

5.1

Simulator validation: Comparison of the delivery ratio with 10(left) and 20(right) simultaneous CBR connections. . . . . . . . . . . . . . 124

5.2

Simulator validation: Comparison of the delivery ratio with 30(left) and 40(right) simultaneous CBR connections. . . . . . . . . . . . . . 124

5.3

Simulator validation: Comparison of the route acquisition delay with 10(left) and 20(right) simultaneous CBR connections.

5.4

Simulator validation: Comparison of the route acquisition delay with 30(left) and 40(right) simultaneous CBR connections.

5.5

. . . . . . . . 125

. . . . . . . . 125

Comparison of the average number of hops for RTRANS messages for 20 connections (left) and 40 connections(right). . . . . . . . . . . . . 128

5.6

Average number of high priority RREQ messages per CBR connection for 20(left) and 40(right) connections.

5.7

. . . . . . . . . . . . . . . . . 129

Average number of RTRANS messages per CBR connection for 20(left) and 40(right) connections. . . . . . . . . . . . . . . . . . . . . . . . . 130

5.8

Number of total hop transmissions for scouts update with 20(left) and 40(right) connections. . . . . . . . . . . . . . . . . . . . . . . . . 131

5.9

Total hop transmissions of low priority messages with and without proactive scout update for 20(left) and 40(right) connections.

. . . . 132

5.10 Delivery ratio of VRP with and without hello messages to maintain up-to-date units’ information about their neighbors.

. . . . . . . . . 133

5.11 Route Acquisition Delay of VRP with and without hello messages to maintain up-to-date units’ information about their neighbors. . . . . 133 5.12 Delivery ratio: different simultaneous CBR connections(left) and different CBR connection duration (right). . . . . . . . . . . . . . . . . 134

x

5.13 Messages per CBR connection: delivery ratio(left) and lost DATA messages because of full buffer(right).

. . . . . . . . . . . . . . . . . 135

5.14 Transmission range: delivery ratio(left) and average delay to establish a route(right).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

5.15 Units’ pause time: Delivery ratio(left) and average delay to establish a route(right).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

5.16 Number of units: Delivery ratio(left) and average delay to establish a route(right).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

5.17 Number of units: size of the virtual path.

. . . . . . . . . . . . . . . 138

5.18 Units’ velocity with different CBR connections: delivery ratio. . . . . 140 5.19 Units’ velocity with different CBR connections: dropped DATA messages.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

5.20 Units’ velocity with different connections duration: delay to establish a route. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 5.21 Units’ velocity with different connections duration: delivery ratio(left) and average delay to establish a route(right).

. . . . . . . . . . . . . 141

5.22 VRP versus DSR: Delivery ratio as a function of the units’ speed for 20(left) and 40(right) simultaneous CBR connections.

. . . . . . . . 144

5.23 VRP versus DSR: Delivery ratio as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. . 144 5.24 VRP versus DSR: Delivery ratio as a function of the number of units in the network (left) and as a function of the units’ transmission range (right).

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

5.25 VRP versus DSR: Delivery ratio as a function of the units’ pause time. 146

xi

5.26 VRP versus DSR: Delivery ratio as a function of the number of simultaneous CBR connections.

. . . . . . . . . . . . . . . . . . . . . 147

5.27 VRP versus DSR: Delay to build a route as a function of the units’ speed for 20(left) and 40(right) simultaneous CBR connections. . . . 149 5.28 VRP versus DSR: Delay to build a route as a function of units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 5.29 VRP versus DSR: Delay to build a route as a function of the number of units in the network.

. . . . . . . . . . . . . . . . . . . . . . . . . 150

5.30 VRP versus DSR: Delay to build a route as a function of the units’ transmission range.

. . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5.31 VRP versus DSR: Delay to build a route as a function of the units’ pause time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 5.32 VRP versus DSR: Delay as a function of the number of simultaneous CBR connections.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

5.33 VRP versus DSR: Routing load as a function of the units’ speed with 20 simultaneous CBR connections. . . . . . . . . . . . . . . . . . . . 154 5.34 VRP versus DSR: Routing Load as a function of the units’ speed with 40 simultaneous CBR connections. . . . . . . . . . . . . . . . . . . . 155 5.35 VRP versus DSR: Routing Load as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. . 155 5.36 VRP versus DSR: Routing Load as a function of the number of units in the network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 5.37 VRP versus DSR: Routing Load as a function of the units’ transmission range.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

xii

5.38 VRP versus DSR: Routing Load as a function of the units’ stop time for units’ velocities 5m/s and 10m/s. . . . . . . . . . . . . . . . . . . 157 5.39 VRP versus DSR: Routing Load as a function of the units’ stop time for units’ velocities 15m/s and 20m/s.

. . . . . . . . . . . . . . . . . 157

5.40 VRP versus DSR: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 0m/s and 2m/s. . . 158 5.41 VRP versus DSR: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 4m/s and 6m/s. . . 158 5.42 VRP versus DSR: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 0m/s and 2m/s.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.43 VRP versus DSR: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 4m/s and 6m/s.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

5.44 VRP versus DSR: Average size of the units’ routing table. . . . . . . 162 5.45 Delivery Ratio of ZRP with unicast and multicast for bordercasting.

163

5.46 Route Acquisition Delay of ZRP with unicast and multicast for bordercasting.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5.47 Routing Overhead of ZRP with unicast and multicast for bordercasting.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5.48 VRP versus ZRP: Delivery ratio as a function of the units’ speed for 20 simultaneous CBR connections of at most 15 seconds duration.

. 165

5.49 VRP versus ZRP: Delivery ratio as a function of the units’ speed for 40 simultaneous CBR connections of at most 15 seconds duration.

. 166

xiii

5.50 VRP versus ZRP: Delivery ratio as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. . 166 5.51 VRP versus ZRP: Delivery ratio as a function of the units’ pause time. 167 5.52 VRP versus ZRP: Delivery ratio as a function of the number of simultaneous CBR connections.

. . . . . . . . . . . . . . . . . . . . . 168

5.53 VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ speed for 20 simultaneous CBR connections. . . . . . . . . 170 5.54 VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ speed for 40 simultaneous CBR connections. . . . . . . . . 170 5.55 VRP(left) versus ZRP(right): Delay to build a route as a function of units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 171

5.56 VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ pause time, for units’ velocity of 5m/s and 10m/s. . . . . . 172 5.57 VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ pause time, for units’ velocity of 15m/s and 20m/s. . . . . 172 5.58 VRP(left) versus ZRP(right): Delay as a function of the number of simultaneous CBR connections for units’ velocity of 0m/s and 2m/s. 173 5.59 VRP(left) versus ZRP(right): Delay as a function of the number of simultaneous CBR connections for units’ velocity of 4m/s and 6m/s. 173 5.60 VRP versus ZRP: Routing load as a function of the units’ speed with 20 simultaneous CBR connections. . . . . . . . . . . . . . . . . . . . 175 5.61 VRP versus ZRP: Routing Load as a function of the units’ speed with 40 simultaneous CBR connections. . . . . . . . . . . . . . . . . . . . 176

xiv

5.62 VRP versus ZRP: Routing Load as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. . 176 5.63 VRP versus ZRP: Routing Load as a function of the units’ stop time for units’ velocities 5m/s and 10m/s. . . . . . . . . . . . . . . . . . . 177 5.64 VRP versus ZRP: Routing Load as a function of the units’ stop time for units’ velocities 15m/s and 20m/s.

. . . . . . . . . . . . . . . . . 177

5.65 VRP versus ZRP: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 0m/s and 2m/s. . . 179 5.66 VRP versus ZRP: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 4m/s and 6m/s. . . 179 5.67 VRP versus ZRP: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 0m/s and 2m/s.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

5.68 VRP versus ZRP: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 4m/s and 6m/s.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

List of Algorithms A.1 Procedure LoopFree. . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 A.2 Procedure Scouts Update . . . . . . . . . . . . . . . . . . . . . . . . . 201 A.3 Procedure Detour. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 A.4 Algorithm used by the source on the Route Acquisition phase. . . . . 203 A.5 Algorithm used when a unit receives a RTRANS. . . . . . . . . . . . 203 A.6 Algorithm used by the last scout when it receives a RERR. . . . . . . 204 A.7 Algorithm used when the RERR reaches the source of the RTRANS. 204 A.8 Algorithm used when a unit receives a RREQ. . . . . . . . . . . . . . 205 A.9 Algorithm used when a unit receives a RREP. . . . . . . . . . . . . . 205

xvi

Chapter 1 Introduction Wireless networks are the subject of widening research as they may provide communication and information processing from virtually anywhere and anytime. Wireless units are often small, mobile, battery powered devices, and communicate with each other through radio signals. As units use radio signals to communicate, they have a limited transmission range. Wireless units can only communicate directly with units that are inside their transmission ranges. To communicate with units that are outside its transmission range, a unit must rely on other units to forward the messages to the destination. A direct communication between two units is called a single hop communication, while the communication is said multihop when a unit must rely on other units to forward its messages. A multihop communication is composed of several single hop communications one after another. Mobility is an important feature of wireless networks. It allows users to move freely, as long as they stay connected to each other or to base stations [34]. For example, a mobile phone user can travel several hundred kilometers while maintaining a single conversation, because the mobile stays connected to cell towers.

2

Chapter 1. Introduction

Flexibility is also an important aspect of wireless networks, which are suitable for rapid development even in remote or inaccessible environments [34]. Wireless networks can be divided into two types: infrastructured networks and independent networks, according to whether or not base stations are present in the network, respectively. Infrastructured networks are distinguished by the presence of at least one base station or access point in the network. The base station is used for all communications, including communications between two mobile units that are within each other’s transmission range. So, if two units want to communicate, the sender must send the message to the base station and then the base station sends the message to the destination. A unit can communicate with any other unit as long as both of them stay inside the base station transmission range, even though no restriction is made over the distance between the two units. The base station can also be connected to a wired network. This allows mobile units to gain network services by connecting with the base station. Wireless networks can use a number of base stations to connect mobile units to an existing network. The infrastructure of a wireless network is almost the same either connecting a single unit or hundreds of units. To establish a wireless network over an area it is only needed to deploy base stations and antennas in the area. Once the infrastructure is built, adding a user to the network is costless. Independent networks are wireless networks in which there is no base station. In such networks, units communicate directly with each other. A direct communication between two units is only possible if they are inside each other’s transmission range, otherwise, they must rely on other units to forward their messages. For example, in figure 1.1 units a and b can communicate directly because they are within each

3

other’s transmission range, while units a and d cannot communicate directly: they must rely on units b and c to forward their messages to each other. Independent networks are also called ad hoc networks, and from now on they will be addressed in this way.

a

b

c

d

Figure 1.1: Multihop wireless network. Ad hoc networks are best suited for applications in environments where fixed infrastructures are unavailable or unfeasible. Examples of such applications are communication in remote or hostile environments, management of emergencies, and disaster recovery. Given that units have a limited transmission range, ad hoc networks are often multihop, and each unit must act as a router for other units’ messages. As the units of an ad hoc network are not homogeneous, their transmission devices may provide different transmission ranges; i.e., unit i can send messages to unit j directly, but unit j cannot send messages to unit i directly. Although wireless links may be asymmetric, in this work we restrict considerations to networks with bidirectional links, i.e., networks where all units have the same transmission range. Since ad hoc networks do not rely on base stations, delivery messages between units is relatively complex. The protocol used to forward messages through the network is called a routing protocol.

4

Chapter 1. Introduction

1.1

Routing

The task of a routing protocol is to construct and to maintain routes between units of a network. Routing protocols can be divided in three major classes: DistanceVector, Link-State and Source Routing protocols. In Distance-Vector routing protocols [7, 75, 76, 81] every unit of the network must maintain a routing table in which all possible destinations within the network are recorded. Each entry of the routing table is referred to a single destination and it contains information that include: a neighbor of the source (the first hop in order to reach the destination); the number of hops needed to reach the destination passing from the neighbor as the first hop. Messages sent in distance-vector routing protocols carry only the source and the destination addresses. When a unit receives a message, it just looks in its routing table which is the next hop to which it must send the message in order to reach the destination, then it sends the message to this unit. Distance-vector routing protocols are efficient and easy to implement; however they do not prevent the formation of loops, as units compute next hops in a completely distributed fashion. There are several modifications to avoid the formation of loops in distance-vector protocol, such as [30, 45, 67]. In Link-State routing protocols [66] each unit maintains a view of the network topology with a cost for each link, and it uses this view to obtain minimum cost routes to each destination. To keep this view up-to-date, each unit regularly broadcast the link costs of its outgoing links to all other units. Each unit requires O(N 2 ) space in order to store the view of the entire network topology, where N is the number of units in the network. The dissemination time is small and proportional

1.1. Routing

5

to D, where D is the network diameter in hops. A performance comparison between distance-vector and link-state routing protocols can be found in [89]. In Source Routing protocols [8, 9, 36, 47], every unit of the network maintains a routing table in which it stores routes to reach the desired destinations. Each entry of the routing table has a complete route from the source to the destination; i.e., each entry of the routing table consists in a list of hops through which the source can reach the destination. Each unit records only its desired routes in its routing table. Messages sent in source routing protocols carry the whole route that they must traverse in order to reach the destination. When a unit receives a message, it simply looks in the message route which is the next hop and forwards the message to this unit. This means that in source routing protocols messages are longer, because they must carry on the whole route through which they must pass. However, source routing protocols do not suffer with the formation of loops. In both distance-vector and source routing protocols, when the source does not possess a route to reach a desired destination, it must find such a route. To find a route to another unit the source sends a route-search message through the network. This phase of the routing protocol is called route discovery or route acquisition phase. In distance-vector protocols, the route-search message sets the route from the source to the destination by setting the route in the intermediate units. When the route-search message goes from the source to the destination, the intermediate units store in reverse order the route travelled so far from the source. When the destination receives the route-search message, it sends a reply to the source through the reverse route. This reply sets, in the intermediate units, the route through which the source can reach the destination.

6

Chapter 1. Introduction

In source routing protocols, the route-search message collects the route through which it passes until it reaches the destination. When the route-search reaches its destination, the collected route is a route between the source and the destination. Then the destination returns a reply message with the collected route to the source. This message travels from the destination to the source along the reverse of the route that was collected by the route-search message.

1.1.1

Routing in Ad Hoc Networks

Because the units of ad hoc networks are mobile, the network topology is subject to frequent changes, implying that routing protocols must react quickly to topology changes. Routing in ad hoc networks should be a distributed algorithm that computes multiple, loop-free routes while keeping the communication overhead to a minimum [6]. The existing routing protocols developed for wired fixed networks, do not fit the needs of ad hoc networks as they would consume a large amount of the network’s bandwidth and of the unit’s processing power. For these reasons, routing in ad hoc networks is a challenging field [75]. Routing protocols for wireless ad hoc networks can be divided into two main categories: proactive and reactive routing protocols. Proactive routing protocols [63, 68, 75] attempt to maintain consistent, up-todate routing information from each unit to every other unit in the network [96]. Each unit should maintain one or more routing tables where it stores routing information to all other units in the network. To maintain the consistency of such routing tables, units must broadcast their routing tables periodically. If they succeed in keeping routing information up-to-date, units can send messages without any delay. Reactive routing protocols [47, 64, 71, 76] create routes only when a unit desires

1.2. IEEE 802.11

7

to send a message. When a unit wants to send a message, it must first find a route to the desired destination, then it can send the message to the destination along this route. Reactive routing protocols avoid the overhead to maintain up-to-date routing tables, but units have to pay a delay on sending their messages. Other categories of routing protocols can also be found in the literature like: Hybrid routing protocols [36, 81] that mix the proactive and the reactive approaches; Geographical routing protocols [6, 8, 9, 54, 82] that use location information to route messages; Power Aware routing protocols [16, 60] that attempt to reduce the power consumption of the units; Hierarchical routing protocols [26, 29, 35, 52, 55, 62, 84, 90] that are focused on imposing a hierarchical structure to the units; Secure routing protocols [40, 93, 102] that are focused on improving the security of the network in hostile environments; Quality of Service routing protocols [17, 22] that are focused in providing real-time quality of service criteria, such as bandwidth constraint, endto-end message delay, and delay jitter. All these categories will be discussed in details on Chapter 2.

1.2

IEEE 802.11

Several wireless technologies have been targeted for data transmission. Bluetooth is a standard used to build small networks between peripherals. Third-Generation (3G) mobile telephony promises data rates of megabits per second, as well as “always on” connectivity. IEEE 802.11 is the most successful technology for wireless networking until nowadays. IEEE 802.11 is a member of the IEEE 802 family, which is a series of specifications for local area networks [14, 34, 41]. The base specification of the 802.11 includes

8

Chapter 1. Introduction

the 802.11 medium access control (MAC ) and two physical layers: a frequencyhopping spread-spectrum and a direct-sequence spread-spectrum. Later revisions have added additional physical layers: high-rate direct-sequence and orthogonal frequency division multiplexing [34, 41]. 802.11 splits the physical layer into two generic components: physical layer convergence procedure, which maps the MAC frames onto the medium, and physical medium dependent, which transmits the frames [34, 41]. The key to the 802.11 specification is the MAC. It controls the data transmissions and rides on every physical layer. Different physical layers may provide different transmission speeds through all of which are supposed to interoperate. The MAC protocol is a set of rules to allow the efficient use of the medium. The 802.11 MAC layer uses a carrier sense multiple access (CSMA) scheme to control access to the transmission medium [34, 41]. Using CSMA, a unit listens to the medium before it starts the transmission, to find out if there is any transmission happening. If the medium is clear, it can start its transmissions, if not, it postpones the transmission for a certain time. In wireless networks, collisions waste valuable transmission capacity, so rather than the collision detection (CSMA/CD) technique employed in the Ethernet, the 802.11 MAC uses a collision avoidance (CSMA/CA) technique. 802.11 uses a distributed access scheme without any centralized controller, and all units use the same method to gain access to the medium [34, 41]. In ad hoc networks, units may not be able to communicate with other units directly. For example, in figure 1.2 unit b can communicate with both units a and c, but the limited transmission range prevents units a and c to communicate with each other directly. From the perspective of unit a, unit c is called a hidden unit. If

1.2. IEEE 802.11

9

a simple transmit-and-pray protocol is used, it would be possible for units a and c to transmit simultaneously, thus rendering unit b unable to make sense of anything [34], units a and c would not even have any indication of the error, because the collision was locally on unit b.

a

b

c

Figure 1.2: Hidden unit problem. Collisions from hidden units may be difficult to be detected in wireless network, because wireless transceivers are generally half-duplex, i.e., they are not able to transmit and receive at the same time. To prevent collisions and the hidden unit problem, 802.11 allows units to use Request to Send (RTS ) and Clear to Send (CTS ) messages. A complete specification of the RTS/CTS protocol can be found in [34]. The IEEE 802.11 RTS/CTS protocol works only with bidirectional links. Thus, we restrict the presentation of this work to ad hoc networks with bidirectional links. Some power conservation techniques can be performed at the MAC layer [12, 96]. Firstly, unnecessary collisions should be eliminated as much as possible since retransmissions consume power. Secondly, in infrastructured networks, units using 802.11 can maximize their battery life by shutting down their radio transceivers, going to sleep periodically. During sleeping periods, the base station can buffer the messages directed to the sleeping units. A unit can retrieve the buffered messages by asking the base station for these messages. However, this technique cannot

10

Chapter 1. Introduction

be simply extended to ad hoc networks. Thirdly, in broadcast networks, instead of having the units powered all the times, it is possible to broadcast a schedule specifying the transmission times for each unit, allowing units to switch off their radio transceivers. To reduce the power consumption on collisions resolution, a new scheme is proposed in [85]. The proposal is to decide the messages delay based on the remaining amount of energy left at each unit, instead of using the unit’s id [15] or the message arrival time [7]. Another proposal for power saving on the MAC layer is PAMAS (Power-Aware Multiple Access protocol with Signalling) [91]. The original 802.11 MAC protocol does not support any type of priority access to the wireless medium. However, a new proposed supplement of the 802.11, the 802.11e, introduces the concept of traffic categories. Each unit has eight traffic categories, or priority levels. A complete specification of the IEEE 802.11e can be found in [44, 65]. The 802.11 is a family of specifications, there are currently four specifications in the family: 802.11a, 802.11b, 802.11e, 802.11g. All four specifications use the CSMA/CA protocol for medium sharing. A full specification of the 801.11 can be found in [34, 41, 42, 43, 44]. The 802.11a specification applies to wireless ATM systems and it is used in access hubs. It operates at radio frequencies between 5GHz and 6GHz. It uses a modulation scheme known as orthogonal frequency-division multiplexing that makes possible data speeds as high as 54 Mbps. The 802.11b uses the modulation method known as complementary code keying (CCK), which is less susceptible to multipath-propagation interference. Its transmission speed reaches 11 Mpbs.

1.3. Power Consumption

11

The 802.11e implements some quality of service issues on wireless networks. It allows traffic differentiation, using EDCF as the modulation method. The 802.11g offers wireless transmission over relatively short distances at up to 54 Mbps and it operates in 2.4 GHz range, what makes it compatible with the 802.11b.

1.3

Power Consumption

Another challenge in ad hoc networks is the power consumption. As mobile units are dependent on battery power, it is important to minimize the energy consumption. Studies show that the major energy consumers of mobile devices are the CPU, display, drivers, memory, keyboard/mouse and principally the wireless interface [48]. Consequently, energy conservation techniques have been introduced in hardware design of mobile terminals, for instance: low-power displays, algorithms to reduce the power consumption of drivers, and low-power CPUs have been developed. On the other hand, high capacity batteries are needed. Additional power savings may result by incorporating low-power strategies into the design of network protocols used for data communication. Since the network interface may often be idle, power could be saved by turning the network interface off when not in use. However, this approach is not fully suitable for ad hoc networks. In such networks, units must participate in multi-hop routing protocols, and cannot turn the network interface on just to receive the messages addressed to it. Thus the coordination between routing protocols and energy saving must be acute in ad hoc networks [4, 16, 48, 60]. Power aware routing protocols will be discussed in Chapter 2.5. Another technique to save energy in ad hoc network relies on controlling the net-

12

Chapter 1. Introduction

work topology. Topology control algorithms attempt to make the network topology energy efficient by setting the units’ transmission range in such a way that a target property, like the connectivity of the network, is guaranteed. Though it has been shown that determining an optimal range assignment is a NP-Hard problem for two and three dimensional cases, several topology control mechanisms can be found on the literature [5, 10, 59, 61, 86, 92].

1.4

Security

Security is an important issue for ad hoc networks, especially for those securitysensitive applications, like military tactical operations. According to [40], there are two main attacker classes: passive and active. The passive attacker does not send messages; it only eavesdrops on the network. The major advantage for the attacker is that, in a wireless environment, the attack is usually impossible to detect. This also makes defending against such attacks difficult. Furthermore, routing information can reveal relationships between units. For example, if a route to a unit is requested more often than to other units, the attacker might expect that this unit is important for the functioning of the network, and disabling it could bring the entire network down. Other important information that can be disclosed by routing data is the location of units. Even if the exact location of the units could not be pointed, the attacker might be able to discover information about the network topology. However, in IP networks it is possible to defend against such attacks, for example using IPsec [53]. To perform an active attack the attacker injects messages into the network and generally also eavesdrops. A major difference in comparison with passive attacks is

1.5. Goals of this dissertation

13

that active attacks can sometimes be detected. The following presents some types of attacks that can usually be easily performed against ad hoc networks: • Black Hole - The black role attack is briefly introduced in [101] . In the attack, a malicious unit uses the routing protocol to advertise itself as having the shortest route to the destination, thus it intercepts all messages to this destination. • Routing Table Overflow - In a routing table overflow attack, the attacker attempts to create routes to nonexistent units. The goal is to create enough routes to prevent new routes from being created or to overwhelm the routing protocol implementation. • Sleep Depravation - The sleep depravation torture is briefly introduced in [93]. Usually, this attack is practical only in ad hoc networks, where battery life is a critical parameter. Battery powered devices try to conserve energy by transmitting only when absolutely necessary. An attacker can attempt to consume batteries by requesting routes, or forwarding unnecessary messages to units using, for example, a black hole attack. • Location Disclosure - A location disclosure attack can reveal something about the location of units or the structure of the network. The information gained might reveal which units are adjacent to the target unit.

1.5

Goals of this dissertation

In this thesis we present a new routing protocol for ad hoc networks, called Virtual Routing Protocol (VRP ). The new protocol aims at providing reliable routing, where

14

Chapter 1. Introduction

reliability is defined as the ability to deliver most of the data messages in spite of units failures, links breakdowns, or buffer overflows caused by overloaded units. VRP is a hybrid source routing protocol. Units running VRP attempt to maintain routes to some units proactively, while they construct routes to other units on-demand. The specification of VRP can also be found in [3]. VRP relies on the following assumptions: (i) bidirectional links; (ii) one-hop neighbor knowledge. The use of bidirectional links guarantees that if unit a can send a message to unit b, unit b can send a message to unit a. The identification of a unit’s neighbors, the latter assumption, may be provided directly by the MAC protocols. If the MAC protocol cannot provide this information, hello messages can be used to provide the required information to the units. VRP defines a logical structure over the network. The logical structure is unrelated to the physical position of the units, being based only on the units’ ids. The logical structure is a directed graph, where in link u → v, unit u is said a scout to unit v and unit v is said a peered unit of unit u. In VRP the proactive task is assigned to the scouts, which are supposed to maintain consistent and up-to-date routes to reach their peered units. When a unit i wants to communicate with another unit j and it does not have a route to reach the destination, unit i requests a route to j to some scout of j. To this purpose, unit i needs to find a route to a scout of j. If i does not have such a route it repeats the process, requesting to the scouts of the scouts of j to routes to

1.5. Goals of this dissertation

15

the scouts of j, and so on. The list of scouts from the source to the destination is called a virtual path. In this way, if the scouts have valid routes to their peered units, units can find routes without using floodings, thus reducing the overhead to find routes. This advantage of VRP is counterbalanced by the overhead to update routes in the scouts. However, the overhead to update routes in the scouts is smaller than the overhead to find routes from the source to the destination using floodings, because scouts updates can be done in low priority and routes archived in a scout can be used by several sources. VRP uses three priority levels on messages. The priority levels are used internally by the units to decide the order in which they send messages. When unit i has messages of different priorities to send, it firstly sends the one with the highest priority. Every message used by the scouts to update their routes to their peered units are sent in the lowest priority. This means that most floodings are executed in the lowest priority, while the messages of higher priority are often unicast messages. In other routing protocols, like [47, 76], floodings need to have a priority higher than other messages. By reducing the congestion of the network, VRP succeeds in avoiding units’ buffer overflows. This enables VRP to deliver almost all data messages generated by the sources. Under light traffic conditions, VRP has a delivery ratio of more than 95%, while under heavy traffic conditions it is never below 75%. Under the same scenarios, the well known DSR protocol achieves delivery ratios of 70% and 50% respectively. The delivery ratio of VRP is almost independent of the units’ speed, while delivery ratio of DSR is inversely proportional to the units’ speed. Under light traffic conditions, VRP also outperforms ZRP a well-known hybrid

16

Chapter 1. Introduction

routing protocol. In such scenarios, the delivery ratio of ZRP can be as low as 82% of the generated data messages, while the delivery ratio of VRP is never below 95%. However, the performance of VRP decreases as the traffic becomes heavier, while the performance of ZRP remains almost constant. Under heavy traffic conditions, the delivery ratio of ZRP is around 80%, while the delivery ratio of VRP decreases to 75% of the generated data messages. The price to be paid by VRP is an increased delay in establishing routes from sources to destinations. Another advantage of the virtual routing protocol is the small size of the units’ routing tables. In VRP, unit j maintains routes only to its peered units and to the units to which j is currently sending messages. Using the virtual routing protocol, units maintain O(k) routes in their routing tables, where k is the number of peered units of each unit, while in other routing protocols, such as the DSR [47] and ZRP [36], units maintain O(N ) routes in their routing table, where N is the number of units in the system. VRP incorporates several strategies to improve the delivery ratio. One of these strategies is Multiple Destinations Floodings. Multiple destination floodings allow units to find routes to more than one unit per flooding. This strategy benefits VRP because units always know to which other units they must keep routes proactively. Thus, considering k as the number of peered units, a unit sends just one flooding destined to k units to update the routes to all of its peered units. This causes much less overhead, in comparison to sending k single destination floodings. This thesis is organized as follows: Chapter 2 is an overview of routing protocols for wireless ad hoc networks; Chapter 3 discusses reliability issues of routing protocols; Chapter 4 describes the Virtual Routing Protocol in details; Chapter 5

1.5. Goals of this dissertation

17

presents the simulation results, a comparison between VRP and DSR and a comparison between VRP and ZRP; and Chapter 6 draws the conclusions and anticipates future work.

18

Chapter 1. Introduction

Chapter 2 Routing Protocols Routing in ad hoc networks is, generally, multihop since units may not be within wireless transmission range of one another. Also routes can often get disconnected as units can move freely and randomly. Thus, routing protocols for ad hoc networks should be distributed and must adapt to frequent changing on the network topology, while keeping the communication overhead to a minimum. Ad hoc routing protocols can be classified in: • Proactive routing protocols [18, 31, 32, 63, 68, 72, 73, 74, 75, 80, 83]. These protocols attempt to maintain consistent and up-to-date routing information from each unit to every unit in the network. When a unit wants to send a message, the route to the destination is already known and can be used immediately. However, proactive routing protocols suffer the disadvantage of additional control traffic that is needed to continually update stale route entries. Proactive routing protocols will be discussed in Section 2.1. • Reactive routing protocols [1, 2, 21, 25, 47, 64, 71, 74, 76, 83]. These protocols do not maintain information about all routes. Often, when a unit wants to

20

Chapter 2. Routing Protocols

send a message, it needs to find a route to the destination, and then it uses this route to send the message. Although reactive protocols need some time to find routes, they do not have the overhead of keeping up-to-date information about the entire network. Reactive routing protocols will be detailed in Section 2.2. • Hybrid routing protocols [36, 39, 74, 81]. These protocols mix the proactive and the reactive approaches, normally using a proactive approach inside a cluster or a zone of the network, and a reactive approach to an inter-cluster or an inter-zone communication. Hybrid routing protocols will be presented in Section 2.3. • Geographical routing protocols [6, 8, 9, 13, 51, 54, 74, 82, 94]. Also called location-based routing protocols, these protocols use location information to decrease the overhead of route discovery and/or route maintenance. The location information may be obtained using the GPS (Global Positioning System) [50], or any other technique that allows the units to have some location information [82, 88]. Geographical routing protocols will be introduced in Section 2.4. • Power Aware routing protocols [4, 16, 60]. As the energy consumption of the network interface can be significant, a unit could save a considerable amount of power by turning it off. In ad hoc networks, however, units must participate of higher-level routing protocols and must cooperate with each other to deliver messages; consequently, a unit cannot simply turn off its network interface when it does not have anything to transmit. A good power saving coordination technique should have the following characteristics: (i) it should allow as many units as possible to turn their network interface off most of the time, since even

21

idle devices consume almost as much energy as active ones [28]; (ii) it must forward messages between any pair of units as fast as if all units were awake [16]. Thus, power saving and routing protocols must be coordinated [16]. Power aware routing protocols can be found in Section 2.5. • Hierarchical routing protocols [26, 29, 35, 52, 55, 62, 74, 84, 90]. Hierarchical routing schemes are typically used by clustering protocols. The main idea of these protocols consists in grouping the units of the system into clusters in order to improve the scalability and/or to reduce the route acquisition delay. Normally these protocols implement a proactive routing strategy inside clusters, and a reactive routing strategy to route messages among clusters, thus reducing the overhead of the proactive protocols, and also reducing the delay of the route searching phase of the reactive ones. • Secure routing protocols [40, 93, 102]. Secure routing protocols are typically requested when the network is performing security-sensitive applications, like military tactical operations. Secure routing protocols should be robust against dynamically changing topology and malicious attacks. • Quality of Service routing protocols [17, 22]. The provision of Quality of Service (QoS) relies on resource reservation. Hence, the data messages of a QoS connection are likely to flow along the same route, on which the required resources are reserved. According to [17], the goal of QoS routing is two-fold: i selecting routes that have sufficient resources to meet the QoS requirements of all admitted connections; ii achieving global efficiency in resource utilization.

22

Chapter 2. Routing Protocols

2.1

Proactive Routing

In proactive routing protocols, every unit i maintains a routing table with the next hop for each destination. When unit i needs to send a message to unit j, it just searches in its routing table to find unit k which is the next hop to arrive at unit j. Then it sends the message to unit k, which must be a neighbor of unit i. Unit k is a neighbor of unit i if unit k is into the transmission range of unit i. When the neighbor receives the message, it repeats the process. In distance-vector protocols, every unit i maintains, for each destination j, a set of distances {dik (j)}; where dik (j) is the distance, for example the number of hops, from unit i to unit j passing through unit k, which is a neighbor of i. For each unit j, unit i maintains the distances dik (j) for all k. Unit i treats neighbor x as a next hop for a message destined for j if dix (j) = min{dik (j)}. The succession of next hops chosen in this manner leads to j along the shortest path. In order to keep the routing table up-to-date, each unit monitors its outgoing links and periodically broadcasts to its neighbors its own routing table. The above protocol is the classical Distributed Bellman-Ford protocol (DBF ) [7], which is an efficient and easy protocol to implement. However, it can cause the formation of loops, as units choose their next hops in a completely distributed fashion based on information which can be incorrect. There are some modifications [30, 45, 67] to the DBF protocol to prevent the formation of loops, although they are difficult to port to ad hoc networks due to the rapid topology change of such networks.

2.1. Proactive Routing

2.1.1

23

Destination-Sequenced Distance Vector

The Destination-Sequenced Distance Vector (DSDV ) protocol [75] is a variant of the Distributed Bellman-Ford method, with the improvement that it is free from loops. In DSDV, messages are transmitted between units using routing tables which are stored at each unit. Each routing table lists all available destinations, the number of hops and the next hop in order to reach them. DSDV requires that each mobile unit broadcasts its own routing table to its current neighbors. Entries in a routing table may change dynamically, and the broadcast must be done often enough to ensure that every unit is able to locate any other unit with high probability. For every unit, broadcasts are assigned increasing sequence numbers, thus broadcasts can be uniquely identified. The route with the most recent sequence number is always used. To guarantee that routing tables are loop-free, units maintain for each possible destination, i.e., for each entry of the routing, the last sequence number received from this unit. When a neighbor of unit i receives a broadcast from unit i, it updates the sequence number of the entry relative to unit i in its routing table, and then rebroadcasts its own routing table. When unit j, which is not a neighbor of i, receives the broadcast from unit k, it compares its own routing table with the received one, and if the sequence number of the entry relative of unit i is newer, then j updates its entry relative to i. To this purpose, unit j updates the sequence number for the received one and unit k becomes the next hop to reach i. After updating its routing table, unit j rebroadcasts the updated routing table. To maintain the consistency of the routing tables, each unit transmits updates periodically and it does the same immediately after receiving significant new infor-

24

Chapter 2. Routing Protocols

mation. Units also keep data about the time elapsed between the arrival of the first route and the arrival of the best route to each particular destination. This data can be used to avoid advertisement of routes that are about to change, then reducing the number of rebroadcasts of possible route entries that are expected to arrive with the same sequence number. This damps fluctuations of the routing tables. One of the most important parameters of the DSDV protocol is the choice of the time interval between broadcasts of routing tables. When any new or substantial modification occurs in the networks, this information must be transmitted soon, effecting as soon as possible all units, although it would be calamitous if the movement of one unit caused a storm of broadcasts on the network. DSDV is an effective routing protocol for ad hoc networks of small populations of mobile units, but it is fairly a brute force approach, because it relies on the periodic advertisement and global dissemination of connectivity information [76].

2.2

Reactive Routing

Reactive protocols, unlike proactive protocols, do not have to maintain any up-todate information about the network. Protocols of this type create routes on-demand, i.e., only when the source desires it. When a unit wants to send a message to another unit, the source initiates a route discovery process, usually flooding, within the network. If the destination is reached, it sends back to the source the discovered route. The route discovery process is completed when a route to the destination is found or all possible routes of the networks are examined. Once a route is established, it is maintained by some procedure, in a routing table until either the destination becomes unreachable

2.2. Reactive Routing

25

through it, or the route is no longer desired by the source. However, a number of reactive routing protocols maintain routes in the routing tables even if they are no longer desired. In reactive routing protocols, the control traffic overhead is greatly reduced since no periodic exchanges of route tables are required. A number of reactive routing protocols have been proposed, like the DSR [47] and the AODV [76], both will be detailed in Sections 2.2.1 and 2.2.2 respectively. Other reactive routing protocols can be found in [74, 83].

2.2.1

Dynamic Source Routing

Source routing is a routing technique in which the sender of a message determines the complete sequence of units through which the message should be forwarded. The sender explicitly lists this route in the messages’ header, thus when unit i receives a message, it just looks in the header of the message and forwards the message to the next hop. Source routing has been used in a number of contexts for routing in wired networks, using either statically configured routes or dynamically constructed source routes [24, 49]. The Dynamic Source Routing (DSR) protocol [47] is an on-demand routing protocol that is based on the concept of source routing. Mobile units are required to maintain route caches, which contain the source routes of which the mobile is aware. Entries in the route cache are continually updated as new routes are learned. To send a message, the sender constructs a source route in the message’s header, giving the address of each host through which the message should be forwarded in order to reach the destination. The sender then transmits the message to the first hop in the source route. When a unit receives a message, if the unit is not the final

26

Chapter 2. Routing Protocols

destination of the message, it simply transmits the message to the next hop in the source route of the message’s header. When the message reaches its destination, it is delivered to the proper application. As messages carry on the entire route between the source and the destination, other units forwarding this message or overhearing it can easily cache the routing information carried by this message. In DSR, each unit maintains a route cache in which it keeps the routes that it has learned, i.e., a routing table that contains the discovered routes from the unit to the others. When a unit wants to send a message to another unit, it first checks its route caches for a route to the destination. If a route is found, it uses this route to transmit the message. Otherwise, the sender may attempt to discover a route to the destination, using the route discovery phase of the protocol, discussed in Section 2.2.1.1. Each entry in the route cache has associated an expiration period with it, after which the route is deleted from the route cache. A unit must monitor that a route stays connected while it is using it. In DSR this monitoring of the routes in use is called route maintenance, described in Section 2.2.1.2. When route maintenance detects a problems in a route, or receives a route error, the route discovery can be used again to discover a new and correct route to the destination. 2.2.1.1

Route Discovery

Route Discovery allows any source to communicate with another mobile unit when the source has no route from itself to the destination in its route cache. To discover a route, a unit broadcasts a route request, RREQ, message. If the route discovery is successful, the sender of the RREQ receives a route reply, RREP, message with

2.2. Reactive Routing

27

the sequence of hops through which it can reach the destination. A RREQ message contains: the sender’s address, the destination’s address, a unique request id and a route record. The sender and the destination addresses are the addresses of the respective units. The request id is set by the sender of the RREQ, to allow the other units in the network to detect duplicate received RREQ. The route record stores the request’s history, in terms of hops, from the unit initiating the route, up to the unit that has just been reached by this RREQ. When a unit receives a RREQ message, it processes this message in the following order: 1. If the pair (sender’s address, request id ) of this message matches a pair in this unit’s list of recently received requests, then it discards the RREQ; 2. Else, if this unit is the destination of this RREQ, then the route record of this message contains a route from the source to the destination. Thus, this unit returns a copy of this route to the sender of the RREQ in a RREP message. 3. Else, this unit appends its own address to the route record and rebroadcasts the request. The first step ensures that routes are loop-free, and removes later copies of the RREQ that can arrive to a unit through a different route. The two other steps ensure that the message is forwarded until it reaches the destination. Once the destination, unit j, receives a RREQ message, it reverses the route in the route record from the RREQ message, thus obtaining a route between itself and the sender of the RREQ, unit i. Then it sends a RREP message to unit i through the reverse route. When the RREP reaches unit i, a route is set up between units i and j.

28

Chapter 2. Routing Protocols

2.2.1.2

Route Maintenance

When forwarding a message using source route, each unit transmitting the message is responsible for confirming that the message has been received by the next hop. In particular, DSR can use the so called passive acknowledgements: a unit hears the transmission of one of its neighbors to the next unit in the route. A unit can also perform route maintenance by setting a bit in the message to request an explicit acknowledgement from the next hop. If the transmission reports a problem that cannot be recovered, this unit sends a route error, RERR, message to the original sender of the message that encountered the broken link. The RERR message contains the addresses of the units at both ends of the hop error, i.e., the unit that detected the broken link, and the unit to which it was attempting to send the message. The RERR message is forwarded through the reverse route of the message that encountered the broken link. When a unit receives a RERR message, it removes from its cache the route to the unit that causes the broken link, and also all routes that contain this unit. When the RERR reaches its destination, this unit decides if this route is still desired. If so, the route discovery is invoked again, to find another route. 2.2.1.3

Optimizations

Some optimizations can be made in the DSR protocol [74] like: Caching Overheard: A unit forwarding or overhearing any message can add the routing information from this message to its own routing table.

2.2. Reactive Routing

29

Replying to Route Requests Using Cached Routes: A unit, receiving a RREQ message for which it is not the destination, searches in its route caches for a route to the destination of the RREQ. If a route is found, this unit can return a RREP to the initiator of the RREQ, instead of forwarding the RREQ message. The RREP message contains, in the route record, the sequence of hops over which this copy of the RREQ was forwarded, concatenated with the route from this unit to the destination of the RREQ. This implies that units must maintain in their route caches all routes, even the ones that are not required any more. The above procedure can cause RREP “storms” over the network, as any unit in the network, which has a route to the destination, will send a RREP to the source of the RREQ, when they receive the RREQ. If units can put their network interface into promiscuous receive mode, they can delay sending RREP for a short period of time, while listening to discover if the initiator of the RREQ begins to use a shorter route. This delay will prevent that all units send RREPs to the initiator of the RREQ. Route Request Hop Limits: RREQ messages can contain a hop limit that may be used to limit the number of hops that this RREQ can traverse. As the RREQ is forwarded, this limit is decremented, when it reaches zero the RREQ is dropped. Piggyback: To reduce the total number of messages transmitted, hosts can piggyback data on route request and route replay messages.

30

Chapter 2. Routing Protocols

2.2.2

Ad Hoc On-Demand Distance Vector

Ad Hoc On-Demand Distance Vector (AODV ) [76] is built over the DSDV [75] protocol. AODV can be considered an improvement of the DSDV, because it minimizes the number of required broadcasts by creating routes on-demand, instead of maintaining a complete list of routes. The authors classified the AODV as pure on-demand route acquisition system, because units do not rely on active routes nor exchange periodically routing information. To establish routes, AODV uses a broadcast route discovery mechanism, which is similar to the one used in DSR. However, instead of source routing, AODV relies on dynamically established route entries among the intermediate units of a route. This difference implies that messages in AODV do not need to carry the route among which they must be forwarded. AODV utilizes sequence numbers like the DSDV to guarantee that all routes are loop-free and to ensure that units use the most recent route information. AODV also uses a route timer for each route. This timer will cause the deletion of the route from the route table if the route is not used within this time (in AODV a route is not deleted when it is not required anymore). AODV requires that each unit maintains a table that contains the next hop to which the message must be sent to reach the correspondent destination, i.e., when unit i wants to send a message to unit j, it just looks in its table for the next hop, unit k, through which it can reach destination j, then it sends the message to unit k. When unit k receives a message for which it is not the destination, it simply looks in its table which is the next hop, unit l, to reach the destination, and sends the message to l. When the source does not have the next hop for the desired

2.2. Reactive Routing

31

destination, it invokes the route discovery process. 2.2.2.1

Route Discovery

When a unit needs to communicate with another unit which it has no routing information about, it starts a route discovery process to find a route to the destination. The source initiates the route discovery by broadcasting to its neighbors a route request message (RREQ). Each neighbor either replies the RREQ or rebroadcasts the RREQ to its own neighbors. If a unit receives a RREQ more than once, it simply drops the redundant ones. Each RREQ generated by a unit is uniquely identified by the broadcast id field, thus each RREQ can be uniquely identified by the pair (source address, broadcast id ), and it is used to identify redundant RREQ. Reverse Route Setup. The reverse route is automatically set, in the units’ tables, as the RREQ traverses the network. When a unit receives a RREQ, it records, on its table, the address of the first neighbor from which the RREQ came from and uses it to build the reverse route. The reverse route entries must be maintained for at least enough time for the RREQ to traverse the entire network and produce a reply to the sender. Forward Route Setup. A unit replies a RREQ either if it is the destination or if it has a fresh enough route to the destination. The route reply message (RREP) is then sent to the neighbor from which the first copy of the RREQ arrives. The RREP is routed back to the source along the reverse route. While the RREP traverses the reverse route, the units in this route record the address of the neighbor from which they receive the RREP, just like the units do

32

Chapter 2. Routing Protocols

with the RREQ, thus setting up the forward route. When the RREP reaches its destination, a forward and a reverse route are built between the source and the destination of the RREQ. 2.2.2.2

Route Maintenance

Units movement may cause the disconnection of a route. If the source unit moves, it must re-initiate the route discovery process to the destination. If a unit belonging to a route or the destination moves, disconnecting the route, its upstream neighbor notices the movement and propagates a link failure notification to each of its own upstream neighbors. These units propagate the link failure notification to their neighbors and so on, until the notification arrives at the source. The source then may re-initiate the route discovery process if a route to the destination is still desired. 2.2.2.3

Local Connectivity Management

When a unit receives a broadcast from a neighbor, it updates its local connectivity information. However, if a unit remains a certain time without sending any broadcasts, it broadcasts to its neighbors a hello message. The hello messages are not rebroadcast as they are used only to maintain the local connectivity. If unit i fails on receiving broadcasts and hello messages from unit j for a certain period of time, it considers that unit j is not a neighbor anymore. Then, if unit i receives a message which it is supposed to forward to unit j, it generates a link failure notification. Though AODV can use Hello messages to maintain local connectivity among neighbors, it is not required by the protocol.

2.3. Hybrid Routing

2.3

33

Hybrid Routing

Hybrid routing protocols are protocols that mix the proactive and the reactive approaches, normally using a proactive approach inside a cluster or a zone of the network, and a reactive approach to an inter-cluster or an inter-zone communication. This is the case of ZRP [36], SHARP [81] and CARD [39], these protocols will be discussed in Sections 2.3.1, 2.3.2 and 2.3.3, respectively.

2.3.1

Zone Routing Protocol

Zone Routing Protocol (ZRP ), [36], is a hybrid proactive/reactive routing protocol. ZRP limits the proactive phase of the protocol to the local neighborhood, while it uses the reactive phase to search units that are not in the local neighborhood. In ZRP, a unit proactively maintains routes to destinations within its local neighborhood. The local neighborhood is called the routing zone and each unit has its own routing zone. The routing zone of unit i is defined as the collection of units whose minimum hop distance from unit i is no greater than the zone radius. The zone radius is a parameter of the ZRP. For example, if the zone radius is set to 2, then the routing zone of unit i is composed by all units that are at most 2 hops from unit i. Units that are inside the routing zone of unit i can be classified as either peripheral or interior units. Peripheral units are the units whose minimum distance to i is equal to the zone radius of unit i. Interior units are the units whose minimum distance to i is less that the zone radius of unit i.

34

Chapter 2. Routing Protocols

2.3.1.1

Intrazone Routing

Each unit of the network must maintain routing information to all units within its routing zone. Thus, proactive routing updates are only locally propagated. Units learn the topology of their routing zone through a localized proactive scheme, called Intrazone Routing Protocol (IARP ). Even though the authors use a basic link-state protocol as the IARP, they claim that any link-state or distance-vector protocol can be modified to serve as IARP by properly restricting the propagation of topology updates. 2.3.1.2

Interzone Routing

The Interzone Routing Protocol (IERP ) is responsible for reactively finding routes to destinations that are outside a unit’s routing zone. IERP exploits the structure of the routing zone. This is done through what the authors called bordercasting. Bordercasting directs messages from a unit to its peripheral units. When a unit wants to communicate with another unit that is not inside its routing zone, it bordercasts a route request to its peripheral units. A peripheral unit checks if the destination is within its zone, if so, it returns a route reply to the source indicating that a route to the destination was found; otherwise, it sends the route request to its own peripheral units. This procedure is repeated until a route to the destination is found. The route request message collects information when it is forwarded just like the DSR, thus the RREP has a single route to return to the source of the route request. When the RREP reaches its destination, a route is established between the source and the destination. The forward and reverse route can also be built like the AODV does, thus reducing the length of the request message, thereby decreasing the query-response time.

2.3. Hybrid Routing

2.3.2

35

Sharp Hybrid Adaptive Routing Protocol

Sharp Hybrid Adaptive Routing Protocol (SHARP ), [81], utilizes both proactive and reactive protocols to perform the routing. SHARP adapts itself between proactive and reactive routing strategies. The adaptation can be done either by measured characteristics of the network or directly by the user, to optimize performance such as loss rate, routing overhead or route creation delay. SHARPS defines a proactive zone around some units of the network. The proactive zone of unit i has its center in unit i, unit i is called the central unit. Units inside the proactive zone of unit i proactively maintain routes to unit i. The number of units within the proactive zone of unit i is defined by the zone radius. All units at a distance less than or equal to the zone radius of unit i are members of the proactive zone of unit i. Units that are out of the proactive zone of unit i utilize a reactive routing to establish routes to unit i. SHARP also provides a new proactive routing protocol that, according to the authors, is both efficient and analytically tractable. While it can use any reactive routing protocol, the actual implementation of SHARP, [81], uses AODV [76]. 2.3.2.1

Proactive Zones

Proactive Zone is the area of the network through which routing information about a unit is exchanged proactively. SHARP creates proactive zones automatically around hot destinations that receive data from many sources. The proactive zone acts as a collector of the messages whose destiny is the center of the proactive zone, these messages are then forwarded efficiently using the proactive routing protocol. To establish which units are inside the proactive zone, SHARP utilizes a metric that is called zone radius. All units with distance less than or equal to the zone

36

Chapter 2. Routing Protocols

radius, from the center of the proactive zone, are inside the proactive zone. SHARP can dynamically adapt the zone radius of each destination based on the incoming traffic and the mobility of the network, creating large zones around popular destinations and small zones, or even no zone at all, around units with low incoming traffic. Units with no proactive zone rely just on the reactive routing protocol. The zone radius controls the mix between proactive and reactive routing for each destination. Increasing the radius, SHARP decreases the route formation delay and the loss ratio, though it increases the message overhead to maintain routes proactively. On the other hand, decreasing the radius, SHARP reduces the overhead, though increasing the delay in route formation and the loss ratio. SHARP can act as a purely reactive routing protocol by setting all units’ zone radius to zero, or it can emulate a proactive protocol by setting the radii to the network diameter. 2.3.2.2

Proactive Routing

The SHARP Proactive Routing (SPR) protocol uses techniques already used by other routing protocols, such as DSDV [75] and TORA [71]. SPR maintains routes to a single destination in each zone. SPR routing is done through a directed acyclic graph (DAG) rooted at the destination. The DAG is built using a construction protocol which is initiated periodically by the destination. In between the reconstructions, the DAG is maintained by an update protocol. The update protocol relies on periodic exchange of updates and local recovery mechanisms to handle link failures. Construction Protocol: The construction protocol is used to periodically generate the DAG. The destination initiates the construction process by broadcasting

2.3. Hybrid Routing

37

a DAG construction message. This message carries the zone radius and a sequence number, to distinguish it from old DAG construction messages. The DAG construction message time-to-live (TTL) is set to the zone radius, thus guaranteeing that the DAG construction message stay inside the proactive zone. The DAG is built by assigning a height to each unit. The height is used for routing and corresponds, initially, to the distance of the unit from the destination. When receiving a DAG construction message from unit k, unit j adds the link k → j to the DAG and rebroadcasts the construction message. A unit can receive DAG construction messages from different neighbors. When a unit receives a DAG, it waits a fixed amount of time before retransmitting it. During this time, the unit collects all construction messages, storing the height information of all neighbors. Then it sets its own height to the minimum among the received ones, and rebroadcasts the DAG construction messages. Construction messages arriving at the unit after this unit has already sent the construction message are disregarded. It is important to point out that each unit forwards a DAG construction message at most once, thereby bounding the number of forwarded messages to the number of units inside the proactive zone. Update Protocol: The update protocol is used for the DAG maintenance either between its reconstructions or on link failures. At fixed time intervals, each unit in the proactive zone broadcasts its current height in an update message, whose TTL is set to one. Each unit records its neighbors height upon receiving update messages. The update messages serve also as “hello” messages and are used to maintain the topology of network by detecting either the formation of new links or the breakage of existing ones.

38

Chapter 2. Routing Protocols

If all downstream links at a unit are failed, the unit reverses the orientation of all its upstream links by choosing a new height greater than the height of its upstream neighbors, then it sends an update message. This process provides two properties: (i) it allows SPR to recover from link failures inside the proactive zone without having to wait until the next reconstruction interval; (ii) it constrains the impact of link failures to a small region. Performing local repairs the optimality of DAG can be lost, since the correct distance to the destination can no longer be known. SHARP compensates this problem by periodically rebuilding the DAG. The SPR routing is performed as follows. A message arriving at a unit is forwarded to the neighbor with the lowest height. If the data cannot be transmitted to this neighbor, it is transmitted to the next best neighbor, and so on. If no neighbor is available to forward the message, the unit performs a link reversal to repair the DAG, and the message is forwarded to the best neighbor in the new formed DAG. However, by doing this, temporary loops can be created. To prevent the loops, a unit piggybacks its new height in the message, thus the unit that receives the message can update its own height before forwarding the message. 2.3.2.3

Reactive Routing

The actual SHARP implementation uses the AODV [76] for the reactive routing protocol. SHARP integrates the proactive and the reactive components without incurring any additional overhead. If the source is inside the destination’s proactive zone, the routing is done proactively. If the source is outside the proactive zone, the route request is broadcast by AODV. When a unit which is inside the destination’s

2.3. Hybrid Routing

39

proactive zone receives a message to this destination, it replies to the source of the route request setting its distance to the destination as zero. Thus, unit i’s proactive zone acts as a collective destination for messages addressed to unit i. Once messages enter in the proactive zone they are efficiently routed to the destination by the proactive protocol.

2.3.3

Contact-based Architecture for Resource Discovery

Contact-based Architecture for Resource Discovery (CARD) [39] architecture is based on the concept of small worlds [100]. CARD adopts a hybrid approach in which units use periodic updates to reach their vicinities within a limited number of hops, R, and a reactive querying beyond the vicinity via contacts. Contacts act as shortcuts that attempt to transform the network into a small world by reducing the degrees of separation between the source and the destination of a transfer. Each unit maintains routes for a few contacts beyond its vicinity. Contacts are polled periodically to validate their presence and routes. As the number of contacts increases, the network view increases; however, at the same time, the overhead involving contacts selection and maintenance also increases. The vicinity of unit k consists in all units which the minimal distance to k is at most R, where R is the radius of the vicinity. The edge units of unit k are all units whose minimal distance to k is exactly R. The maximum contact distance (r) is defined as the maximum distance, in number of hops, between a unit and its contacts. The Number of Contacts (N oC) specifies the maximum number of contacts a unit can select. The depth of search (D) specifies the levels of contacts queried by a source. Figure 2.1 exemplifies the above definitions.

40

Chapter 2. Routing Protocols

contact

C2

contact

C3 E2 E3 S R E1

r contact

C1

S: Source Unit E: Edge Unit C: Contact Unit R: Vicinity Radius r: Maximum Contact Distance

Figure 2.1: CARD architecture overview.

2.3.3.1

Contact Selection Mechanism

CARD employs a hybrid of proactive and reactive approaches for resource discovery. All units within R hops from a unit i form the unit i’s vicinity. Each unit proactively maintains routes to units inside its vicinity. Each unit also maintains routes to a few units that lie outside the unit’s vicinity. These units serve as contacts for constructing routes beyond the vicinity. Contacts are chosen using the following mechanisms: Contact Selection Procedure: Any potential source may choose to select contacts. The procedure starts when a source i sends a Contact Selection (CS ) message

2.3. Hybrid Routing

41

through each of its edge units Ei , one at a time, until N oC number of contacts are selected or until all edge units have been attempted. An edge unit receiving a CS forwards it to a randomly chosen neighbor j. Each unit receiving a CS decides whether or not to become a contact for i based on the contact selection method. If the unit does not choose to be a contact, it forwards the CS to a randomly chosen neighbor (excluding the one from which the CS was received). The CS traverses in a depth-first manner until a contact is chosen or the distance traversed by the CS reaches r hops. If a contact is still not chosen, CS backtracks to the previous unit which forwards the CS to another randomly chosen neighbor. When a contact is selected, the route to the contact is returned to i. Contact Selection Method: To increase the contacts cover of the network, the contacts of a unit i should be disjoint and the vicinities of different contacts of the same unit should be non-overlapping. To achieve these objectives the CS message should contain the following information: (i) id of unit i (the source); (ii) a list of already known contacts (Contact List); (iii) the hop count. When a unit j receives a CS, it first checks if i is inside its vicinity. This check is easily performed as units maintain information about their vicinities proactively. Unit j also checks if its vicinity contains any of the units listed in the CS Contact List. If neither i nor any of the units in the Contact List are inside the vicinity of j, j can choose if to become a contact for i or not. This choice is based on one of two methods: a probabilistic method or an edge method. Using the probabilistic method, unit j probabilistically chooses itself as a contact. This probability is computed based on the number of hops between i and j and on

42

Chapter 2. Routing Protocols

values R and r. The probability should guarantee that contacts are chosen among the units that are between 2R and r hops from the source. This is done to assure a minimal overlapping between the vicinities of the contacts and the vicinity of i. If the CS reaches the limit distance from the source and this unit cannot become a contact, the CS is backtracked. However, choosing contacts in this way can result in a situation where there is some overlap between the vicinity of the contacts. This is possible because units do not have knowledge of their positions once the CS is out of the vicinity of i. Also the probabilistic method can be expensive in terms of the amount of traffic generated by CSs. This is due to the backtrack mechanism when the probability fails. To avoid the above problems the edge method can be employed. This method consists in adding to the CS message the list of all edge units (Edge List) of i. Also a sequence number is included in the CS to prevent the formation of loops. On receiving a CS, apart from checking for overlapping with i’s vicinity and the vicinities of all already selected contacts, the receiving unit checks for overlapping with the vicinities of any of the units in the Edge List as well. This ensures that all contacts of i are at least 2R hops from i. According to the authors, this eliminates the possibility of overlapping. 2.3.3.2

Contact Maintenance Procedure

Units mobility may change the route to a contact. Therefore a unit must keep track of its contacts and their routes. To this purpose, every unit periodically polls its contacts as follows: 1. Each unit periodically sends a validation message to its contacts. The validation message carries the route through which it is supposed to be forwarded;

2.3. Hybrid Routing

43

2. Each unit on the route that receives the message checks if the next hop is a directly connected neighbor. If so, it forwards the message to the next hop. If not, the unit tries to salvage the route using the local recovery mechanism, presented below; 3. If the route cannot be salvaged using the local recovery, the contact is considered lost; 4. If the route to the contact is validated but the number of hops from the source to the contact is not between 2R and r, the contact is considered lost; 5. After validating all of its contacts, if the number of contacts left is less than the specified N oC, a unit can start a new contact selection. The local recovery mechanism is invoked when a route to a contact is broken. This mechanism attempts to recover the route to the contact instead of losing it. Assume that unit u has lost the connection with the next unit v. Using the local recovery mechanism, unit u searches in its vicinity for the presence of any unit that was after v in the original route. If it finds such unit, it recovers the route by sending the message to this unit. For example, consider the route (a → b → c → d → e). If unit b loses the contact with unit c, unit b searches in its vicinity for units d or e. If it finds unit d or unit e, it recovers the route by sending the message to this unit. 2.3.3.3

Query Mechanism

When a unit i wants to establish a route to any other unit j, it first checks if j is within its vicinity. If j is not found in the vicinity of i, i sends a Destination Search Query (DSQ) to its contacts. The DSQ message consists in: the depth of search (D), and the target id.

44

Chapter 2. Routing Protocols

Upon receiving a DSQ the contact checks the value of D. If D is equal to 1, the contact searches in its own vicinity for unit j. If j is found, the query is successful and the route to j is returned to i. If j is not found, the contact simply drops the DSQ. If D > 1, the contact decrements D by 1 and forwards the DSQ to its own contacts. The source, unit i, first sends a DSQ with D = 1 to its contacts, so only the first level of contacts are queried. After querying all its contacts, if the source does not receive a route to the destination within a specific time, it creates a new DSQ with D = 2 and sends it again to its contacts. Each contact observes that D = 2, decrements D by one, and sends the DSQ to their own contacts, the second level contacts. Upon receiving the DSQ, the second level contacts, observes that D = 1 and searches in their own vicinities for the destination. If it is found, a route is returned to the source. If the source does not receive a route to the destination within the specific time, it creates a new DSQ with D = 3, and the whole process is repeated. According to the authors, the query mechanism presented above is much more efficient than flooding and smart flooding, reaching 90% of overhead savings, and than bordercasting, reaching 80% of overhead savings. However, the authors do not provide any analysis of the delay to establish routes.

2.4

Geographical Routing

Geographical routing protocols have a different approach from the previously presented ones. It is essential for geographic routing protocols that units know their own position, for example, using geographical coordinates that can be obtained by the

2.4. Geographical Routing

45

use of GPS [50]. Lately, some approaches have been presented to allow geographical routing without the use of GPS, like [82] and [88]. In [82], the authors present an algorithm for assigning coordinates to mobile units that does not require the units to know their physical positions. These coordinates are then used by the geographical routing protocol. The authors also claim that in the presence of obstacles, geographical routing with virtual coordinates significantly outperforms geographical routing with real units coordinates, because virtual coordinates reflect the network connectivity instead of units’ true positions. In [88], the authors present a technique to compute positions of units from basic information, which identifies the units that are in the communication range of other units. The algorithm consists of three steps: (i) Compute shortest routes between all pairs of units in the region, estimating the distance between each pair of units. This builds a distance matrix; (ii) Apply a multidimensional scaling (MDS ) technique over the distance matrix built on step (i) building a relative map of the network; (iii) Given a sufficient number of anchor units, transform the relative map to an absolute map. An anchor unit is a unit of which the real coordinates are known. The minimum number of anchors is 3 for a two-dimensional map, and 4 for a three-dimensional map. If the number of anchors is not sufficient to construct an absolute map, the relative map can be used as it provides correct and useful information about the network connectivity, even though accurate absolute coordinates are not found. This method has a strong limitation, as the current implementation is centralized. In geographical routing, units use the physical location information of other units either to forward messages, as the case of DREAM [6] and the Self Organized Terminode routing [8, 9], or to restrict the propagation area of route requests, as

46

Chapter 2. Routing Protocols

the case of LAR [54]. Descriptions of these protocols can be found in Sections 2.4.1, 2.4.3 and 2.4.2, respectively. Other geographical routing protocols can be found in [13, 51, 74, 94]. However, a new challenge arises in geographical routing: how to deal with deadends and obstacles, because a unit can have no neighbor closer to the destination, thus having no neighbor to forward the message. Some solutions for this is presented in the literature [56, 82, 88].

2.4.1

Distance Routing Effect Algorithm for Mobility

In the Distance Routing Effect Algorithm for Mobility (DREAM ) routing protocol [6], location information is disseminated to the entire network, similarly to the routing information in proactive protocols. DREAM uses this information to route the messages from the source, unit i, to the destination, unit j. When unit i wants to send a message to unit j, unit i searches in its own routing table the location of unit j. Then it sends the message to all its neighbors which are physically closer to unit j. These units repeat the process by sending the message to their neighbors which are closer to j, and so on, therefore the message always gets closer to the destination, until it arrives to unit j, if possible. Although the protocol disseminates the location information in a proactive way, it builds the routes in an on-demand fashion. The probability of finding the destination relies on how the location information is disseminated. The authors propose two parameters to establish the frequency with which the location information must be transmitted: 1. Mobility Rate: The faster a unit moves, the more often it must communicate its location.

2.4. Geographical Routing

47

2. Distance Effect: The farther two units are separated, the less often they need location information about each other. Intuitively, when two units are moving at the same speed, with respect to a fixed unit, the closer one appears to be changing more rapidly than the one that is farther away of the fixed unit. The distance effect states that units that are far apart need to update each other’s location less frequently than units that are closer together. To deal with this, an “age” is associated with each location information message. The age is the number of hops that this message can travel from the sender. So a unit can establish how far a location information can travel in the network, thus updating more frequently the closer units and reducing the bandwidth utilization.

2.4.2

Location-Aided Routing

Another use of the location information is to re-build broken routes. In the LocationAided Routing (LAR) [54], when the source receives a route error message, which means that the route is not available anymore, the source uses the location information about the destination to restrict the new route search area. Assuming that on time t0 the source builds a route to the destination and it knows the position of the destination. At time t1 the source wants to send another message to this destination, but it gets a route error, so the old route is not available anymore. Instead of starting a new route request over the entire network, the source calculates an expected zone, detailed in Section 2.4.2.1, in which it expects to find the destination. After the expected zone is computed, the source computes a request zone, detailed in Section 2.4.2.2 which is the zone inside which the RREQ will be forwarded. Units

48

Chapter 2. Routing Protocols

only forward the RREQ if they are inside the request zone. Using LAR, the source can restrict the area of the RREQ propagation; however, it is possible that in the restricted zone there is no route between the source and the destination, or the destination is outside the restricted zone. If there is no route between the source and the destination inside the restrict zone, the source can expand the expected zone to try to find at least one route to the destination. In [54] the authors use the entire network as expanded expected zone. 2.4.2.1

Expected Zone

The expected zone is calculated based on the position p of the destination at time t0 , the time elapsed t1 − t0 , and on the speed of the destination, v. The expected zone is a circular region of radius equals to v(t1 − t0 ) that is centered at location p. However, if the destination moves faster than v, it can be actually outside of the expected zone. In general, v can be assumed as the units’ maximum speed, thus avoiding the problem. If the source does not know a previous location of the destination, it cannot reasonably define an expected zone. In this case, the expected zone can be considered as the entire ad hoc network, so the protocol is reduced to a basic flooding. 2.4.2.2

Request Zone

The request zone is the physical area of the network through which the RREQ will be forwarded. The request zone must contains the source and the expected zone. Then, if the source is inside the expected zone, the request zone is assumed to be the expected zone, otherwise, the request zone can be assumed as the smallest rectangle that contains the source and the expected zone.

2.4. Geographical Routing

49

The RREQ must carry on the physical location of the request zone, such that units are enable to forward the RREQ only if they are inside the request zone.

2.4.3

Self Organized Terminode Routing

The Self Organized Terminode Routing protocol [8, 9] is focused on large networks, which the authors call a terminode network. Units in such networks are referred to as terminodes. The routing protocol consists of two phases: Terminode Local Routing (TLR) and Terminode Remote Routing (TRR). TLR and TRR are detailed in Sections 2.4.3.1 and 2.4.3.1, respectively. 2.4.3.1

Terminode Local Routing

TLR is a mechanism that allows terminodes to reach other terminodes that are in their vicinity. TLR does not use location information to forward messages. TLR is inspired by the intrazone routing protocol of the ZRP. TLR-reachable area of terminode i includes the terminodes whose distance from i is at most the local radius. The local radius is measured in number of hops. Every terminode proactively maintains information about the terminodes that are in its TLR-reachable area. This information is used to forward messages to terminodes that are inside the TLR-reachable area. 2.4.3.2

Terminode Remote Routing

TRR is a mechanism that allows terminodes to send messages to destinations that are outside their TLR-reachable area. TRR consists of the following elements: Anchored Geodesic Packet Forwarding (AGPF ), Anchored Path Discovery (APD), Path Maintenance and Multipath Routing. All elements are discussed below.

50

Chapter 2. Routing Protocols

Anchored Geodesic Packet Forwarding: AGPF is a method to send messages to remote locations based on location information. When terminode i wants to send a message to terminode j, it first discovers j’s locations using a mobility management method. Then, i finds which one of its neighbors is the closest to j, say terminode k, and it forwards the message to this neighbor. When k receives the message, it firstly checks if j is inside its TLR-reachable zone, in this case the message is sent through the TLR; otherwise, k repeats the process, sending the message to its own neighbor which is the closest to j. Obviously, the AGPF may fail. For this reason, the authors propose the use of anchors. An anchor is a physical geographical point which, in general, does not correspond to terminodes. The source adds to the message a list of anchors through which the message should pass. When a terminode receives a message, it checks if it is close to the first anchor of the message, if so, it removes the anchor from the message and sends the message in the direction of the next anchor. Between anchors, the AGPF method is used. According to the authors, if the anchors are correctly set, the message will arrive at the destination with high probability. Anchored Path Discovery: APD offers two methods to construct anchored paths, Friend Assisted Path Discovery (FAPD) and Geographical Maps-based Path Discovery (GMPD). Friend Assisted Path Discovery: In FAPD, each terminode maintains a list of other terminodes, called friends. Friends of terminode i are the terminodes to which i maintains one or several paths. With this scheme, a terminode may contact its friends in order to find an anchored path to the destination.

2.5. Power Aware Routing

51

Geographical Maps-based Path Discovery: In large networks, it is possible to identify denser areas, the authors call such areas as towns. In GMPD, each terminode must have a map of the towns. In order to find an anchored path to the destination, the source access its map and determines the anchored path as a list of town centers that the message has to visit in order to reach the destination. Path Maintenance: allows terminodes to improve acquired paths, and to delete obsolete ones. Multipath Routing: A terminode can maintain several anchored paths to a single destination, in order to reduce traffic and reestablish a broken path.

2.5

Power Aware Routing

An approach to power aware routing is based on turning off the network interface of as many units as possible, since, as shown in [28], idle devices consume almost as much energy as active ones. A power saving routing based on this technique should have the following characteristics: it should allow as many units as possible to turn off their network interfaces most of the time. However, even if most of the units have their network interfaces switched off, the routing protocol should forward messages between any pair of units almost as if all units were awake [16]. A routing protocol allowing units to save power by turning off their network interfaces is the Span protocol [16], to be detailed in Section 2.5.1 A different approach considers that ad hoc routing protocols attempts to define routes based on minimizing either the number of hops or the delay between the source and the destination. Consequently, some units become responsible for routing

52

Chapter 2. Routing Protocols

messages between many source-destination couples. This implies that some units may deplete their energy faster than other units. A better choice of routes can be one where messages are forwarded through longer routes, passing through units that have plenty of energy reserves [91]. Several metrics can be used to the purpose of power saving in routing protocols: minimizing the energy consumed for each message; minimizing the power level variance in each unit; minimizing the ratio cost/message; minimizing the maximum unit cost. The above metrics focus on individual units: therefore, using these metrics might lead to a system where the residual power of the units is high, but the system is not connected because some critical units have depleted their power. For this reason another metric is used in [60] by the max-min zPmin routing protocol. Max-min zPmin focus on maximizing the global lifetime of the network, and it will be presented in Section 2.5.2.

2.5.1

Span

An energy saving routing protocol, the Span protocol, is presented in [16]. According to the authors, Span allows some units to turn off their network interfaces as long as there are enough awaked units in the network to form a connected backbone. Each unit in the network makes periodic, local decisions on whether to sleep or stay awake as a coordinator, participating to the forwarding backbone. Coordinators are the awaken units that form the backbone. A unit decides voluntarily to be a coordinator if it discovers that two of its neighbors cannot communicate with each other directly or via one coordinator. To keep the number of coordinators to a minimum and to distribute in time the role of coordinator, each unit delays the announcement of its willingness to become

2.5. Power Aware Routing

53

a coordinator. This delay takes into account two factors: the amount of remaining energy and the number of neighbors it can connect. This combination ensures, with high probability, a capacity-preserving connected backbone at any point in time, and a uniform energy consumption of all units. Messages are always forwarded through the backbone. A non-coordinator unit remains in power-saving mode and periodically checks if it should become a coordinator. Span is a proactive routing protocol using a routing technique similar to those of previously presented proactive routing protocols.

2.5.2

Max-Min zPmin

The authors of [60] claim that max-min zPmin combines the benefits of selecting the route with the minimum power consumption and the route that maximizes the minimum residual power in the units of the network. A unit must know accurately the power level of all other units in order to compute a route using this protocol. One way to notify the power level to all units could be broadcast, but this would generate a huge power consumption defeating the idea of power awareness. To solve this problem, the authors propose a zone-based routing protocol that relies on max-min zPmin . 2.5.2.1

Zone-based routing

Zone-based routing divides the network area into small geographical zones. To route a message between zones, the protocol computes a zone route, i.e., the sequence of zones through which the message must pass, from the origin zone to the destination zone. Each zone has the control on how the message is routed inside it until it reaches the next zone. The Zone-based routing consists in: (i) estimating the power

54

Chapter 2. Routing Protocols

level of each zone; (ii) computing a zone route for each message; (iii) computing the best route for the message inside each zone. Each message is forwarded across the zone using the information about the zone power estimates. A global controller for routing messages manages the zone. This controller should be the unit with the highest amount of remaining power, though other schemes can be used to elect and change the controller. Zone border units normally belong to more than one zone; thus neighboring zones can communicate with each other through the units on the overlap area. Zone Power Level Estimation: For each zone, the power estimate is controlled by the zone controller. This estimation measures the number of messages that can be forwarded through the zone. For this estimation, the controller polls each unit of the zone for its power level, than it runs the max-min zPmin algorithm and broadcasts the result to all units of the zone. The frequency of this process is inversely proportional to the estimated power level. Routing Inside Zones: When unit i, on the overlap area between zones A and B, receives a message that must be forwarded to the next zone C, it computes the max-min zPmin route between itself and the units in the overlap area between zones B and C, then it sends the message through the resulting route. Global Routing When a unit wants to send a message, it constructs a zonegraph of the system, which models the global routing problem. Figure 2.2 shows an example of zone-graph. The graph consists of a zone label vertex and k direction vertices, where k is the number of neighboring zones. Each direction vertex is labelled with the power level estimation (power labels were omitted in figure 2.2).

2.6. Hierarchical Routing

A

B

C

D

55

A

B

C

D

Figure 2.2: Zone Graph of four zones in a square network field.

The zone label vertex is connected with all other k vertices. Each direction vertex is connected to the neighboring zone label vertex in that direction. The global route can then be found as the max-min route in the zone graph that starts in the sender’s zone vertex and ends in the destination’s zone vertex.

2.6

Hierarchical Routing

Hierarchical routing schemes are typically used by clustering protocols. Clustering has been used in ad hoc networks since their appearance. Several clustering strategies have been proposed with the focus on imposing a hierarchical structure to the units in order to increase scalability, improve bandwidth utilization, and to reduce delays for route queries [26, 29, 35, 52, 55, 62, 74, 84, 90]. Normally clustering in ad hoc networks is performed in two phases: cluster formation and cluster maintenance. The first phase consists, mainly, in choosing cluster-heads. Then the cluster is formed by associating units with each cluster-head. Several algorithms have been proposed in the literature to deal with the cluster-head election problem. In [26] and [35] the cluster-head selection is based on the ID of the

56

Chapter 2. Routing Protocols

units, the unit with the lowest-id among its neighbors is elected as a cluster-head, these algorithms are called lowest-ID algorithms. In [20] the cluster-head election is based on the stability of the units, this algorithm is called Least Cluster Change (LCC) algorithm. This technique reduces the number of cluster-head changes, thus reducing the overhead of the network. These algorithms establish that the units cannot move during the cluster formation phase. Once all units are partitioned into clusters, the non mobility assumption is released. The second phase, the cluster maintenance, consists in maintaining the cluster coverage over the network in the presence of mobility. As units can move freely, the algorithm must deal with cluster-head and non cluster-head units that go from one cluster to another, and with units that become orphan, without a cluster. In lowest-ID clusters, the cluster maintenance normally is done by periodically invoking the cluster formation process. In the LCC algorithm, only two conditions cause the cluster head to change: when two cluster heads come within range of each other and when a unit becomes disconnected from any cluster. When a non cluster-head unit is moving, just the cluster membership changes, eliminating the leaving unit from the cluster or adding the arriving unit in the cluster. In [52] a cluster-based routing protocol without cluster-heads is presented. A route in the protocol generally consists of hops of different transmit power such that the clustered structure of the network is respected. The protocol consists of simply using the lowest transmission power level λ, such that the destination is reachable (in multiple hops) by using power levels no larger than λ in all transmissions. Choices about which unit is the next hop in order to reach the destination are made at the source and at every intermediate unit along the route. In [90] an architecture for hierarchical routing based on virtual subnets is defined.

2.6. Hierarchical Routing

57

In this method, units addresses depend on their current physical connectivity and address availability. Consider a network segmented into p segments each containing at most q units. The address of each unit is composed of (x1 , x0 ), where x1 is base-p and it specifies in which physical subnet of the network the unit is, and x0 is base-q and it specifies which the virtual subnet of the unit is. Note that each unit is affiliated to a physical subnet and to a virtual subnet. Units of a physical subnet are within close proximity in a local geographical area and they can communicate with each other directly, or via a routing protocol restricted to the respective physical subnet. Units of a virtual subnet are disperse among the network and they may communicate directly if they can use special directional antennas or they can use a routing scheme to reach each other. When a unit moves outside its physical subnet into another physical subnet, it must change its address, getting a new x1 and a new x0 , which means that the unit is also changing its virtual subnet. If a subnet is complete and another unit wants to join it, the new unit receives a “guest” address from a nearby physical subnet. When an address becomes available in a subnet, a unit with a “guest” address changes its address to the available one. When a unit addressed (x1 , x0 ) wants to communicate with another one addressed (x3 , x2 ), it looks to the destination address. If the physical subnet of the source and the destination matches, x1 = x3 , the source simply sends the message to the destination using the local routing protocol. If the physical subnet of the source and the destination does not match, x1 6= x3 , the source compares the logical address of itself with the destination one, if it matches, x0 = x2 , the source already has a route to the destination and uses it. If x1 6= x3 and x0 6= x2 the source sends the message to the unit (x5 , x4 ) such that { x5 = x1 and x4 = x2 } or { x5 = x3

58

Chapter 2. Routing Protocols

and x4 = x0 }, and this unit is then responsible to forward the message to the destination.

2.7

Secure Routing

Attacks on ad hoc networks routing protocols generally fail into one of two main categories: routing disruption attacks and resource consumption attacks [40]. In a routing disruption attack, the attacker attempts to cause legitimate data messages to be routed in dysfunctional ways. In a resource consumption attack, the attacker injects messages into the network in an attempt to consume valuable network resources such as bandwidth, or to consume units resource such as memory or computational power. An example of a routing disruption attack is for an attacker to send routing messages to create a black hole. The attacker may also attempt to partition the network by injecting forgotten routing messages to prevent one set of units from reaching another. An example of a resource consumption attack is for an attacker to inject extra data messages into the network, which will consume bandwidth resources when forwarded. Similarly, the attacker can inject extra control messages into the network, which will consume even more bandwidth or computational resources as other units process and forward such messages. With either of these attacks, the attacker can try to extract maximum resources from units on both sides of a vertex cut, such that the units waste energy forwarding messages to the vertex cut, only to have them dropped. Several protocol for secure routing are present in the literature, like [40, 93, 102].

2.7. Secure Routing

59

The following section details one of these protocols, Ariadne [40].

2.7.1

Ariadne

In [40] a secure on-demand routing protocol (Ariadne) is presented. Ariadne is based on the DSR routing protocol. The security of Ariadne relies on the secrecy and authenticity of keys stored in the units. To set up shared secret key, Ariadne can use a variety of mechanisms such as [23, 57]. Ariadne also requires that each unit has an authentication key from the Route Discovery chain of every unit initiating Route Discoveries. This key can be set in the same as the public key. Ariadne uses a symmetric cryptography. In general, ad hoc networks routing protocols do not need secrecy or confidentiality. These properties are required to achieve privacy or anonymity for the sender of the message. Even in the Internet it is challenging to achieve such properties, and this area is still the subject of active research. Ariadne does not prevent the attacker from injecting unicast messages in the network. However, malicious Route Request messages that can flood the network are prevented. To convince the destination of the legitimacy of each field of a Route Request, the initiator simply includes a message authentication code with the shared key of the destination. The destination can easily verify the authenticity of the route request using the same shared key. To prevent unauthorized units from sending Route Errors, Route Errors must de authenticated by the sender. Each unit on the return route to the source forwards the Route Error just if it is authenticated. If the authentication is delayed, each unit that will be able to authenticate the Route Error buffers it until it can be

60

Chapter 2. Routing Protocols

authenticated. Until the unit is able to authenticate the Route Error it does not use the information of the Route Error to update its route cache. Once the message is authenticated, the unit removes from its route cache all routes using the indicated link, and then forwards the message. To guarantee that intermediate units forward messages that they are requested to forward, Ariadne relies on feedback information about which messages were successfully delivered. The feedback can be received either through an extra end-to-end network layer, or by exploiting properties of transport layers. This feedback approach is similar to that used in the IPv6 for Neighbor Unreachability Detection [69]. As Ariadne does not guarantee security over the optimizations of DSR, the resulting protocol is less efficient than the highly optimized version of DSR that runs in a trusted environment. In [40] the authors also demonstrate that source routing facilitates securing ad hoc networks routing protocols. Source routing empowers the sender to circumvent potentially malicious units, and enables the sender to authenticate every unit in a Route Reply. Such fine-grained route control is absent in most distance-vector routing protocols, which makes such protocols more challenging to fully secure.

2.8

Quality of Service Routing

Quality of Service (QoS) routing protocols for wired networks cannot be applied directly to ad hoc networks [17], as the dynamic nature of ad hoc networks makes the available state information inherently imprecise, and also because units can join, leave or rejoin the network at any time and in any location.

2.8. Quality of Service Routing

61

It is difficult to provide QoS in ad hoc networks due to its dynamic nature. The overhead of QoS routing in such networks is likely to be higher than that in a wired environment. If the topology of the network changes too fast, the provision of QoS is even impossible. However, QoS can be feasible in other cases where the topology changes are less frequently. Several QoS routing protocols can be found in the literature, like [17, 22]. In [17] two routing problems are studied: delay-constrained routing and bandwidthconstrained routing. Note that the first one is NP-complete [33], while the second one is solvable in polynomial time, given precise state information [17]. A route that satisfies the delay (or bandwidth) constraint is called a feasible route. The authors claim that the proposed routing protocol has the following properties: 1. The protocol can tolerate the imprecision of the available state information. Good routing performance in terms of success ratio, message overhead, and average route cost are achieved even when the degree of the information imprecision is high. Note that the information imprecision exists only in QoS routing. 2. Multi-route, parallel routing is used to increase the probability of finding a feasible route. 3. The protocol considers not only the QoS requirements but also the optimality of the route. Low-cost routes are given preference in order to improve the overall network performance. 4. In order to reduce the level of QoS disruption, fault-tolerance techniques are brought in for the maintenance of the established routes.

62

Chapter 2. Routing Protocols

The authors also assume that units are aware of its neighboring units. This can be done through “hello” messages, if the MAC protocol does not provide such service. Also each unit is assumed to keep up-to-date information about all outgoing links. This information consists in: (i) The link delay; (ii) The unused bandwidth of the link; (iii) The cost of sending a message through the link. The delay, bandwidth and cost of a route R = {i → j → k → ... → l → m} are defined as follows: • delay(R) = delay(i, j) + delay(j, k) + ... + delay(l, m) • bandwidth(R) = min{bandwidth(i, j), bandwidth(j, k), ..., bandwidth(l, m)} • cost(R) = cost(i, j) + cost(j, k) + ... + cost(l, m) Given a source s, a destination t and a delay requirement D, the problem of delayconstrained routing is to find a route R from s to t such that the delay(R) ≤ D. If more than one route satisfies the requirement, the one with the least cost is selected. On the other hand, given a source s, a destination t and a bandwidth requirement B, the problem of bandwidth-constrained routing is to find a route R from s to t such that the bandwidth(R) ≥ B. If more than one route satisfies the requirement, the one with the least cost is selected. The routing protocol proposed in [17] consists in a multi-route distributed routing scheme, called ticket-based probing. The basic idea of such routing is outlined below. A ticket is the permission of searching one route. The source unit issues a number of tickets based on the available state information. One guideline is that more tickets are issued for the connections with tighter requirements. Probe messages are sent from the source toward the destination to search for a low-cost route which satisfies the QoS requirement. Each probe is required to carry at least one ticket. At an

2.8. Quality of Service Routing

63

intermediate unit, a probe with more than one ticket is allowed to be split into multiple ones, each searching a different downstream sub-route. The maximum number of probes at any time is bounded by the total number of tickets. Since each probe searches a route, the total number of routes searched is also bounded by the number of tickets. Upon receiving a probe, an intermediate unit decides based on its state: (1) whether the received probe should be split; (2) to which neighbor units the probe should be forwarded. The goal is to utilize the state information at the intermediate units to guide the limited tickets along the best routes to the destination, so that the probability of finding a low-cost route is maximized. In the article the authors provide ways to determine the best number of tickets to be allowed to a probe. The required QoS is ensured during the time when an established route remains unbroken. The QoS provision is, however, disrupted if the units mobility breaks the established route. To avoid sending a route error to the source when the route is broken, the protocol uses a route repair mechanism. Dynamic route-repairing repairs the route at the breaking point, shifts the data traffic to a neighbor unit, and re-configures the route around the breaking point without re-routing the connection along a completely new route. For example, consider the route R = {..., k, i, j, ...}, if R is broken because i moves out of the transmission range of k. Instead of sending a route error message to the source, k tries to repair the route by broadcasting a repair requesting message to its current neighbors asking if any of them are able to take over the job of i. Upon receiving the message, the neighbors of k that have a link to j reply their resources availabilities to k. Based on the received information, k might find that unit i′ has sufficient resources for that hole. Then it adds the link (k, i′ ) to the route

64

Chapter 2. Routing Protocols

and then sends a route repairing message to i′ . Upon receiving the route repairing message, i′ reserves the required resources and adds the link (i′ , j) to the route. If k does not receive any answer from its neighbors, or the neighbors do not have sufficient resources, k sends a route error message to the source as it is done in the other reactive routing protocols, and the source must reestablish another route to the destination.

Chapter 3 Reliability This Chapter deals with reliability in ad hoc networks. Reliable communication via DSR and ZRP routing protocols is analysed and improvements enabled by the virtual routing protocol are anticipated.

3.1

Routing Reliability

In wireless ad hoc networks, where units communicate along routes set up by a routing protocol, reliability may be defined as the ability to provide high delivery ratio, that is, to deliver most of the data messages in spite of units failures, links breakdowns, or buffer overflows caused by overloaded units. Given the intrinsic nature of wireless ad hoc networks, reliability is a major issue. Considering that units of an ad hoc network are dependent on battery power, battery depletion is relatively frequent, causing the units to fail. Links failures may be expected due to interferences in the wireless medium, or, most probably, to units mobility, when pairs of units either move out of the reciprocal transmission range or are shadowed by obstacles. The situation where a unit is disconnected from the

66

Chapter 3. Reliability

rest of the network is equivalent to the crash fault of the unit. Failures may be recoverable: broken links between couples of units may later become available again, either when the two units return within each other’s transmission range or when they move across the obstacles. Failures of units due to depleted batteries may be recovered after battery recharge/replacement. Links and units failures may rise at any time, before or during the route acquisition phase of the routing protocol, or during communications along already established routes. As mentioned in the previous Chapter, the route acquisition phase of the majority of routing protocols for ad hoc networks is based on floodings. This allows these protocols to deal with failures occurring before or during the route acquisition phase. If a combination of faults prevents the source from building a route to the destination, the destination is declared unreachable, and the route acquisition can be tried later in the hope that the fault situation has been recovered. Faults affecting the communication between two mobiles along a route that was successfully established are managed by means of a route maintenance phase of the routing protocol. In this case, the routing protocol may be unable to avoid substantial messages losses. Once a route R has been established, the source starts sending messages through R. If a link or a unit of R fails, the unit upstream the failed link or unit detects the failure of R. Typically, the unit that detects the failure sends a route error message (RERR) to the source of the communication. Once the source receives the RERR, it repeats the route acquisition phase to establish a new route to the destination and resume communication. Messages sent in the time elapsed between the occurrence of the failure and its notification to the source may be lost. Furthermore, during the time elapsed between the notification of the RERR and the setup of a new route, the source cannot send further data messages. The

3.2. Reliability evaluation of DSR

67

messages, meantime generated by the application layer for that destination, are buffered in the source, and they may be dropped if the buffer size is exceeded. The overhead of the routing protocol may also contribute to message losses. In fact, both the route acquisition and the route maintenance phases of the routing protocols rely on a considerable amount of messages travelling in the network. This is specially true if the routing protocols rely on floodings to establish routes. These messages contribute to network congestion, and may contribute to longer buffering of data messages, and, ultimately, to data message losses if the buffer capacity of the mobile units are exceeded.

3.2

Reliability evaluation of DSR

Although DSR [47] is one of the most prominent on-demand routing protocol for ad hoc networks, it may prove relatively weak on respect to reliability. The delivery ratio of DSR, i.e., the percentage of DATA messages delivered to their destinations, depends on many factors, among them: the speed of units; the number of simultaneous source-destination connections; the units’ pause time. The effects of such dependencies are discussed in [78] and investigated in this Section, which reports simulation results. A detailed specification of the simulator used can be found in Chapter 5.2. These simulations were performed using a network covering a square area of 1000x1000 meters, with 75 mobile units. The transmission range of the units is 250 meters. The speed of the units goes from 0m/s (no mobility) to 20m/s. In the two first cases, figures 3.1 and 3.2, the units’ pause time is set to 0 (the pause time is the time elapsed between the arrival of the unit at its destination point and the

68

Chapter 3. Reliability

Delivered data messages 100

Delivery (%)

90 80 70 60 40 CBR connections 20 CBR connections

50 40 0

5

10 Units’ Velocity (m/s)

15

20

Figure 3.1: DSR delivery ratio for different number of simultaneous sourcedestination connections. departure towards a different destination point in the network. If the pause time is 0, the units are always travelling). Initially, all units are stopped for a pause time. In figure 3.3, the pause time goes from 0 seconds to 600 seconds, equals to the entire duration of the simulation experiments. Finally figure 3.4 shows the percentage of dropped data messages because buffer overflows. Figures 3.1 and 3.2 report the delivery ratio of DSR for different units’ velocity. In figure 3.1, the number of simultaneous source-destination connections is set to 20 and 40. Each connection generates 2 messages per seconds and the maximum duration of each connection is 15 seconds. It is seen that the delivery ratio decreases as the units’ speed increases. Also, the negative effect caused by the increasing velocity is accentuated as the number of simultaneous connections increases from 20 to 40 simultaneous connections. In figure 3.2 the number of simultaneous source-destination connections is kept to 20. Each source generates 2 messages per second and the maximum duration of each connection is set to 15 and 120 seconds. It is noticed that shorter connections cause

3.2. Reliability evaluation of DSR

69

Delivered data messages 100 95

Delivery (%)

90 85 80 75 Connections length = 15s Connections length = 120s

70 65 0

5

10 Units’ velocity (m/s)

15

20

Figure 3.2: DSR delivery ratio for different duration of the source-destination connections. Delivered data messages 100

Delivery (%)

95 90 85 80 units’ speed = 5 units’ speed = 10 units’ speed = 15 units’ speed = 20

75 70 0

100

200 300 400 Units’ pause time (seconds)

500

600

Figure 3.3: DSR delivery ratio for different units’ pause time.

more message losses than longer connections. This happens because the protocol must establish a route for each connection between the source and the destination, and the network congestion caused by frequent floodings used at route setups is a major cause of message losses. Figure 3.3 shows the delivery ratio of DSR for different settings of pause time, which range from 0 to 600 seconds. The number of simultaneous source-destination connections is 20, with each connection generating 2 messages per seconds and the

70

Chapter 3. Reliability

Dropped messages 50 Units’ buffer size = 300 Units’ buffer size = 500 Units’ buffer size = 1000

45 40 35

%

30 25 20 15 10 5 0 0

5

10 Units’ velocity (m/s)

15

20

Figure 3.4: Percentage of dropped data messages because units’ buffer overflow for 40 simultaneous connections. maximum duration of each connection is set to 15 seconds. As it could be expected, the delivery ratio of DSR increases when the pause time increases and it decreases when the units’ velocity increases. In conclusion, routing reliability of DSR is negatively affected by increasing the velocity of the units. The delivery ratio may fall below 75% with light traffic conditions, i.e., 20 simultaneous source-destination connections. With heavy traffic conditions, i.e., 40 simultaneous source-destination connections, the delivery ratio of DSR can be as low as 50% of the generated data messages. The delivery ratio of DSR is highly influenced by the units’ buffer overflow. Figure 3.4 shows the percentage of data messages being lost due to buffer overflows. These simulations were performed using 40 simultaneous source-destination connections, each of which generates 2 messages per second and the maximum duration of each connection is 15 seconds. The size of the units’ buffer is set to 300, 500 and 1000 messages. As expected, as the size of the buffers increases, the number of the lost messages decreases. Also, with small buffers, DSR is more susceptible to the increasing in the speed of the units.

3.3. Reliability evaluation of ZRP

3.3

71

Reliability evaluation of ZRP

ZRP [36], being a hybrid protocol, is composed by two parts, one proactive and another one reactive. The use of a proactive routing protocol to forward some messages helps ZRP to improve the route acquisition delay, as some routes are already made when they are needed. The reactive part of ZRP, i.e., the so called bordercast protocol, can be implemented in two different manners: using only unicast messages; using multicast. A detailed view on ZRP and bordercast can be found in Chapter 2.3.1. When bordercast is implemented using multicast, the performance of ZRP is highly improved, as it will be demonstrated in Chapter 5.5. Thus the following results consider just ZRP with multicast. These simulations were performed using a network covering a square area of 1000x1000 meters, with 75 mobile units. The transmission range of the units is 250 meters. The speed of the units goes from 0m/s (no mobility) to 20m/s. In the two first cases, figures 3.5 and 3.6, the units’ pause time is set to 0 (the pause time is the time elapsed between the arrival of the unit at its destination point and the departure towards a different destination point in the network. If the pause time is 0, the units are always travelling). Initially, all units are stopped for a pause time. In figure 3.7, the pause time goes from 0 seconds to 600 seconds, equals to the entire duration of the simulation experiments. Figures 3.5 and 3.6 report the delivery ratio of ZRP for different units’ velocity. In figure 3.5, the number of simultaneous source-destination connections is set to 20 and 40. Each connection generates 2 messages per seconds and the maximum duration of each connection is 15 seconds. It is seen that the delivery ratio decreases as the units’ speed increases.

72

Chapter 3. Reliability

Delivered data messages 100 98 96 Delivery (%)

94 92 90 88 86 84

40 CBR connections 20 CBR connections

82 80 0

5

10

15

20

Units’ Velocity (m/s)

Figure 3.5: ZRP delivery ratio for different number of simultaneous sourcedestination connections. Delivered data messages 100

Delivery (%)

95

90

85

80

Connections length = 15s Connections length = 120s

75 0

5

10

15

20

Units’ velocity (m/s)

Figure 3.6: ZRP delivery ratio for different duration of the source-destination connections. In figure 3.6 the number of simultaneous source-destination connections is kept to 20. Each source generates 2 messages per second and the maximum duration of each connection is set to 15 and 120 seconds. It is noticed that shorter connections cause more message losses than longer connections. This happens because the protocol must establish a route for each connection between the source and the destination, and the network congestion caused by frequent route acquisitions is a major cause of message losses. Figure 3.7 shows the delivery ratio of ZRP for different settings of pause time, which range from 0 to 600 seconds. The number of simultaneous source-destination

3.4. The Approach to Reliability of VRP

73

Delivered data messages 100 98

Delivery (%)

96 94 92 90 88 units’ speed = 5 units’ speed = 10 units’ speed = 15 units’ speed = 20

86 84 82 0

100

200

300

400

500

600

Units’ pause time (seconds)

Figure 3.7: ZRP delivery ratio for different units’ pause time.

connections is 20, with each connection generating 2 messages per seconds and the maximum duration of each connection is set to 15 seconds. As it could be expected, the delivery ratio of ZRP increases when the pause time increases and it decreases when the units’ velocity increases. In conclusion, the negative effect of increasing units velocity is light in ZRP, under light traffic conditions the delivery ratio is around 80%, while under heavy traffic conditions it is never below 75% of the generated data messages.

3.4

The Approach to Reliability of VRP

The virtual routing protocol aims at reducing the network congestion by attempting to avoid buffer overflows. This is done by relying as little as possible on network floodings and by using low priority levels for flooding messages. Most floodings are executed in low priority, since the routes to be established through floodings are not urgent, given that the protocol can rely on redundant routes. Conversely in other routing protocols, like DSR [46, 47], floodings need to be executed on higher priorities, since the routes they construct through floodings are urgent.

74

Chapter 3. Reliability

As it is demonstrated by simulation results reported in Chapter 5, VRP is able to deliver almost all data messages produced by the sources. This behavior is relatively independent of the velocity of the mobile units. Under light traffic conditions, VRP always has a delivery ratio above 95% of the data messages generated independently of the unit’s speed, while DSR has a delivery ratio that is dependent on units’ speed and can be as low as 70% of the data generated, and ZRP has a delivery ratio which is also dependent on the units’ velocity and can be as low as 82% of the generated data messages. With heavy traffic conditions, for 40 simultaneous source-destination connections, the delivery ratio of VRP (which decreases with increasing units’ velocity) is still around 80% when the units’ speed is 20m/s. In comparison, the delivery ratio of DSR under the same scenario is as low as 50% of the generated data messages. However, when comparing VRP with ZRP, VRP loses performance under heavy traffic conditions and high units’ velocity. As it will be shown in Chapter 5, with 40 simultaneous connections and units’ velocity greater than 12m/s, the delivery ratio of ZRP is higher than the delivery ratio of VRP. This happens because in such traffic conditions, scouts are not able to maintain their archived routes up-to-date. Thus the traffic is focused on some units, which start to suffer from buffer overflows.

Chapter 4 Virtual Routing Protocol Consider a mobile ad hoc network composed by N mobile units. We assume that each one of these units can be uniquely identified, and for the rest of this work we will identify the units with integer ids ranging from 0 to N − 1. Due to the units’ mobility and failures, the network topology changes on time. At a given instant of time t, it is possible to define a graph G(V, E), where V is the set of units, and E is the set of links at time t. There is a link between units i and j at time t, i.e., a link (i, j) ∈ E, if the two units are within each other’s transmission range at time t, and they are not shadowed by obstacles. Figure 4.1 depicts an ad hoc network with its corresponding graph G.

Figure 4.1: Ad hoc network(left) with its corresponding graph G(right).

76

Chapter 4. Virtual Routing Protocol

The virtual routing protocol (VRP ) relies on the following assumptions: (i) bidirectional links; (ii) one-hop neighbor knowledge. The use of bidirectional links states that if link (i, j) ∈ E, then link (j, i) ∈ E. The identification of a unit’s neighbors may be provided directly by the MAC protocols. If the MAC protocol cannot provide this information, the protocol must use “hello” messages to assure that the units are aware of their neighbor units. This assumption is also used by other routing protocols such as the TORA [71] and the ODMRP [58]. Two units, i and j, are said adjacent if (i, j) ∈ E. The set of all units that are adjacent to unit k are called the Neighbor set of k, denoted by Nk . In VRP, we define a logical structure over the network, graph L(V, A), which is completely independent of the units’ physical position. Set A is the set of links of the logical structure and it depends exclusively on the choice of the logical structure. Several logical structures are presented in Section 4.1 with some pros and cons for their use. Links in set A are not necessarily bidirectional. In a link (u, v) ∈ A, unit u is called the scout and unit v is called the peered unit. The following defines scouts and peered units. Definition 4.1. Scout: For (u, w) ∈ A, u is called a scout to w. Definition 4.2. Peered: For (w, v) ∈ A, v is called a peered unit of w. For a unit w, it is also possible to define the scouts’ set of w, denoted by Sw , and the peered units’ set of w, denoted by Pw . Set Sw is formed by all units that have

77

a link to unit w in the logical structure. Set Pw , is formed by all units that have a link from unit w in the logical structure. More formally: Definition 4.3. Scout set of w: The Scout set of unit w, Sw is defined as following: ∀(u, w) ∈ A then u ∈ Sw . Definition 4.4. Peered set of w: The Peered set of unit w, Pw is defined as following: ∀(w, v) ∈ A then v ∈ Pw . The logical structure is made by scouts and peered units. Scouts are supposed to maintain real physical routes to their peered units. The problem of building and maintaining these routes will be discussed on Section 4.2.3. The same logical structure must be known by all units. In this thesis we assume that the virtual structure is distributed to the units at the network set up, i.e., the logical structure is always known by the units. However, the logical structure can be distributed to the units using a broadcast protocol as long as it guarantees that all units use always the same logical structure. When unit i wants to communicate with unit j, it must establish a path on graph G from itself to unit j. Using VRP, it first establishes a path on graph L, a virtual path, from itself to j. The virtual path is a chain of scouts with their corresponding peered units. In other words, when unit i wants to communicate with unit j, instead of making a flooding to find a path to j, it can use a route to j that is archived in any scout of j, say unit u. Note that, simply based on the logical structure, unit i knows who the scouts of j are. If i = u or u ∈ Ni this procedure ends, otherwise, unit i repeats the process to find routes to the scouts of u, say w, who archive routes to u, and so on. This procedure defines a sequence of scouts going from i to j. These sequence of scouts is the virtual path from i to j.

78

Chapter 4. Virtual Routing Protocol

After computing the virtual path, it must be translated into a physical route. If the scouts of the virtual path have valid physical routes to their peered units, then the translation of the virtual path into a physical route is possible, and unit i finds a physical route to reach unit j. When a scout w receives a message that must be forwarded to one of its peered units u, unit w appends on the physical route of the message the route through which it is possible to reach u. Then w forwards the message through this route. This can be done if the scout w has a valid physical route to its peered unit u, otherwise the route from w to u is invalid and the message cannot be forwarded any further. A detailed specification on how to build the route between two units and what happens when the source cannot reach the destination through the virtual path can be found in Section 4.2.1.

4.1

Logical Structures

The logical structure of a system is completely independent of time and of the units’ physical position. The location of every unit of given index u in the logical structure is identified by a simple algorithm. This means that the logical structure is known by all units, and all units know the same logical structure. The use of a logical structure completely independent from the physical position of the units makes possible to build a path from the source to the destination without any exchange of message, even though this path is just virtual. As a path from the source to the destination can be built without any exchange of messages, it is possible to establish a physical route from the source to the destination using just unicast messages as it will be detailed later in this Chapter. However, having the

4.1. Logical Structures

79

logical structure completely independent from the units position can be a problem if the units movement is too fast. This is because units must keep some information proactively, and this information is obtained through flooding. Thus a highly dynamic network may imply in lots of flooding. It will be shown, through simulation results in Chapter 5, that with units speed until 20m/s and a logical structure independent from the physical position of the units it is possible to establish routes between sources and destinations using just unicast messages. The path from the source to the destination in the logical structure is called a virtual path, and it is built by the source without sending messages. If the selected virtual path cannot be translated into a physical route because of invalid routes archived in the scouts, the source must find another path to the destination either using another virtual path or by doing a flooding. Almost any logical structure can be used by VRP. In this work we present some structures that can be used as logical structures: Rings of Rings (RoR), hypercube, cube connected cycles (CCC ) and 3D torus. The hypercube (Section 4.1.2), the cube connected cycles (Section 4.1.3) and the 3D torus (Section 4.1.4) are common known structures and their details can be found in the literature, while the RoR is presented in Section 4.1.1. Hypercubes, CCCs and 3D torus are formed with bidirectional links: this implies that ∀u : Su = Pu . Note that the choice of the logical structure depends on the user application, and the user is free to find the best suitable logical structure for his application. Some pros and cons about the scalability, i.e., the capacity of adding or removing units, of these structures can be found in Chapter 4.1.5, even though scalability and its consequences are not part of the subject of this work. Scalability is part of future work.

80

Chapter 4. Virtual Routing Protocol

Note that the degree of the logical structure is one of the most important parameters of the VRP. Consider a system with N units and let k be the degree of the logical structure, i.e., the number of scouts of each unit, k is also the number of routes that each unit must archive. A high degree of connectivity, i.e., a high k, increases the number of redundant virtual paths between the units, reduces the size of the virtual paths and might reduce the delay to build routes. However, it increases the overhead of control messages, and it also increases the size of the units’ routing tables. On the other hand, a small degree of connectivity k, while reducing the overhead of control messages and the size of the units’ routing tables, implies in longer virtual paths and it increases the delay to build routes. Most important, a small k reduces the number of redundant virtual paths between units and it compromises the ability to tolerate units and links failures. Note that if k = N − 1, VRP behaves like a proactive routing protocol; if k = 0 VRP behaves as a simple reactive routing protocol.

4.1.1

Rings of Rings

We assume that there are two integers, x and y, such that, x ∗ y = N , where N is the number of units in the system. In graph L, units are arranged into x logical rings, each of which are composed by y units. In graph L a unit is connected to s − 1 units, where 1 < s ≤ y, inside its ring and to 1 unit in the next ring. Formally, set V is partitioned into x rings, called V0 , V1 , ..., Vx−1 , where unit u ∈ Va if a ∗ y ≤ u < (a + 1) ∗ y. In other words: Va = {u : a ∗ y ≤ u < (a + 1) ∗ y}

4.1. Logical Structures

81

There is an edge (u, v) ∈ A if: • v mod y = (u + d) mod y, where 1 ≤ d < s; or • v = (u + y) mod n; Set Sw = {u : (u, w) ∈ A} is the set of scouts to unit w. A scout of unit w, unit u for example, is a unit that is supposed to know a path, in G, from itself to w, i.e., a physical route. Set Pw = {v : (w, v) ∈ A} is the set of peered units by w, i.e., the units to which w is supposed to have a physical route to. Figure 4.2 shows the scouts and peered units of a single generic unit w. w

s−1 Va−1

s−1 Va

Units peered by w

Va+1

Scouts for w

Figure 4.2: Virtual Structure: Ring of Rings. To denote unit w, located in ring Vw at position qw , it is possible to use notation (Vw , qw ), where Vw = ⌊ wy ⌋, qw = w mod y, and w = Vw ∗ y + qw . The distance between two units u and v in graph L, denoted as d(u, v), is the length of the shortest path between u and v in L. It is immediate that d(u, v) = |Vu − Vv | mod x + ⌈

|qu − qv | mod y ⌉ s−1

82

Chapter 4. Virtual Routing Protocol

A link in graph L can be represented by a pair of integers [a, b], such that a ∈ {0, 1}, 0 ≤ b ≤ s − 1, and a = 0 iff b 6= 0. A scout (Vu , qu ) can reach a peered unit (Vv , qv ) in L by the link [(Vv − Vu ) mod x, (qv − qu ) mod y] A path connecting two units u, (Vu , qu ), and v, (Vv , qv ), in L can be represented by a sequence of links [a1 , b1 ], ..., [am , bm ], such that: Vv = (Vu +

m X

ah ) mod x

h=1

qv = (qu +

m X

bh ) mod y

h=1

A shortest path from unit u and unit v in L is easily obtained by combining the following links: 1. m1 links [1, 0] with m1 = ((Vu − Vv ) mod x): these links allow to reach the ring of Vv from the ring of Vu ; v ) mod y 2. m2 links [0, s − 1] with m2 = ⌊ (qu −qs−1 ⌋; v ) mod y ⌉ − m2; 3. m3 links [0, (v − u − m2 (s − 1)) mod y], with m3 = ⌈ (qu −qs−1

The diameter of the RoR, that is, the maximum distance between two units, is the maximum distance between two units in the same ring plus the number of rings: y +x−1 s−1

4.1.2

Hypercube

A k-dimensional hypercube graph is an undirected graph consisting of n = 2k vertices labelled from 0 to 2k − 1. Units are connected based on the Hamming distance of

4.1. Logical Structures

83

their labels. The Hamming distance of two d-digits binary number is the count of different binary digits between the two numbers. Thus, there is an edge between any two vertices if and only if their binary ids differ by one and only by one bit [95]. A hypercube is a d-regular structure, where d is the dimensional of the hypercube and it is an increasing function of the hypercube’s size (d = logn). Figure 4.3 shows a hypercube of 16 units. w

Scouts and peered units by w

Figure 4.3: Virtual Structure: Hypercube. Hypercubes have the advantage of having a limited number of links between any two units of the system, logn, this limits the size of the virtual path when the hypercube is used as the logical structure for the virtual routing protocol. However, hypercubes are not scalable structures, i.e., it is not possible to simply add or remove a single unit from the system.

4.1.3

Cube Connected Cycles

A cube connected cycle (CCC ) is obtained by replacing each vertex of a hypercube by a cycle of vertices, or units. The number of units in each cycle must be greater or equal to the dimension of the original hypercube.

84

Chapter 4. Virtual Routing Protocol

The CCC(d, λ) can be described by two parameters, d and λ: d is the dimension of the underlying hypercube, and λ is the number of units per cycle, and λ ≥ d [79]. Figure 4.4 shows the CCC(3,3).

w

Scouts and peered units by w

Figure 4.4: Virtual Structure: Cube Connected Cycles. The address of a unit is represented by a tuple (c, p), where c is the cycle to which the unit belongs and p is the position of the unit inside the cycle. The number of cycles is 2d and the total number of units in the system is λ2d . There is a link between two units with addresses (x, y) and (w, z) if and only if: 1. y = z and x differs from w in the yth least significant bit. 2. x = w and either |y − z| = 1 or |y − z| = d − 1. In other words, a unit is always connected with two units inside its cycle, and to one unit outside its cycle. Thus the degree of the structure is 3. CCCs, being built over hypercubes, have the same advantage of limited number of links between any two units of the system. However, CCCs have a small degree of connectivity and thus a limited number of redundant paths between units.

4.1. Logical Structures

4.1.4

85

3D Torus

The 3D Torus of size N = lxlxl is a structure composed of N units arranged in l grids, each one with side equals to l. The number of link in the torus is constant and equals to 6. Units in the 3D torus can be addressed by the tuple (x, y, z) with x = 0, ..., l − 1, y = 0, ..., l − 1 and z = 0, ..., l − 1. A unit addressed (x, y, z) is connected with units addressed ((x ± 1) mod l, y, z), (x, (y ± 1) mod l, z) and (x, y, (z ± 1) mod l). The figure 4.5 shows the 3D torus with 64 units (side equals to 4) [97].

w

Scouts and peered units by w

Figure 4.5: Virtual Structure: 3D Torus The maximum distance between units in the 3D torus is at most

√ 3

l.

Table 4.1 resumes some properties of the logical structures mentioned in this chapter.

86

Chapter 4. Virtual Routing Protocol

Structure RoR

Diameter y s−1

+x−1

Number of Scouts 1 p. If a unit can be placed in the tree on two different places at the same level, the choice between these places is completely random. Consider a system with N = 18 units defining a RoR composed by 3 rings and 3 scouts per unit, shown in figure 4.6. Assume that unit 0 is the source of communication and unit 17 is the destination; so unit 0 should build tree T17 . Figure 4.7 exemplifies the construction of T17 with the preceding pruning rules. However, note that the source stops the construction of T17 when it reaches itself or one of its

4.2. Protocol Specification

91

17 Level 0

15

11

16 Level 1

5

9

9

10

13

14

10

14

15 Level 2

4

3

17

3

8

12

7

7

17

8

13

12

4

9

8

Level 3

3

2

16

2

1

15

1

6

11

7

6

2

6

16

17 Level 4

1

0

14

0

5

13

0

10

11 Level 5

Figure 4.7: Tree T17 , built when a unit wants to send a message to unit 17.

neighbors. In figure 4.7 unit 15 appears in level 1, and for this reason it is not considered on level 2. Unit 10 can be placed at level 2 as a successor of both units 11 and 16. In the construction of figure 4.7 unit 10 is placed randomly as a successor of unit 16. The virtual path to the destination is the path in T17 , from either the source or a neighbor of the source to the destination. Considering that unit 10 ∈ N0 , a possible virtual path between units 0 and 17 can be the one depicted in figure 4.8. Note that in this case, unit 0 stops the construction of T17 at level 2. After computing the virtual path, the source must translate it into a physical route from itself to the destination. This physical route is the one that will be used to forward messages.

92

Chapter 4. Virtual Routing Protocol

0

10

16

17

Figure 4.8: Virtual path computed from the source unit 0 to the destination unit 17. 4.2.1.2

Route Setup

In the route setup, the source, i, knows a virtual path, V P = {vp0 , vp1 , ..., vpn }, to the destination, j, with vp0 = i and vpn = j, and it wants to translate this virtual path on a physical route R to the destination. To translate the virtual path to a physical route, the source uses a route translation (RTRANS ) message. The route translation message carries the virtual path through which it is supposed to pass, V P , and the physical route from i, which is constructed during the translation process. Firstly, the vp0 = i needs to contact the first unit in the virtual path, vp1 , which is either a neighbor of unit i or a unit for which i is a scout. If vp1 is a neighbor of i, then i simply puts the id of vp1 in the physical route of the RTRANS and forwards it to vp1 . Otherwise, i is a scout to vp1 , and it is supposed to have a route to vp1 . Then, i puts this route on the physical route of the RTRANS and sends the message through this route. As long as the message travels along this route, every unit receiving the RTRANS forwards the message to the next unit in the physical route. When RTRANS eventually reaches vp1 , then vp1 appends the route to vp2 on the physical route already stored in the RTRANS, and forwards the message through it. This is because vp1 is a scout to vp2 , and it is supposed to have a route to vp2 . This process is repeated until the RTRANS reaches the destination vpn . For any intermediate vpk , when the RTRANS reaches a unit vpk , it appends the route to vpk+1 and forwards the

4.2. Protocol Specification

Source

93

Virtual hop

Physical route unit

Destination

Figure 4.9: Physical route through which the RTRANS should be forwarded.

k

j Transmission range of unit

Source

Virtual hop

Physical route unit

Destination

Figure 4.10: Physical route through which the RTRANS is forwarded.

message through it. The route from vpk to vpk+1 is supposed to be archived in vpk , as vpk is a scout to vpk+1 . As the RTRANS has a defined route to be forwarded through, it is possible that it passes through a unit which is a physical neighbor of the destination of the RTRANS, figure 4.9 exemplifies this situation. Thus, VRP allows unit k to deliver the RTRANS directly to its destination if the RTRANS’s destination is a physical neighbor of unit k, i.e., unit k forwards the RTRANS to its destination instead

94

Chapter 4. Virtual Routing Protocol

vp 1 j=vp

3

vp 2 i=vp Source

0

Virtual hop

Physical route unit

Destination

Figure 4.11: Physical route of a RTRANS message. vp 1 j=vp

3

vp 2 i=vp Source

0

Virtual hop

Physical route unit

Destination

Figure 4.12: Physical route of a RTRANS message without loops.

of forwarding the RTRANS to the next unit in the RTRANS route. This is done to reduce the length of the RTRANS’s physical route, and it can be viewed by comparing the routes in figure 4.9 and 4.10. Figure 4.9 illustrates the route that the message should be forwarded through and figure 4.10 illustrates the route that the message is really forwarded through. When the RTRANS message reaches its destination, it contains a physical route from the source to the destination. The RTRANS message, in general, does not pass

4.2. Protocol Specification

95

14 13

15

12 16 11 4

5 17

10 3 18 6

2

19

24

9

1

23

7

8

20

22 21

Source

Virtual hop

Physical route unit

Destination

Figure 4.13: Cutting loops at the destination. 14 13

15

12 16 11 4

5 17

10 3 18 6

2 1

19

24

9 8

23

7 20

22 21

Source

Virtual hop

Physical route unit

Destination

Figure 4.14: Cutting loops at the intermediate units.

through the shortest route and it may contain loops. Figure 4.11 shows a route of a RTRANS message. For this reason, when the destination receives the RTRANS message, it executes the LoopFree procedure. The LoopFree procedure computes route R′ ⊆ R, shown in figure 4.12. R′ is a shortest loop-free route over R that connects the source and the destination.

96

Chapter 4. Virtual Routing Protocol

Note that it is possible to cut loops before the RTRANS reaches the destination. When a unit detects a loop in a RTRANS message, it cuts it immediately. However, VRP does not consider this possibility, because a intermediate unit can cut a small loop and, by cutting this loop, it could be not possible to cut a larger loop. This is illustrated in figures 4.13 and 4.14. Both figures show the route that the destination returns to the source into the RREP message. The difference between cutting loops only in the destination, figure 4.13, and cutting loops in the intermediate unit, figure 4.14, is obvious. If the protocol cuts loops only in the destination the resulting route will have 9 hops. If the protocol allows intermediate units to cut loop the resulting route will have 17 hops. After computing R′ , the destination sends a route reply (RREP ) message, with the route R′ , to the source through the reverse route of R′ . So, the source has a loopfree route to reach the destination, and all data messages (DATA) are forwarded to the destination through route R′ . However, the translation of the chosen virtual path may fail, if the route from a unit in the virtual path to the next unit on the virtual path is no longer valid. If the route through which a RTRANS message is supposed to be forwarded is broken, it is possible to try to reestablish the connection to the destination without having to return to the source of the RTRANS, i.e., it is possible to try to find a detour from the unit that has detected the broken link to the destination. When unit k is supposed to forward the RTRANS to unit h but unit h is no longer a neighbor of k, then unit k detects a broken link. When unit k detects a broken link, it tries to find a detour to the destination to reestablish the connection. A detour DT = {dt0 , dt1 , ..., dtn } is a virtual path from k to the destination of RTRANS, where dt0 = k and dtn = vpn = j (the destination of the RTRANS).

4.2. Protocol Specification

97

The detour must have some properties: 1. it must be disjoint from the old virtual path V P = {vp0 , ..., vpn } of the RTRANS. To this purpose k computes Tj over L′ = (V ′ , A′ ) with V ′ = V − V P/vpn ; 2. the physical route from unit k to dt1 must not contain the link that was found to be broken. The first property ensures that RTRANS neither returns to the source nor ends in a deadlock. The deadlock can be generated if two units keep detouring a RTRANS one to the other. After computing the detour, unit k substitutes the invalid part of the original virtual path of the RTRANS with the detour. For example, if the route gets broken after it has passed by vpm , the new virtual path becomes: V P + DT = vp0 , ..., vpm , dt0 , ..., dtn Figure 4.15 exemplifies the replacement of the invalid virtual path with the detour. Also, unit k deletes the invalid part of the physical route of the RTRANS, i.e., the part of the physical route that comes after the broken link, and it appends on the resulting route the route to dt1 . Then unit k forwards the message to the next unit in the physical route. The perfect functioning of the protocol can only be guaranteed if the scouts have valid routes to their peered units, most of the time. To guarantee this, unit k must warn the last scout through which the RTRANS has passed, vpm , that the route that vpm has to vpm+1 is no longer valid. To warn the last scout, unit k sends a

98

Chapter 4. Virtual Routing Protocol

k a:

b:

vp

vp

vp

...

k= dt

dt

...

dt =vp

vp

vp

vp

...

0

0

c:

0

1

1

1

2

2

vp

vp

vp

vp

vp

k= dt

m−1

n

m

m+1

...

vp

n−1

vp

n

n

m−1

m

0

dt

1

...

dt =vp n

n

Figure 4.15: Substitution of the virtual path with the detour when unit k finds a broken route: a: virtual path; b: detour; c: new RTRANS virtual path.

route error (RERR) message to vpm . It can be noticed that unit k already has a physical route to unit vpm , this route is part of the physical route of the RTRANS message. How scouts update their routes will be discussed on Chapter 4.2.3. Note that the RERR message inherits the high priority of the RTRANS. A single message can be detoured several times. To avoid that the RTRANS remains in the network for a long period, the source can establish the maximum number of times a RTRANS message can be detoured. This limit is set in the RTRANS. Each time a unit detours the RTRANS it subtracts one from the number of detours allowed. When either the number of detours reaches 0 or there is no detour available to forward the message, a RERR message is sent to the source. Note that this RERR is sent to the last scout and then from the last scout to the source. The route to the last scout and the route from the last scout to the source are already known. However, the route from the last scout to the source may contain loops: thus the last scout executes the LoopFree procedure to obtain a loop-free route to the source. When the source receives a route error message, it can compute another disjoint

4.2. Protocol Specification

99

virtual path to the destination, if any is available. To compute the new virtual path V P ′ , the source constructs Tj over L′ = (V ′ , A′ ) with V ′ = V − V P/vpn , where V P is the set of units already used in previous virtual paths. If the logical structure has a high connectivity, it may be expected that the source is able to construct alternate virtual paths over L′ = (V ′ , A′ ). To avoid testing all this virtual paths the user can establish a limit on the number of tested virtual paths. If this limit is reached or there are no more virtual paths available, the source ends up by searching a physical route from itself to the destination by sending a route request (RREQ) message. RREQ messages are flooding messages. When the route request message reaches the destination, it contains a physical, loop-free route from the source to the destination. Then the destination reverts this route and sends a route reply (RREP) to the source through this route, and the source can use this route to send messages to the destination. If the protocol is not able to build a route between the source and the destination using route requests, the protocol warns the higher level protocol that it is not possible to establish the connection with the destination and drops the message. It is important to point that the route translation process can be very long depending on the scouts physical positions. In the worst case, the scouts on a virtual path may be in totally opposite direction to each other so that the final actual route computed might be a very long zigzag route. However, it will be demonstrated through simulation results in Chapter 5.3.1 and figure 5.5 that the size of a route established using the route translation process, after cutting its loops, is in average from two to three times the size of the shortest possible route between the units.

100

Chapter 4. Virtual Routing Protocol

4.2.2

Route Maintenance

Due to mobility and limited power of the units, routes can get disconnected. A route R′ = {r0 , r1 , ...rm } gets disconnected when two consecutive units rp and rp+1 lose their connection, either because they move outside each other’s transmission range, or there is an obstacle that does not permit them to communicate directly, or because at least one of them fails, say unit rp+1 . When unit rp tries to send a DATA message to unit rp+1 , it identifies the broken link, then unit rp informs the source r0 that route R′ gets disconnected, by sending a RERR message to the source. Note that rp cannot inform the last scout, as it is done in the route acquisition phase of the protocol, because it does not know which is the last scout as DATA messages do not carry virtual paths. RERR messages inherit their priorities from the DATA messages. When the source receives the RERR, it must set another route to the destination, if a route to that destination is still desired. The new route can be built either using another disjoint virtual path (if any virtual path is available and the limit on the number of tested virtual paths is not reached) or by flooding the network with a RREQ message.

4.2.3

Scout Update

Scout Update is executed by a scout u when it receives a route error notifying that the route to some peered unit w ∈ Pu is no longer valid. All messages used by scout update are forwarded in low priority. This greatly reduces interferences with the messages used in route acquisition, route maintenance and in data communication, which are forwarded with higher priorities.

4.2. Protocol Specification

101

When executing a scout update, scout u, besides looking reactively for a route to w ∈ Pu , also looks proactively for routes to all units in Pu . This means that scout u uses the same RREQ message to update all of its archived routes, thus avoiding sending an individual RREQ to each one of its peered units. A RREQ message with this behavior is called a multiple destination RREQ. The multiple destination RREQ differs from the single destination RREQ by the contents of the destination field: in the single destination RREQ, the destination field contains the id of the destination unit; while in multiple destination RREQ, it contains the special id α. This special id means that the destinations of a multiple destination RREQ message are all units in Pu , where u is the source of the RREQ. When unit g receives a RREQ with α in the destination field, it analyses the graph L. If g ∈ Pu , g sends a RREP to the source of the RREQ, unit u. The only difference between the multiple destination RREQ and the single destination RREQ is that in the former one the RREQ is forwarded even by its destinations. Thus, the RREQ reaches the entire network. A unit receiving a RREQ, drops the message only if the same message was already received. If the unit u has s peered units, the proactive update of routes to all of its peered units adds little overhead. The additional cost essentially consists in s − 1 unicast RREP messages travelling in the reverse directions along the new discovered routes from u to every unit in Pu . 4.2.3.1

Proactive Scout Update

To guarantee the perfect functionality of VRP, the scouts must have valid routes to their corresponding peered units almost always. Thus a scout must update a broken link as soon as it detects that the route is broken. However, if a route archived in

102

Chapter 4. Virtual Routing Protocol

a scout is not used for a long period of time, this route can result broken when it is used for the next time, to avoid this problem the scout can employ a proactive scout update. The proactive scout update is executed in regular time intervals ∆. If a scout updates its routes to its peered units at time t, in time t + ∆ the scout reupdates its routes to its peered units if no update is made in between, i.e., if the scout detects that a route to its peered units is broken in between t and t + ∆, say at time t′ , the scout reupdates its routes immediately at t′ , and the time to the next proactive scout setup becomes t′ + ∆. In this way, the proactive scout update is executed only when the network traffic is small, and there is some virtual paths that are not used. ∆ can be set equal to infinite (∆ = ∞), thus the proactive scout update will never be executed, leaving the scout update in a reactive fashion. The proactive scout update uses multiple destination RREQ messages, thus a unit have to send just one RREQ message to update the route to all of its peered units. When the network starts its operation, the scouts do not have valid routes to their corresponding peered units, and it is possible to perform a proactive scout update at time 0 to guarantee the perfect functionality of the VRP from the network beginning. The number of messages sent for the proactive scout update of each scout is 1 RREQ message and s RREP messages, where s is the number of peered units.

4.3. Size of the Routing Tables

4.3

103

Size of the Routing Tables

The virtual routing protocol maintains only small routing tables. A unit maintains routes only to its peered units and to the units with which it is communicating in this moment. If the number of peered units is s, each unit of the system maintains routes to O(s) other units.

4.4

Messages

Five different types of messages are used by the virtual routing protocol, route translation (RTRANS ), route request (RREQ), route reply (RREP ), route error (RERR) and data messages (DATA). The RTRANS, RREQ and RREP messages are used in the route acquisition and in the scouts update phases of the protocol to establish routes from one unit to another, while the RERR is used during the route acquisition and the route maintenance phase from one unit to warn other units about broken links.

4.4.1

Route Translation - RTRANS

The route translation (RTRANS) message is used by the source to translate a virtual path into a physical route to the destination. priority

last−scout

detours allowed

current hop

virtual path

physical route

Figure 4.16: Route Translation message. Figure 4.16 illustrates the RTRANS message. The fields are defined as follows: • priority: the priority of the RTRANS, which is always high in this implementation;

104

Chapter 4. Virtual Routing Protocol

• last-scout: the id of the last virtual hop through which the RTRANS has passed; • detours allowed : the number of times the RTRANS can be detoured; • virtual path: the virtual path computed by the source; • current hop: the number of units through which the RTRANS has passed; • physical route: the physical route from the source to the destination. The source of the message is the first unit in the virtual path. The destination of the message if the last unit of the virtual path. When a unit wants to communicate with another unit and it does not have a physical route to it, it generates a RTRANS message from itself to the other unit. The source address of the RTRANS is the address of the unit that generates the RTRANS, and the destination address of the RTRANS is the address of the target unit. The contents of the virtual path field of the RTRANS is the virtual path to the destination computed by the source. The first unit in the virtual path is the source, and the second unit is either a neighbor of the source or a source’s peered unit. Thus the source knows a route to this unit, which is copied into the physical route field of the RTRANS. The RTRANS is then forwarded through this route. When a unit k receives a RTRANS message, it analyses it in this order:

4.4. Messages

105

If k is the destination of the RTRANS then k invokes the LoopFree procedure to compute a loop-free route connecting k to the source of the RTRANS; k discards RTRANS; k sends a RREP to the source of RTRANS; Else If k is the last unit in the current physical route then /* This implies that k must be the next virtual hop */

k appends on the physical route the route to the next virtual hop; k sets last-scout to k; k increments the current hop counter; k sends RTRANS to the next unit in the physical route; Else /* k is a unit in the route from the last-scout to the next virtual hop */

k increments the current hop of the RTRANS message; k forwards the message to the next unit in the physical route. If k is a virtual hop of the RTRANS message that does not have a route to the next virtual hop, or k is a unit in the physical route whose attempts to send the RTRANS to the next unit fails, then k tries to establish a detour to the destination. If the current number of detours allowed for RTRANS is zero or there is no detour available from k to the destination, then k sends a RERR message to the source of the RTRANS and piggybacks in this RERR the RERR to the last-scout of the RTRANS. If k finds a detour to the destination, it decrements the number of detours allowed by one, and forwards the message through the detour. If a detour can be used, k must generate a RERR message to the last-scout of the RTRANS to warn it about the broken link.

106

Chapter 4. Virtual Routing Protocol

4.4.2

Route Request - RREQ

The route request (RREQ) message is used on the route acquisition phase of the protocol if there is no virtual path available between the source and the destination, as well as on the scout update phase. RREQ messages are always flooded through the entire network. They can be used with single or multiple destinations. Single destination RREQ are used by the source to find a route to a destination, while multiple destinations RREQ are used by the scouts to update routes to their peered units. source

destination

sequence number

priority

physical route

Figure 4.17: Route Request message. The RREQ message, figure 4.17, has the following fields: • source: the id of the source unit; • destination: on single destination flooding it contains the id of the destination unit; on multiple destinations flooding it contains the special character α; • sequence number : is used to uniquely identify each RREQ; • priority: is set to low in messages used in the scout update phase, and it is set to high when used in the route acquisition phase; • physical route: the physical route from the source to the destination. Note that each RREQ message must be uniquely identified to guarantee that the route being built by the RREQ is loop-free. The sequence number, chained with the source address, is able to uniquely identify each RREQ in the system. This technique is borrowed from other routing protocols like the DSR [47].

4.4. Messages

107

When a RREQ is received by unit k, it is analysed as follows: If k already received this RREQ message then /* this can be revealed by the tuple (source, sequence-number ) */

k discards the message; Else k archives a copy of the tuple (source, sequence-number ); /* to identify future copies of this RREQ */

If destination = k then k reverts the route of the RREQ; /* finding a route from k to the source of the RREQ */

k discards RREQ; k sends a RREP to the source of the RREQ through the reverse route; Else If destination = α and k ∈ Psource k sends a RREP to the source; k appends its own id into the physical route; k rebroadcasts the RREQ. Else k appends its own id into the physical route; k rebroadcasts the RREQ.

4.4.3

Route Reply - RREP

The route reply (RREP) message is used by the destination of either a RTRANS or a RREQ, to return to the source of the RTRANS or RREQ the route connecting the source to itself. priority

physical route

Figure 4.18: Route Reply message. The RREP message, figure 4.18, contains the following fields:

108

Chapter 4. Virtual Routing Protocol

• priority: the priority of the RREP, which is inherited from the RTRANS or the RREQ; • physical route: the physical route from the source of the RREP to the destination of the RREP. The source of the message is the first unit in the physical route. The destination of the message if the last unit of the physical route. When a unit j receives a RTRANS of which it is the destination, it executes the LoopFree procedure to obtain a loop-free route from the source of the RTRANS, denoted unit i, to itself unit j. If the received message is a RREQ message, the route between the source, unit i, and the destination, unit j, is already loop-free. As VRP assumes that all units have the same transmission range, the reverse route from unit i to unit j enables j to communicate with i. Thus, unit j puts the reversed, loop-free route into the physical route field of the RREP and sends the messages through this route. The priority of the RREP message is inherited from RTRANS, or RREQ. When RREP is received by unit k, it is analysed as follows: If destination = k then k reverts the physical route; /* k uses this route to send DATA */ k stores the reverted route to send DATA messages to the destination;

Else

k discards the RREP;

k forwards the message to the next unit in the physical route; If the next unit is not inside unit k’s transmission range then k drops the RREP message.

4.4. Messages

109

If the RREP is dropped, the destination of the RREP (that is the source of the RTRANS or RREQ) will not receive the RREP and after a timeout it may retransmit the RTRANS or RREQ.

4.4.4

Route Error

The route error (RERR) message is used to warn other units about a broken route. A broken route can be detected when forwarding either RTRANS or DATA messages. original−dest

priority

broken−unit

last−scout

actual hop

virtual path

physical route

Figure 4.19: Route Error message. The RERR message, figure 4.19, contains the following fields: • original-dest: the id of the original destination of the RTRANS or DATA message; • priority: the priority of the RERR, which is inherited from the RTRANS or DATA message; • broken-unit: the id of the unit that caused the broken link; that is the unit to which the current unit was unable to send the RTRANS or DATA message; • last-scout: used to piggyback the RERR to the last scout of the RTRANS while going to the source; • physical route: the physical route from the source of the RERR to the destination of the RERR.

110

Chapter 4. Virtual Routing Protocol

The source of the message is the first unit in the physical route. The source is the unit that has detected the broken link. The destination of the message if the last unit of the physical route. The destination is the source of the RTRANS or DATA message. The broken link can be identified by the pair (source, broken-unit) in the RERR message. The precise meanings of some fields and the way the RERR is managed are different when the RERR occurs on RTRANS or DATA messages, as described below. 4.4.4.1

Route Error on Data Messages

If a unit detects a broken link when it is forwarding a DATA message, it creates a RERR to warn the source of the DATA message about the broken link. The fields of the RERR are used as follows: • priority is the same of the DATA message; • physical route is the reverse route along which the DATA message has travelled until now; this information can be recovered from the physical route field of the DATA message; • broken-unit contains the id of the unit that caused the broken link, i.e., the next unit in the physical route of the RTRANS; • original-dest field contains the original destination of the DATA message, and it is used to warn the source that the route to this destination is not valid anymore. The other fields of the RERR are not used. After the RERR is created, the RERR is forwarded until it reaches its destination. When the RERR reaches its

4.4. Messages

111

destination, this unit constructs another route if a route to the original destination of the DATA message is still needed. 4.4.4.2

Route Error on RTRANS Messages

When a unit k detects a broken link when forwarding a RTRANS message, it tries to find a detour to reestablish the connection with the destination. If a detour is found, k sends a route error to last-scout to warn it about the broken link. Otherwise, k sends a RERR to the source of the RTRANS and it uses this RERR to piggyback a RERR to the last-scout. • priority of the RERR is the same of the RTRANS, i.e., high; • last-scout is the same of the RTRANS; • broken-unit contains the id of the unit to which k was unable to send RTRANS; • original-dest contains the original destination of the RTRANS. This information is needed by the source of the RTRANS to identify the route to be rebuilt; • physical route field is the reverse route of the RTRANS. When a unit k receives a RERR, it analyses it in this order:

112

Chapter 4. Virtual Routing Protocol

If last-scout 6= ∅ and k = last-scout then

/* RERR generated when forwarding a RTRANS message */ /* The field last-scout of the RERR is the last scout of the RTRANS */

k invokes the scout update procedure; If destination 6= k then

/* That is, the RERR destination is the source of the RTRANS */

k invokes the LoopFree procedure to cut the loops from the physical route of the RERR message; /* Finding a loop-free route to the source of the RTRANS */

k substitutes the route of the RERR with the loop-free route returned by the LoopFree procedure; Else

k forwards the message to the next unit; /* k is the final destination of the RERR */

k discards the RERR message;

Else

If destination = k then /* k is the source of the RTRANS or DATA message*/

k builds another route to that destination, if it is still desired; Else

k discards the RERR; k forwards the RERR to the next unit in the physical route.

4.4.5

Data messages

As the VRP is based on a source routing, DATA messages must carry the physical route through which they must pass. The DATA message, figure 4.20, consists in the following fields: • priority: the priority of the DATA message, set to medium in the current implementation of VRP; • physical route: the physical route from the source to the destination;

4.5. Loop Free Routes

113

• data: the data carried by the message. The source of the message is the first unit in the physical route. The destination of the message if the last unit of the physical route. priority

physical route

data

Figure 4.20: Route Reply message. When a DATA message is received by unit k, it is analysed as follows: If destination = k then k passes the message to the upper level protocol; Else k forwards the message to the next unit in the physical route;

4.5

Loop Free Routes

Routing protocols should construct loop-free routes. The following discussion proves that the virtual routing protocol guarantees that DATA messages are always routed through loop-free routes. Each RREQ message can be uniquely identified by the tuple (source, sequencenumber ). The RREQ message is forwarded until it reaches its destination or until it has passed through all units of the network. The pair (source, sequence-number ) allows units to discard duplicate copies of a RREQ: all units forward the first RREQ they receive, and drop later copies. This process assures that the route built by the RREQ is loop-free, because a unit does not forward the same RREQ twice. This is the same technique used in [47].

114

Chapter 4. Virtual Routing Protocol

RREQ messages are used by the source to build a route to the destination when no virtual path is available between these two units. From the preceding reasoning, it is immediate that such routes are loop-free. The routes from scouts to their corresponding peered units, archived in the scouts themselves, are inherently loop-free. This property is guaranteed because such routes are constructed using RREQ messages. Routes constructed by translating virtual paths into physical routes, by means of RTRANS messages, may contain loops. The RTRANS is sent from one virtual hop to another. When the RTRANS reaches a virtual hop, it collects the route from this virtual hop to the next one. The route from one virtual hop to the next one is guaranteed to be loop-free as it is built using RREQ messages. This guarantees that the RTRANS reaches the destination, unless it results in a route error. Also, the field current-hop of the RTRANS is used to assure that a unit always knows which is the next physical hop, i.e., the unit to which it must forward the RTRANS. However, when the RTRANS reaches its destination, the collected physical route may have loops. If the destination receives a route with loops, the LoopFree procedure is called to obtain a loop-free route. After computing the loop-free route, the unit reverts this route and it becomes the route of the RREP, thus it is guaranteed to be loop-free. This route is used to reach the source of the RTRANS. DATA messages are forwarded through physical routes received in RREP messages. As the physical route of the RREP is loop-free, the physical route of the DATA messages is also guaranteed to be loop-free. When a unit is forwarding a RTRANS message and it finds a broken link, it tries to reestablish the route. If it can reestablish the connection, it must warn the

4.5. Loop Free Routes

115

last scout through which the RTRANS has passed about the broken link. The route between this unit and the last scout is guaranteed to be loop-free because it was the route archived in the last scout, and routes archived in the scouts are always loop-free. If the connection cannot be reestablished, the unit must warn the source of the RTRANS about it, and it must also warn the last scout, this is done by sending a RERR message. The RERR is forwarded in two stages: first it goes from the unit that finds the broken link to the last scout; then it goes from the last scout to the source of the RTRANS. The first stage is guaranteed to be fault-free as explained above. The route for the second stage, however, might not be loop-free: for this reason the last scout invokes the LoopFree procedure to compute a loop-free route from itself to the source of the RTRANS. On the other hand, when a unit is forwarding a DATA message and it finds a broken link, it simply reverts the physical route passed by the DATA message until this unit and this becomes the physical route of the RERR. As the physical route of the DATA messages are loop-free, the physical route of the RERR is also guaranteed to be loop-free.

4.5.1

LoopFree procedure

LoopFree is a simple procedure which receives a route from unit i to unit j which may contain loops, and returns a shortest loop-free route between i and j.

116

Chapter 4. Virtual Routing Protocol

4.6

Improvements

Several improvements to VRP have been devised and could be easily implemented. The improvements include: Scout Update over Received Messages, Shortcuts in Virtual Route Translation, Avoiding High Priority Flooding and Proactive Zone. These improvements are briefly described in this Section. Implementation and evaluation are matters for future work.

4.6.1

Scout Update over Received Messages

The scout update over received messages allows the scouts to update routes to their peered units using routes from received RREP messages. When a unit u receives a RREP, it analyses the physical route of the RREP. If this route contains one peered unit of u, unit w, then, u may update its archived route to w with this new route, as the RREP probably has a fresher route. This may save later floodings of RREQ messages to update the scouts.

4.6.2

Shortcuts in Virtual Path Translation

Let V P = {vp0 , vp1 , ..., vpn } be the virtual path of a RTRANS message, and k be a unit in the physical route from vp0 to vp1 and also a neighbor of vpm , i.e., k ∈ Nvpm , with m > 0. When k receives the RTRANS, it can shortcut the route translation by sending the RTRANS directly to vpm Figure 4.21 illustrates this modification. Unit k can send the message to unit w, which is a virtual hop of the RTRANS, and the RTRANS has not passed through w yet. Although unit u is also a neighbor of k, k does not send the RTRANS to u, because the RTRANS has already passed through u.

4.6. Improvements

117

u

k w

Source

Virtual hop

Physical route unit

Destination

Figure 4.21: Shortcut in virtual path translation.

4.6.3

Avoiding High Priority Flooding

High priority floodings are used by the source when no virtual path is available between itself and the unit to which it wants to communicate. This situation occurs after the source has sent the maximum allowed number of RTRANS messages all of which resulted in a route error. Note that a RERR is returned to the source either when the maximum allowed number of detours has been reached, or when no more detours are available. When the source of the RTRANS receives the RERR, it may simply delay sending the message instead of using a high priority RREQ. After this delay, the source retries the virtual paths to reach the destination. These virtual paths are probably up-to-date, as the scouts have invoked the scout update procedure meanwhile the previous RTRANS messages were forwarded. If there is no route between the source and the destination, the source cannot

118

Chapter 4. Virtual Routing Protocol

keep delaying the message forever. If a message reaches the maximum delay limit, the message is dropped and the high level protocol is warned.

4.6.4

Proactive Zone

It is possible to define a proactive zone around each unit of the system, like it is done in [36, 39, 81]. The proactive zone of unit i is the collection of units whose minimum hop distance from unit i is not greater than the zone radius. For example, if the zone radius of unit i is set to 2, than the proactive zone of unit i is composed by all units that are at most 2 hops from unit i. The proactive zone can be used to reduce the length of the virtual paths and also to reduce the delay to establish routes between two units. However, it increases the routing overhead due to routing messages needed to update routes inside the proactive zone of the units. Reducing the length of the virtual paths might also reduce the time to construct the physical routes by means of RTRANS messages and also reduce the length of routes used by DATA messages.

Chapter 5 Simulation Results This Section contains a detailed evaluation of the virtual routing protocol and a comparison between VRP and DSR and between VRP and ZRP. We choose to compare the virtual routing protocol with the DSR because both protocols use the source routing technique and DSR, together with AODV, is one of the most prominent on-demand routing protocol. And to compare VRP with ZRP because both are hybrid routing protocols, even though their approach are different. A comparison between VRP and other routing protocols, like AODV, is part of future work. The purposes of these simulations are: (i) to evaluate VRP for different traffic loads, for different speed of the units, for different transmission ranges of the units and for different number of units in the network; (ii) to compare VRP with DSR and ZRP based on the delivery ratio, on the routing overhead, on the delay to establish routes, and on the size of the routing tables.

120

Chapter 5. Simulation Results

To the purpose of this evaluation and comparison a detailed model of the link layer protocols would just bring in some new variables without significant contribution to the accuracy of the results. For these reasons, a new simulator was built. VRP, as defined in Chapter in 4, the version of DSR defined in the internet draft number 9 [46], and the version of ZRP defined in the internet draft number 4 [37] were implemented in the simulator. VRP was implemented without any of the improvements outlined in Chapter 4.6. The implementation of such improvements is part of on going work. The simulation results of VRP reported here were performed using the Ring of Rings logical structure. Different logical structures might have a better performance depending on the user application.

5.1

Simulator

The simulator incorporates a simplified emulation of the MAC protocol. More precisely, this protocol emulates the CSMA and the RTS/CTS protocols of the IEEE 802.11. It works as follows: when a unit u wants to send a message to unit v, it invokes the MAC protocol which analyses the neighbor units of u (CSMA). If no unit is using the medium, the MAC protocol silences the neighbors of u (the RTS phase) and the neighbors of v (CTS phase); then unit u can start its transmission. If a neighbor of u is using the medium, the transmission of unit u is delayed. The delay implemented in the simulator is an exponential backoff, i.e., the delay is randomly chosen between 0 and 2θ , where θ is the number of times the unit tries to send the message. After the delay, unit u is allowed to retry the transmission. If two units want to start their transmissions at the same moment, the MAC layer allows one

5.1. Simulator

121

of these units to use the medium and it imposes a delay to the other. The choice about which unit uses the medium and which is delayed is completely random. The MAC layer implemented in the simulator also provides information to the units about their neighbor units. This information is supplied and used by all routing protocols (DSR, VRP and ZRP). The roughest approximation of the simulator is that it does not consider collisions. Assume that a unit u starts to send a message to unit v at time t and it finishes sending the message at time t′ . The RTS/CTS protocol, of the simulated layer, silences the units that are neighbors of u and v at time t and also any other unit which becomes a neighbor of u or v before time t′ . In the simulator each unit maintains an out buffer for messages. The out buffer of unit i contains the DATA message produced at unit i that are waiting for a route, the routing messages produced by unit i and not sent yet, and the messages that unit i received and must forward to other units. In all simulation reported in this Chapter, the buffer size was set for 300 messages. The out buffer is implemented as a LRU (Last Recent Used ) buffer. Different replacement strategies could be used, although they were not implemented in the simulator. For example, it would be possible to drop messages based on their priorities instead of their ages. Data messages stay in the out buffer waiting for a route for 60 seconds, and if no route to the destination can be built in this time the messages are dropped. Units send messages from their respective out buffers according to their priorities, i.e., messages with higher priorities are sent before messages with smaller priorities.

122

Chapter 5. Simulation Results

5.1.1

Simulator Validation

To validate the new simulator, called Simple Wireless Routing Simulator (SWRS ), the results provided by SWRS are compared with the results of simulations reported in [78], where the DSR protocol was simulated with Network Simulator 2 (NS-2 ) [27]. Simulations with SWRS use the same simulation parameters and scenarios as in [78]. To the purpose of validation, two parameters are compared: the delivery ratio and the route acquisition delay. Is should be noticed that the results produced by the two simulators might be influenced by different implementations of the DSR routing protocol. SWRS implements the DSR routing protocol following the specifications of the internet draft number 9 [46] including all optimizations proposed in the draft, while the results presented in [78] were obtained with NS-2 following the specification of the internet draft number 3, even though it is not clear if all optimizations were implemented or not. The simulation parameters are as follows: the network is a field of 1500m x 300m, composed by 50 units. The transmission range of the units is 250m. The link bandwidth is set to 2Mb/s. Only data messages of 512-bytes are used. The mobility model is the random waypoint model. Each unit starts its journey from a random location to a random selected destination with a randomly chosen speed. The speed is uniformly distributed between 0 to 20m/s. Once the destination is reached, another random destination is selected after a pause time. The pause time varies from 0 to 900 seconds. Simulations are run for 900 seconds. Each data represents the average of at least five runs with identical traffic models, but different randomly generated mobility scenarios. To generate the different scenarios a pseudo-casual number generator was used.

5.1. Simulator

123

To prevent buffering data messages forever, data messages that wait for a route for more than 30 seconds are dropped. Figures 5.1 and 5.2 compare the delivery ratio of DSR produced by SWRS and the ones produced with NS-2 reported in [78]. The results are reported for 10, 20, 30 and 40 simultaneous CBR connections. For 10, 20 and 30 connections, each source generates 4 messages per second, while for 40 connections, each source generates 3 messages per second. It is possible to observe from figure 5.1 that when the number of connections is small, i.e., the network traffic conditions are light, the results produced by SWRS are extremely close to the results produced by the NS2. On the other hand, when the network traffic conditions become heavier, i.e., 30 and 40 simultaneous CBR connections (figure 5.2), the results produced by SWRS are influenced by the units’ mobility (The units’ mobility is inversely proportional to the pause time, i.e., increasing the pause time decreases the mobility and vice versa). When the mobility is high, the dominating cause to messages losses is the mobility itself, and in such case the results produced by SWRS are extremely close to the ones produced by NS2. However, under heavy traffic conditions but with low mobility, the major cause of messages loses is the collisions. In this case the results produced by the SWRS can be considered as an optimistic result, as SWRS does not consider collisions. Figures 5.3 and 5.4 compare the route acquisition delay of DSR produced by SWRS and the ones produced with NS2 reported in [78]. It is possible to observe from figure 5.3 than when the number of connections is small, i.e., the network traffic conditions are light, the results produced by SWRS are very similar to the ones produced by the NS-2.

124

Chapter 5. Simulation Results

Delivered data messages - 20 CBR connections 100

95

95

90

90 Delivery (%)

Delivery (%)

Delivered data messages - 10 CBR connections 100

85 80 75 70

85 80 75 70

New Simulator NS-2

65

New Simulator NS-2

65

60

60 0

100

200

300

400

500

600

700

800

900

0

100

200

300

Stop time (sec)

400

500

600

700

800

900

Stop time (sec)

Figure 5.1: Simulator validation: Comparison of the delivery ratio with 10(left) and 20(right) simultaneous CBR connections. Delivered data messages - 40 CBR connections 100

95

95

90

90 Delivery (%)

Delivery (%)

Delivered data messages - 30 CBR connections 100

85 80 75 70

85 80 75 70

New Simulator NS-2

65

New Simulator NS-2

65

60

60 0

100

200

300

400 500 Stop time (sec)

600

700

800

900

0

100

200

300

400 500 Stop time (sec)

600

700

800

900

Figure 5.2: Simulator validation: Comparison of the delivery ratio with 30(left) and 40(right) simultaneous CBR connections.

On the other hand, when the network traffic conditions become heavier, 30 and 40 simultaneous CBR connections (figure 5.2), the results produced by SWRS are again influenced by the units’ mobility. When the mobility is high, the major cause of delay in the route acquisition is the mobility itself, and in such case the results produced by SWRS are extremely close to the ones produced by NS-2. However, under heavy traffic conditions but with low mobility, the dominating cause of delay during the route acquisition is the collisions produced by the heavy traffic. In this case the results produced by SWRS can be considered as an optimistic result. In conclusion, simulations outputs produced by SWRS are extremely close to the

5.1. Simulator

125

Average delay to establish a route - 10 CBR connections

Average delay to establish a route - 20 CBR connections

1.8

1.8 New Simulator NS-2

1.6

1.4 Time (miliseconds)

1.4 Time (miliseconds)

New Simulator NS-2

1.6

1.2 1 0.8 0.6

1.2 1 0.8 0.6

0.4

0.4

0.2

0.2

0

0 0

100

200

300

400

500

600

700

800

900

0

100

200

300

Stop time (sec)

400

500

600

700

800

900

Stop time (sec)

Figure 5.3: Simulator validation: Comparison of the route acquisition delay with 10(left) and 20(right) simultaneous CBR connections. Average delay to establish a route - 30 CBR connections

Average delay to establish a route - 40 CBR connections

1.8

1.8 New Simulator NS-2

1.6

1.4 Time (miliseconds)

1.4 Time (miliseconds)

New Simulator NS-2

1.6

1.2 1 0.8 0.6

1.2 1 0.8 0.6

0.4

0.4

0.2

0.2

0

0 0

100

200

300

400 500 Stop time (sec)

600

700

800

900

0

100

200

300

400 500 Stop time (sec)

600

700

800

900

Figure 5.4: Simulator validation: Comparison of the route acquisition delay with 30(left) and 40(right) simultaneous CBR connections.

results produced with NS-2 when collisions are not a major issue in the simulations. This situations occur when the traffic conditions are light, i.e., when the number of connections is small, and also when the traffic conditions are heavy and the mobility is high. On the other hand, when the traffic conditions are heavy and the mobility is small, collisions are a major issue, and the results produced by SWRS can be considered as an optimistic result of the protocols functioning.

126

Chapter 5. Simulation Results

5.2

Simulation Model

Traffic is modelled as a number of randomly selected source/destination units. Sources generate a Constant Bit Rate (CBR) traffic. The number of sources is constant during the entire simulation experiment. The duration, in seconds, of each CBR connection is randomly selected in the interval (0, CBR Len). The number of messages generated per second for each CBR connection is fixed for the duration of the entire simulation. The number of CBR connections, the maximum duration of the connections and the number of messages per connection are set to model different traffic loads of the network. The network covers a square field area of sides ranging from 1000 to 2000 meters. The units’ transmission range goes from 200 to 500 meters and the number of units varies from 75 to 201 units. Given the network area and the number of units in the network, the transmission range should be great enough to guarantee the connectivity of the network. The mobility model used is the random waypoint model [78]. In the random waypoint model, each unit starts in a random location, where it is paused for a pause time. When the pause time expires, the unit chooses a random destination inside the network area and it starts its journey to the destination point with a randomly selected velocity. Units’ speed is uniformly distributed between 0 and V el M ax. When a unit either reaches the destination point or chooses velocity 0, it pauses again. When the pause time expires, the unit restarts its movement. In our simulations the pause time ranges from 0 seconds to 600 seconds, while V el M ax ranges from 0m/s (no mobility) to 20 m/s. The link bandwidth was set to 1Mb/s, and the messages size for 512 bytes.

5.3. Evaluation

127

Each simulation run is set to 600 simulated seconds. All reported data are derived as the average of at least five runs with identical traffic models, but different randomly generated scenarios. For any given traffic model, every different scenario is characterized by different settings of:(i) the start point of the units; (ii) the units’ mobility (speed and pause time); (iii) the communication sources; (iv) the destination of each communication; (v) the duration of each communication. This way to report the data is exactly the same as the one used in [78]. For each simulation run at least 1000 routes are built. The number of detours allowed for each RTRANS message was always set to 3, except when otherwise mentioned.

5.3

Evaluation

This Section evaluates VRP with a different number of units in the network, different traffic load, different transmission range and different units’ velocity.

5.3.1

Virtual Path Translation

Simulations to evaluate the performance of the virtual path translation via RTRANS messages were performed using a network of 1000x1000 meters, with 75 units. The transmission range of the units varies from 200 to 500 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity is 1m/s. The number of simultaneous CBR connections were set to 20 and 40, where each CBR connection generates 2 messages per second and the connection duration is set randomly up to a maximum of 15 seconds. Figure 5.5 shows the length of the route from the source to the destination con-

128

Chapter 5. Simulation Results

Average number of hops for RTRANS messages - 20 CBR connections

Average number of hops for RTRANS messages - 40 CBR connections

16

16 RTRANS complete RTRANS with loops RTRANS without loops Virtual Hops Shortest route

Number of hops

12

12

10 8

10 8

6

6

4

4

2 200

250

300

350

400

Transmission range (meters)

450

RTRANS complete RTRANS with loops RTRANS without loops Virtual Hops Shortest route

14

Number of hops

14

500

2 200

250

300

350

400

450

500

Transmission range (meters)

Figure 5.5: Comparison of the average number of hops for RTRANS messages for 20 connections (left) and 40 connections(right).

structed by translating the virtual path by means of RTRANS messages. RTRANS complete is the complete length of the route from the source to the destination; RTRANS with loops is the length of the route constructed by the RTRANS, it is smaller than the RTRANS complete because when the RTRANS passes through a neighbor of the destination, this unit shortcuts the RTRANS to the destination; RTRANS without loops is the length of the loop-free route from the source to the destination; Virtual Hops is the length of the virtual path from the source to the destination; Shortest route is the length of the shortest route connecting the source with the destination. It can be seen that increasing the connectivity of the network, the difference between the RTRANS complete and RTRANS with loops decreases. This happens because increasing the network connectivity, the size of the virtual paths is reduced as shown in figure 5.5. Figure 5.5 also illustrates the difference between the length of the RTRANS with loops and RTRANS without loops. As RTRANS messages can contain several loops, independently of the connectivity of the network, it is essential that the destination of the RTRANS cuts the loops before sending the RREP. The figure also illustrates

5.3. Evaluation

129

Number of high priority RREQ per connections - 20 CBR connections

Number of high priority RREQ per connections - 40 CBR connections

0.14

0.12 Using max_detours = 0 Using max_detours = 3

Using max_detours = 0 Using max_detours = 3

0.1

0.1

Number of messages

Number of messages

0.12

0.08 0.06 0.04

0.08 0.06 0.04 0.02

0.02 0

0 0

1

2

3

4

5

0

1

Units’ velocity (m/s)

2

3

4

5

Units’ velocity (m/s)

Figure 5.6: Average number of high priority RREQ messages per CBR connection for 20(left) and 40(right) connections.

the difference between the loop-free route built by the RTRANS and the shortest route between sources and destinations. Figures 5.6 and 5.7 illustrate the effectiveness of detours. For these simulations the units’ speed varies from 0m/s to 5m/s, and the units’ transmission range is fixed at 250 meters. Other simulation parameters are the same as the ones mentioned above. Two sets of simulations were performed, in the first one the number of detours allowed to the RTRANS messages were set to 0, meaning that when a RTRANS message reaches a broken link, a RERR message is immediately returned to the source; in the second set of simulations, the number of detours allowed were set to 3, i.e., each RTRANS message can be detoured 3 times before a RERR message is sent to the source. Figure 5.6 shows the number of high priority RREQ messages sent per CBR connection for different unit’s velocity. As expected, when no detours are allowed, the number of high priority RREQ message is much higher. Figure 5.7 shows the number of RTRANS messages sent by the source per CBR connection for different unit’s velocities. When detours are not allowed, the source must send more RTRANS messages to establish a single connection with the desti-

130

Chapter 5. Simulation Results

Number of RTRANS messages per connection - 20 CBR connections

Number of RTRANS messages per connection - 40 CBR connections

2

2 Using max_detours = 0 Using max_detours = 3 Detours

1.8

Using max_detours = 0 Using max_detours = 3 Detours

1.8 1.6

1.4

Number messages

Number messages

1.6

1.2 1 0.8 0.6

1.4 1.2 1 0.8 0.6

0.4

0.4

0.2

0.2

0

0 0

1

2

3

4

Units’ velocity (m/s)

5

0

1

2

3

4

5

Units’ velocity (m/s)

Figure 5.7: Average number of RTRANS messages per CBR connection for 20(left) and 40(right) connections.

nation. The figure also reports the number of detours used to establish each CBR connection. This number increases as the speed of units increases. In fact, as the speed of the unit increases, the routes archived by the scouts get broken more frequently.

5.3.2

Scout Update

These simulations were made in a network of 1000x1000 meters, with 75 units. The transmission range is set to 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity varies from 0m/s to 5m/s. The number of simultaneous CBR connections is set to 20 and 40, where each CBR connection generates 2 messages per second and the duration of each connection is set randomly up to a maximum of 15 seconds. Figure 5.8 shows the total number of hop transmissions needed for the scout update phase of the protocol. It also compares the performance of VRP using multiple destinations RREQ with a version of VRP that uses only single destination RREQ messages. It can be noticed that the use of multiple destinations RREQ

131

Total hop transmissions for scouts update (RREQ + RREP) - 20 CBR connections 100000 Multiple destinations flooding 90000 Single destination flooding 80000 70000 60000 50000 40000 30000 20000 10000 0 0

1

2

3

4

5

Units’ velocity (m/s)

Number of hop transmissions

Number of hop transmissions

5.3. Evaluation

Total hop transmissions for scouts update (RREQ + RREP) - 40 CBR connections 260000 240000 Multiple destinations flooding Single destination flooding 220000 200000 180000 160000 140000 120000 100000 80000 60000 40000 20000 0 0 1 2 3 4 5 Units’ velocity (m/s)

Figure 5.8: Number of total hop transmissions for scouts update with 20(left) and 40(right) connections.

considerably reduce the total number of transmissions. This is due to the reduction on the number of RREQ messages, even though the number of RREP messages is increased.

5.3.3

Proactive Scout Setup

These simulations were performed using a network of 1000x1000 meters, with 75 units. The transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity is 1m/s. The number of simultaneous CBR connections were set to 20 and 40, where each CBR connection generates 2 messages per second and the duration of each connection is set randomly up to a maximum of 15 seconds. Figure 5.9 reports the total number of transmissions performed during the whole simulation experiments for the scout update phase of the protocol (RREQ + RREP messages). The figure demonstrates the advantage of doing a proactive scouts update at time 0. The use of such proactive update reduces the amount of transmissions needed to update the scouts. The figure also shows that this difference increases as the number of simultaneous CBR connections increases from 20(left) to 40(right).

Chapter 5. Simulation Results

Total hop transmissions for scouts update (RREQ + RREP) - 20 CBR connections 70000 No proactive setup 60000 With proactive setup

Total hop transmissions for scouts update (RREQ + RREP) - 40 CBR connections 140000 No proactive setup 120000 With proactive setup

50000

100000

Number of messages

Number of messages

132

40000 30000 20000 10000

80000 60000 40000 20000

0

0 0

1

2

3

4

5

0

Units’ velocity (m/s)

1

2

3

4

5

Units’ velocity (m/s)

Figure 5.9: Total hop transmissions of low priority messages with and without proactive scout update for 20(left) and 40(right) connections.

5.3.4

Using Hello Messages

VRP is designed to use units’ neighbors information to route acquisition. VRP can obtain such information either from the MAC layer, if it can provide such information, or by using “hello” messages. This section compares the performance of VRP when it gets the neighbors information from the MAC layer and when it must uses hello messages to obtain such information. These simulations were performed using a network of 1000x1000 meters, with 75 units. The transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity is 1m/s. The number of simultaneous CBR connections were set to 20 and 40, where each CBR connection generates 2 messages per second and the duration of each connection is set randomly up to a maximum of 15 seconds. The hello interval used goes from 1 to 20 seconds. Simulations were performed using all hello intervals. The data reported here correspond to the best one found among all simulations with different hello intervals. Figure 5.10 compares the delivery ratio of VRP with 20 and 40 simultaneous

5.3. Evaluation

133

Delivered data messages

Delivered data messages

100

100

99.5 95 98.5

Delivery (%)

Delivery (%)

99

98 97.5 97

90 85 80

96.5 With Hello Without Hello

75

With Hello Without Hello

96 95.5

70 0

5

10

15

20

0

5

10

Units’ velocity (m/s)

15

20

Units’ velocity (m/s)

Figure 5.10: Delivery ratio of VRP with and without hello messages to maintain up-to-date units’ information about their neighbors. Time to establish a route

Time to establish a route

2500

80000 With Hello Without Hello

2000

70000

With Hello Without Hello

Time (miliseconds)

Time (miliseconds)

60000 1500

1000

50000 40000 30000 20000

500

10000 0

0 0

5

10 Units’ velocity (m/s)

15

20

0

5

10 Units’ velocity (m/s)

15

20

Figure 5.11: Route Acquisition Delay of VRP with and without hello messages to maintain up-to-date units’ information about their neighbors.

connections, left graph and right graph respectively. As shown by the figure, when the traffic condition is light, 20 connections, the use of hello messages does not affect the delivery ratio of VRP. While when the traffic condition if heavy, 40 connections, the use of hello message just slightly affects the delivery ratio when the units’ velocity is high. Figure 5.11 compares the route acquisition delay of VRP with 20 and 40 simultaneous connections, left graph and right graph respectively. The figure shows that the use of hello messages imposes a higher delay for VRP, also the delay gets higher as the speed of the units increases and as the traffic conditions becomes heavier, from 20 to 40 simultaneous connections.

134

Chapter 5. Simulation Results

Delivered data messages

Delivered data messages

100

100

99 99.5 Delivery (%)

Delivery (%)

98 97 96 95

Units Velocity = 0 Units Velocity = 2 Units Velocity = 4 Units Velocity = 6

94

99

98.5 Units Velocity = 0 Units Velocity = 2 Units Velocity = 4 Units Velocity = 6

98

93

97.5 10

15

20

25

30

35

40

45

50

Number of simultaneous CBR connections

15

60

120

180

240

300

Duration of each CBR connections (seconds)

Figure 5.12: Delivery ratio: different simultaneous CBR connections(left) and different CBR connection duration (right).

5.3.5

Delivery Ratio under different Traffic Conditions

This Section evaluates the performance of VRP over different traffic conditions. These simulations were made in a network of 1000x1000 meters, with 75 units and transmission range of 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity varies from 0m/s to 6m/s. The number of simultaneous CBR connections goes from 10 to 50, each connection generates 2 messages per second and the maximum duration of each CBR connection ranges from 15 seconds to 300 seconds. Figure 5.12 shows the delivery ratio of VRP for a different number of simultaneous CBR connections (left) and different time duration of CBR connections (right). In both cases, the speed of the units goes from 0 to 6m/s. As the number of simultaneous connections increases, the traffic in the network also increases. As the traffic increases, the protocol keeps performing well with units’ velocity not exceeding 4m/s. With units’ velocity equal to 6m/s the delivery ratio decreases when the number of simultaneous connections is above 40. The reason is that the buffer of the units begins to overflow due to overload.

5.3. Evaluation

135

Delivered data messages

Dropped data messages

100

25 Units Velocity = 0 Units Velocity = 2 Units Velocity = 4

20 Dropped Message (%)

Delivery (%)

95 90 85 80 Units Velocity = 0 Units Velocity = 2 Units Velocity = 4

75

15

10

5

70

0 2

3

4

5

6

7

8

9

10

2

Messages per second per CBR connection

3

4

5

6

7

8

9

10

Messages per second per CBR connection

Figure 5.13: Messages per CBR connection: delivery ratio(left) and lost DATA messages because of full buffer(right).

The influence of the buffer overflows is analysed in figure 5.13. These simulations consider 20 simultaneous CBR connections, each of which has the duration of 15 seconds, and the number of DATA messages generated by each connection goes from 2 messages per second to 10 messages per second. As expected, under heavy traffic conditions, data messages are dropped because of buffer overflows, which decreases the delivery ratio.

5.3.6

Delivery Ratio and Route Acquisition Delay under different Transmission Ranges

This Section evaluates VRP under different units’ transmission ranges. As the transmission range of the units increases, the diameter of the network decreases and the number of neighbors of each unit also increases. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units varies from 200 meters to 500 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity is 1m/s and the number of simultaneous CBR connections is set to 20 and 40. Each CBR connection generates 2 messages per second and the duration of each connection is set randomly up to a

136

Chapter 5. Simulation Results

Average time to establish a route 300

99.8

250 Time (miliseconds)

Delivery (%)

Delivered data messages 100

99.6 99.4 99.2 20 connections 40 connections

99 98.8 200

250

300

350

400

450

20 connections 40 connections

200 150 100 50

500

Trasmission range (meters)

0 200

250

300

350

400

450

500

Trasmission range (meters)

Figure 5.14: Transmission range: delivery ratio(left) and average delay to establish a route(right).

maximum of 15 seconds. Figure 5.14 shows the delivery ratio of the virtual routing protocol (left) and the average time to establish a route (right). The delivery ratio of VRP is excellent with all transmission ranges. As the transmission range increases, the delay to establish routes decreases, due to the reduction on the network diameter.

5.3.7

Delivery Ratio and Route Acquisition Delay under different Pause Times

This Section evaluates VRP for different units’ pause time. The pause time is the time elapsed between the arrival of a unit at its destination point and the departure towards a new destination. These simulations were made in a network of 1000x1000 meters, with 75 units. The transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity varies from 5m/s to 20 m/s. The number of simultaneous CBR connections is 20, where each CBR connection generates 2 messages per second and the maximum duration of each connection is 15 seconds. The pause time goes from 0 seconds to 600 seconds

5.3. Evaluation

137

Delivered data messages

Time to establish a route

100

2000

99.5

1800

Units Velocity = 5 Units Velocity = 10 Units Velocity = 15 Units Velocity = 20

1600 Time (miliseconds)

Delivery (%)

99 98.5 98 97.5 Units Velocity = 5 Units Velocity = 10 Units Velocity = 15 Units Velocity = 20

97 96.5

1400 1200 1000 800 600 400 200

96

0 0

100

200

300

400

500

600

Units’ pause time (seconds)

0

100

200

300

400

500

600

Unit’s pause time (seconds)

Figure 5.15: Units’ pause time: Delivery ratio(left) and average delay to establish a route(right).

(the duration of the simulation). Figure 5.15, on the left, shows the delivery ratio of VRP, which is excellent even with high velocities and small pause times. The delivery ratio of the protocol is almost independent of these parameters. On the other hand, the delay to establish a route, shown on the right part of figure 5.15, increases as the units’ speed increases. The figure also shows that the delay is affected by the pause time just when the speed of the units is high.

5.3.8

Delivery Ratio and Route Acquisition Delay under different Number of Units

These simulations evaluate VRP for different numbers of units in the network. The number of units goes from 75 to 201. The transmission range of the units is set to 250 meters. To keep the same connectivity, the size of the network field is increased within the number of units: for 75 units, the size of the network is 1000x1000 meters; for 108 units, the size of the network is 1400x1400 meters; for 150 units, 1700x1700 meters; and for 201 units, 2000x2000 meters. The number of units was chosen to

138

Chapter 5. Simulation Results

Delivered data messages

Average time to establish a route

99

2200 Always 5 Scouts Increased number of Scouts

Always 5 Scouts Increased number of Scouts

2000 1800 time (miliseconds)

Delivery (%)

98.5

98

97.5

1600 1400 1200 1000 800 600 400

97

200 75

108

150

201

75

Number of units in the system

108

150

201

Number of units in the system

Figure 5.16: Number of units: Delivery ratio(left) and average delay to establish a route(right). Average size of the Virtual Path 6.5 Always 5 Scouts Increased number of Scouts Number of messages

6

5.5

5

4.5

4 75

108

150 Number of units in the system

201

Figure 5.17: Number of units: size of the virtual path.

maintain the RoR complete. The logical structure used is a RoR with: x = 3, and y = 25, y = 36, y = 50 and y = 67, for 75, 108, 150 and 210 units, respectively. The number of scouts also varies depending on the number of units, here is reported results for the value that showed the best performance. This value is: 5 for 75 units, 9 for 108 and 150 units, and 15 for 201 units. Units’ velocity is always 2 m/s, and the number of simultaneous CBR transmissions is 20. Each CBR connection generates 2 messages per second and the maximum duration of each connection is 15 seconds. The left side of figure 5.16 shows the delivery ratio of VRP for different num-

5.3. Evaluation

139

bers of units in the network. It is noticed that as the number of units increases, the delivery ratio decreases, due to the increasing in the network diameter, which consequently increases the size of the physical routes. The right side of figure 5.16 shows the delay to establish routes of VRP for different numbers of units in the network. It is noticed that as the number of units increases, the delay increases, due to the increasing in the network diameter. Figures 5.16 and 5.17 also show the advantage of increasing the number of scouts above the stated number of 5 scouts independent of the number of units. For each number of units, the number of scouts was increased, and the figure reports the results for the value that showed the best performance. This value is: 5 for 75 units, 9 for 108 and 150 units, and 15 for 201 units.

5.3.9

Delivery Ratio and Route Acquisition Delay under different Units’ Velocity

This Section evaluates VRP under different units’ velocity. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 20 m/s. The number of simultaneous CBR connections is 20 and 40. Each CBR connection generates 2 messages per second and the maximum duration of each connection is either 15 or 120 seconds. The pause time is 0, i.e., when a unit reaches its destination point, it immediately starts another movement. The left side of figure 5.18 shows the delivery ratio of VRP as the units’ velocity ranges from 0m/s to 20m/s. The right side of figure 5.18 reports the same data as

140

Chapter 5. Simulation Results

Delivered data messages

Delivered data messages

100

100 99.5

Delivery (%)

Delivery (%)

95

90

85

99 98.5 98

80

20 connections 40 connections

97.5

20 connections 40 connections 75

97 0

5

10

15

20

0

1

2

3

Units’ velocity (m/s)

4

5

6

7

8

9

Units’ velocity (m/s)

Figure 5.18: Units’ velocity with different CBR connections: delivery ratio. Dropped messages 14 20 connections 40 connections

12 10

%

8 6 4 2 0 0

5

10 Units’ velocity (m/s)

15

20

Figure 5.19: Units’ velocity with different CBR connections: dropped DATA messages.

the left side, but it shows a detailed view for units’ velocity from 0m/s to 9m/s. Note that with velocities until 9m/s, the delivery is always excellent for both 20 and 40 simultaneous CBR connections. However, with velocities above 9m/s and 40 simultaneous connections the delivery ratio decreases with increasing speed, this is due to buffer overflows. In fact, the number of dropped data messages increases in this situation, as shown in figure 5.19. When the size of the buffer is not critical, as the case with 20 connections, VRP performs well independently of the velocity of the units. Figure 5.20 shows, for the above parameters, the average delay to establish a

5.3. Evaluation

141

Time to establish a route

Time to establish a route

60000

3500 20 connections 40 connections

20 connections 40 connections

3000 Time (miliseconds)

Time (miliseconds)

50000 40000 30000 20000 10000

2500 2000 1500 1000 500

0

0 0

5

10

15

20

0

1

2

3

Units’ velocity (m/s)

4

5

6

7

8

9

Units’ velocity (m/s)

Figure 5.20: Units’ velocity with different connections duration: delay to establish a route. Delivered data messages

Time to establish a route

100

2000

99.5

1800

Time (miliseconds)

99 Delivery (%)

Connections length = 15s Connections length = 120s

1600

98.5 98 97.5

1400 1200 1000 800 600

97 400 Connections length = 15s Connections length = 120s

96.5

200

96

0 0

5

10 Units’ velocity (m/s)

15

20

0

5

10

15

20

Units’ velocity (m/s)

Figure 5.21: Units’ velocity with different connections duration: delivery ratio(left) and average delay to establish a route(right).

route. Note that the delay is also influenced by the units’ buffer. For 40 connections at 10 m/s, the buffer of the units starts to overflow and the delay becomes significantly worse. Figure 5.21 analyses VRP for different units’ velocity with 20 simultaneous CBR connections with the duration of each connection set to 15 seconds and 120 seconds. It is seen that the delivery ratio and the average delay of the route acquisition phase of the protocol are substantially unaffected by the duration of the connection.

142

Chapter 5. Simulation Results

5.4

VRP compared with DSR

This Section contains a comparison between VRP and DSR. The comparison is based in four parameters: the delivery ratio, the route acquisition delay, the normalized routing load and size of units’ routing table. The DSR version implemented in the new simulator (SWRS) is the one defined in the internet draft number 9 [46]. Although a detailed view of DSR can be found in Chapter 2.2.1, this section adds some features of DSR that were implemented in the simulator. 1. To reduce the number of global floodings, before a unit sends a RREQ to find a route to a certain destination, it sends a RREQ with time to live equals to 1, i.e., a RREQ that reaches just the neighbors of the sender. If one of these units has a route to the destination, it answers to the source and the source can start using this route. If no unit answers within a timeout (which in the simulations was set to 10 milliseconds) the source sends a global RREQ, which floods the entire network. 2. To reduce the control traffic overhead, when a broken link is found, the upstream unit searches in its route cache for a route to the destination before sending a route error message to the source. If it has another route to the destination it sends the message through this route. This avoids the route error message and probably another flooding from the source to the destination. 3. When a unit receives a message, it copies to its cache all the information that is present in the route of the message. In other words, it copies to its route cache the routes to all units present in the message route.

5.4. VRP compared with DSR

5.4.1

143

Delivery ratio

The delivery ratio is the percentage of DATA messages generated by the CBR connections that are delivered to their destinations. Figures 5.22 and 5.23 show the delivery ratio of the protocols for different units’ velocity. Simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 20 m/s. The pause time is 0, i.e., when a unit reaches its destination point, it immediately starts another movement. Two simulations results are presented for VRP: with a proactive scout update on the beginning of the simulation (VRP proactive setup); and without this proactive scout setup (VRP reactive setup). In figure 5.22 the number of simultaneous CBR connections is 20 on the left, and 40 on the right. Each CBR connection generates 2 messages per second and the duration of the connection is at most 15 seconds. In figure 5.23 the number of simultaneous CBR connections is 20. Each CBR connection generates 2 messages per second, and the maximum duration of each connection is 120 seconds. As shown in figures 5.22 and 5.23, the performance of VRP is almost unaffected by increasing the units’ speed under light traffic conditions (20 simultaneous CBR connections), while the negative influence of increasing speed is moderate with heavy traffic conditions (40 simultaneous CBR connections). However, the delivery ratio of VRP is always superior to the performance of DSR: with 40 simultaneous CBR connections and units’ velocity of 20m/s, VRP still delivers more than 75% of the generated data messages, while the delivery ratio of DSR drops as low as 45% of the

144

Chapter 5. Simulation Results

Delivered data messages - 20 CBR connections

Delivered data messages - 40 CBR connections

100

100

95

90

Delivery (%)

Delivery (%)

90 85 80

80 70 60

75

VRP proactive setup VRP reactive setup DSR

70

VRP proactive setup VRP reactive setup DSR

50

65

40 0

5

10

15

20

0

5

10

Units’ Velocity (m/s)

15

20

Units’ Velocity (m/s)

Figure 5.22: VRP versus DSR: Delivery ratio as a function of the units’ speed for 20(left) and 40(right) simultaneous CBR connections. Delivered data messages 100

Delivery (%)

95

90

85

80

DSR VRP proactive setup VRP reactive setup

75 0

5

10 Units’ velocity (m/s)

15

20

Figure 5.23: VRP versus DSR: Delivery ratio as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. created data messages. The left part of figure 5.24 shows the delivery ratio of VRP and DSR for a different number of units. The number of units goes from 75 to 201. The transmission range of the units is set to 250 meters. To keep the same connectivity, the size of the network field is increased within the number of units: for 75 units, the size of the network is 1000x1000 meters; for 108 units, the size of the network is 1400x1400 meters; for 150 units, 1700x1700 meters; and for 201 units, 2000x2000 meters. The number of units was chosen to maintain the RoR complete. The logical structure used is a RoR with: x = 3, and y = 25, y = 36, y = 50 and y = 67, for 75,

5.4. VRP compared with DSR

145

Delivered data messages

Delivered data messages

100

100 95

Delivery (%)

Delivery (%)

95

90

85

90 85 80

80

VRP with increased number of scouts VRP with 5 scouts DSR

75

75 75

108

150 Number of units in the system

201

70 200

VRP DSR 250

300

350

400

450

500

Trasmission range (meters)

Figure 5.24: VRP versus DSR: Delivery ratio as a function of the number of units in the network (left) and as a function of the units’ transmission range (right).

108, 150 and 210 units, respectively. The number of scouts also varies depending on the number of units, here is reported results for the value that showed the best performance. This value is: 5 for 75 units, 9 for 108 and 150 units, and 15 for 201 units. The units’ velocity is 1m/s, and the pause time is 0. The number of simultaneous CBR connections is 20, each CBR connection generates 2 messages per second, and the duration of each CBR connection is at most 15 seconds. The figure shows that VRP maintains a stable delivery ratio of more than 98% of the generated data messages independently of the number of units in the network, while DSR loses performance with increasing number of units. Note that the size of the network area was increased with the number of units: this was done to maintain the connectivity of the network and to increase the diameter of the network. In the right side of figure 5.24, simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units goes from 200 to 500 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity is 1m/s and the pause time is 0. Note that as the transmission range of the units increases, the network connectivity also increases, and diameter of the network decreases. Due to the limited use of floodings, which avoids buffer overflows, VRP

146

Chapter 5. Simulation Results

Delivered data messages

Delivered data messages

100

100 95

Delivery (%)

Delivery (%)

95

90

85

90 85 80

VRP - vel=5 VRP - vel=10 DSR - vel=5 DSR - vel=10

80

VRP - vel=15 VRP - vel=20 DSR - vel=15 DSR - vel=20

75

75

70 0

100

200

300

400

Units’ pause time (seconds)

500

600

0

100

200

300

400

500

600

Units’ pause time (seconds)

Figure 5.25: VRP versus DSR: Delivery ratio as a function of the units’ pause time.

is able to keep the delivery ratio high even for highly connected networks. Figure 5.25 compares the delivery ratio of VRP and DSR for different units’ pause time. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 5m/s to 20m/s. The number of simultaneous CBR connections is 20. Each CBR connection generates 2 messages per second and the maximum duration of each CBR connection is 15 seconds. The left part of the figure depicts the delivery ratio for 5m/s and 10m/s while the right part of the figure depicts the delivery ratio for 15m/s and 20m/s. As shown in the figure, the performance of VRP is almost independent of the velocity of the units and of the pause time, while the performance of DSR highly depends on these parameters. In both protocols, the delivery ratio is minimum with velocity equal to 20m/s and pause time equal to 0. In this case the delivery ratio of VRP is above 96% of the generated data messages, while the delivery ratio of DSR is below 75%. Figure 5.26 compares the delivery ratio of VRP and DSR for a different number of simultaneous CBR connections. These simulations were made in a network of

5.4. VRP compared with DSR

147

Delivered data messages 100

Delivery (%)

95 90 85 VRP - vel=2 VRP - vel=4 VRP - vel=6 DSR - vel=2 DSR - vel=4 DSR - vel=6

80 75 70 10

15

20

25

30

35

40

45

50

Number of simultaneous CBR connections

Figure 5.26: VRP versus DSR: Delivery ratio as a function of the number of simultaneous CBR connections. 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 2m/s to 6 m/s. The number of simultaneous CBR connections goes from 10 to 50. Each CBR connection generates 2 messages per second and the maximum duration of each CBR connection is 15 seconds. The superior performance of VRP is due to the limited use of floodings, which makes buffer overflows relatively infrequent. When the frequency of buffer overflows increases (in figure 5.26 this situation occurs for velocity equal to 6m/s and 50 simultaneous CBR connections), the performance of VRP decreases, but the delivery ratio is still above 90%, while, under the same traffic conditions, the delivery ratio of DSR drops to 50% of the generated data messages. As seen from figures 5.22, 5.23, 5.24, 5.25 and 5.26, VRP always outperforms DSR in the delivery ratio. To determine the superior performance, the key feature of VRP is the ability to have most floodings in low priority, as they are used for the purpose of scout update, which is a non-urgent task. In most cases this allows VRP to avoid buffer overflows, and consequently data messages losses.

148

Chapter 5. Simulation Results

5.4.2

Route Acquisition Delay

The route acquisition delay is the time needed to the source to construct a route between itself and the desired destination. This delay occurs when source unit i wants to communicate with destination unit j at time t and unit i does not have a route to reach unit j. Figures 5.27 and 5.28 compare the delay of both protocols for different units’ speed. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 20 m/s. The pause time is 0, i.e., when a unit reaches its destination point, it starts another movement immediately. Two simulations results are presented for VRP: with a proactive scout update on the beginning of the simulation (VRP proactive setup); and without this proactive scout setup (VRP reactive setup). In figure 5.27, the number of simultaneous CBR connections is 20 on the left, and 40 on the right. Each CBR connection generates 2 messages per second and the duration of the connection is at most 15 seconds. In figure 5.28, the number of simultaneous CBR connections is 20, each CBR connection generates 2 messages per second, and the maximum duration of each connection is 120 seconds. As shown in figures 5.27 and 5.28, the delay of VRP increases as the speed of the units increases, and it gets much worse under heavy traffic conditions (40 simultaneous CBR connections), while the delay of DSR is almost independent of the speed of the units and of the traffic condition. Figure 5.29 shows the route acquisition delay of the protocols for a different

5.4. VRP compared with DSR

149

Average delay to establish a route - 20 CBR connections

Average delay to establish a route - 40 CBR connections

3500

60000 VRP proactive setup VRP reactive setup DSR

VRP proactive setup VRP reactive setup DSR

50000

2500

Time (miliseconds)

Time (miliseconds)

3000

2000 1500 1000

40000 30000 20000 10000

500 0

0 0

5

10

15

20

0

5

10

Units’ Velocity (m/s)

15

20

Units’ Velocity (m/s)

Figure 5.27: VRP versus DSR: Delay to build a route as a function of the units’ speed for 20(left) and 40(right) simultaneous CBR connections. Average delay to establish a route 2000 DSR VRP proactive setup VRP reactive setup

1800

Time (miliseconds)

1600 1400 1200 1000 800 600 400 200 0 0

5

10 Units’ velocity (m/s)

15

20

Figure 5.28: VRP versus DSR: Delay to build a route as a function of units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. number of units. The number of units goes from 75 to 201. The transmission range of the units is set to 250 meters. To keep the same connectivity, the size of the network field is increased within the number of units: for 75 units, the size of the network is 1000x1000 meters; for 108 units, the size of the network is 1400x1400 meters; for 150 units, 1700x1700 meters; and for 201 units, 2000x2000 meters. The number of units was chosen to maintain the RoR complete. The logical structure used is a RoR with: x = 3, and y = 25, y = 36, y = 50 and y = 67, for 75, 108, 150 and 210 units, respectively. The number of scouts also varies depending on the number of units, here is reported results for the value that showed the best

150

Chapter 5. Simulation Results

Average delay to establish a route 2200 2000

VRP with increased number of scouts VRP with 5 scouts DSR

Time (miliseconds)

1800 1600 1400 1200 1000 800 600 400 200 0 75

108

150

201

Number of units in the system

Figure 5.29: VRP versus DSR: Delay to build a route as a function of the number of units in the network. performance. This value is: 5 for 75 units, 9 for 108 and 150 units, and 15 for 201 units. The units’ velocity is 1m/s, and the pause time is 0. The number of simultaneous CBR connections is 20, each CBR connection generates 2 messages per second, and the duration of each CBR connection is at most 15 seconds. The figure shows that the delay of VRP decreases for an increasing number of scouts, although in both cases the delay of VRP is above the delay of DSR. In figure 5.30, simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units goes from 200 to 500 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity is 1m/s and the pause time is 0. Note that as the transmission range of the units increases, the network connectivity also increases, and diameter of the network decreases. Due to the limited use of floodings, which avoids buffer overflows, VRP is able to maintain its route acquisition delay while DSR loses performance. As DSR’s route acquisition is based on floodings, when the connectivity of the network increases, the number if units trying to send messages at the same moment also increases, thus more units have their transmissions delayed, which increases the route acquisition delay of the protocol.

5.4. VRP compared with DSR

151

Average delay to establish a route 2500

Time (miliseconds)

2000

VRP DSR

1500

1000

500

0 200

250

300

350

400

450

500

Trasmission range (meters)

Figure 5.30: VRP versus DSR: Delay to build a route as a function of the units’ transmission range.

Figure 5.31 compares the delay to build a route in VRP and DSR for different units’ pause time. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 5m/s to 20 m/s. The number of simultaneous CBR connections is 20 and each CBR connection generates 2 messages per second. The left part of the figure depicts the delay for 5m/s and 10m/s while the right part of the figure depicts the delay for 15m/s and 20m/s. As shown in figure 5.31, the delay of VRP is always greater than the delay of DSR. Also, the delay of VRP depends on the units’ velocity and on the pause time, while the delay of DSR is almost independent of such parameters. The delay of VRP is comparable to the delay of DSR only with large pause times. Figure 5.32 compares the delay to construct a route in VRP and DSR for a different number of simultaneous CBR connections. These simulations were made in a network of 1000x1000 meters, with 75 units. The transmission range is fixed at 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5.

152

Chapter 5. Simulation Results

Average delay to establish a route

Average delay to establish a route

1000

2000 VRP - vel=5 VRP - vel=10 DSR - vel=5 DSR - vel=10

VRP - vel=15 VRP - vel=20 DSR - vel=15 DSR - vel=20

1500 Time (miliseconds)

Time (miliseconds)

800

600

400

1000

500

200

0

0 0

100

200

300

400

500

600

0

100

200

Units’ pause time (seconds)

300

400

500

600

Units’ pause time (seconds)

Figure 5.31: VRP versus DSR: Delay to build a route as a function of the units’ pause time. Average delay to establish a route

Average delay to establish a route

25000

2500 VRP - vel=0 VRP - vel=2 VRP - vel=4 VRP - vel=6 DSR - vel=0 DSR - vel=2 DSR - vel=4 DSR - vel=6

15000

VRP - vel=2 VRP - vel=4 DSR - vel=2 DSR - vel=4

2000 Time (miliseconds)

Time (miliseconds)

20000

10000

5000

1500

1000

500

0

0 10

15

20 25 30 35 40 Number of simultaneous CBR connections

45

50

10

15

20 25 30 35 40 Number of simultaneous CBR connections

45

50

Figure 5.32: VRP versus DSR: Delay as a function of the number of simultaneous CBR connections. The units’ velocity goes from 0m/s to 6 m/s and the pause time is 0. The number of simultaneous CBR connections ranges from 10 to 50. Each CBR connection generates 2 messages per second, and the duration of each CBR connection is 15 seconds. The right-hand side graphic is an expanded view of the delay with velocities of 2m/s and 4 m/s. As shown in figure 5.32 the delay of VRP is very close to the delay of DSR for small velocities, 2m/s, independent of the number of connections. However for higher velocities, the delay of VRP gets much worse than the delay of DSR. In conclusion, as seen from figures 5.27, 5.28, 5.29, 5.31 and 5.32, the delay to

5.4. VRP compared with DSR

153

establish a route with VRP is always greater than the delay with DSR. This happens because the route acquisition phase of VRP, in the attempts to avoid floodings, may require setting several virtual paths, before succeeding in translating one of them into a physical route from the source to the destination. While this technique avoids global overloading, and consequently buffer overflows, it increases the number of unicast messages needed for route translation, which contributes to longer route acquisition delays.

5.4.3

Normalized Routing Load

The normalized routing load is the number of routing messages transmissions per delivered message. The number of routing messages transmissions consists in the number of single hop transmissions for all routing messages. Note that a single routing message can travel several hops before reaching its destination, all single hop transmissions are taken into account to measure the routing load. This Section contains a comparison between the routing load of VRP and DSR. Two simulations results are presented for VRP: with a proactive scout update on the beginning of the simulation, the left part of figures 5.33, 5.34 and 5.35; and without this proactive scout setup, the right part of figure 5.33, 5.34 and 5.35. In figures 5.33, 5.34 and 5.35, the simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity goes from 0m/s to 20 m/s, and the pause time is 0. In figures 5.33 and 5.35, the number of simultaneous CBR connections is 20, while in figure 5.34 it is 40. In all cases each CBR connection generates 2 messages per second. In figures 5.33 and 5.34 the duration of each CBR connection is 15

154

Chapter 5. Simulation Results

Routing overhead per data message - VRP with proactive scouts setup

Routing overhead per data message - VRP without proactive scouts setup

18

18 VRP total VRP high priority VRP low priority DSR

16

14 Hop Transmissions

Hop Transmissions

14

VRP total VRP high priority VRP low priority DSR

16

12 10 8 6

12 10 8 6

4

4

2

2

0

0 0

5

10

15

20

0

Units’ Velocity (m/s)

5

10

15

20

Units’ Velocity (m/s)

Figure 5.33: VRP versus DSR: Routing load as a function of the units’ speed with 20 simultaneous CBR connections. seconds, while in figure 5.35 the duration of each CBR connection is 120 seconds. In these figures, the left part compares the routing load of VRP using a proactive scout update at time 0 and DSR, and the right part compares the routing load of VRP without this proactive scout update and DSR. As shown in figure 5.33, the total overhead of VRP is smaller than the overhead of DSR under light traffic conditions (20 connections). This advantage is partly lost under heavy traffic conditions (40 connections), figure 5.34, and for long connections, where the routing overhead of VRP and DSR is essentially the same, figure 5.35. However, it should be considered that in VRP a considerable part of the traffic runs in low priority. This traffic is due to messages used for the purpose of scout update, and it provides a smaller contribution to the network congestion. If the traffic in DSR is compared with the high priority traffic alone in VRP, the preceding figures demonstrate a significant advantage of VRP over DSR in all situations. Figure 5.36 shows the routing load of the protocols for different numbers of units in the network. The number of units goes from 75 to 201. The transmission range of the units is set to 250 meters. To keep the same connectivity, the size of the network field is increased within the number of units: for 75 units, the size of the network

5.4. VRP compared with DSR

155

Routing overhead per data message - VRP with proactive scouts setup

Routing overhead per data message - VRP without proactive scouts setup

30

30 VRP total VRP high priority VRP low priority DSR

20

VRP total VRP high priority VRP low priority DSR

25 Hop Transmissions

Hop Transmissions

25

15 10 5

20 15 10 5

0

0 0

5

10

15

20

0

5

Units’ Velocity (m/s)

10

15

20

Units’ Velocity (m/s)

Figure 5.34: VRP versus DSR: Routing Load as a function of the units’ speed with 40 simultaneous CBR connections. Routing overhead per data message - VRP with proactive scouts setup

Routing overhead per data message - VRP without proactive scouts setup

12

12 VRP total VRP high priority VRP low priority DSR

VRP total VRP high priority VRP low priority DSR

10 Hop Transmissions

Hop Transmissions

10 8 6 4 2

8 6 4 2

0

0 0

5

10 Units’ velocity (m/s)

15

20

0

5

10

15

20

Units’ velocity (m/s)

Figure 5.35: VRP versus DSR: Routing Load as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. is 1000x1000 meters; for 108 units, the size of the network is 1400x1400 meters; for 150 units, 1700x1700 meters; and for 201 units, 2000x2000 meters. The number of units was chosen to maintain the RoR complete. The logical structure used is a RoR with: x = 3, and y = 25, y = 36, y = 50 and y = 67, for 75, 108, 150 and 210 units, respectively. The number of scouts also varies depending on the number of units, here is reported results for the value that showed the best performance. This value is: 5 for 75 units, 9 for 108 and 150 units, and 15 for 201 units. The units’ velocity is 1m/s, and the pause time is 0. The number of simultaneous CBR connections is 20, each CBR connection generates 2 messages per second, and the duration of each

156

Chapter 5. Simulation Results

Routing overhead per data message - VRP with always 5 scouts

Routing overhead per data message - VRP with increased number of scouts

25

25 VRP total VRP high priority VRP low priority DSR

VRP total VRP high priority VRP low priority DSR

20 Hop Transmissions

Hop Transmissions

20

15

10

5

15

10

5

0

0 75

108

150

201

75

108

Number of units in the system

150

201

Number of units in the system

Figure 5.36: VRP versus DSR: Routing Load as a function of the number of units in the network. Routing overhead per data message 12

Hop Transmissions

10

VRP total VRP high priority VRP low priority DSR

8 6 4 2 0 200

250

300

350

400

450

500

Trasmission range (meters)

Figure 5.37: VRP versus DSR: Routing Load as a function of the units’ transmission range.

CBR connection is at most 15 seconds. As shown in figure 5.36, the total routing overhead of VRP is higher than the routing load of DSR. However, the load due only to high priority messages in VRP is less than the routing load of DSR. In figure 5.37, simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units goes from 200 to 500 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity is 1m/s and the pause time is 0. As shown in the figure, the routing overhead of DSR becomes worst when the connectivity of the network is increased, this happens

5.4. VRP compared with DSR

157

Routing overhead per data message - Units’ velocity = 5m/s

Routing overhead per data message - Units’ velocity = 10m/s

5

14 VRP total VRP high priority VRP low priority DSR

Hop Transmissions

4 3.5

VRP total VRP high priority VRP low priority DSR

12 Hop Transmissions

4.5

3 2.5 2 1.5

10 8 6 4

1 2

0.5 0

0 0

100

200

300

400

500

600

0

100

Units’ pause time (seconds)

200

300

400

500

600

Units’ pause time (seconds)

Figure 5.38: VRP versus DSR: Routing Load as a function of the units’ stop time for units’ velocities 5m/s and 10m/s. Routing overhead per data message - Units’ velocity = 15m/s

Routing overhead per data message - Units’ velocity = 20m/s

20

9 VRP total VRP high priority VRP low priority DSR

Hop Transmissions

16 14

VRP total VRP high priority VRP low priority DSR

8 7 Hop Transmissions

18

12 10 8 6

6 5 4 3

4

2

2

1

0

0 0

100

200 300 400 Units’ pause time (seconds)

500

600

0

100

200 300 400 Units’ pause time (seconds)

500

600

Figure 5.39: VRP versus DSR: Routing Load as a function of the units’ stop time for units’ velocities 15m/s and 20m/s.

because units must send floodings to search for routes in DSR, while in VRP the route acquisition is mainly based on unicast messages. Figures 5.38 and 5.39 show the average routing load in both protocols for different units’ pause time. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 5m/s to 20 m/s. The number of simultaneous CBR connections is 20. Each CBR connection generates 2 messages per second, and the maximum duration of each connection is 15 seconds. Figure 5.38 depicts the routing load for units’ velocity of

158

Chapter 5. Simulation Results

Routing overhead per data message - Units’ velocity = 0m/s

Routing overhead per data message - Units’ velocity = 2m/s

4.5

10

Hop Transmissions

VRP total VRP high priority VRP low priority DSR

9

VRP total VRP high priority VRP low priority DSR

8 Hop Transmissions

4 3.5 3 2.5 2 1.5

7 6 5 4 3

1

2

0.5

1

0

0 10

15

20

25

30

35

40

45

50

10

15

Number of simultaneous CBR connections

20

25

30

35

40

45

50

Number of simultaneous CBR connections

Figure 5.40: VRP versus DSR: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 0m/s and 2m/s. Routing overhead per data message - Units’ velocity = 4m/s

Routing overhead per data message - Units’ velocity = 6m/s

12

12 VRP total VRP high priority VRP low priority DSR

11

VRP total VRP high priority VRP low priority DSR

10 Hop Transmissions

Hop Transmissions

10 8 6 4

9 8 7 6 5 4 3

2

2 0

1 10

15

20 25 30 35 40 Number of simultaneous CBR connections

45

50

10

15

20 25 30 35 40 Number of simultaneous CBR connections

45

50

Figure 5.41: VRP versus DSR: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 4m/s and 6m/s.

5m/s(left) and 10m/s(left), while figure 5.39 depicts the routing load for 15m/s(left) and 20m/s(right). As shown in figures 5.38 and 5.39 the total routing overhead of VRP is smaller than the routing overhead of DSR for small pause times, independent of the speed of the units. However, for high pause times DSR has a smaller routing overhead. If only the high priority messages of VRP are considered, then the routing load of VRP is constantly smaller than the routing load of DSR. Figures 5.40 and 5.41 show the routing load of both protocols for a different number of simultaneous CBR connections. These simulations were made in a net-

5.4. VRP compared with DSR

159

work of 1000x1000 meters. The number of units in the network is 75, and their transmission range is fixed at 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 6 m/s and the pause time is 0. The number of simultaneous CBR connections ranges from 10 to 50. Each CBR connection generates 2 messages per second, and the maximum duration of each CBR connection is 15 seconds. Figure 5.40 shows the routing load for 0m/s(left) and 2m/s(right) while figure 5.41 shows the routing load for 4m/s(left) and 6m/s(right). As shown in figures 5.40 and 5.41, the total routing load of VRP is smaller than the routing overhead of DSR independent of both the units’ velocity and the number of simultaneous CBR connections. Figures 5.42 and 5.43 shows the network bandwidth utilization for different traffic loads. The bandwidth utilization is the total bandwidth used by all units per second. These simulations were made in a network of 1000x1000 meters. The number of units in the network is 75, and their transmission range is fixed at 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 6 m/s and the pause time is 0. Figure 5.42 shows the routing load for units’ velocity of 0m/s(left) and 2m/s(right), while figure 5.43 shows the routing load for units’ velocity of 4m/s(left) and 6m/s(right). The number of simultaneous CBR connections ranges from 10 to 50, and each CBR connection generates 2 messages per second, and the maximum duration of each CBR connection is 15 seconds: with 10 connections, the sources generates a traffic of 80Kb/s; with 20 connections, the sources generates a traffic of 160Kb/s; with 30 connections, 240Kb/s; with 40 connections, 320Kb/s; with 50 connections, 400Kb/s.

160

Chapter 5. Simulation Results

Bandwidth Consumption per second by all units

Bandwidth Consumption per second by all units

4000 3500 3000

4000 VRP control VRP total DSR control DSR total

3500 3000 2500 Kb/s

Kb/s

2500

VRP control VRP total DSR control DSR total

2000

2000

1500

1500

1000

1000

500

500

0 80 Kb/s

160 Kb/s

240 Kb/s

320 Kb/s

0 80 Kb/s

400 Kb/s

160 Kb/s

Data load generated by the CBR sources

240 Kb/s

320 Kb/s

400 Kb/s

Data load generated by the CBR sources

Figure 5.42: VRP versus DSR: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 0m/s and 2m/s. Bandwidth Consumption per second by all units

Bandwidth Consumption per second by all units

4000 3500 3000

4000 VRP control VRP total DSR control DSR total

3500 3000 2500 Kb/s

Kb/s

2500 2000

2000

1500

1500

1000

1000

500

500

0 80 Kb/s

VRP control VRP total DSR control DSR total

160 Kb/s 240 Kb/s 320 Kb/s Data load generated by the CBR sources

400 Kb/s

0 80 Kb/s

160 Kb/s 240 Kb/s 320 Kb/s Data load generated by the CBR sources

400 Kb/s

Figure 5.43: VRP versus DSR: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 4m/s and 6m/s.

As shown in figures 5.42 and 5.43, the total bandwidth utilization of DSR is smaller than the total bandwidth utilization of VRP when the traffic generated by the CBR sources is light. When the traffic generated gets heavier, DSR starts to use more bandwidth than VRP. However, when the traffic generated reaches the maximum, the bandwidth utilization of DSR is reduced, this is because DSR losses lots of data messages due to buffer overflows. When the number of lost data messages increases, the bandwidth utilization decreases, as these messages are removed from the units’ buffer. If only the bandwidth utilization due to routing messages is considered, VRP

5.4. VRP compared with DSR

161

uses less bandwidth than DSR in almost all situations, the only situation when DSR uses less bandwidth than VRP is when the units are stopped and the traffic generated by the CBR sources is light. Furthermore, it should be recalled that a significant part of the traffic generated by VRP is due to low priority messages, which contribute much less to network congestion, as compared to high priority messages. If only high priority messages are considered, figures 5.33 to 5.41 show that the high priority traffic of VRP is always smaller than the total traffic of DSR, and this advantage increases under heavy traffic load conditions of the network.

5.4.4

Size of the Routing Tables

This Section analyses the size of the routing tables of the units. As shown in figure 5.44 the size of the routing tables kept by the units with VRP is much smaller than the size of the route caches needed with DSR. This is because in VRP units keep routes to reach their peered units and routes that are currently in use, while the route caches kept by the units with DSR contain routes to much more units. To avoid larger route caches, DSR can implement a limit in its size, although this limit may contribute to increase the delay to route acquisitions and to increase the routing load. In our implementation route caches do not have any space limit and entries in a DSR route cache are dropped after a time limit. Simulations to derive data reported in figure 5.44 where run with the following setting: the network is a square of 1000x1000 meters, with 75 units and the transmission range of the units is 250 meters; the logical structure used by VRP is the RoR: x = 3, y = 25 and s = 5; units’ speed goes from 0m/s to 20 m/s; the number of simultaneous CBR conditions is 20, where each CBR connection generates 2

162

Chapter 5. Simulation Results

Average size of the units’ routing table 80 VRP DSR

70

Number of routes

60 50 40 30 20 10 0 0

5

10

15

20

Velocity (m/s)

Figure 5.44: VRP versus DSR: Average size of the units’ routing table.

messages per second and the duration of each CBR connection is at most 15 seconds.

5.5

VRP compared with ZRP

This Section contains a comparison between VRP and ZRP. The comparison is based in three parameters: the delivery ratio, the route acquisition delay and the normalized routing load. The parameters used in these simulations to compare VRP with ZRP are exactly the same as the ones used to compare VRP to DSR. Also the results presented in this section for VRP are exactly the same as the ones presented in the comparison between VRP and DSR, in Section 5.4. The ZRP version implemented in the simulator is the one defined in the internet draft number 4 [37]. A detailed view of ZRP can be found in Chapter 2.3.1. The following is a list of the features of ZRP that were implemented in the simulator: 1. Units use the neighbors information provided by the simulated MAC protocol to build their zone and to improve the intrazone routing protocol. 2. The zone radius implemented is always equals to 2.

5.5. VRP compared with ZRP

163

Delivered data messages 100 95

Delivery (%)

90 85 80 75

ZRP multicast ZRP unicast

70 65 0

5

10

15

20

Units’ Velocity (m/s)

Figure 5.45: Delivery Ratio of ZRP with unicast and multicast for bordercasting.

3. The intrazone routing protocol is a simple link-state routing. After an update interval, a unit verifies if its outgoing links have changed, in this case it sends an update message to its neighbors. 4. The update interval goes from 1 to 20 seconds. Each simulation was performed using all different update intervals, and the data reported here consists in the best one among all update intervals. 5. The interzone routing protocol used is the bordercast, whose details can be found in Chapter 2.3.1. The bordercast was implemented in two versions: (i) using unicast messages; (ii) using multicast. The performance of ZRP using multicast is always superior to the performance of ZRP with unicast messages, as illustrated in figures 5.45, 5.46, 5.47. Thus, the results reported for the comparison between VRP and ZRP are referred to ZRP with multicast for bordercasting.

164

Chapter 5. Simulation Results

Average delay to establish a route 180 160

ZRP multicast ZRP unicast

Time (miliseconds)

140 120 100 80 60 40 20 0 0

5

10

15

20

Units’ Velocity (m/s)

Figure 5.46: Route Acquisition Delay of ZRP with unicast and multicast for bordercasting. Routing overhead per data message 35 ZRP multicast ZRP unicast

Hop Transmissions

30 25 20 15 10 5 0 0

5

10 Units’ Velocity (m/s)

15

20

Figure 5.47: Routing Overhead of ZRP with unicast and multicast for bordercasting.

5.5.1

Delivery ratio

The delivery ratio is the percentage of DATA messages generated by the CBR connections that are delivered to their destinations. Figures 5.48, 5.49 and 5.50 show the delivery ratio of the protocols for different units’ velocity. Simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 20 m/s. The pause time is 0, i.e., when a unit reaches its destination point, it

5.5. VRP compared with ZRP

165

Delivered data messages - 20 CBR connections 100 98

Delivery (%)

96 94 92 90 88 86

VRP proactive setup VRP reactive setup ZRP

84 82 0

5

10

15

20

Units’ Velocity (m/s)

Figure 5.48: VRP versus ZRP: Delivery ratio as a function of the units’ speed for 20 simultaneous CBR connections of at most 15 seconds duration. immediately starts another movement. Two simulation results are presented for VRP: with a proactive scout update on the beginning of the simulation (VRP proactive setup); and without this proactive scout setup (VRP reactive setup). In figure 5.48, the number of simultaneous CBR connections is 20, and on figure 5.49 it is 40. In both cases, each CBR connection generates 2 messages per second and the duration of each connection is at most 15 seconds. In figure 5.50, the number of simultaneous CBR connections is 20. Each CBR connection generates 2 messages per second, and the maximum duration of each connection is 120 seconds. As shown in figure 5.48 and in figure 5.50, the performance of VRP is almost unaffected by increasing the units’ velocity under light traffic conditions (20 simultaneous CBR connections), while the negative influence of increasing speed highly affects the performance of ZRP. The delivery ratio of VRP is never below 94% of the generated data messages, while in ZRP it is below 80%. Under heavy traffic conditions, as shown in figure 5.49 (40 simultaneous CBR connections), the increasing speed affects VRP negatively, even though the delivery

166

Chapter 5. Simulation Results

Delivered data messages - 40 CBR connections 100

Delivery (%)

95

90

85

80

VRP proactive setup VRP reactive setup ZRP

75 0

5

10

15

20

Units’ Velocity (m/s)

Figure 5.49: VRP versus ZRP: Delivery ratio as a function of the units’ speed for 40 simultaneous CBR connections of at most 15 seconds duration. Delivered data messages 100

Delivery (%)

95

90

85

80

ZRP VRP proactive setup VRP reactive setup

75 0

5

10

15

20

Units’ velocity (m/s)

Figure 5.50: VRP versus ZRP: Delivery ratio as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. ratio is never below 75% of the generated data message. Under the same traffic conditions and with high mobility, ZRP has a performance better than VRP. With heavy traffic conditions and high units’ velocities, VRP starts to lose messages due to buffer overflows. This happens because scouts start to have lots of their archived routes broken. To update their archived routes, scouts must perform low priority floodings. As these floodings have a low priority, they are delayed, and thus these scouts remain longer with broken routes to their respective peered units. This implies that lots of messages are forwarded by the few scouts that have valid routes, thus saturating these units, causing their buffers to overflow.

5.5. VRP compared with ZRP

167

Delivered data messages

Delivered data messages

100

100 98

98

96 Delivery (%)

Delivery (%)

96 94 92 90

92 90 88

VRP - vel=5 VRP - vel=10 ZRP - vel=5 ZRP - vel=10

88

94

VRP - vel=15 VRP - vel=20 ZRP - vel=15 ZRP - vel=20

86 84

86

82 0

100

200

300

400

Units’ pause time (seconds)

500

600

0

100

200

300

400

500

600

Units’ pause time (seconds)

Figure 5.51: VRP versus ZRP: Delivery ratio as a function of the units’ pause time.

Figure 5.51 compares the delivery ratio of VRP and ZRP for different units’ pause time. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 5m/s to 20m/s. The number of simultaneous CBR connections is 20. Each CBR connection generates 2 messages per second and the maximum duration of each CBR connection is 15 seconds. The left part of the figures depicts the delivery ratio for 5m/s and 10m/s, while the right part depicts the delivery ratio for 15m/s and 20m/s. As shown in figure 5.51, the performance of VRP is almost independent of the velocity of the units and of the pause time, while the performance of ZRP highly depends on these parameters. In both protocols, the delivery ratio is minimum with velocity equal to 20m/s and pause time equal to 0. In this case, the delivery ratio of VRP is above 96% of the generated data messages, while the delivery ratio of ZRP is around 85%. Figure 5.52 compares the delivery ratio of VRP and ZRP for a different number of simultaneous CBR connections. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250

168

Chapter 5. Simulation Results

Delivered data messages 100

98

98 Delivery (%)

Delivery (%)

Delivered data messages 100

96

94 VRP - vel=2 VRP - vel=4 ZRP - vel=2 ZRP - vel=4

92

96

94

92 VRP - vel=6 ZRP - vel=6

90

90 10

15

20

25

30

35

40

Number of simultaneous CBR connections

45

50

10

15

20

25

30

35

40

45

50

Number of simultaneous CBR connections

Figure 5.52: VRP versus ZRP: Delivery ratio as a function of the number of simultaneous CBR connections. meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 2m/s to 6 m/s. The number of simultaneous CBR connections goes from 10 to 50. Each CBR connection generates 2 messages per second and the maximum duration of each CBR connection is 15 seconds. The superior performance of VRP is due to the use of a limited number of unicast messages to route acquisition, which makes buffer overflows relatively infrequent. When the frequency of buffer overflows increases (50 simultaneous CBR connections with units’ speed equals to 6m/s), the performance of VRP decreases, but the delivery ratio is still around 94%. Under the same traffic conditions, the delivery ratio of ZRP is around 90%. As seen in figures 5.48, 5.50, 5.51 and 5.52, VRP always outperforms ZRP with light traffic conditions (around 20 simultaneous CBR connections) . Also the performance of VRP is almost unaffected by increasing the mobility of the units. The mobility is increased by increasing the units’ velocity and by reducing the pause time. If the traffic conditions become heavier, figures 5.49 and 5.52, the units’ velocity becomes an important factor. If the units’ velocity is maintained small (the left part of figure 5.52), the performance of VRP always outperforms ZRP, and the

5.5. VRP compared with ZRP

169

performance of both protocols is almost unaffected by the increasing traffic conditions. When the velocity of the units increases (right part of figure 5.52), both protocol start to lose performance when increasing the traffic conditions. However, the performance of VRP is more affected by the increasing traffic conditions than the performance of ZRP, as shown in figure 5.49. Under heavy traffic conditions and with high units’ speed, figure 5.49, the performance of ZRP becomes better than the performance of VRP. This happens because in this extreme traffic conditions, scouts are not able to perform the low priority updates, thus the traffic is restricted to some units, which start to suffer from buffer overflows.

5.5.2

Route Acquisition Delay

The route acquisition delay is the time needed to the source to construct a route between itself and the desired destination. This delay occurs when source unit i wants to communicate with destination unit j at time t and unit i does not have a route to reach unit j. The route acquisition delay of VRP was reported in Section 5.4, where VRP was compared with DSR. These results are replicated in the left part of figures 5.53 to 5.59 to simplify the comparison with ZRP. The route acquisition delay of ZRP is reported in the right part of these figures. Note that the scale of the graphics are different, as the delay of ZRP is much smaller than the delay of VRP. It is important to point that, in ZRP, the delay to establish this route is an extremely small constant when the destination is inside the source’s routing zone. The reason is that the intrazone routing is a proactive routing protocol. The use of such proactive routing protocol contributes to reduce

170

Chapter 5. Simulation Results

VRP - Average delay to establish a route - 20 CBR connections

ZRP - Average delay to establish a route - 20 CBR connections

3500

70 VRP proactive setup VRP reactive setup

All routes Interzone routes only

60

2500

Time (miliseconds)

Time (miliseconds)

3000

2000 1500 1000 500

50 40 30 20 10

0

0 0

5

10

15

20

0

5

Units’ Velocity (m/s)

10

15

20

Units’ Velocity (m/s)

Figure 5.53: VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ speed for 20 simultaneous CBR connections. VRP - Average delay to establish a route - 40 CBR connections

ZRP - Average delay to establish a route - 40 CBR connections

60000

180 VRP proactive setup VRP reactive setup

50000

All routes Interzone routes only

160

Time (miliseconds)

Time (miliseconds)

140 40000 30000 20000

120 100 80 60 40

10000 20 0

0 0

5

10 Units’ Velocity (m/s)

15

20

0

5

10 Units’ Velocity (m/s)

15

20

Figure 5.54: VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ speed for 40 simultaneous CBR connections.

the route acquisition delay of ZRP. The graphics that report data for ZRP also compare the average delay when considering all routes with the average delay only for the interzone routing protocol. These two results are reported to illustrate the reduction in the route acquisition delay caused by the use of a proactive routing zone around the units. All simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. In figures 5.53 and 5.54, the velocity of the units goes from 0 to 20m/s. In figure

5.5. VRP compared with ZRP

171

VRP - Average delay to establish a route

ZRP - Average delay to establish a route

2000

25

1600

20

1400

Time (miliseconds)

Time (miliseconds)

All routes Interzone routes only

VRP proactive setup VRP reactive setup

1800

1200 1000 800 600 400

15

10

5

200 0

0 0

5

10

15

20

0

Units’ Velocity (m/s)

5

10

15

20

Units’ Velocity (m/s)

Figure 5.55: VRP(left) versus ZRP(right): Delay to build a route as a function of units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration.

5.53 the number of simultaneous CBR connections is 20, while in figure 5.54 if is 40. In both cases each CBR connection generates 2 messages per second and the duration of the connection is at most 15 seconds. In figure 5.55, the velocity of the units ranges from 0 to 20m/s. The number of simultaneous CBR connections is 20, each CBR connection generates 2 messages per second, and the maximum duration of each connection is 120 seconds. Figures 5.56 and 5.57 compare the delay to build a route in VRP and ZRP for different units’ pause time. The units’ velocity ranges from 5m/s to 20 m/s. The number of simultaneous CBR connections is 20 and each CBR connection generates 2 messages per second. Figure 5.56 depicts the delay for 5m/s and 10m/s, while figure 5.57 depicts the delay for 15m/s and 20m/s. Figures 5.58 and 5.59 compare the delay to build a route in VRP and ZRP for different traffic conditions. In these simulations the units’ velocity goes from 0m/s to 6 m/s. The number of simultaneous CBR connections ranges from 10 to 50. Each CBR connection generates 2 messages per second, and the duration of each CBR connection is 15 seconds.

172

Chapter 5. Simulation Results

VRP - Average delay to establish a route

ZRP - Average delay to establish a route

900

50 Vel = 5 Vel = 10

800

40 Time (miliseconds)

Time (miliseconds)

Interzone - Vel=5 Interzone - Vel=10 All routes - Vel=5 All routes - Vel=10

45

700 600 500 400 300

35 30 25 20 15

200

10

100

5

0

0 0

100

200

300

400

500

600

0

100

200

Units’ Velocity (m/s)

300

400

500

600

Units’ Velocity (m/s)

Figure 5.56: VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ pause time, for units’ velocity of 5m/s and 10m/s. VRP - Average delay to establish a route

ZRP - Average delay to establish a route

2000

80 Vel = 15 Vel = 20

1800 1600

Interzone - Vel=15 Interzone - Vel=20 All routes - Vel=15 All routes - Vel=20

70 Time (miliseconds)

Time (miliseconds)

60 1400 1200 1000 800 600

50 40 30 20

400

10

200 0

0 0

100

200 300 400 Units’ Velocity (m/s)

500

600

0

100

200

300 400 Units’ Velocity (m/s)

500

600

Figure 5.57: VRP(left) versus ZRP(right): Delay to build a route as a function of the units’ pause time, for units’ velocity of 15m/s and 20m/s.

As shown from figure 5.53 to figure 5.59, the delay of VRP is highly dependent of the units’ velocity, i.e., when the velocity increases, the delay of VRP also increases, while the delay of ZRP remains almost constant. The delay of VRP also increases when the traffic becomes heavier. Even tough the delay of ZRP also increases when the traffic becomes heavier, the difference between both protocols is huge. As seen from figure 5.53 to figure 5.58, the route acquisition delay of ZRP is very small. ZRP implements two techniques to reduce the route acquisition delay: (i) a proactive zone routing around each unit; (ii) multicast for the interzone routing protocol. The use of a proactive zone routing around each unit causes that when

5.5. VRP compared with ZRP

173

VRP - Average delay to establish a route

ZRP - Average delay to establish a route

700

40 Vel = 0 Vel = 2

Interzone - Vel=0 Interzone - Vel=2 All routes - Vel=0 All routes - Vel=2

35 30

500

Time (miliseconds)

Time (miliseconds)

600

400 300 200

25 20 15 10

100

5

0

0 10

15

20

25

30

35

40

45

50

10

15

20

Units’ Velocity (m/s)

25

30

35

40

45

50

Units’ Velocity (m/s)

Figure 5.58: VRP(left) versus ZRP(right): Delay as a function of the number of simultaneous CBR connections for units’ velocity of 0m/s and 2m/s. VRP - Average delay to establish a route

ZRP - Average delay to establish a route

25000

250 Vel = 4 Vel = 6

Interzone - Vel=4 Interzone - Vel=6 All routes - Vel=4 All routes - Vel=6

200 Time (miliseconds)

Time (miliseconds)

20000

15000

10000

5000

150

100

50

0

0 10

15

20

25 30 35 Units’ Velocity (m/s)

40

45

50

10

15

20

25 30 35 Units’ Velocity (m/s)

40

45

50

Figure 5.59: VRP(left) versus ZRP(right): Delay as a function of the number of simultaneous CBR connections for units’ velocity of 4m/s and 6m/s.

the destination is inside the source’s zone, the route acquisition delay is a very small constant. The price to be paid is that the proactive routing zone must be kept up-to-date, thus increasing the routing overhead. However, as it will be shown in Section 5.5.3, the overhead to maintain the proactive routing zones up-to-date is very small, and it slightly affects the performance of ZRP. Also, the use of such proactive zones makes possible to use multicast to establish routes to units that are outside the source’s zone. The use of multicast to establish such routes decreases the routing overhead, thus compensating the small overhead to maintain the proactive routes up-to-date.

174

Chapter 5. Simulation Results

To reduce the route acquisition delay of VRP, it is possible to implement a proactive zone routing around each unit. This proactive routing zone might reduce the size of the virtual paths, thus probably reducing the route acquisition delay. The price to be paid to implement this proactive zone routing around each unit is an increasing on the routing overhead of the routing protocol. However, this overhead is extremely small if the MAC protocol provides to the units information about their neighbors. For example, to maintain a proactive routing zone with radius equal to 2 and using a simple link-state routing as the proactive routing protocol, each unit sends at most one message in each update interval, furthermore these messages are local messages, i.e., they have Time To Live equal to 1. Besides, if a proactive routing zone is implemented in VRP, scouts can use multicast to scout updates instead of floodings. The use of multicast might reduce the routing overhead, consequently it might also reduce the buffer overflows, thus further increasing the delivery ratio. The use of a proactive routing zone and multicast for the scouts update are part of future work.

5.5.3

Normalized Routing Load

The normalized routing load is the number of routing messages transmissions per delivered data message. The number of routing messages transmissions consists in the number of single hop transmissions for all routing messages. Note that a single routing message can travel several hops before reaching its destination, and that all single hop transmissions are taken into account to measure the routing load. This Section contains a comparison between the routing load of VRP and ZRP. Two simulations results are presented for VRP: the left part of figures 5.60, 5.61, and 5.62 reports data of a protocol version with a proactive scout update on the

5.5. VRP compared with ZRP

175

Routing overhead per data message - VRP with proactive scouts setup

Routing overhead per data message - VRP without proactive scouts setup

9

12 VRP total VRP high priority VRP low priority ZRP

8

Hop Transmissions

Hop Transmissions

7

VRP total VRP high priority VRP low priority ZRP

10

6 5 4 3

8 6 4

2 2 1 0

0 0

5

10

15

20

Units’ Velocity (m/s)

0

5

10

15

20

Units’ Velocity (m/s)

Figure 5.60: VRP versus ZRP: Routing load as a function of the units’ speed with 20 simultaneous CBR connections. beginning of the simulation; while the right part of figures refers to a protocol version without this proactive scout setup. In figures 5.60, 5.61 and 5.62, the simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. Units’ velocity goes from 0m/s to 20 m/s, and the pause time is 0. In figures 5.60 and 5.62, the number of simultaneous CBR connections is 20, while in figure 5.61 it is 40. In all cases each CBR connection generates 2 messages per second. In figures 5.60 and 5.61 the duration of each CBR connection is 15 seconds, while in figure 5.62 the duration of each CBR connection is 120 seconds. As shown in figures 5.60, 5.61 and 5.62, ZRP almost always has a total overhead smaller than VRP. However, the overhead of VRP is composed by high and low priority messages. If only the high priority overhead is compared with the overhead of ZRP, under light traffic conditions (figures 5.60 and 5.62) VRP has, almost always, a smaller overhead. Under heavy traffic (figure 5.61) VRP has a smaller overhead when the velocity of the units is small. Figures 5.63 and 5.64 show the average routing load in both protocols for dif-

176

Chapter 5. Simulation Results

Routing overhead per data message - VRP with proactive scouts setup

Routing overhead per data message - VRP without proactive scouts setup

30

30 VRP total VRP high priority VRP low priority ZRP

VRP total VRP high priority VRP low priority ZRP

25 Hop Transmissions

Hop Transmissions

25 20 15 10

20 15 10

5

5

0

0 0

5

10

15

20

0

5

Units’ Velocity (m/s)

10

15

20

Units’ Velocity (m/s)

Figure 5.61: VRP versus ZRP: Routing Load as a function of the units’ speed with 40 simultaneous CBR connections. Routing overhead per data message - VRP with proactive scouts setup

Routing overhead per data message - VRP without proactive scouts setup

6

6 VRP total VRP high priority VRP low priority ZRP

VRP total VRP high priority VRP low priority ZRP

5 Hop Transmissions

Hop Transmissions

5 4 3 2 1

4 3 2 1

0

0 0

5

10

15

Units’ velocity (m/s)

20

0

5

10

15

20

Units’ velocity (m/s)

Figure 5.62: VRP versus ZRP: Routing Load as a function of the units’ speed with 20 simultaneous CBR connections of at most 120 seconds duration. ferent units’ pause time. These simulations were made in a network of 1000x1000 meters, with 75 units, and the transmission range of the units is 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 5m/s to 20 m/s. The number of simultaneous CBR connections is 20. Each CBR connection generates 2 messages per second, and the maximum duration of each connection is 15 seconds. Figure 5.63 depicts the routing load for units’ velocity of 5m/s(left) and 10m/s(right), while figure 5.64 depicts the routing load for 15m/s(left) and 20m/s(right). As shown in figures 5.63 and 5.64, the total routing overhead of ZRP is always

5.5. VRP compared with ZRP

177

Routing overhead per data message - Units’ velocity = 5m/s

Routing overhead per data message - Units’ velocity = 10m/s

4.5

6 VRP total VRP high priority VRP low priority ZRP

Hop Transmissions

3.5

VRP total VRP high priority VRP low priority ZRP

5 Hop Transmissions

4

3 2.5 2 1.5

4 3 2

1 1 0.5 0

0 0

100

200

300

400

500

600

0

100

Units’ pause time (seconds)

200

300

400

500

600

Units’ pause time (seconds)

Figure 5.63: VRP versus ZRP: Routing Load as a function of the units’ stop time for units’ velocities 5m/s and 10m/s. Routing overhead per data message - Units’ velocity = 15m/s

Routing overhead per data message - Units’ velocity = 20m/s

7

9 VRP total VRP high priority VRP low priority ZRP

5

VRP total VRP high priority VRP low priority ZRP

8 7 Hop Transmissions

Hop Transmissions

6

4 3 2

6 5 4 3 2

1

1

0

0 0

100

200 300 400 Units’ pause time (seconds)

500

600

0

100

200 300 400 Units’ pause time (seconds)

500

600

Figure 5.64: VRP versus ZRP: Routing Load as a function of the units’ stop time for units’ velocities 15m/s and 20m/s.

smaller than the total routing overhead of VRP. VRP outperforms ZRP only when the pause time is maximum, i.e., when the units remain paused during the whole simulation. However, recalling that the overhead of VRP is composed by high and low priority messages, if only the high priority overhead of VRP is compared with the overhead of ZRP, VRP always has a smaller overhead. Figures 5.65 and 5.66 show the routing load of both protocols for a different number of simultaneous CBR connections. These simulations were made in a network of 1000x1000 meters. The number of units in the network is 75, and their transmission range is fixed at 250 meters. The logical structure used is the RoR:

178

Chapter 5. Simulation Results

x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 6 m/s and the pause time is 0. The number of simultaneous CBR connections ranges from 10 to 50. Each CBR connection generates 2 messages per second, and the maximum duration of each CBR connection is 15 seconds. Figure 5.65 shows the routing load for 0m/s(left) and 2m/s(right), while figure 5.66 shows the routing load for 4m/s(left) and 6m/s(right). As shown in figures 5.65 and 5.66, the overhead of VRP is directly proportional to the units’ speed. With no mobility, left part of figure 5.65, the total overhead of VRP is less than half of the overhead of ZRP. However, when the velocity of the units increases, ZRP maintains its overhead almost constant, while the overhead of VRP increases with the velocity. With 2m/s and 4m/s, the right part of figure 5.65 and the left part of figure 5.66 respectively, the total overhead of VRP is smaller than the total overhead of ZRP when the number of connections is high, while ZRP shows some advantages when the number of connections is low. With 6m/s, the right part of figure 5.66, the total overhead of ZRP is always smaller than the total overhead of VRP. However, if only the high priority overhead of VRP is considered, VRP outperforms ZRP, in all cases. By figures 5.65 and 5.66, it is possible to notice that the overhead of VRP strongly depends on the units’ velocity. When the units are paused, the overhead of VRP is minimum. With increasing mobility of the units the overhead increases proportionally to the units’ velocity. Another interesting point of VRP is that its overhead decreases as the number of simultaneous connections increases, figures 5.65 and 5.66. This happens because the routes archived in the scouts are utilized for more connections, thus dividing the

5.5. VRP compared with ZRP

179

Routing overhead per data message - Units’ velocity = 0m/s

Routing overhead per data message - Units’ velocity = 2m/s

3

4 VRP total VRP high priority VRP low priority ZRP

VRP total VRP high priority VRP low priority ZRP

3.5 Hop Transmissions

Hop Transmissions

2.5 2 1.5 1

3 2.5 2 1.5

0.5

1

0

0.5 10

15

20

25

30

35

40

45

50

10

15

Number of simultaneous CBR connections

20

25

30

35

40

45

50

Number of simultaneous CBR connections

Figure 5.65: VRP versus ZRP: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 0m/s and 2m/s. Routing overhead per data message - Units’ velocity = 4m/s

Routing overhead per data message - Units’ velocity = 6m/s

5.5

8 VRP total VRP high priority VRP low priority ZRP

5

4

Hop Transmissions

Hop Transmissions

4.5

VRP total VRP high priority VRP low priority ZRP

7

3.5 3 2.5 2

6 5 4 3

1.5 2

1 0.5

1 10

15

20 25 30 35 40 Number of simultaneous CBR connections

45

50

10

15

20 25 30 35 40 Number of simultaneous CBR connections

45

50

Figure 5.66: VRP versus ZRP: Routing Load as a function of the number of simultaneous CBR connections for units’ velocities 4m/s and 6m/s.

costs to maintain these routes up-to-date. When the speed of the units increases, the routes archived in the scouts become broken more frequently, thus the scouts must perform scout updates more frequently, which increments the routing overhead: this can be noticed by comparing figures 5.65 and 5.66. However, when frequent scout updates and heavy traffic conditions (40 or 50 simultaneous CBR connections) are combined, VRP reaches a buffer saturation point, i.e., the buffer of the scouts with valid routes overflow, as shown in the right part of figure 5.66. In this case, the large number of data messages produced by increasing the CBR connections do not leave space to accommodate the increasing

180

Chapter 5. Simulation Results

Bandwidth Consumption per second by all units

Bandwidth Consumption per second by all units

4000 3500 3000

4000 VRP control VRP total ZRP control ZRP total

3500 3000 2500 Kb/s

Kb/s

2500

VRP control VRP total ZRP control ZRP total

2000

2000

1500

1500

1000

1000

500

500

0 80 Kb/s

160 Kb/s

240 Kb/s

320 Kb/s

0 80 Kb/s

400 Kb/s

160 Kb/s

Data load generated by the CBR sources

240 Kb/s

320 Kb/s

400 Kb/s

Data load generated by the CBR sources

Figure 5.67: VRP versus ZRP: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 0m/s and 2m/s. Bandwidth Consumption per second by all units

Bandwidth Consumption per second by all units

4000 3500 3000

4000 VRP control VRP total ZRP control ZRP total

3500 3000 2500 Kb/s

Kb/s

2500 2000

2000

1500

1500

1000

1000

500

500

0 80 Kb/s

VRP control VRP total ZRP control ZRP total

160 Kb/s 240 Kb/s 320 Kb/s Data load generated by the CBR sources

400 Kb/s

0 80 Kb/s

160 Kb/s 240 Kb/s 320 Kb/s Data load generated by the CBR sources

400 Kb/s

Figure 5.68: VRP versus ZRP: Network bandwidth utilization as a function of the data load generated by the CBR connections for units’ velocities 4m/s and 6m/s.

routing overhead. This situation is also noticed in the delivery ratio of VRP, as illustrated in figure 5.52. Figures 5.67 and 5.68 show the network bandwidth utilization for different traffic loads. The bandwidth utilization is the total bandwidth used by all units per second. These simulations were made in a network of 1000x1000 meters. The number of units in the network is 75, and their transmission range is fixed at 250 meters. The logical structure used is the RoR: x = 3, y = 25 and s = 5. The units’ velocity goes from 0m/s to 6 m/s and the pause time is 0. Figure 5.67 shows the routing load for units’ speed of 0m/s(left) and 2m/s(right), while figure 5.68 shows the routing load for

5.5. VRP compared with ZRP

181

units’ speed of 4m/s(left) and 6m/s(right). The number of simultaneous CBR connections ranges from 10 to 50, and each CBR connection generates 2 messages per second, and the maximum duration of each CBR connection is 15 seconds: with 10 connections, the sources generate a traffic of 80Kb/s; with 20 connections, the sources generate a traffic of 160Kb/s; with 30 connections, 240Kb/s; with 40 connections, 320Kb/s; with 50 connections, 400Kb/s. As shown in figures 5.67 and 5.68, the total bandwidth utilization of VRP is higher than the total bandwidth utilization of ZRP. One reason for the higher bandwidth utilization of VRP is that VRP does not forward data through the shortest route. In fact, as shown in figure 5.5, routes built by VRP are, in average, 1.5 times longer than the shortest route. If only the bandwidth utilization due to routing messages is considered, VRP uses less bandwidth than ZRP under light traffic conditions and small velocities, as shown in figures 5.67 and 5.68. When the traffic conditions become heavier and the units’ mobility increases, VRP consumes more bandwidth than ZRP. Furthermore, it should be recalled that a significant part of the traffic generated by VRP is due to low priority messages, which contributes much less to network congestion, as compared to high priority messages. If only high priority messages are considered, figures 5.60 and 5.66 show that the high priority traffic of VRP is almost always smaller than the overhead of ZRP, however this advantage can be lost under heavy traffic load conditions and high units velocities, as shown in figure 5.61.

182

Chapter 5. Simulation Results

Chapter 6 Conclusion and Future Work A new routing protocol for wireless ad hoc networks, called Virtual Routing Protocol (VRP ) has been presented in this thesis. VRP has been developed with the goal of providing reliable routing, defined as the ability to provide almost 100% data messages delivery ratio. To this purpose, VRP uses several strategies to reduce the network congestion arising from route acquisition and route maintenance, which are major causes of messages losses in most routing protocols, like DSR. Note that dynamic route acquisition and route maintenance are needed due to units’ mobility. The basic idea of VRP consists in defining a logical structure over the network. This structure is unrelated to the physical position of the units and it is unaffected by the units’ mobility. Every unit is responsible for maintaining physical routes to its neighbors in the logical structure. If unit u is a logical neighbor of unit v, it maintains a physical route to reach unit v from itself. Unit u is called a scout of v, while v is called a peered unit of u. The logical structure is a regular graph where each unit has a given degree, and there are multiple logical paths between any pair of units in the network. This allows the protocol to tolerate unit and link failures.

184

Chapter 6. Conclusion and Future Work

The degree of the fault tolerance depends on the degree of the logical structure, which is a parameter of the design. When unit i starts a communication with unit j and it does not have a route to unit j, it invokes the route acquisition phase of the protocol. This phase consists in establishing a virtual path from unit i to unit j, which does not require any exchange of messages. The virtual path is a path in the logical structure from the source to the destination, where each unit is a scout for the next unit and a peered unit of the previous one. The virtual path is then translated into a physical route, by chaining the physical routes stored by the scouts of the virtual path. The route translation is done by sending a unicast message along the virtual path, which collects the physical route from the scouts, thus building the route from the source to the destination. The translation of the virtual path into a physical route succeeds if the routes stored in the scouts are up-to-date. If not, the route acquisition and translation proceeds through an alternate virtual path from the farthest unit f that was reached along the original route, and a scout update process is invoked by the scout immediately upstream of unit f . This process is used by the scouts to update routes to their peered units, and it is based on flooding messages. Since this update is not urgent, the scout update proceeds in background, at the lowest priority level. In fact, VRP uses three priority levels for messages. Priorities are used internally by the units to decide the order in which messages should be sent. Flooding messages needed for the scout update are dispatched in the lowest priority. High priority floodings are used by the source for the purpose of route acquisition only if the route translation results in failures for all available virtual paths, or the maximum allowed number of virtual paths is reached. Except for this sporadic situation, high priority is reserved to unicast messages. Conversely, in most routing protocols, such

185

as [47, 76], flooding messages need to be dispatched with maximum priority. The above presented features of VRP contribute to reduce the network congestion, and consequently, to reduce the message losses due to buffer overflows. VRP has been evaluated and compared with the Dynamic Source Routing protocol (DSR) and with the Zone Routing Protocol (ZRP) by means of simulation. The simulator, which was built for this specific purpose, relies on a relatively simple model of the link layer protocols, although it allows accurate and efficient evaluation of the upper protocols and the units’ mobility. The simulator was validated by comparing its output with the output of the well known NS-2 [27] for some scenarios and traffic conditions. In the simulator, the network always covers a square field area of sides ranging from 1000 to 2000 meters. The units’ transmission range goes from 200 to 500 meters and the number of units varies from 75 to 200 units. Units’ speed is uniformly distributed between 0 and 20 m/s. The pause time, which is the time elapsed between the arrival of the unit at its destination point and the departure towards a new location in the network, goes from 0 to 600 seconds. Traffic is modelled as a number of randomly selected source/destination units. Sources generate a Constant Bit Rate (CBR) traffic. The number of simultaneous CBR connections ranges from 10 to 50. Each CBR connection generates 2 or 10 messages per seconds, and the maximum duration of each CBR connections is either 15 or 120 seconds. Results reported in this dissertation are for 600 simulated seconds, and each data represents an average of at least five runs with identical traffic models, but different randomly generated scenarios. The buffer of the units is always set to 300 messages in all simulation experiments. It was found that under light traffic conditions the average delivery ratio of VRP

186

Chapter 6. Conclusion and Future Work

is always above 95% and it is almost unaffected by increasing units’ mobility. The mobility of the units has been increased both by increasing the unit’s speed and by reducing the pause time. Under heavy traffic conditions, the average delivery ratio is never below 75%, and the negative influence of increasing mobility is moderate. With the same simulation model and under the same scenarios, the delivery ratio of DSR is about 70% under light traffic conditions and about 50% under heavy traffic conditions. Under both traffic conditions, the performance of DSR highly depends on the units’ mobility: the delivery ratio of DSR significantly decreases as the mobility of the units increases even for light traffic conditions. When the units’ velocity is set to 1m/s, VRP maintains a stable delivery ratio of more than 98% of the generated data messages, independently of the number of units present in the network, while DSR loses performance with increasing number of units. For a network of 200 units, VRP delivers more than 98% of the generated data message, while DSR delivers about 75%. Increasing the transmission range of the units, the network connectivity is increased, and the diameter of the network is decreased. Due to the limited use of floodings, which avoids buffer overflows, VRP is able to keep the delivery ratio high even for highly connected networks. For 500 meters of transmission range, VRP delivers almost 100% of the generated data messages, while DSR delivers about 70%. The poorer performance of DSR is due to frequent invocation of the route acquisition phase of the protocol, caused by relatively short duration of CBR connections. As DSR relies on floodings for route acquisition, the occurrence of buffer overflows is quite frequent. In general, it was found that the poorer performance of DSR derives from a much higher frequency of buffer overflows due to network congestion. Congestion

187

is caused by floodings used for route acquisitions. This was verified by increasing the buffer size on DSR from 300 to 1000 messages. With the increased size of the buffer, the delivery ratio of DSR under heavy traffic conditions goes from 50% to more than 97% of the generated data messages. Under light traffic conditions, VRP also outperforms ZRP. The delivery ratio of VRP is above 95%, while the delivery ratio of ZRP is around 82% of the generated data messages. However, under heavy traffic conditions, the negative influence of increasing speed is noticed by VRP, even though the delivery ratio is never below 75% of the generated data message. Under the same traffic conditions and with high mobility, ZRP performs better than VRP. The performance of ZRP remains around 80% of the generated data messages. With heavy traffic conditions and high units’ velocities, VRP starts to lose messages due to buffer overflows. This happens because scouts start to have lots of their archived routes broken. To update their archived routes, scouts must perform low priority floodings. As these floodings have a low priority, they are delayed, and thus these scouts remain longer with broken routes to their respective peered units. This causes that lots of messages are forwarded by the few scouts that have valid routes, thus saturating these units, causing their buffers to overflow. Another advantage of VRP is the small size of the routing tables, as units maintain routes only to their peered units and to the units to which they are currently sending messages. Using the virtual routing protocol, units maintain O(k) routes in their routing tables, where k is the number of peered units of each unit, while in other routing protocols, such as the DSR [47] and ZRP [36], units maintain O(N ) routes in their routing table, where N is the number of units in the system. The excellent delivery ratio of VRP is counterbalanced by an increased commu-

188

Chapter 6. Conclusion and Future Work

nication latency, i.e., the delay to establish routes between sources and destinations. In comparison with DSR and ZRP, the average latency of VRP is always higher. This happens because the route acquisition phase of VRP, in the attempts to avoid floodings, may set several virtual paths, before succeeding in translating one of them into a physical route from the source to the destination. While this technique avoids global overloading, and consequently buffer overflows, it increases the number of unicast messages needed for route translation, which contribute to longer route acquisition delays. Future work includes the further development and optimization of VRP, studies to reduce its route acquisition delay and routing overhead. It also includes the design of a VRP version for power aware routing and the study of some security issues under VRP. To reduce the route acquisition delay, it is possible to borrow some techniques used in ZRP [36]. It is possible to implement a proactive zone route around each unit of the system. In fact, VRP already implements such zone as units must be aware of their neighbors, this can be viewed as a proactive zone route of radius equal to 1. Having this zone with a larger radius might reduce the route acquisition delay considerably, by reducing the size of the virtual paths. As it was evidenced by the simulation of ZRP, the overhead to update the proactive zone is relatively small. Some of the improvements proposed in Chapter 4.6, such as Shortcuts in Virtual Path Translation, can also contribute to reduce the route acquisition delay. To reduce the routing overhead, it is possible to implement the scouts update using multicast messages instead of floodings. This development is also borrowed from ZRP, and it is related with the use of a larger proactive zone routing around each unit. When the proactive zone of the units is equal to 1, the scouts update with

189

multicast is exactly the same as doing the scouts update through flooding. Also, it is possible to perform the scouts update based on received messages, the Scout Update over Received Messages improvement. It might also be possible to design a version of VRP for power aware routing. In this version each link in the logical structure would be assigned a weight. The weight of each link is equal to the minimum of the power reserve of the units that are part of the logical link. Scouts can collect the weight of the links to their peered units during the scout update phase of the protocol. If a unit knows the weight of all links of the logical structure, this unit can choose the virtual path with the highest weight that connects itself with the destination to send its messages. It it is not feasible to maintain the logical structure weights up-to-date in all units, the power aware strategy could be distributed: each virtual hop decides which will be the next virtual hop based on its local information, and sends the message to this unit. This choice is based on the weight of the logical structure that this unit knows. When the next virtual hop receives the message, it repeats the process. The virtual routing protocol might also incorporate some security issues against passive attackers without many changes in the protocol. To protect routing information and data traffic from passive attacks, a cryptography scheme should be used. The use of such a scheme requires a key management service. Assuming a public key scheme, VRP requires that a unit must keep only the public key of its scouts and peered units, instead of keeping the public key of all units in the network. Future work also includes the analysis of scalability with different logical structures and also the analysis and specification of the ‘reshuffle” property of the Ring of Rings logical structure. It also includes extensive comparison with other reactive and hybrid routing protocols, such as AODV [76], CARD [39] and SHARP [81].

190

Chapter 6. Conclusion and Future Work

Evaluation of VRP should also be performed with NS-2 [27] or GloMoSim [103] simulators, to the purpose of a more accurate analysis of issues related with link layer protocols.

Bibliography [1] S. Agarwal, A. Ahuja, J.P. Singh, and R. Shorey, “Route-Lifetime Assessment Based Routing (RABR) Protocol for Mobile Ad-Hoc Networks,” Proc. IEEE International Conference on Communications (ICC 2000), pp. 1697-1701, 2000. [2] G. Aggelou, and R. Tafazolli, “RDMAR: A Bandwidth-Efficient Routing Protocol for Mobile Ad Hoc Networks,” Proc. ACM International Workshop on Wireless Mobile Multimedia (WoWMoM 1999), pp. 26-33, 1999. [3] L.C.P. Albini, A. Caruso, S. Chessa, and P. Maestrini, “Reliable Routing in Wireless Ad Hoc Networks,” Submitted to The First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services (MobiQuitous 2004), 2004 [4] L. Anderegg, and S. Eidenbenz, “Ad hoc-VCG: A Truthful and Cost-Efficient Routing Protocol for Mobile Ad hoc Networks with Selfish Agents,” Proc. ACM International Conference on Mobile Computing and Networking (MobiCom 2003), pp. 245-259, 2003. [5] L. Bao, and J.J. Garcia-Luna-Aceves, “Topology Management in Ad Hoc Networks,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2003), pp.129-139, 2003. [6] S. Basagni, I. Chlamtac, V.R. Syrotiuk, and B.A. Woodward, “A Distance Routing Effect Algorithm for Mobility (DREAM),” Proc. ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom 1998), pp. 76-84, 1998. [7] D. Bertsekas, and R. Gallager, Data Networks, Prentice Hall, 1987. [8] L. Blazevic, S. Giordano, and J.Y. Le Boudec, “Self Organized Terminode Routing Simulation,” Proc. International Workshop on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM 2001), pp. 81-88, 2001. [9] L. Blazevic, S. Giordano, and J.Y. Le Boudec, “Self Organized Terminode Routing,” Tech. Report DSC/2001/024 - Swiss Federal Institute of Technology - Lausanne - Swiss, 2001.

192

Chapter 6. Bibliography

[10] D.M. Blough, M. Leoncini, G. Resta, and P. Santi, “The k-Neigh Protocol for Symmetric Topology Control in Ad Hoc Networks,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2003), pp. 141-152, 2003. [11] J. Boleng, “Efficient network layer addressing for mobile ad hoc networks,” Tech. Report MCS-00-09 - The Colorado School of Mines, 2000. [12] L. Bononi, M. Conti, and L. Donatiello, “A Distributed Mechanism for Power Saving in IEEE 802.11 Wireless LANs,” Mobile Networks and Applications, vol. 6, no. 3, pp. 211-222, 2001. [13] P. Bose, P. Morin, I. Stojmenovic, and J. Urrutia, “Routing with guaranteed delivery in ad hoc wireless networks,” Workshop on Discrete Algorithms and Methods for Mobile Computing and Communications (DialM ’99), 1999. [14] F. Cali, M. Conti, and E. Gregori, “IEEE 802.11 wireless LAN: Capacity analisys and protocol enhancement,” Proc. INFOCOM 1998, pp. 142-149, 1998. [15] J.I. Capetanakis, “Tree Algorithm for Packet Broadcast Channels,” IEEE Transactions on Information Theory, vol. 25, no. 5, pp. 505-515, 1979. [16] B. Chen, K. Jamieson, H. Balakrishnan, and R. Morris, “Span: An EnergyEfficient Coordination Algorithm for Topology Maintenance in Ad Hoc Wireless Networks,” Proc. ACM International Conference on Mobile Computing and Networking (MobiCom 2001), pp. 85-96, 2001. [17] S. Chen, and K. Nahrstedt, “Distributed Quality-of-Service Routing in Ad-Hoc Networks,” IEEE Journal on Selected Areas in Communications, vol. 17, no. 8, pp. 1-19, 1999. [18] T.W. Chen, and M. Gerla, “Global State Routing: A New Routing Scheme for Ad-hoc Wireless Networks,” Proc. of the IEEE International Conference on Communications (ICC 1998), pp. 171-175, 1998. [19] S. Cheshire, and B. Adohe, “Dynamic configuration IPv4 link-local addresses,” Internet DRAFT, 2001. [20] C.-C. Chiang, H.-K. Wu, W. Liu, and M. Gerla, ”Routing in Clustered Multihop, Mobile Wireless Networks with Fading Channel,” Proc. IEEE Singapore International Conference on Networks 97 (SICON), pp. 197-211, 1997. [21] M.S. Corson, and A. Ephremides, “A Distributed Routing Algorithm for Mobile Wireless Networks,” ACM/Baltzer Wireless Networks, vol. 1, no. 1, pp. 61-81, 1995.

6.0. Bibliography

193

[22] S. De, S.K. Das, H. Wu, and C. Qiao, “Trigger-Based Distributed QoS Routing in Mobile Ad Hoc Networks,” Mobile Computing and Communications Review, vol. 6, no. 3, pp. 22-35, 2002. [23] T. Dierks, and C. Allen, “The TLS protocol version 1.0” RFC 2246, 1999. [24] R.C. Dixon, and D.A. Pitt, “Addressing, bridging, and source routing,” IEEE Network, vol. 2, no. 1, pp. 25-32, 1988. [25] R. Dube, C.D. Rais, K.Y. Wang, and S.K. Tripathi, “Signal Stability-Based Adaptive Routing (SSA) for Ad Hoc Mobile Networks,” IEEE Personal Communications Magazine, vol. 4, no. 1, pp. 36-45, 1997. [26] A. Ephremides, J.E. Wieselthier, and D.J. Baker, “A Design Concept for Reliable Mobile Radio Networks with Frequency Hopping Signaling,” Proc. IEEE,, vol. 75, no. 1, pp. 56-73, 1987. [27] K. Fall, and K. Varadhan, “NS notes and documentation,” Available from http://www-mash.cs.berkeley.edu/ns/, 1999. [28] L.M. Feeney, and M. Nilsson, “Investigating the Energy Consumption of Wireless Network Interface in an Ad Hoc Networking Environment,” Proc. IEEE Conference on Computer Communications (INFOCOM 2001), 2001. [29] Y. Fernandess, and D. Malkhi, “K-Clustering in Wireless Ad Hoc Networks,” Proc. POMC 2002, pp. 31-37, 2002. [30] J.J. Garcia-Luna-Aceves, “A Unified Aprroach to Loop-Free Routing using Distance Vectors or Link States,” Proc. ACM SIGCOMM 89, pp. 212-233, 1989. [31] J.J. Garcia-Luna-Aceves, and M. Spohn, “Scalable Link-State Internet Routing,” Proc. of the IEEE International Conference on Network Protocol (ICNP 1998), pp. 52-61, 1998. [32] J.J. Garcia-Luna-Aceves, and M. Spohn, “Source-Tree Routing in Wireless Networks,” Proc. of the IEEE International Conference on Network Protocol (ICNP 1999), pp. 273-282, 1999. [33] M. Garey, and D. Johnson, Computers and Intractability: A Guide to the Theory of NP-Completeness, W.H. Freeman and Co., 1979. [34] M.S. Gast, 802.11 Wireless Networks - The Definitive Guide, O’Reilly, 2002. [35] M. Gerla, and J.T.-C. Tsai, ”Multicluster, Mobile Multimedia Radio Networks,” Wireless Networks, vol. 1, pp. 255-265, 1995.

194

Chapter 6. Bibliography

[36] Z.J. Haas, and M.R. Pearlman, “The Performance of Query Control Schemes for the Zone Routing Protocol,” IEEE/ACM Transactions on Networking, vol. 09, no. 4, pp. 427-438, 2001. [37] Z.J. Haas, M.R. Pearlman, and P. Samar, “The Zone Routing Protocol (ZRP) for Ad Hoc Networks,” IETF Internet DRAFT - version 4. [38] A. Helmy, “Small Worlds in Wireless Network,” IEEE Communications Letters, vol. 7, no. 10, pp. 490-492, 2003. [39] A. Helmy, S. Garg, P. Pamu, and N. Nahata, “Contact based architecture for resource discovery (CARD) in large scale MANets,” Proc. IEEE/ACM Int. Parallel and Distributed Processing Symp. (IPDPS 2003), pp. 219-227, 2003. [40] Y.C. Hu, A. Perrig, and D.B. Johnson, “Ariadne: A Secure On-Demand Routing Protocol for Ad Hoc Networks,” Proc. ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom 2002), pp. 12-23, 2002. [41] IEEE 802.11 WG, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specification, August 1999. [42] IEEE 802.11a WG, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specification: High-speed Physical Layer Extension at the 5 GHz Band, September 1999. [43] IEEE 802.11b WG, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specification: High-speed Physical Layer Extension in 2.4 GHz Band, September 1999. [44] IEEE 802.11e/D4.0, Draft Supplement to Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Medium Access Control (MAC) Enhancements for Quality of Service (QoS), November 2002. [45] J.M. Jaffe, and F.H. Moss, “A Responsive Distributed Routing Algorithm for Computer Networks,” IEEE Transactions on Communications, vol. 30, no. 7 pp. 1758-1762, 1982. [46] D.B. Johnson, and D.A. Maltz, “The Dynamic Source Routing Protocol for Mobile Ad Hoc Netwoks,” IETF Internet DRAFT - version 9. [47] D.B. Johnson, and D.A. Maltz, “Dynamic Source Routing in Ad Hoc Wireless Netwoks,” Mobile Computing - Chapter 5, Kluwer Academic Press, pp. 153-181, 1996. [48] C.E. Jones, K.M. Sivalingam, P. Agrawal, and J.C. Chen, “A Survey of Energy Efficient Network Protocols for Wireless Networks,” Wireless Networks, vol. 7, pp. 343-358, 2001.

6.0. Bibliography

195

[49] M.F. Kaashoek, R. van Renessa, H. van Staveren, and A.S. Tanenbaum, “FLIP: An internetwork protocol for supporting distributed systems,” ACM Transactions on Computer Systems, vol. 11, no. 1, pp. 73-106, 1993. [50] E.D. Kaplan, Understanding the GPS: Principles and Applications, Artech House, 1996. [51] B. Karp, and H.T. Kung, “GPSR: Greedy Perimeter Stateless for Wireless Networks,” Proc. ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom 2000), pp. 243-254, 2000. [52] V. Kawadia, and P.R. Kumar, “Power Control and Clustering in Ad Hoc Networks,” Proc. IEEE INFOCOM 2003, 2003. [53] S. Kent, and R. Atkinson, “Secutity Architecture for the Internet Protocol,” RFC 2401, 1998. [54] Y.B. Ko, and N.H. Vaidya, “Location-Aided Routing (LAR) in mobile ad hoc networks,” Wireless Networks, vol. 06, pp. 307-321, 2000. [55] P. Krishna, N. Vaidya, M. Chatterjee, and D. Pradhan, “A Cluster-based Approach for Routing in Dynamic Networks,” Computer Communication Review, vol. 27, no. 2, pp. 49-65, 1997. [56] F. Kuhn, R. Wattenhofer, Y. Zhang, and A. Zollinger, “Geometric Ad-Hoc Routing: Of Theory and Practice,” Principles of Distributed Computing, 2003. [57] B. Kumar, “Integration of Security in Network Routing Protocols,” SIGSAC Review, vol. 11, no. 2, pp. 18-25, 1993. [58] S.J. Lee, W. Su, and M. Gerla, “On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks,” ACM Mobile Networks and Applications, vol. 7, pp. 441-453, 2002. [59] N. Li, J.C. Hou, and L. Sha, “Design and Analysis of an MST-Based Topology Control Algorithm,” Proc. IEEE Conference on Computer Communications (INFOCOM 2003), 2003. [60] Q. Li, J. Aslam, and D. Rus, “Online Power-aware Routing in Wireless Ad-hoc Networks,” ACM SIGMOBILE 01, pp. 97-107, 2001. [61] X.Y. Li, P.J. Wan, Y. Wang, and C.W. Yi, “Fault Tolerant Deployment and Topology Control in Wireless Networks,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2003), pp. 117-128, 2003.

196

Chapter 6. Bibliography

[62] C.R. Lin, and M. Gerla, “Adaptive Clustering for Mobile Wireless Networks,” IEEE Journal on Selected Areas in Communications, vol. 15, no. 7, pp. 12651275, 1997. [63] C.R. Lin, and J.S. Liu, “QoS Routing in Wireless Ad Hoc Networks,” IEEE Journal on Selected Areas in Communications, special issue on Wireless Ad Hoc Networks, vol. 17, no. 8, pp. 1426-1438, 1999. [64] D.A. Maltz, J. Broch, J. Jetcheva, and D.B. Johnson, “The Effects of OnDemand Behavior in Routing Protocols for Multihop Wireless Ad Hoc Networks,” IEEE Journal on Selected Areas in Communications, special issue on Wireless Ad Hoc Networks, vol. 17, no. 8, pp. 1439-1453, 1999. [65] S. Mangold, S. Choi, P. May, O. Klein, G. Hietz, and L. Stibor, “IEEE 802.11e Wireless LAN for Quality of Service,” Proc. European Wireless 2002, 2002. [66] J.M. McQuillan, I. Richer, and E.C. Rosen, “The new routing algorithm for the ARPANET,” IEEE Transactions on Communications, vol. 28, no. 5, pp. 711-719, 1980. [67] P.M. Merlin, and A. Segall, “A Failsafe Distributed Routing Protocol,” IEEE Transactions on Communications, vol. 27, no. 9 pp. 1280-1287, 1979. [68] S. Murthy, and J.J. Garcia-Luna-Aceves, “An Efficient Routing Protocol for Wireless Networks,” ACM/Baltzer Mobile Networks and Applications, special issue on Routing in Mobile Communications Networks, vol. 1, no. 2, pp. 183197, 1996. [69] T. Narten, E. Nordmark, and W.A. Simpson, “Neighbor Discovery for IP Version 6 (IPv6),” RFC 2461, 1998. [70] S. Nesargi, and P. Prakash, “MANETconf: Configuration of hosts in a mobile ad hoc network,” Proc. IEEE Conference on Computer Communications (INFOCOM 2002), 2002. [71] V.D. Park, and D.S. Corson, “A Highly Adaptive Distributed Routing Algorithm for Mobile Wireless Networks,” Proc. IEEE Conference on Computer Communications (INFOCOM 1997), pp. 1405-1413, 1997. [72] G. Pei, M. Gerla, and T.W. Chen, “Fisheye State Routing: A Routing Scheme for Ad Hoc Wireless Networks,” Proc. IEEE International Conference on Communications (ICC 2000), pp.70-74, 2000. [73] G. Pei, M. Gerla, and X. Hong, “LANMAR: Landmark Routing for Large Scale Wireless Ad Hoc Networks with Group Mobility,” Proc. ACM/IEEE Workshop on Mobile Ad Hoc Networking and Computing (MobiHoc 2000), pp. 11-18, 2000.

6.0. Bibliography

197

[74] C.E. Perkings, Ad Hoc Networking, Addison-Wesley, 2001. [75] C.E. Perkins, and P. Bhagwat, “Highly Dynamic Destination-Sequenced Distance-Vector Routing (DSDV) for Mobile Computers,” Proc. ACM SIGCOMM 1994, pp. 234-244, 1994. [76] C.E. Perkins, and E.M. Royer, “Ad-hoc On-Demand Distance Vector (AODV) Routing,” Proc. IEEE Workshop on Mobile Computing Systems and Applications (WMCSA 1999), pp. 90-100, 1999. [77] C.E. Perkings, E.M. Royer, and S.R. Das, “IP address autoconfiguration for ad hoc networks,” Internet DRAFT - IETF Working Group MANET, 2000. [78] C.E. Perkings, E.M. Royer, S.R. Das, and M.K. Marina, “Performance Comparison of Two On-Demand Routing Protocols for Ad Hoc Networks,” IEEE Personal Communications, pp. 16-28, 2001. [79] F.P. Preparata, and J. Vuillemin, “The Cube-Connected Cycles: A Versatile Network for Parallel Computation,” Communication of the ACM, vol. 24, no.5, pp. 300-309, 1981. [80] M.B. Pursley, and H.B. Russell, “Routing in Frequency-Hop Packet Radio Networks with Partial-Band Jamming,” IEEE Transactions on Communications, vol. 41, no. 7, pp. 1117-1124, 1993. [81] V. Ramasubramanian, Z.J. Haas, and E.G. Sirer, “SHARP: A Hybrid Adaptive Routing Protocol for Mobile Ad Hoc Networks,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2003), pp. 303-314, 2003. [82] A. Rao, S. Ratnasamy, C. Papadimitriou, A. Shenker, and I. Stoica, “Geographical Routing without Location Information,” Proc. ACM International Conference on Mobile Computing and Networking (Mobicom 2003), pp. 96-108, 2003. [83] E.M. Royer, and C. Toh, “A Review of Current Routing Protocols for AdHoc Mobile Wireless Networks,” IEEE Personal Communication Magazine, pp. 46-55, 1999. [84] E.M. Royer, “Multi-Level Hierarchies for Scalable Ad Hoc Routing,” Wireless Networks, pp. 461-478, 2003. [85] Y.E. Sagduyu, and A. Ephremides, “Energy-Efficient Collisions Resolution in Wireless Ad-Hoc Networks,” Proc. IEEE Conference on Computer Communications (INFOCOM 2003), 2003.

198

Chapter 6. Bibliography

[86] P. Santi, D.M. Blough, and F. Vainstein, “A Probabilistic Analysis for the Range Assignment Problem in Ad Hoc Networks,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), pp. 212-220, 2001. [87] C. Schurgers, G. Kulkarni, and M.B. Srivastava, “Distributed assigment of encoded MAC addresses in sensor networks,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2001), 2001. [88] Y. Shang, W. Ruml, Y. Zhang, and M.P.J. Fromherz, “Localization from Mere Connectivity,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 2003), pp. 201-212, 2003. [89] A.U. Shankar, C. Alaettinoglu, I. Matta, and K.D. Zieger, “Performance Comparison of Routing Protocols using MaRS: Distance-Vector versus Link-State,” ACM Sigmetrics and Performance, vol. 20, no. 1, pp. 181-192, 1992. [90] J. Sharony, “An Architecture for Mobile Radio Networks with Dynamically Changing Topology using Virtual Subnets,” Mob. Netw. Appl., vol. 1, no. 1, pp. 75-86, 1996. [91] S. Singh, M. Woo, and C.S. Raghavendra, “Power-Aware Routing in Mobile Ad Hoc Networks,” Proc. ACM/IEEE International Conference on Mobile Computing and Networking (MobiCom 1998), pp. 181-190, 1998. [92] A. Srinivas, and E. Modiano, “Minimum Energy Disjoint Path Routing in Wireless Ad-hoc Networks,” Proc. ACM International Conference on Mobile Computing and Networking (MobiCom 2003), pp. 122-133, 2003. [93] F. Stajano, and R. Anderson, “The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks,” Proc. International Workshop on Security Protocols, 1999. [94] I. Stojmenovic, “Position-Based Routing in Ad Hoc Networks,” IEEE Communications Magazine, vol. 40, no. 7, pp. 02-08, 2002. [95] H. Sullivan, and T.R. Bashkow, “A Large Scale Homogeneous, Fully Distributed Parallel Machine,” Proc. Fourth Symposium on Computer Architecture, pp. 105117, 1977. [96] C.K. Toh, Ad Hoc Mobile Wireless Networks - Protocols and Systems, Prentice Hall PTR, 2002. [97] Y.C. Tseng, T.H. Li, S.K.S. Gupta, and D.K. Panda, “Bandwidth-Optimal Complete Exchange on Wormhole-Routed 2D/Torus Networks: A DiagonalPropagation Approach,” IEEE Transactions on Parallel and Distributed Systems, vol. 8, no. 4, pp. 380-396, 1997.

6.0. Bibliography

199

[98] N.H. Vaidya , “Weak Duplicate Address Detection in Mobile Ad Hoc Networks,” Proc. ACM International Symposium on Mobile Ad Hoc Networking and Computing (MobiHoc 02), pp. 206-212, 2002. [99] I.M. Vinogradov, An Introduction to the Theory of Numbers, Pergamon Press, 1955. [100] D.J. Watts, Small Worlds, Princeton University Press, 1999. [101] F. Wang, B. Vetter, and S. Wu, “Secure Routing Protocols: Theory and Practice,” North Carolina State University, 1997. [102] M.G. Zapata, and N. Asoken, “Securing Ad hoc Routing Protocols,” Proc. WiSe 2002, pp. 1-10, 2002. [103] X. Zeng, R. Bagrodia, and M. Gerla, “GloMoSim: a Library for Parallel Simulation of Large-scale Wireless Networks,” Proc. 12th Workshop on Parallel and Distributed Simulations (PADS 1998), 1998.

200

Chapter 6. Bibliography

Appendix A Algorithms in Pseudo-Code Algorithm A.1 Procedure LoopFree. Algorithm at unit k: Input: Received RTRANS, i /*source*/, j /*destination*/ 01 R = physical route of the RTRANS; 02 R′ = Shortest route in R from i to j; 03 return R′ ;

Algorithm A.2 Procedure Scouts Update Algorithm at unit k: Input: α /*special character, indicates multiple destinations RREQ*/ 01 Create RREQ message with destination field = α 02 Broadcast the RREQ;

202

Appendix A. Algorithms in Pseudo-Code

Algorithm A.3 Procedure Detour. Algorithm at unit k: Input: Received RTRANS, j /*destination*/, Nk , L 01 If (number of detour of RTRANS −1 > 0) 02 V H = virtual hops already passed by the RTRANS; 03 L′ = L − V H; 04 Compute Tj using new L′ ; 05 V P ′ = path in Tj from (k or l ∈ Nk ) to j; /* The path from k to the first unit in V P ′ must not contain the broken link */ 06 Repeat 07 If (k has a route to the first unit in V P ′ ) 08 Substitute the non valid part of the virtual path with V P ′ ; 09 Substitute the non valid physical route with the route to the next virtual hop; 10 Else 11 Compute another V P ′ over Tj ; 12 Until (find a valid detour or no more paths are available on Tj ); 13 If (a valid detour were found) 14 Create RERR message to the last scout through which the RTRANS has passed; 15 Send the RTRANS to the next unit in the new RTRANS route; 16 Send the RERR to the next unit in the RERR route; 17 Else 18 Create RERR message to the source of the RTRANS; 19 Send the RERR to the last scout through which the RTRANS has passed; 20 Else 21 Create RERR message to the source of the RTRANS; 22 Send the RERR to the last scout through which the RTRANS has passed;

203

Algorithm A.4 Algorithm used by the source on the Route Acquisition phase. Algorithm at unit i (source): Input: j /*destination*/, Ni , L Virtual Path Setup: 01 Compute Tj until find (i or k ∈ Ni ); 02 V P = path in Tj from (i or k ∈ Ni ) to j; 03 Put V P in RTRANS; Route Setup: 04 Put route from i to V P1 in RTRANS; 05 Send RTRANS to the first unit in the RTRANS route;

Algorithm A.5 Algorithm used when a unit receives a RTRANS. Algorithm at unit k: Input: Received RTRANS, Nk , L, i /*source*/, j /*destination*/ 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20

If (k = j) R = physical route of the RTRANS; R′ = Procedure LoopFree(R); Create RREP to i; Send RREP to i through R′ ; Else If (j ∈ Nk ) Send RTRANS to j; Else If (k is the last unit in the RTRANS route and k ∈ V P of RTRANS) If (k has a route to the next virtual hop) Append in the RTRANS route the path to the next virtual hop; Send the RTRANS to the next unit in the RTRANS route; Else Call Procedure Detour(RTRANS, j, Nk , L); Else If (next unit in the RTRANS route ∈ Nk ) Send RTRANS to next unit in the RTRANS route; Else Call Procedure Detour(RTRANS, j, Nk , L);

204

Appendix A. Algorithms in Pseudo-Code

Algorithm A.6 Algorithm used by the last scout when it receives a RERR. Algorithm at unit k: Input: Received RERR, j /*destination of the RERR*/ 01 next vh = next unit in the virtual hop; 02 Call Procedure Scouts Update(next vh); 03 If (k 6= j); 04 R = physical route of the RTRANS; 05 R′ = Procedure LoopFree(R); 06 Substitute the route of the RERR to R′ ; 07 Send the RERR to the next unit in the physical route;

Algorithm A.7 Algorithm used when the RERR reaches the source of the RTRANS. Algorithm at unit i: Input: j /*destination*/, Ni , L 01 If (a virtual path is available from i to j and the maximum allowed virtual paths attempts were not reach) 02 Repeat algorithm A.4; 03 Else 04 Create a RREQ message to find a route from i to j; 05 Broadcast the RREQ;

205

Algorithm A.8 Algorithm used when a unit receives a RREQ. Algorithm at unit k: Input: received RREQ, i /*source of the RREQ*/, j /*destination*/, L, α /*special character, indicates multiple destinations RREQ*/ 01 If (k already received this RREQ) 02 Drop the RREQ; 03 Else 04 If (k = j) 05 Create RREP i; 06 Send the RREP through the route collected by the RREQ; 07 Else 08 If (j = α and j is a scout to i in L) 09 Create RREP to i; 10 Send the RREP through the route collected by the RREQ; 11 Appends k on the route of the RREQ; 12 Broadcast the RREQ;

Algorithm A.9 Algorithm used when a unit receives a RREP. Algorithm at unit k: Input: received RREP, i /*source of the RREP */, j /*destination of the RREP */, Nk 01 If (k = j) 02 Archive the route from j to i; 03 Else 04 If (the next unit in the physical route ∈ Nk ); 05 Send the RREP to the next unit in the physical route; 06 Else 07 Drop the message;